アプリケーションの移行

このトピックには次の項が含まれます:

•

移行とは

•

移行の種類

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

•	サーバー・グループの移行

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

•

自動移行

•

移行の取消し

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

移行とは

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

同様に、アプリケーション・サーバーは、特定のマシン上でクライアントのリクエストを処理するように構成されています。ただし、マシンに障害が発生したり、保守のための停止が必要になると、そのマシン上のサーバーは使用できなくなります。このような場合は、構成済のBACKUPマシンまたは代替マシンにサーバーを移行できます。

停止の準備(サービスまたはアップグレードのため)として移行を行う管理者は、マシン障害に固有の問題に対応する必要はありません。したがって、この状況では管理者にとっての移行アクティビティの制御の自由度は相対的に高くなります。

Masterマシンの移行

マスター・マシンの移行は、構成済のMASTERマシンから構成済のBACKUPマシンにDBBLを移動するプロセスとなります。これにより、構成済のMASTERマシンがダウンしている間も、サーバーの処理を継続できます。移行を行うには、まず、設定済BACKUPマシンを代理のMASTERマシンとし、設定済MASTERマシンを代理のBACKUPマシンとするよう、管理者側から要求します。これで、すべての管理機能は、代理のMASTERマシンで行われます。つまり、構成内のほかのマシンをモニタリングし、構成の動的な変更を受け付けます。

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

図7-1 マスターの移行の実行

 

サーバー・グループの移行

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

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

図7-2 サーバー・グループの移行

 

マシンの移行

1つのサーバー・グループのみを移行することが便利な場合もありますが、多くの場合は、マシン全体を移行する必要があります。このタイプの移行は、コンピュータに障害が発生した場合などに必要となります。マシンの移行には、マシン上で稼働する各サーバー・グループの移行が含まれます。各サーバー・グループに対して代替マシンを構成する必要があります。

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

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

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

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

図7-3 スケジュール設定された移行の実行

 

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

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

移行の種類

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

•	MASTERマシンとBACKUPマシンを切り替える

•	プライマリ・マシン上の1つのサーバー・グループを代替マシンへ移行する

•	プライマリ・マシン上のすべてのサーバー・グループを代替マシンへ移行する

•	トランザクション・ログを移行する

移行を取り消すこともできます。

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

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

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

注意:	MASTERマシンとBACKUPマシンで同じリリースのOracle Tuxedoシステム・ソフトウェアを実行していることを確認してからMASTERマシンを移行してください。

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

tmadmin master

 

ほとんどの場合、アプリケーション・サーバーを代替サイトに移行するか、またはMASTERマシンを復元する必要があります。tmadminコマンドの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtmadmin(1)のリファレンス・ページを参照してください<Default ?Font>。

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

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

リスト7-1 MASTERマシンとBACKUPマシンの切替え(BACKUPマシンからMASTERマシンにアクセスできる場合)

$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL. All rights reserved.
> master
よろしいですか。[y, n] y
SITE1からSITE2にアクティブなDBBLを移行しています。お待ちください。
DBBLはSITE1からSITE2へ移行しました。
> q

 

リスト7-2では、BACKUPマシンからMASTERマシンにアクセスできないため、DBBLプロセスはバックアップ・ノード(SITE2)のBACKUPマシン上に作成されます。

リスト7-2 MASTERマシンとBACKUPマシンの切替え(BACKUPマシンからMASTERマシンにアクセスできない場合)

$ tmadmin

...

TMADMIN_CAT:199: 警告: 管理者になれません。使用可能なコマンドは制限されています。

> master

よろしいですか。[y, n]

SITE2上に新しいDBBLを作成しています。お待ちください。

新しいDBBLをSITE2に作成しました。

> q

$ tmadmin

...

> pcl SITE1

DBBLのクリーニングをしています。

システムが安定するまで10秒間お待ちください。

掲示板から3個のSITE1サーバーを削除しました

> q

 

リスト7-3およびリスト7-4では、古いマスター(SITE1)が再度アクセスできるようになったら、次のコマンドを実行して新しいMPモードが正常に動作するようにします。両ノードのtlistenが起動していることを確認します。

リスト7-3 新しいMPモードの正常な動作の確認(サイト1で古いマスターが再度アクセスできるようになった後)

$ tmadmin

...

> pcl SITE2

DBBLのクリーニングをしています。

システムが安定するまで10秒間お待ちください。

掲示板から3個のSITE2サーバーを削除しました

> q

$tmshutdown -y

 

リスト7-4 新しいMPモードの正常な動作の確認(サイト2で古いマスターが再度アクセスできるようになった後)

$ tmadmin

...

> boot -B SITE1 -l SITE1

情報: Oracle Tuxedo、バージョン12.1.1.0、64ビット、パッチ・レベル(なし)

管理プロセスを起動しています

exec BBL -A :

SITE1で -> プロセスid=15044 ... 起動済。

アプリケーションのサーバー・プロセスを起動します。

exec serverping -A :

SITE1で -> プロセスid=15053 ... 起動済。

2個のプロセスを起動しました。

> q

 

サーバー・グループの移行

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

2.	サーバー・グループを移行する場合は、次のコマンドを実行して、グループ内のサーバーを停止します。

tmshutdown -R -g groupname

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

tmadmin

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

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

migrategroup(migg)

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

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

migratemach(migm)

 

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

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

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

1.	MASTERマシンから、次のコマンドを入力して、移行するグループを停止します。

tmshutdown -R -g groupname

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

tmadmin

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

migrategroup groupname

4.	必要に応じてトランザクション・ログを移行します。

5.	必要に応じてアプリケーション・データを移行します。

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

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

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

tmadmin

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

pclean primary_machine

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

migrate groupname

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

boot -g groupname

