アプリケーションの移行について

通常、管理者は、設定済みの MASTER マシンで日常的な管理タスクを行います。MASTER マシン上の DBBL は、コンフィギュレーション内のほかのマシンを監視し、コンフィギュレーションを更新し、TMIB への動的な変更をブロードキャストします。マシンのクラッシュ、データベースの破壊、BEA Tuxedo システムの問題、ネットワークの分断、アプリケーションの障害などが原因でMASTER マシンに障害が発生しても、アプリケーションは停止しません。クライアントのアプリケーションへの参加、サーバからのサービス要求の発行、およびローカル・マシンでの名前指定は引き続き可能です。ただし、MASTER マシンが復元されない限り、サーバをアクティブまたは非アクティブにしたり、管理者側でシステムを動的に再コンフィギュレーションすることはできません。

同様のことがアプリケーション・サーバにも当てはまります。アプリケーション・サーバは、特定のマシン上でクライアントのリクエストを処理するようにコンフィギュレーションされていますが、マシンに障害が発生したり、シャットダウンする必要が生じると、そのマシン上のサーバは使用できなくなります。このような場合は、設定済みの BACKUP マシンまたは代替マシンにサーバを移行することができます。

シャットダウンの準備 (サービスまたはアップグレードのため) として移行を行う場合、マシン障害に固有の問題は管理者に通知されません。したがって、この場合の管理者は、高レベルの権限で移行作業を管理できます。

Master マシンの移行

Master マシンの移行とは、設定済みの MASTER マシンから設定済みの BACKUP マシンに DBBL を移動するプロセスのことです。このプロセスにより、設定済みの MASTER マシンがダウンしていても、サーバは引き続きサービスを提供することができます。移行を行うには、まず、設定済みの BACKUP マシンを代理の MASTER マシンとし、設定済みの MASTER マシンを代理の BACKUP マシンとするよう、管理者側から要求します。これで、すべての管理機能は、代理の MASTER マシンで行われます。つまり、コンフィギュレーション内のほかのマシンを監視し、コンフィギュレーションの動的な変更を受け付けます。

次の図では、マシン 2 (設定済みの BACKUP マシン) が代理の MASTER マシンになり、マシン 1 (設定済みの MASTER マシン) が代理の BACKUP マシンになっています。設定済みの MASTER マシンが利用できるようになると、代理の MASTER マシン (設定済みの BACKUP マシン) から再びアクティブにされます。設定済みの MASTER マシンには、代理の MASTER マシンを制御する権限が再び与えられます。

管理者は、各サーバ・グループに対してプライマリ・マシンと代替マシンを指定します。サーバ・グループの移行プロセスでは、代替マシン上のサーバ・グループをアクティブにします。

次の図では、グループ A がマシン 1 (プライマリ・マシン) に割り当てられ、マシン 2 がグループ A の代替マシンとして割り当てられています。移行後、グループ A はマシン 2 でアクティブ化されます。つまり、このグループ内のすべてのサーバおよび関連するサービスは、マシン 2 (代理のプライマリ・マシン) で提供されます。

単に 1 つのサーバ・グループを移行することも便利ですが、実際には、マシン全体の移行の方が必要です。たとえば、コンピュータに障害が発生した場合にこのタイプの移行が必要になります。マシンの移行には、そのマシン上で稼動する各サーバ・グループを移行することも含まれます。各サーバ・グループには、代替マシンを設定する必要があります。

スケジュール設定された移行の実行

制御された状況 (コンピュータをオフラインにしたり、アップグレードする必要がある場合など) では、管理者は、サーバやサービスの現在のコンフィギュレーション情報を保存し、これらの情報を、代替マシンでサーバをアクティブにするときに使用できます。コンフィギュレーション情報をこのように使用できるのは、サーバが非アクティブになり、移行の要求に応答できなくなっても、サーバ・エントリがプライマリ・マシンに保持されるためです。

移行処理では、サーバ・グループ全体を移行することも、マシン全体を移行することもできます。マシン全体の移行は、プライマリ・マシン上のすべてのサーバ・グループに対して同じマシンが代替マシンとして設定されている場合に可能です。これ以外の場合 (プライマリ・マシン上の異なるサーバ・グループに対して別々の代替マシンが設定されている)、サーバはマシン単位ではなく、グループ単位で移行しなければなりません。

次の図では、マシン 1 が設定済みの MASTER マシンおよびグループ B のプライマリ・マシンであり、マシン 2 が設定済みの BACKUP です。サーバ・グループ B には、プライマリ・マシンとしてマシン 1 が設定されており、代替マシンとしてマシン 3 が設定されています。マシン 1 がダウンすると、マシン 2 が代理の MASTER マシンとなります。サーバ・グループ B は非アクティブになり、代替マシンであるマシン 3 に移行され、再びアクティブになります。

移行の対象がアプリケーションの一部であっても、全体であっても、サービスの中断を最小限に抑えるように変更処理を行ってください。アプリケーションのマシン、ネットワーク、データベース、およびその他のコンポーネントの整合性は、そのままにしておく必要があります。BEA Tuxedo システムにはアプリケーションの移行時に、すべてのコンポーネントの整合性を保持するための方法が用意されています。