13 Exalogicエンタープライズ・デプロイメント用のサーバー移行の構成

サーバー移行を構成すると、SOA管理対象サーバーを1つのホストから別のものに移行でき、サーバーの1つをホストしているノードに障害が発生した場合でも、別のノードでそのサービスを継続できます。この章では、Fusion Middleware SOA Exalogicエンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

この章の内容は次のとおりです。

第13.1項「Exalogicエンタープライズ・デプロイメント用のサーバー移行の概要」
第13.2項「サーバー移行リース表のユーザーおよび表領域の設定」
第13.3項「Oracle WebLogic管理コンソールを使用したリース用のGridLinkデータ・ソースの作成」
第13.4項「ノード・マネージャのプロパティ・ファイルの編集」
第13.5項「wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定」
第13.6項「サーバー移行ターゲットの構成」
第13.7項「サーバー移行のテスト」
第13.8項「サーバー移行構成のバックアップ」

13.1 Exalogicエンタープライズ・デプロイメント用のサーバー移行の概要

管理対象サーバーWLS_OSB1、WLS_SOA1、WLS_OSB2およびWLS_SOA2のサーバー移行を構成します。WLS_OSB1とWLS_SOA1の管理対象サーバーは、障害発生時にSOAHOST2で再起動するように構成されます。WLS_OSB2とWLS_SOA2の管理対象サーバーは、障害発生時にSOAHOST1で再起動するように構成されます。サーバーWLS_OSB1、WLS_SOA1、WLS_OSB2およびWLS_SOA2は、WebLogicサーバー移行によってフェイルオーバーされる特定の浮動IPでリスニングします。

この後の項の手順を実行し、管理対象サーバーWLS_OSB1、WLS_SOA1、WLS_OSB2およびWLS_SOA2のサーバー移行を構成します。

13.2 サーバー移行リース表のユーザーおよび表領域の設定

この項では、サーバー移行リース表のユーザーおよび表領域を設定します。

注意:

同じドメイン内の他のサーバーがサーバー移行ですでに構成済である場合、同じ表領域およびデータ・ソースを使用できます。その場合、データベース・リース用のデータ・ソースおよびマルチ・データ・ソースを再作成する必要はありませんが、それらを、サーバー移行で構成しようとしているクラスタに再度ターゲット指定する必要があります。

leasingという表領域を作成します。たとえば、sysdbaユーザーとしてSQL*Plusにログオンし、次のコマンドを実行します。
```
create tablespace leasing 
logging datafile 'DB_HOME/oradata/orcl/leasing.dbf' size 32m autoextend on next 32m maxsize 2048m extent management local;
```

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

create user leasing identified by password;
grant create table to leasing;
grant create session to leasing;
alter user leasing default tablespace leasing;
alter user leasing quota unlimited on leasing;

leasing.ddlスクリプトを使用してleasing表を作成します。
1. 次のディレクトリのいずれかに配置されているleasing.ddlファイルを、自身のデータベース・ノードにコピーします。
```
WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920
```
2. leasingユーザーとしてデータベースに接続します。
3. SQL*Plusでleasing.ddlスクリプトを実行します。
```
@Copy_Location/leasing.ddl;
```
4. ツールが完了したら、SQL*Plusプロンプトに次のように入力します。
```
commit;
```

13.3 Oracle WebLogic管理コンソールを使用したリース用のGridLinkデータ・ソースの作成

付録D「GridLinkデータ・ソースの作成」を使用し、Oracle WebLogic管理コンソールを使用してリース表のGridLinkデータ・ソースを作成します。

リース表データ・ソースには、次の名前を使用します。

データ・ソース名: leasing
JNDI名: jdbc/leasing
データベース・ユーザー名: Leasing

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

この項では、ノード・マネージャのプロパティ・ファイルを編集します。これは、サーバーが実行されているノード、SOAHOST1およびSOAHOST2上のノード・マネージャに対して実行する必要があります。

nodemanager.propertiesファイルは、次のディレクトリにあります。

WL_HOME/common/nodemanager

interfaceとして、SOAおよびOSBサーバーによってサーバー移行に使用されるEoIBおよびIPoIBインタフェースを入力します。次に、サーバー移行によって制御される関連するIPアドレス範囲を入力します。このエントリには、IPアドレスのみを使用でき、ホスト名は使用できないことに注意してください。IPアドレスの後には、関連するネットマスクが続きます。次に例を示します。

bond0=soahost1-priv-v1-ip, soahost1-priv-v2-ip,NetMask=255.255.248.0

bond1=soahost1vhn1vip, soahost1vhn2vip,NetMask=255.255.248.0

注意:

bond0:1やbond0:2などのサブインタフェースを指定しないでください。このインタフェースは、:0や:1を指定せずに使用します。ノード・マネージャのスクリプトによって、様々な:X対応IPが調べられ、どれを追加してどれを削除するのかが判別されます。たとえば、Linux環境で有効な値は、構成されているインストールの数に応じて、bond0、bond1、bond2、bond3、bondnになります。