サーバー・グループの移行例

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

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

$ tmshutdown -R -g GROUP1
アプリケーションのサーバー・プロセスをシャットダウンします。
サーバーID = 1、グループID = GROUP1、マシン= SITE1: シャットダウンに成功しました
1個のプロセスが終了しました。
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migg GROUP1
移行が正常終了しました。
> q

 

リスト7-6では、プライマリ・マシンから代替マシンにアクセスできません。

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

$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> pclean SITE1
DBBLのクリーニングをしています。
システムが安定するまで10秒間お待ちください。
掲示板から3個のSITE1サーバーを削除しました
> migg GROUP1
移行が正常終了しました。
> boot -g GROUP2
アプリケーションのサーバー・プロセスを起動します。
exec simpserv -A :
(SITE2上) ->プロセスID=22699を起動しました。
1個のプロセスを起動しました。
> q

 

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

1.	LMIDパラメータを使用して、サーバー・グループが稼働するプロセッサを指定します。LMIDのすべてのサーバー・グループに対して同じ代替ロケーションを指定します。

2.	UBBCONFIGファイルのRESOURCESセクションで、次のようにパラメータを設定します。

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

•	MIGRATEオプションを指定します。

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

tmshutdown -R

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

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

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

1.	MASTERマシンから、次のコマンドを入力して移行するプライマリ・マシンを停止します。

tmshutdown -R -1 primary_machine

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

tmadmin

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

migratemach primary_machine

4.	必要に応じてトランザクション・ログを移行します。

5.	必要に応じてアプリケーション・データを移行します。

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

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

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

tmadmin

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

pclean primary_machine

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

migratemach primary_machine

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

boot -l alternate_machine

マシンの移行例

リスト7-7に、マシンの移行方法を示します。最初の例では、プライマリ・マシンから代替マシンにアクセスできます。

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

$ tmshutdown -R -l SITE1
アプリケーションのサーバー・プロセスをシャットダウンします。
サーバーID = 1、グループID = GROUP1、マシン= SITE1: シャットダウンに
成功しました 1個のプロセスが終了しました。
$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> migm SITE1
移行が正常終了しました。
> q

 

リスト7-8では、プライマリ・マシンから代替マシンにアクセスできません。

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

$ tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> pclean SITE1
DBBLのクリーニングをしています。
システムが安定するまで10秒間お待ちください。
掲示板から3個のSITE1サーバーを削除しました
> migm SITE1
移行が正常終了しました。
> boot -l SITE2
アプリケーションのサーバー・プロセスを起動します。
exec simpserv -A :
(SITE2上) ->プロセスID=22782を起動しました。
1個のプロセスを起動しました。
> q

 

自動移行

1台の論理マシンのみでエラーが発生する(接続不可状態になる)と、自動移行機能が有効で、かつUBBで定義されたバックアップ・マシンがエンティティに含まれる場合、マシンのエンティティ(DBBLおよびサーバー・グループ)は自動移行機能によって移行されます。単にネットワークの問題が原因でマシンが接続不可状態になっている場合に自動移行が呼び出されると、ネットワークの問題が解決し、接続不可のマシンが復活した後、重複するエンティティのいずれかが削除されます。

自動移行機能を有効化するには、2つのしきい値オプションをUBBCONFIGの*RESOURCESセクションで構成する必要があります。

•	DBBLFAILOVER numeric_value (0 <= num < 32768)

DBBLFAILOVER*SANITYSCAN*SCANUNIT is the time threshold for migrating DBBL.このパラメータは、秒単位か、またはSCANUNITがミリ秒で指定されている場合にはミリ秒単位で指定されます。DBBLの自動移行が有効になるのは、DBBLFAILOVERが0を超える場合のみです。

•	SGRPFAILOVER numeric_value (0 <= num < 32768)

SGRPFAILOVER*SANITYSCAN*SCANUNITは、サーバー・グループを移行する場合の時間のしきい値です。このパラメータは、秒単位か、またはSCANUNITがミリ秒で指定されている場合にはミリ秒単位で指定されます。指定しない場合、SGRPFAILOVERはデフォルトで0に設定されます。サーバー・グループの自動移行が有効になるのは、SGRPFAILOVERが0を超える場合のみです。

それ以外にも、2つの関連属性TA_DBBLFAILOVERおよびTA_SGRPFAILOVERがMIB操作用のT_DOMAINクラスで定義されます。

詳細は、UBBCONFIG(5)またはTM_MIB(5)のリファレンスを参照してください。

移行の取消し

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

停止を実行しても、migrateコマンドを発行する前であれば、表7-1に示すコマンドの1つを使用して移行を取り消すことができます。

 

表7-1 移行の取消し

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

移行の取消し例

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

リスト7-9 サーバー・グループGROUP1の移行の取消し

$tmadmin
tmadmin - Copyright © 1987-1990 AT&T; 1991-1993 USL.
> psr -g GROUP1

a.out Name Queue Name Grp Name ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - (DEAD MIGRATING)
> psr -g GROUP1
TMADMIN_CAT:121: そのようなサーバーはありません
migg -cancel GROUP1
>boot -g GROUP1
アプリケーションのサーバー・プロセスを起動します。
exec simpserv -A:
(SITE1上) ->プロセスID=27636を起動しました。1個のプロセスを起動しました。
> psr -g GROUP1

a.out Name Queue Name Grp Name ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - ( - )
> q

 

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

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

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

tmadmin

2.	すべてのグループ内のサーバーを停止し、ログへの書込みを中止します。

3.	次のコマンドを実行して、テキスト・ファイルにTLOGをダンプします。

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

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

4.	filenameをBACKUPマシンにコピーします。

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

loadtlog -m machine filename

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

logstart machine

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

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