アプリケーションの移行

通常、管理者は、設定済みの MASTER マシンで日常的な管理タスクを行います。MASTER マシン上の DBBL は、コンフィグレーション内のほかのマシンをモニタし、コンフィグレーションを更新し、TMIB への動的な変更をブロードキャストします。マシンのクラッシュ、データベースの破壊、Oracle 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 に移行され、再びアクティブになります。

グループ内のすべてのサーバを非アクティブにしたら、代理のプライマリマシンから代理の代替マシンにグループを移行できます。実行中のサーバ、現在宣言されているサービス、および動的に変更されたコンフィグレーション内容を指定する必要はありません。設定済みの代替マシンは、設定済みのプライマリマシン上で利用可能なサーバ (非アクティブの場合) のコンフィグレーション情報から、これらの情報を取得します。使用されているデータ依存型ルーティングが代替マシンでも適用される場合、サービスは、ルーティング先のグループ名 (マシン名ではない) に基づいてルーティングされます。

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

移行の種類

Oracle Tuxedo システムでの移行作業には、次の種類があります。

上記のアプリケーションコンポーネントの組み合わせに従って移行を行い、分断されたネットワークを回復するためのユーティリティを使用すると、マシン全体を移行できます。

Master マシンと Backup マシンの切り替え

MASTER マシンを保守のために停止する場合、または予想外の問題が原因でアクセスできなくなった場合 (ネットワークの分断など) は、MASTER マシンでの作業を設定済みの BACKUP マシンに移行する必要があります。

この種の移行は、DBBL を MASTER マシンから BACKUP マシンへ移行することによって実現できます。DBBL を移行するには、次のコマンドを入力します。

ほとんどの場合、アプリケーションサーバを代替サイトに移行するか、または MASTER マシンを復元する必要があります。tmadmin コマンドの詳細については、『Tuxedo コマンドリファレンス』の「tmadmin(1)」リファレンスページを参照してください。

MASTER マシンと BACKUP マシンの切り替え例

次の 2 つの tmadmin セッションの例では、MASTER マシンと BACKUP マシンの切り替え方法を示しています。ここでは、BACKUP マシンから MASTER にアクセスできるかどうかは無関係です。最初の例では、BACKUP マシンから MASTER にアクセスできるため、DBBL プロセスは MASTER マシンから BACKUP マシンへ移行されます。

2 番目の例では、BACKUP マシンから MASTER マシンにアクセスできないため、DBBL プロセスは BACKUP マシン上に作成されます。

サーバグループの移行

UBBCONFIG ファイルの GROUPS セクションで、移行されるサーバグループの LMID パラメータに代替ロケーションを指定します。そのグループ内のサーバには RESTART=Y を指定し、UBBCONFIG ファイルの RESOURCES セクションで MIGRATE オプションを指定する必要があります。
サーバグループを移行する場合は、次のコマンドを実行して、グループ内のサーバを停止します。

tmshutdown -R -g groupname

次のコマンドを入力して tmadmin セッションを開始します。

tmadmin

tmadmin のプロンプトで、次のどちらかのコマンドを入力します。

1 つのグループ内のすべてのサーバを移行するには、次のコマンドを入力します。

migrategroup(migg)

このコマンドには、1 つのサーバグループの名前を引数として指定します。

マシン上のすべてのサーバグループ (LMID で指定) を移行するには、次のコマンドを入力します。

migratemach(migm)

移行するサーバグループに含まれるサーバに対してトランザクションが記録されている場合は、TLOG を BACKUP マシンに移動し、それをロードしてウォームスタートを行います。

サーバグループの移行 (プライマリマシンから代替マシンにアクセスできる場合)

プライマリマシンから代替マシンにアクセスできる場合は、次の手順でサーバグループを移行します。

次のコマンドを入力して、MASTER マシンを停止します。

tmshutdown -R -g groupname

次のコマンドを入力して、プライマリマシンで tmadmin セッションを開始します。

tmadmin

次のコマンドを入力して、適切なグループを移行します。

migrategroup groupname

必要に応じてトランザクションログを移行します。
必要に応じてアプリケーションデータを移行します。

サーバグループの移行 (プライマリマシンから代替マシンにアクセスできない場合)

プライマリマシンから代替マシンにアクセスできない場合は、必要に応じて次の手順で MASTER マシンと BACKUP マシンを切り替えます。

代替マシンで次のコマンドを入力して tmadmin セッションを開始します。

tmadmin

次のコマンドを入力して、クリーンアップと再起動が必要なプライマリマシン上のサーバを指定し、処理を実行します。

pclean primary_machine

次のコマンドを入力して、適切なサーバグループを設定済みの代替マシンに転送します。

migrate groupname

次のコマンドを入力して、移行後のサーバグループを起動します。

boot -g groupname