NetMask:
```
NetMask=255.255.248.0
```
このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。このネット・マスクは、インタフェース上のネット・マスクと同一にする必要があります。
UseMACBroadcast:
```
UseMACBroadcast=true
```
このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうか、つまり、arpingコマンドで-bフラグを使用するかどうかを指定します。

ノード・マネージャの出力(ノード・マネージャが起動されたシェル)で、これらのプロパティが使用されていることを確認します。それ以外の場合、移行中に問題が発生することがあります。ノード・マネージャの出力に次に類似したものが表示される必要があります。

StateCheckInterval=500
bond0=*,NetMask=255.255.248.0
UseMACBroadcast=true

注意:

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

nodemanager.propertiesファイルのStartScriptEnabledプロパティをまだtrueに設定していない場合はそのように設定します。これは、ノード・マネージャが管理対象サーバーを起動できるようにするために必要です。
次のディレクトリにあるstartNodeManager.shスクリプトを実行することで、SOAHOST1およびSOAHOST2でノード・マネージャを起動します。
```
/u02/private/oracle/config/nodemanager 
```

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

wlsifconfig.shスクリプトに環境およびスーパーユーザー権限を設定します。

表13-1に示すファイルがPATH環境変数に含まれていることを確認します。

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

ファイル	存在するディレクトリ
wlsifconfig.sh	`MSERVER_HOME/bin/server_migration`
wlscontrol.sh	`WL_HOME/common/bin`
nodemanager.domains	`WL_HOME/common/nodemanager`

WebLogicユーザー(oracle)にパスワード制約のないsudo権限を付与し、/sbin/ifconfigおよび/sbin/arpingバイナリの実行権限を付与します。

セキュリティ上の理由から、sudoはwlsifconfig.shスクリプトを実行するために必要なコマンドのサブセットに限定する必要があります。たとえば、次の手順を実行し、wlsifconfig.shスクリプトに環境およびスーパーユーザー権限を設定します。

注意:

この手順の実行に適したsudoおよびシステム権限については、システム管理者にお問い合せください。

WebLogicユーザーoracleにパスワード制約のないsudo権限を付与し、/sbin/ifconfigおよび/sbin/arpingバイナリの実行権限を付与します。

WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します次に、sudo実行権限をoracleおよびifconfigとarpingに付与する/etc/sudoers内のエントリの例を示します。

WebLogicユーザー(oracle)にパスワード制約のないsudo権限を付与するには、/sbin/ifconfigおよび/sbin/arpingバイナリの実行権限を付与します。

Defaults:oracle !requiretty
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping

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

この項では、soa_clusterおよびosb_clusterのサーバー移行ターゲットを構成します。クラスタ移行を構成するには、DataSourceForAutomaticMigrationプロパティをtrueに設定します。

クラスタ内の移行を構成する手順は、次のとおりです。

第8.18.2項「Oracle Traffic Directorを介したアクセスの検証」に示すURLにあるOracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ名をクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行可能とするマシン(SOAHOST1およびSOAHOST2)を選択して、右向き矢印をクリックします。
自動移行に使用するデータ・ソースを選択します。この場合は、リース・データ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
「変更のアクティブ化」をクリックします。
「使用可能」フィールドで、移行可能とするマシンを選択して、右向き矢印をクリックします。この場合は、SOAHOST1およびSOAHOST2を選択します。
第8.5.3項「SOAHOST1での管理サーバーの起動」の説明に従って、サーバー移行が構成された管理対象サーバーを再起動します。

注意:

移行を特定のマシンにのみ許可する場合は、クラスタに対して候補を指定しないで、サーバーごとのみで候補を指定してください。

13.7 サーバー移行のテスト

この項では、サーバー移行をテストします。たとえば、OSBサーバーの移行をテストする手順は、次のとおりです。

SOAHOST1からテストする手順は、次のとおりです。

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

SOAHOST2からテストする手順は、次のとおりです。

ローカルのノード・マネージャ・コンソールを確認します。SOAHOST1上のWLS_OSB1の再起動の最後の試行から30秒経過後に、SOAHOST2上のノード・マネージャによって、WLS_OSB1の浮動IPを起動し、そのサーバーをこのノード上で再起動することが要求されます。
仮想ホスト名を使用してOSBコンソールにアクセスします。次に例を示します。
```
soahost1vhn1.mycompany.com/soa-infra/
```

前述の手順に従って、管理対象サーバーWLS_OSB2、WLS_SOA1およびWLS_SOA2のサーバー移行をテストします。

表13-2は、管理対象サーバーおよび障害発生時にそれらの移行先となるホストを示しています。

表13-2 管理対象サーバーの移行

管理対象サーバー	移行元	移行先
WLS_OSB1	SOAHOST1	SOAHOST2
WLS_OSB2	SOAHOST2	SOAHOST1
WLS_SOA1	SOAHOST1	SOAHOST2
WLS_SOA2	SOAHOST2	SOAHOST1

管理コンソールからの検証

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

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

移行ステータス表に、移行のステータスに関する情報が表示されます。

注意:

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

13.8 サーバー移行構成のバックアップ

サーバー移行構成をバックアップします。詳細は、第14.8項「Oracle SOAエンタープライズ・デプロイメントのバックアップ」を参照してください。