Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11gリリース1(11.1.1) B55899-01 |
|
戻る |
次へ |
このエンタープライズ・トポロジでは、WLS_SOA1およびWLS_SOA2管理対象サーバー用のサーバーの移行を構成する必要があります。WLS_SOA1管理対象サーバーは障害時にSOAHOST2で再起動するように構成されます。WLS_SOA2管理対象サーバーは障害時にSOAHOST1で再起動するように構成されます。この構成では、WLS_SOA1およびWLS_SOA2サーバーは、WLSサーバーの移行によってフェイルオーバーされる特定の浮動IPをリスニングします。WLS_SOAn管理対象サーバーのサーバー移行を構成する手順は次のとおりです。
手順6: サーバー移行ターゲットの構成
手順7: サーバー移行のテスト
手順1では、サーバー移行リース・テーブルのユーザーと表領域を設定します。
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スクリプトを使用してリース・テーブルを作成します。
ORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracle/817
ディレクトリまたはORACLE_BASE/product/fmw/wlserver_10.3/server/db/oracle/920
ディレクトリにあるleasing.ddl
ファイルをデータベース・ノードにコピーします。
leasing
ユーザーとしてデータベースに接続します。
leasing.ddl
スクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
手順2では、Oracle Weblogic Server管理コンソールを使用して、リース・テーブルのマルチ・データ・ソースを作成します。
マルチデータソースの設定プロセス中に、各RACデータベース・インスタンスのデータソースを、これらのデータソースとグローバル・リース・マルチデータソースの両方に対して作成します。データ・ソースを作成する手順は次のとおりです。
該当のソースが非XAデータソースであることを確認します。
マルチ・データ・ソースの名前は、<MultiDS>-rac0や<MultiDS>-rac1という形式にします。
Oracleのドライバ(Thin)バージョン9.0.1、9.2.0、10または11を使用します。
「グローバル・トランザクションのサポート」、「1フェーズ・コミット」を使用し、データベースのサービス名を指定します。
これらのデータ・ソースのターゲットをSOAクラスタに設定します。
マルチ・データ・ソースの作成
マルチ・データ・ソースを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「サービス」ノードを開き、「JDBC」ノードを開きます。
「マルチ・データ・ソース」をクリックします。「JDBCマルチ・データ・ソースの概要」ページが表示されます。
「ロックして編集」をクリックします。
「新規」をクリックします。「新しいJDBCマルチ・データ・ソースの作成」ページが表示されます。
「新規」をクリックします。
「名前」にleasingと入力します。
「JNDI名」にjdbc/leasingと入力します。
アルゴリズムとして「フェイルオーバー」を選択します(デフォルト)。
「次」をクリックします。
「ターゲット」に「BAM_Cluster」を選択します。
「次へ」をクリックします。
「非XAドライバ」を選択します(デフォルト)。
「次へ」をクリックします。
「新しいデータ・ソースの作成」をクリックします。
「名前」にleasing-rac0と入力します。「JNDI名」にjdbc/leasing-rac0と入力します。「データベース・タイプ」にoracleと入力します。ドライバのタイプには、「Oracle driver (Thin) for RAC Service-Instance connections, Versions:10, 11」を選択します。
注意: リース・テーブル用のマルチ・データ・ソースを作成する場合、その名前は<MultiDS>-rac0や<MultiDS>-rac1という形式にします。 |
「次へ」をクリックします。
「グローバル・トランザクションのサポート」の選択を解除します。
「次へ」をクリックします。
リース・スキーマについて、サービス名、データベース名、ホスト・ポートおよびパスワードを入力します。
「次へ」をクリックします。
「構成のテスト」をクリックして接続できることを確認します。
データ・ソースをSOA_Clusterにターゲット設定します。
データ・ソースを選択して右側の画面に追加します。
RACデータベースの最初のインスタンスに対して「新しいデータ・ソースの作成」をクリックし、そのデータ・ソースをBAM_Clusterにターゲット設定します。2番目のRACデータベース・インスタンスでも、この手順を実行します。
使用するマルチ・データ・ソースに2番目のデータ・ソースを追加します。
「変更のアクティブ化」をクリックします。
手順3では、ノード・マネージャと管理サーバー間でのホスト名検証に適切な証明書を作成します。この手順の詳細は、第7.2項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」および第7.4項「SOAHOST2でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
手順4では、ノード・マネージャのプロパティ・ファイルを編集します。このファイルは、nodemanager.properties
という名前のファイルで、ORACLE_BASE/product/fmw/wlserver_10.3/common/nodemanager
ディレクトリにあります。サーバーの移行が適切に機能するには、次に示すプロパティを追加する必要があります。
Interface=eth0
NetMask=255.255.255.0
UseMACBroadcast=true
Interface
このプロパティは浮動IP(eth0など)のインタフェース名を指定します。
NetMask
このプロパティは浮動IP用インタフェースのネット・マスクを指定します。このネット・マスクは、インタフェースのネット・マスクと同じにする必要があります。このドキュメントの例では、255.255.255.0を使用します。
UseMACBroadcast
このプロパティはARPパケットを送信する際にノードのMACアドレスを使用するかどうかを指定します。つまり、arping
コマンドで-bフラグを使用するかどうかを指定します。
ノード・マネージャの出力(ノード・マネージャを起動するシェル)で、これらのプロパティが使用されていることを確認してください。使用されていない場合は、移行中に問題が発生することがあります。ノード・マネージャの出力には次のような行が含まれます。
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
注意: サーバーのプロパティ(起動プロパティ)が適切に設定されており、ノード・マネージャがサーバーをリモートで起動できる場合には、次の手順は必要ありません。 |
nodemanager.properties
ファイルで次のプロパティを設定します。
StartScriptEnabled
このプロパティはtrue
に設定します。これは、ノード・マネージャが管理対象サーバーを起動できるようにするためにShiphometに必要なものです。
ORACLE_BASE/ product/fmw/wlserver_10.3/server/bin/
ディレクトリにあるstartNodeManager.sh
スクリプトを実行し、ノード1とノード2でノード・マネージャを起動します。
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じnodemanager.properties ファイルを使用する複数のノードが起動します。ただし、NetMask プロパティやInterface プロパティにはノードごとに異なる値が必要です。この場合、環境変数を使用してノードごとに個別のパラメータを指定します。たとえば、SOAHOSTnで異なるインタフェース(eth3)を使用するには、SOAHOSTn> export JAVA_OPTIONS=-DInterface=eth3 としてInterface 環境変数を使用します。この環境変数をシェルに設定した後、ノード・マネージャを起動します。 |
手順5では、wlsifconfig.sh
スクリプトの環境とスーパー・ユーザー権限を設定します。
PATH環境変数に次のファイルが含まれていることを確認します。
sudoの構成をwlsifconfig.sh
スクリプトに付与します。
パスワードの要求がなくても動作するようにsudoを構成します。
セキュリティ上の理由から、sudoの付与はwlsifconfig.sh
スクリプトの実行に必要なコマンドの一部に限定する必要があります。たとえば、wlsifconfig.sh
スクリプトの環境とスーパー・ユーザー権限を設定する手順は次のとおりです。
パスワードによる制限を設けずにsudo権限をWebLogicユーザー(oracle)に付与し、/sbin/ifconfigバイナリおよび/sbin/arpingバイナリの実行権限を付与します。
WebLogicユーザー(oracle)がこのスクリプトを実行できることを確認します。sudo実行権限をoracle
およびifconfig
とarping
に付与するエントリを記述した/etc/sudoersの例を次に示します。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
注意: この手順に適するsudo権限とシステム権限については、システム管理者に問い合せてください。 |
手順6では、サーバー移行ターゲットを構成します。クラスタの移行を構成すると、DataSourceForAutomaticMigration
プロパティがtrueに設定されます。次の手順に従って、クラスタ内の移行でクラスタの移行を構成します。
http://<host>:<adminPort>/console
のOracle WebLogic Server管理コンソールにログインします。通常、adminPort
はデフォルトの7001です。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。
「移行」タブをクリックします。
「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。
自動移行に使用するデータソースを選択します。この場合は、リース・データソースを選択します。
「保存」をクリックします。
サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ターゲット・ノードで障害の発生したサーバーをノード・マネージャが自動的に起動できるようになります。
「保存」をクリックします。
管理サーバーを再起動します。
ヒント: 「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、実際の構成と異なる内容が表示されます。 |
最後に、手順7でサーバー移行をテストします。サーバーの移行が適切に行われていることを確認する手順は次のとおりです。
ノード1で次の操作を実行します。
WLS_SOA1管理対象サーバーを停止します。
停止するには、次のコマンドを実行します。
SOAHOST1> kill -9 <pid>
PIDには管理対象サーバーのプロセスIDを指定します。ノード内のPIDは、次のコマンドを実行して識別できます。
SOAHOST1> ps -ef | grep WLS_SOA1
ノード・マネージャのコンソールを確認します。WLS_SOA1の浮動IPが無効になったことを示すメッセージが表示されます。
ノード・マネージャがWLS_SOA1の2回目の再起動を試行するまで待機します。ノード・マネージャは30秒間待機してからこの再起動を試行します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーがローカルで再び再起動されないことを示すメッセージがノード・マネージャによってログに記録されます。
ノード2で次の操作を実行します。
ローカル・ノード・マネージャのコンソールを確認します。ノード1でのWLS_SOA1の再起動が前回試行されてから30秒間経過した後に、WLS_SOA1の浮動IPが表示され、サーバーをこのノードで再起動することを示すメッセージがノード2のノード・マネージャにより表示されます。
同じIPでsoa-infraコンソールにアクセスします。
移行は次のように管理コンソールで確認することもできます。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。