ヘッダーをスキップ
Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド
リリースEL X2-2、X3-2、X4-2およびX5-2
E51446-03
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

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

サーバー移行を構成すると、SOAおよびOIMの管理対象サーバーを別のホストに移行できるようになるため、サーバーの1つをホストしているノードが失敗しても、サービスは別のノード上で継続されます。この章では、アイデンティティ管理のエンタープライズ・デプロイメントで、サーバー移行を構成する方法について説明します。

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

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 Serverの移行によってフェイルオーバーされる特定のフローティングIPでリスニングします。

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

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

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


注意:

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

  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管理コンソールを使用したリースのためのGridLinkデータ・ソースの作成

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

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

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

  2. 「チェンジ・センター」で「ロックして編集」をクリックします(選択されていない場合)。

  3. 「ドメイン構造」ツリーで、「サービス」を展開してから、Data Sourcesを選択します。

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

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

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

    • データベース・ドライバ: データベース・ドライバの場合*OracleのGridLink接続用ドライバ(Thin)、バージョン:11以降を選択を選択します。

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

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

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

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

    • サービス名: 小文字のデータベース・サービス名を入力します。GridLinkデータ・ソースの場合は、Oracle RACのサービス名を入力する必要があります。次に例を示します。

      oamedg.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およびポートを使用します。たとえば、CUSTDBHOST1-VIP.mycompany.com (ポート1521)やCUSTDBHOST2-VIP.mycompany.com (ポート1521)です。1521はDB_LSNR_PORTです。

      Oracle Database 10gの場合、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、付録B「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=PS5oamedg.mycompany.com))) succeeded.

    ポート1521はDB_LSNR_PORTです。

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

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

    • 「FANの有効化」を選択して、Oracle FANイベントにサブスクライブしてこれらのイベントを処理します。

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

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

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


    注意:

    Oracle Database 11gリリース1 (11.1)の場合、各データベースのONSサービスのホスト名およびポートを使用します。次に例を示します。

    CUSTDBHOST1.mycompany.com (port 6200)

    および

    CUSTDBHOST2.mycompany.com (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ファイルは、次のディレクトリにあります。

/u02/private/oracle/config/nodemanager

サーバー移行が適切に動作できるようにするためには、次のプロパティを追加します。

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

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

注意:

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

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

  2. /u02/private/oracle/config/nodemanager/server/binディレクトリにあるstartNodeManager.shスクリプトを実行して、IDMHOST1およびIDMHOST2でノード・マネージャを起動します。


注意:

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

export JAVA_OPTIONS=-DInterface=bond3

環境変数がシェルに設定された後、ノード・マネージャを起動します。

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

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

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

表14-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

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

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

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

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

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

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

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

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

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

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

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

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

  10. SOAクラスタに対して手順2から9を繰り返します。

  11. サーバー移行の候補マシンを設定します。次のように、すべての管理対象サーバーについてこのタスクを実行する必要があります。

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

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

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

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

    5. 「Migration Configuration」セクションにある「Available」フィールドで、移行を許可するマシンを選択し、右矢印をクリックします。WLS_OIM1の場合は、IDMHOST2を選択します。WLS_OIM2の場合は、IDMHOST1を選択します。

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

      これにより、ノード・マネージャによって、障害が発生したサーバーをターゲット・ノードで自動的に起動できるようになります。

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

    8. WLS_SOA1およびWLS_SOA2管理対象サーバーについて、前述の手順を繰り返します。

    9. 第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、サーバー移行を構成した管理対象サーバーを再起動します。


      注意:

      特定のマシンに対してのみ移行を許可する場合は、クラスタの候補を指定せずに、サーバーごとに候補を指定します。

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. 左のコンソールで、「ドメイン」をクリックします。

  3. 「モニタリング」タブをクリックし、「移行」サブタブをクリックします。

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


注意:

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

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

第16.6項「Oracle IDMエンタープライズ・デプロイメントのバックアップ」の説明に従って、データベースおよびWebLogicドメインをバックアップします。

  前
前 		 次
次
  ドキュメント・ライブラリへ移動
ライブラリ		 製品リストへ移動
製品		 目次へ移動
目次		 索引へ移動
索引