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

この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。

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

第14.1項「エンタープライズ・デプロイメント用のサーバー移行の概要」
第14.2項「サーバー移行リース表のユーザーと表領域の設定」
第14.3項「管理コンソールを使用したリース用のGridLinkデータ・ソースの作成」
第14.4項「ノード・マネージャのプロパティ・ファイルの編集」
第14.5項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」
第14.6項「サーバー移行ターゲットの構成」
第14.7項「サーバー移行のテスト」

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

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

次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。

14.2 サーバー移行リース表のユーザーと表領域の設定

create tablespace leasingコマンドを使用して、サーバー移行リース表のユーザーおよび表領域を設定します。

サーバー移行リース表のユーザーおよび表領域を設定する手順は次のとおりです。

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スクリプトを使用してleasing表を作成します。
1. 次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。
```
WL_HOME/server/db/oracle/817
WL_HOME/server/db/oracle/920
```
2. leasingユーザーとしてデータベースに接続します。
3. leasing.ddlスクリプトをSQL*Plusで実行します。
```
SQL> @copy_location/leasing.ddl;
```

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

Oracle WebLogic Server管理コンソールからリース表用のGridLinkデータ・ソースを作成します。

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

Oracle WebLogic Server管理コンソールにログインします。
まだ行っていない場合は、「チェンジ・センター」で「ロックして編集」をクリックし、「次へ」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
「データ・ソースのサマリー」ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次を入力します。
- 「名前」フィールドにデータ・ソースの論理名を入力します。たとえば、leasingです。
- JNDIの名前を入力します。たとえば、jdbc/leasingです。
- 「データベース・ドライバ」には、OracleのGridLink接続用ドライバ(Thin) バージョン 11以降を選択します。
- 「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「GridLinkデータ・ソース接続プロパティのオプション」で「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

次の接続プロパティを入力します。

サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACサービス名を入力します。例:
```
wcpedg.mycompany.com
```

ホスト名およびポート: 使用しているRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用しデータベースで適切なパラメータを問い合せることによって特定できます。

NAME                 TYPE        VALUE
 
--------------------------------------------------
 
remote_listener     string db-scan.mycompany.com:1521

注意:

Oracle Database 11g R1では、次のように、各データベースのインスタンス・リスナーにVIPとポートを使用します。

custdbhost1-vip.mycompany.com (port 1521)

および

custdbhost2-vip.mycompany.com (1521)

データベース・ユーザー名: leasing。
パスワード: welcome1など。
パスワードの確認: 再度パスワードを入力し、「次へ」をクリックします。

「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。正常に接続された場合の通知例を次に示します。
```
Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.mycompany.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=wcpedg.mycompany.com))) succeeded.
```
「次へ」をクリックします。

「ONSクライアント構成」ページで、次の手順を実行します。

「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
データベースよりレポートされたRACデータベースとONSリモート・ポートのSCANアドレスもここに入力し(例は下を参照)、「ADD」をクリックします。
```
[orcl@db-scan ~]$ srvctl config nodeapps -s
 
ONS exists: Local port 6100, remote port 6200, EM port 2016
```
「次へ」をクリックします。

注意:

Oracle Database 11g R1には、各データベースのONSサービスのホスト名とポートを次のように使用します。

custdbhost1.mycompany.com (port 6200)

および

custdbhost2.mycompany.com (6200)

「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

正常に接続された場合の通知例を次に示します。
```
Connection test for db-scan.mycompany.com:6200 succeeded.
```
「次へ」をクリックします。
「ターゲットの選択」ページで「SOA_Cluster」をターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。

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

サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。

WL_HOME/common/nodemanager

次のプロパティを追加してサーバー移行が正常に動作するようにします。

Interface

Interface=eth0

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

注意:

サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0も:1も指定しないで使用します。ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

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

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

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

注意:

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

nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。

注意:

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

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

wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定するには、次の手順を実行します。

表14-1に示すファイルをPATH環境変数で指定していることを確認します。

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

ファイル	ディレクトリの場所
`wlsifconfig.sh`	ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration
`wlscontrol.sh`	WL_HOME/common/bin
`nodemanager.domain`	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権限とシステム権限については、システム管理者に問い合せてください。

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

サーバー移行ターゲットを構成します。「クラスタの移行の構成」では、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。

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

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

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

Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「変更のアクティブ化」をクリックします。
管理サーバーと、サーバー移行が構成されているサーバーを再起動します。

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

ヒント:

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

14.7 サーバー移行のテスト

サーバーの移行が適切に行われていることを確認する手順は次のとおりです。

ノード1からテストする手順は次のとおりです。

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

ノード2からテストする手順は次のとおりです。

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

管理コンソールでの確認

管理コンソールを使用して移行を検証することも可能です。

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

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

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

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

注意:

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