Oracle® Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド 11gリリース1(11.1.1) B61378-01 |
|
戻る |
次へ |
この高可用性トポロジでは、管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバーの移行を構成する必要があります。管理対象サーバーWLS_OIM1およびWLS_SOA1は、障害発生時にOIMHOST2上で再起動されるように構成されます。管理対象サーバーWLS_OIM2およびWLS_SOA2は、障害発生時にOIMHOST1上で再起動されるように構成されます。この構成のため、サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2およびWLS_SOA2は、WLSサーバーの移行によってフェイルオーバーされる特定の浮動IP上でリッスンします。管理対象サーバーに対してサーバーの移行を構成する手順を次に示します。
次の手順により管理対象サーバーWLS_OIM1、WLS_SOA1、WLS_OIM2、WLS_SOA2に対してサーバーの移行を構成できます。これによりサーバーやプロセスでの障害発生時に管理対象サーバーは別のノードにフェイルオーバーされます。
最初の手順では、サーバー移行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」という名のユーザーを作成し、それに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表を作成します。
WL_HOME/server/db/oracle/817ディレクトリまたはWL_HOME/server/db/oracle/920ディレクトリのleasing.ddlファイルを自身のデータベース・ノードにコピーします。
leasingユーザーとしてデータベースに接続します。
SQL*Plusでleasing.ddlスクリプトを実行します。
SQL> @Copy_Location/leasing.ddl;
2番目の手順では、Oracle WebLogic Server管理コンソールからleasing表用のマルチ・データ・ソースを作成します。マルチ・データ・ソースの設定プロセス中に、各Oracle RACデータベース・インスタンスのデータ・ソースを、これらのデータ・ソースとグローバル・リース・マルチ・データ・ソースの両方に対して作成します。データ・ソースを作成する前に、次の準備が必要です。
XA以外のデータ・ソースであることを確認します。
マルチ・データ・ソース名は<MultiDS>-rac0や<MultiDS>-rac1などの形式で指定します。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10、11を使用します。
データ・ソースはグローバル・トランザクションのサポートを必要としません。このため、データ・ソースに対してどのような分散トランザクション・エミュレーション/参加アルゴリズムも使用しないでください(「グローバル・トランザクションのサポート」オプションの「ロギング・ラスト・リソース」、「2フェーズ・コミットのエミュレート」または「1フェーズ・コミット」オプション、または「グローバル・トランザクションのサポート」オプションを選択しないでください)。データベースのサービス名を指定します。
これらのデータ・ソースのターゲットをOIM_CLUSTERおよびSOA_CLUSTERに設定します。
接続プールの初期容量が0(ゼロ)に設定されていることを確認します。それには、「サービス」、「JDBC」、「データ・ソース」の順に選択します。「データ・ソース」画面で、「データソース名」、「接続プール」タブの順に選択して、「初期容量」フィールドに「0」(ゼロ)を入力します。
マルチ・データ・ソースを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノード、「JDBC」ノードの順に展開します。
「マルチ・データ・ソース」をクリックします。「JDBCマルチ・データ・ソースの概要」ページが表示されます。
「ロックして編集」をクリックします。
「新規」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
名前として「leasing
」を入力します。
JNDI名として「jdbc/leasing
」を入力します。
アルゴリズムとして「フェイルオーバー」を選択します(デフォルト)。
「次へ」をクリックします。
ターゲットとしてOIM_CLUSTERおよびSOA_CLUSTERを選択します。
「次へ」をクリックします。
「非XAドライバ」(デフォルト)を選択します。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
名前として「leasing-rac0
」を入力します。JNDI名として「jdbc/leasing-rac0
」を入力します。データベース・タイプとして「oracle
」を入力します。ドライバ・タイプには、Oracle RACサーバー・インスタンス接続用Oracleドライバ(Thin)バージョン10、11を選択します。
注意: leasing表用のマルチ・データ・ソースを作成するときには、名前を<MultiDS>-rac0や<MultiDS>-rac1などの形式で入力します。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」を選択解除します。
「次へ」をクリックします。
リース・スキーマについて、サービス名、データベース名、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして、接続できることを確認します。
「次へ」をクリックします。
データ・ソースをOIM_CLUSTERおよびSOAクラスタにターゲット設定します。
データ・ソースを選択して右側の画面に追加します
Oracle RACデータベースの2番目のインスタンスに対して「新しいデータ・ソースの作成」をクリックし、そのデータ・ソースをOIM_CLUSTERおよびSOA_CLUSTERにターゲット設定します。Oracle RACデータベースの2番目のインスタンスに対して、この手順を繰り返します
2番目のデータ・ソースをマルチ・データ・ソースに追加します。
「変更のアクティブ化」をクリックします。
この手順では、ノード・マネージャのプロパティ・ファイルを編集します。これはサーバーの移行が構成される両方のノード(OIMHOST1およびOIMHOST2)のノード・マネージャに対して実行する必要があります。
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に設定します。これは、ノード・マネージャが管理対象サーバーを起動するために必要です。
WL_HOME/server/binディレクトリ下のstartNodeManager.sh
スクリプトを実行し、OIMHOST1とOIMHOST2でノード・マネージャを起動します。
注意: 共有記憶域のインストールからノード・マネージャを実行する場合、同じnodemanager.properties ファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティやInterfaceプロパティが必要な場合があります。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、HOSTnで異なるインタフェース(eth3)を使用するには、Interface環境変数の「HOSTn> export JAVA_OPTIONS=-DInterface=eth3 」を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。 |
4番目の手順では、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定します
PATH環境変数に次のファイルが含まれていることを確認します。
sudoの構成をwlsifconfig.sh
スクリプトに付与します。
パスワードの要求がなくても動作するようにsudoを構成します。
セキュリティ上の理由から、sudo権限の付与はwlsifconfig.sh
スクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、次の手順に従ってwlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します
パスワードによる制限なしにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。次は、/etc/sudoers内部にあるエントリの例を示します。このエントリでは、oracle
のsudo実行権限をifconfig
とarping
に対して付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
注意: この手順に適切なsudo権限とシステム権限については、システム管理者に問い合せてください。 |
6番目の手順では、サーバー移行ターゲットを構成します。まず、すべての使用可能なノードをクラスタのメンバーに割り当て、次に、サーバー移行用に構成された各サーバーに候補となるマシン(適切な順序で)を指定します。次の手順に従って、クラスタ内の移行でクラスタの移行を構成します。
http://Host:Admin_Port/consoleでOracle WebLogic Server管理コンソールにログインします。通常、Admin_Portはデフォルトで7001です。
「ドメイン構造」ウィンドウで「環境」ノードを開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
移行を構成するクラスタ(OIM_CLUSTER)を表の「名前」列でクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この例では、「OIMHOST1」と「OIMHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、リース・データ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
ヒント: 「サーバーのサマリー」ページの「この表のカスタマイズ」をクリックしてから、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動して、サーバーを実行しているマシンを確認します。このサーバーが自動的に移行すると、構成と異なる内容になります。 |
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。WLS_OIM1の場合は、「OIMHOST2」を選択します。WLS_OIM2の場合は、「OIMHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャはターゲット・ノード上で障害発生サーバーを自動的に起動できます。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
管理対象サーバーWLS_SOA1およびWLS_SOA2に対して前述の手順を繰り返します。
管理サーバー、ノード・マネージャ、サーバー移行用に構成されたサーバーを再起動します。
最後の手順では、サーバー移行をテストします。サーバーの移行が適切に行われていることを確認するには次の手順を実行します。
OIMHOST1で次の操作を実行します。
WLS_OIM1管理対象サーバーを停止します。これには、次のコマンドを実行します。
OIMHOST1> kill -9 pid
pidは、その管理対象サーバーのプロセスID(PID)を指定します。次のコマンドを実行すると、ノードのPIDを識別できます。
OIMHOST1> ps -ef | grep WLS_OIM1
ノード・マネージャのコンソールを確認します。WLS_OIM1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_OIM1の2回目の再起動を試行するまで待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャでサーバーを再起動したら、再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。
OIMHOST2で次の操作を実行します。
ローカルのノード・マネージャ・コンソールを確認します。OIMHOST1でのWLS_OIM1の再起動が前回試行されてから30秒間経過した後に、WLS_OIM1の浮動IPが表示されサーバーをこのノードで再起動することを示すメッセージがOIMHOST2のノード・マネージャにより表示されます。
同じIPでsoa-infraコンソールにアクセスします。
前述の手順により管理対象サーバーWLS_OIM2、WLS_SOA1、WLS_SOA2に対してサーバーの移行をテストできます。
表17-2は、移行に失敗した管理対象サーバーとホストの例を示しています。
表17-2 WLS_OIM1、WLS_OIM2、WLS_SOA1、WLS_SOA2サーバーの移行
管理対象サーバー | 移行元 | 移行先 |
---|---|---|
WLS_OIM1 |
OIMHOST1 |
OIMHOST2 |
WLS_OIM2 |
OIMHOST2 |
OIMHOST1 |
WLS_SOA1 |
OIMHOST1 |
OIMHOST2 |
WLS_SOA2 |
OIMHOST2 |
OIMHOST1 |
移行は管理コンソールで確認することもできます。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
注意: サーバーが移行された後に、それを元のノードまたはマシンにフェイルバックさせるには、Oracle WebLogic管理コンソールから管理対象サーバーを停止して、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |