9 サーバー移行

このエンタープライズ・トポロジでは、WLS_SOA1およびWLS_SOA2管理対象サーバー用のサーバーの移行を構成する必要があります。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。この構成では、WLS_SOA1およびWLS_SOA2サーバーは、WLSサーバーの移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_SOAn管理対象サーバーのサーバー移行を構成する手順は次のとおりです。

ステップ1: サーバー移行リース・テーブルのユーザーおよび表領域の設定
ステップ2: Oracle WebLogic Server管理コンソールでのマルチ・データ・ソースの作成
ステップ3: SOAHOST1およびSOAHOST2と管理サーバー間でのホスト名検証証明書の有効化
ステップ4: ノード・マネージャのプロパティ・ファイルの編集
ステップ5: wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定
ステップ6: サーバー移行ターゲットの構成
ステップ7: サーバー移行のテスト

9.1 サーバー移行リース・テーブルのユーザーおよび表領域の設定

ステップ1では、サーバー移行リース・テーブルのユーザーと表領域を設定します。

leasingという表領域を作成します。たとえば、SYSDBAユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。

SQL> create tablespace leasing
        logging datafile 'DB_HOME/oradata/orcl/leasing.dbf'
        size 32m autoextend on next 32m maxsize 2048m extent management local;

leasingというユーザー名を作成し、リース表領域に割り当てます。

SQL> create user leasing identified by welcome1;

SQL> grant create table to leasing;

SQL> grant create session to leasing;

SQL> alter user leasing default tablespace leasing;

SQL> alter user leasing quota unlimited on LEASING;

leasing.ddlスクリプトを使用してリース・テーブルを作成します。
1. WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリにあるleasing.ddlファイルをデータベース・ノードにコピーします。
2. leasingユーザーとしてデータベースに接続します。
3. leasing.ddlスクリプトをSQL*Plusで実行します。
```
SQL> @copy_location/leasing.ddl;
```

9.2 Oracle WebLogic Server管理コンソールでのマルチデータ・ソースの作成

ステップ2では、Oracle Weblogic Server管理コンソールを使用して、リース・テーブルのマルチ・データ・ソースを作成します。

マルチデータ・ソースの設定プロセス中に、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバル・リース・マルチデータ・ソースの両方に対して作成します。データ・ソースを作成する手順は次のとおりです。

該当のソースが非XAデータソースであることを確認します。
マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10または11を使用します。
データソースは、グローバル・トランザクションのサポートを必要としません。したがって、データソースに対して、どのようなタイプの分散トランザクション・エミュレーション/参加アルゴリズムも使用しない(「グローバル・トランザクションのサポート」オプション、または「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプションを選択しない)で、データベースのサービス名を指定します。
これらのデータ・ソースのターゲットをSOAクラスタに設定します。
データソースの接続プールの初期容量が0に設定されていることを確認してください。そのためには、「サービス」→「JDBC」→「データ・ソース」を選択します。「データ・ソース」画面で、「データソース名」をクリックして「接続プール」タブをクリックし、「初期容量」フィールドに「0」と入力します。

マルチ・データ・ソースの作成

マルチ・データ・ソースを作成する手順は次のとおりです。

Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開いてから、「データ・ソース」をクリックします。

「JDBCマルチ・データ・ソースの概要」ページが表示されます。
「データソース」→「新しいJDBCマルチ・データ・ソースの作成」をクリックします。
「ロックして編集」をクリックします。
「新規」をクリックします。

「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「名前」にleasingと入力します。
「JNDI名」にjdbc/leasingと入力します。
アルゴリズムとして「フェイルオーバー」を選択します(デフォルト)。
「次」をクリックします。
「ターゲット」に「SOA_Cluster」を選択します。
「次へ」をクリックします。
「非XAドライバ」を選択します(デフォルト)。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として、leasing-rac0と入力します。JNDI名として、jdbc/leasing-rac0と入力します。データベースのタイプとして、oracleと入力します。ドライバのタイプとして、Oracle Driver (Thin) for RAC server-Instance connection Version 10,11と入力します。

注意:
リース・テーブル用のマルチ・データ・ソースを作成する場合、その名前は<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
リース・スキーマについて、サービス名、データベース名、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして接続できることを確認します。
「次へ」をクリックします。
データ・ソースをSOA_Clusterにターゲット設定します。
データ・ソースを選択して右側の画面に追加します。
Oracle RACデータベースの2番目のインスタンスに対して「新しいデータ・ソースの作成」をクリックし、そのデータ・ソースをSOA_Clusterにターゲット設定します。2番目のOracle RACデータベース・インスタンスでも、この手順を実行します。
使用するマルチ・データ・ソースに2番目のデータ・ソースを追加します。
「変更のアクティブ化」をクリックします。