サーバグループの移行例

次の 2 つのセッション例では、サーバグループの移行方法を示しています。ここでは、プライマリマシンから代替マシンにアクセスできるかどうかは無関係です。最初の例では、プライマリマシンから代替マシンにアクセスできます。

2 番目の例では、プライマリマシンから代替マシンにアクセスできません。

1 つのマシンから別のマシンへのサーバグループの移行

LMID を使用して、サーバグループが稼働するプロセッサを指定します。LMID のすべてのサーバグループに対して同じ代替ロケーションを指定します。
UBBCONFIG ファイルの RESOURCES セクションで、次のようにパラメータを設定します。

LMID で指定したマシン上の各サーバに対して、RESTART=Y を設定します。
MIGRATE オプションを指定します。

次のコマンドを入力して、すべてのサーバグループを停止し、グループ内のサーバが再起動可能になるように設定します。

tmshutdown -R

プライマリマシンを保守のために停止する場合、またはプライマリマシンにアクセスできなくなった場合は、tmadmin(1) migratemach (migm) コマンドを使用してすべてのサーバグループを 1 つのマシンから別のマシンに移行します。このコマンドでは、引数として 1 つの論理マシン識別子を指定します。

マシンの移行 (プライマリマシンから代替マシンにアクセスできる場合)

プライマリマシンから代替マシンにアクセスできる場合は、次の手順でマシンを移行します。

マシン上で次のコマンドを入力して、MASTER マシンを停止します。

tmshutdown -R -1 primary_machine

次のコマンドを入力して、MASTER マシンで tmadmin セッションを開始します。

tmadmin

tmadmin のプロンプトで、次のコマンドを入力して適切なマシンを移行します。

migratemach primary_machine

必要に応じてトランザクションログを移行します。
必要に応じてアプリケーションデータを移行します。

マシンの移行 (プライマリマシンから代替マシンにアクセスできない場合)

プライマリマシンから代替マシンにアクセスできない場合は、必要に応じて次の手順で MASTER マシンと BACKUP マシンを切り替えます。

代替マシンで次のコマンドを入力して tmadmin セッションを開始します。

tmadmin

次のコマンドを入力して、クリーンアップと再起動が必要なプライマリマシンを指定し、処理を実行します。

pclean primary_machine

次のコマンドを入力して、適切なサーバグループを設定済みの代替マシンに転送します。

migratemach primary_machine

次のコマンドを入力して、移行後のサーバグループを起動します。

boot -l alternate_machine

マシンの移行例

次のセッションの例は、マシンの移行方法を示しています。最初の例では、プライマリマシンから代替マシンにアクセスできます。

2 番目の例では、プライマリマシンから代替マシンにアクセスできません。

移行の取り消し

サーバグループまたはマシンを非アクティブにした後で移行作業を中止したい場合は、再びサーバグループまたはマシンをアクティブにする前に移行を取り消すことができます。ネームサーバ内にある、非アクティブにされたサーバとサービスの情報はすべて削除されます。

停止を実行しても、migrate コマンドを実行する前であれば、次のコマンドを使用して移行を取り消すことができます。

取り消しの対象	コマンド	結果
サーバの移行	`tmadmin migrategroup -cancel` または `tmadmin migg -cancel`	掲示板からサーバエントリが削除されます。移行が取り消された場合は、サーバを再起動する必要があります。
マシンの移行	`tmadmin` `migratemach` -`cancel` または `tmadmin migm -cancel`	移行は中止されます。

移行の取り消し例

次の tmadmin セッションの例は、サーバグループとマシンが、対応するプライマリマシンと代替マシン間で移行される手順を示しています。

Backup マシンへのトランザクションログの移行

トランザクションログを BACKUP マシンに移行するには、次の手順に従います。

次のコマンドを入力して tmadmin セッションを開始します。

tmadmin

すべてのグループ内のサーバを停止し、ログへの書き込みを中止します。
次のコマンドを実行して、テキストファイルに TLOG をダンプします。

dumptlog [-z config] [-o offset] [-n filename] [-g groupname]

注意 : TLOG は、引数 config および offset を使用して指定します。offset はデフォルトで 0 に設定されます。name はデフォルトで TLOG に設定されます。-g オプションを選択すると、TMS によって調整された、groupname のレコードだけがダンプされます。

filename を BACKUP マシンにコピーします。
次のコマンドを入力して、指定したマシンの既存の TLOG にファイルを読み込みます。

loadtlog -m machine filename

次のコマンドを入力して、TLOG を強制的にウォームスタートさせます。

logstart machine

TLOG の情報が読み込まれ、この情報を使用して共有メモリ内のトランザクションテーブルにエントリが作成されます。

サーバを BACKUP マシンに移行します。

Oracle Tuxedo アプリケーション実行時の管理

アプリケーションの移行