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

サーバー移行を構成すると、SOAおよびOIMで管理されているサーバーをあるホストから別のホストに移行できるようになります。これにより、いずれかのサーバーをホストしているノードに障害が発生しても、他のノードでサービスを継続できます。この章では、Identity Managementのエンタープライズ・デプロイメントでサーバー移行を構成する方法について説明します。

この章で説明する手順は次のとおりです。

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

• 第14.2項「サーバー移行leasing表のユーザーと表領域の設定」

• 第14.3項「Oracle WebLogic管理コンソールを使用したLeasingのGridLinkデータ・ソースの作成」

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

• 第14.5項「wlsifconfig.shスクリプトの環境権限とスーパーユーザー権限の設定」

• 第14.6項「サーバー移行ターゲットの構成」

• 第14.7項「サーバー移行のテスト」

• 第14.8項「サーバー移行構成のバックアップ」

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

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

次の項の手順を実行し、WLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2の管理対象サーバーのサーバー移行を構成します。

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

この項では、サーバー移行leasing表のためのユーザーと表領域を設定します。

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

1. 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;
   

2. 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;
   

3. 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;
      

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

この項では、Oracle WebLogic Server管理コンソールでリース表のGridLinkデータ・ソースを作成します。

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

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。

3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。

4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

   • 名前: データ・ソースの論理名を入力します。たとえば、leasingです。

   • 「JNDI」: JNDIの名前を入力します。たとえば、jdbc/leasingです。

   • データベース・ドライバ: データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。

   • 「次へ」をクリックします。

5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。

6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。

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

   • サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、OIMEDG.mycompany.comです。

   • ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。

     show parameter remote_listener;
     
     NAME                 TYPE        VALUE
      
     --------------------------------------------------
      
     remote_listener     string      DB-SCAN.mycompany.com:1521
     

     
     

     注意: Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: DBHOST1-VIP.mycompany.com (ポート1521)およびDBHOST2-VIP.mycompany.com (ポート1521)、ここでの1521はDB_LSNR_PORTです。 Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

     
     

   • データベース・ユーザー名: leasing。

   • パスワード: たとえば、welcome1などを入力します。

   • パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続が成功したときに表示される通知の一例を示します。

   Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=DB-SCAN.mycompany.com)
   (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=OIMEDG.mycompany.com))) succeeded.
   

   ここでの1521はDB_LSNR_PORTです。

   「次へ」をクリックします。

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

   • 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

   • ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。

     srvctl config nodeapps -s
      
     ONS exists: Local port 6100, remote port 6200, EM port 2016
     

   • 「次へ」をクリックします。

   
   

   注意: Oracle Database 11g リリース1 (11.1)では、次の例のように、各データベースのONSサービスのホスト名とポートを使用します。 DBHOST1.mycompany.com (port 6200) および DBHOST2.mycompany.com (port 6200)

   
   

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

    接続が成功したときに表示される通知の一例を示します。

    Connection test for DB-SCAN.mycompany.com:6200 succeeded.
    

    「次へ」をクリックします。

11. 「ターゲットの選択」ページで、ターゲットとしてoim_clusterおよびsoa_clusterを選択し、「クラスタのすべてのサーバー」を選択します。

12. 「終了」をクリックします。

13. 「変更のアクティブ化」をクリックします。

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

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

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
eth0=*,NetMask=255.255.255.0
UseMACBroadcast=true

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

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

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

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

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

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

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

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

ファイル	ディレクトリの場所
wlsifconfig.sh	MSERVER_HOME/bin/server_migration
wlscontrol.sh	WL_HOME/common/bin
nodemanager.domains	WL_HOME/common/nodemanager

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

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

注意: この手順の実行に適するsudo権限とシステム権限については、システム管理者に問い合せてください。

スクリプトがWebLogicユーザー(oracle)によって実行可能であることを確認してください。sudo実行権限をoracleおよびifconfigとarpingに付与するエントリを記述した/etc/sudoersの例を次に示します。

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

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

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

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

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

1. 第17.2項「Identity ManagementコンソールのURLについて」に記載されているURLを使用して、Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで「環境」ノードを開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

3. 表の「名前」列で、移行を構成するクラスタ(oim_cluster)をクリックします。

4. 「移行」タブをクリックします。

5. 「ロックして編集」をクリックします。

6. 「使用可能」フィールドで、移行先として許可するマシン(IDMHOST1およびIDMHOST2)を選択して、右向き矢印をクリックします。

7. 自動移行に使用するデータ・ソースを選択します。この場合は、リース・データ・ソースを選択します。

8. 「保存」をクリックします。

9. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

10. 移行を構成するサーバーを選択します。

11. 「移行」タブをクリックします。

12. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

13. 「変更のアクティブ化」をクリックします。

14. SOAクラスタについて手順2 - 13を繰り返します。

15. 第17.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、WebLogic管理サーバー、ノード・マネージャ、およびサーバー移行を構成したサーバーを再起動します。

14.7 サーバー移行のテスト

この項では、サーバー移行をテストします。サーバーの移行が適切に行われていることを確認するには次の手順を実行します。

IDMHOST1からテストするには:

1. WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。

   kill -9 pid
   

   pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノードのPIDを識別できます。

   ps -ef | grep WLS_OIM1
   

2. ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。

3. ノード・マネージャがWLS_OIM1の2回目の再起動を試行するのを待ちます。この再起動を試行するまでに30秒間待機します。

4. ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。

IDMHOST2からテストするには:

1. ローカルのノード・マネージャ・コンソールを確認します。IDMHOST1でWLS_OIM1の再起動が最後に試行されてから30秒経過した後、IDMHOST2のノード・マネージャによって、WLS_OIM1の浮動IPが有効化されていること、およびこのノードでサーバーが再起動されていることが表示されます。

2. 仮想ホスト名を使用してOIMコンソールにアクセスします。例: http://OIMHOST1VHN.mycompany.com:14000/identity

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

表14-2は、管理対象サーバーと、障害が発生した場合のそれらの移行先のホストを示しています。

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

管理対象サーバー	移行元	移行先
WLS_OIM1	IDMHOST1	IDMHOST2
WLS_OIM2	IDMHOST2	IDMHOST1
WLS_SOA1	IDMHOST1	IDMHOST2
WLS_SOA2	IDMHOST2	IDMHOST1

管理コンソールでの確認

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

1. 管理コンソールにログインします。

2. 左側のペインでIDMDomainをクリックします。

3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

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

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

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

第17.6.3項「インストール時および構成時のバックアップの実行」の説明に従って、データベースとWebLogicドメインをバックアップします。