7 アプリケーションの移行

このトピックには、次の項があります。

• 移行とは
  
• 移行オプション
  
• MasterマシンとBackupマシンの切替え
  
• サーバー・グループの移行
  
• 1つのマシンから別のマシンへのサーバー・グループの移行
  
• 自動移行
  
• 移行の取消し
  
• Backupマシンへのトランザクション・ログの移行
  

7.1 移行とは

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

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

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

• Masterマシンの移行
  
• サーバー・グループの移行
  
• マシンの移行
  
• スケジュール設定された移行の実行
  

7.1.1 Masterマシンの移行

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

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

図7-1 Masterマシンの移行

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

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

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

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

7.1.3 マシンの移行

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

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

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

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

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

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

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

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

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

7.2 移行オプション

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

• MASTERマシンをBACKUPマシンに切り替える(その逆も可能)
• プライマリ・マシン上の1つのサーバー・グループを代替マシンへ移行する
• プライマリ・マシン上のすべてのサーバー・グループを代替マシンへ移行する
• トランザクション・ログを移行する
• プライマリ・マシン上の1つのサーバー・グループを代替マシンへ移行する

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

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

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

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

ノート:

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

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

tmadmin master

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

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

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

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

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

$ tmadmin
tmadmin - ................................;...................................
>master
are you sure? [y,n] y
Migrating active DBBL from SITE1 to SITE2, please wait...
DBBL has been migrated from SITE1 to SITE2
> q

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

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

$ tmadmin 
...   
TMADMIN_CAT:199: WARN: Cannot become administrator.Limited set of commands available.
> master 
Are you sure? [y, n] y 
Creating new DBBL on SITE2, please wait ...  
New DBBL created on SITE2 
> q 
$ tmadmin 
....
>pcl SITE1 
Cleaning the DBBL. 
Pausing 10 seconds waiting for system to stabilize. 
3 SITE1 servers removed from bulletin board 
>q 

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

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

$ tmadmin
... 
>pcl SITE2 
Cleaning the DBBL. 
Pausing 10 seconds waiting for system to stabilize. 
3 SITE2 servers removed from bulletin board
> q 
$tmshutdown -y 

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

$ tmadmin
...
> boot -B SITE1 -l SITE1
INFO:....................., 64-bit, Patch Level (none)
Booting admin processes ...
exec BBL -A: 
on SITE1 -> process id=15044 ... Started.
Booting server processes ...
exec serverping -A : 
on SITE1 -> process id=15053 ... Started.
2 processes started.
>q 

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

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

   tmshutdown -R -ggroupnam

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

   tmadmin

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

   migrategroup(migg)

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

   ノート:

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

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

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

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

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

   tmshutdown -R -g groupname

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

   tmadmin

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

   migrategroup groupname

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

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

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

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

   tmadmin

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

   pclean primary_machine

3. コマンドmigrate groupnameを入力して、適切なサーバー・グループを構成済の代替マシンに転送します
4. 次のコマンドを入力して、移行後のサーバー・グループを起動します。

   boot -g groupname

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

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

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

$ tmshutdown -R -g GROUP1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1: shutdown succeeded
1 process stopped.
$ tmadmin
tmadmin - ................................. 
> migg GROUP1 
migg successfully completed
> q

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

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

$ tmadmin
tmadmin - ..............................; ............
> pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migg GROUP1
migg successfully completed.
> boot -g GROUP2
Booting server processes ...
exec simpserv -A :
on SITE2 -> process id=22699 ... Started.
1 process started.
>q

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

1. LMIDパラメータを使用して、サーバー・グループが稼働するプロセッサを指定します。LMIDのすべてのサーバー・グループに対して同じ代替ロケーションを指定します。
2. UBBCONFIGファイルのRESOURCESセクションで、次のようにパラメータを設定します
   • LMIDで指定したマシン上の各サーバーに対して、RESTART=Yを設定します。
   • MIGRATEオプションを指定します。
3. 次のコマンドを入力して、すべてのサーバー・グループを停止し、グループ内のサーバーが再起動可能になるように設定します。

   tmshutdown -R

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

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

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

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

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

   tmshutdown -R -1

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

   tmadmin

3. tmadminのプロンプトで、次のコマンドを入力して適切なマシンを移行します: migratemach primary_machine
4. 必要に応じてトランザクション・ログを移行します。
5. 必要に応じてアプリケーション・データを移行します。

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

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

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

   pclean primary_machine

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

   migratemach primary_machine

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

   boot -l

   alternate_machine

7.5.3 マシンの移行例

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

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

$ tmshutdown -R -l SITE1
Shutting down server processes...
Server ID = 1 Group ID = GROUP1 machine = SITE1:shutdown         
succeeded 1 process stopped.
$ tmadmin
tmadmin - .............................;............
> migm SITE1
migm successfully completed
>q

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

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

$ tmadmin
tmadmin - .............................;............
>pclean SITE1
Cleaning the DBBL.
Pausing 10 seconds waiting for system to stabilize.
3 SITE1 servers removed from bulletin board
> migm SITE1
migm successfully completed.
> boot -l SITE2
Booting server processes ...
exec simpserv -A :
on SITE2 -- process id=22782 ... Started.
1 process started.
>q

7.6 自動移行

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

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

• DBBLFAILOVER numeric_value (0 <= num < 32768)/>

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

• SGRPFAILOVER*SANITYSCAN*SCANUNITは、サーバー・グループを移行する場合の時間のしきい値です。このパラメータは、秒単位か、またはSCANUNITがミリ秒で指定されている場合にはミリ秒単位で指定されます。指定しない場合、SGRPFAILOVERはデフォルトで0に設定されます。サーバー・グループの自動移行が有効になるのは、SGRPFAILOVERが0より大きな値に構成された場合のみです。SGRPFAILOVER*SANITYSCAN*SCANUNITは、サーバー・グループを移行する場合の時間のしきい値です。このパラメータは、秒単位か、またはSCANUNITがミリ秒で指定されている場合にはミリ秒単位で指定されます。指定しない場合、SGRPFAILOVERはデフォルトで0に設定されます。サーバー・グループの自動移行が有効になるのは、SGRPFAILOVERが0よりも大きな値に構成された場合のみです。それ以外にも、2つの関連属性TA_DBBLFAILOVERおよびTA_SGRPFAILOVERがMIB操作用のT_DOMAINクラスで定義されます。

詳細は、UBBCONFIG(5)またはTM_MIB(5)を参照してください。

7.7 移行の取消し

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

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

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

• 移行の取消し例
  

7.7.1 移行の取消し例

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

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

$tmadmin
tmadmin - ......................; ..........
> psr -g GROUP1
a.out Name Queue Name Grp Name ID RqDone Ld Done CurrentService
 ---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - (DEAD  MIGRATING)
> psr -g GROUP1
TMADMIN_CAT:121: No such server
migg -cancel GROUP1
>boot -g GROUP1
Booting server processes...
exec simpserv -A:
on SITE1 ->process id_27636 ... Started. 1 process started.
> psr -g GROUP1
a.out Name Queue Name Grp Name ID RqDone Ld Done Current Service
---------- ---------- -------- -- ------ ------- ---------------
simpserv 00001.00001 GROUP1 1 - - ( - )
> q

7.8 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マシンに移行します。