9.3 SOAHOST1およびSOAHOST2と管理サーバー間でのホスト名検証証明書の有効化

ステップ3では、ノード・マネージャと管理サーバー間でのホスト名検証に適切な証明書を作成します。この手順の詳細は、第8.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」および第8.5項「SOAHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。

9.4 ノード・マネージャのプロパティ・ファイルの編集

ステップ4では、ノード・マネージャのプロパティ・ファイルを編集します。これは、サーバー移行が構成されている両方のノードのノード・マネージャで実行する必要があります。nodemanager.propertiesファイルは、WL_HOME/common/nodemanagerディレクトリにあります。

Interface=eth0

NetMask=255.255.255.0

UseMACBroadcast=true

Interface

このプロパティは浮動IP(eth0など)のインタフェース名を指定します。

注意:

eth0:1やeth0:2のようなサブ・インタフェースは指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、:Xに対応した各種のIPを横断して、どれを追加または削除するかを判定します。たとえば、Linux環境で有効な値はeth0、eth1、eth2、eth3またはethnで、いずれになるかは、構成されているインタフェースの数によって異なります。

NetMask

このプロパティは浮動IP用インタフェースのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。このドキュメントの例では、255.255.255.0を使用します。
UseMACBroadcast

このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの出力(ノード・マネージャを起動するシェル)で、これらのプロパティが使用されていることを確認してください。使用されていない場合は、移行中に問題が発生することがあります。ノード・マネージャの出力には次のような行が含まれます。

...
StateCheckInterval=500
Interface=eth0
NetMask=255.255.255.0
...

注意:

サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。

nodemanager.propertiesファイルで次のプロパティを設定します。
- StartScriptEnabled
  
  このプロパティはtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動できるようにするためにShiphometに必要なものです。
WL_HOME/server/binディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:

共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.propertiesファイルを使用する複数のノードが起動します。ただし、NetMaskプロパティやInterfaceプロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3としてInterface環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。

9.5 wlsifconfig.shスクリプトの環境およびスーパー・ユーザー権限の設定

ステップ5では、wlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定します。

PATH環境変数に次のファイルが含まれていることを確認します。

表9-1 PATH環境変数に必要なファイル

ファイル	ディレクトリの場所
`wlsifconfig.sh`	`ORACLE_BASE/admin/<domain_name>/mserver/ <domain_name>/bin/server_migration`
`wlscontrol.sh`	`WL_HOME/common/bin`
`nodemanager.domains`	`WL_HOME/common/nodemanager`

sudoの構成をwlsifconfig.shスクリプトに付与します。
- パスワードの要求がなくても動作するようにsudoを構成します。
- セキュリティ上の理由から、sudoの付与は wlsifconfig.shスクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.shスクリプトの環境とスーパー・ユーザー権限を設定する手順は次のとおりです。
  1. パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
  2. WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。
```
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
```
注意:
この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

9.6 サーバー移行ターゲットの構成

ステップ6では、サーバー移行ターゲットを構成します。クラスタの移行を構成すると、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。次の手順に従って、クラスタ内の移行でクラスタの移行を構成します。

http://<host>:<adminPort>/consoleのOracle WebLogic Server管理コンソールにログインします。通常、adminPortはデフォルトの7001です。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。

サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。

Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理サーバーと、サーバー移行が構成されているサーバーを再起動します。

管理サーバーを再起動するには、第4.7項「SOAHOST1での管理サーバーの起動」の手順を使用します。

ヒント:

「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、実際の構成と異なる内容が表示されます。

9.7 サーバー移行のテスト

最後に、ステップ7でサーバー移行をテストします。サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1で次の操作を実行します。

WLS_SOA1管理対象サーバーを停止します。

停止するには、次のコマンドを実行します。
```
SOAHOST1> kill -9 <pid>
```
PIDには管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。
```
SOAHOST1> ps -ef | grep WLS_SOA1
```
ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOA1の2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。

ノード2で次の操作を実行します。

ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_SOA1の再起動が前回試行されてから30秒間経過した後に、WLS_SOA1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。
同じIPでsoa-infraコンソールにアクセスします。

管理コンソールでの確認

移行は次のように管理コンソールで確認することもできます。

管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。

「移行の状態」の表に、移行の状態に関する情報が表示されます。

図9-1 管理コンソールの「移行の状態」画面

「図9-1 管理コンソールの「移行の状態」画面」の説明

注意:

サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。