| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B55899-07 |
|
前 |
次 |
この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。
この章の項目は次のとおりです。
管理対象サーバーWLS_SOA1およびWLS_SOA2のサーバー移行を構成します。サーバー移行が構成されていると、障害が発生したときに、WLS_SOA1管理対象サーバーがSOAHOST2で再起動し、WLS_SOA2管理対象サーバーがSOAHOST1で再起動します。WLS_SOA1およびWLS_SOA2サーバーは、Oracle WebLogic Serverによってフェイルオーバーされる特定の浮動IPをリスニングします。
次の項の手順を実行し、管理対象サーバーのサーバー移行を構成します。
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.ddlファイルを、データベース・ノードにコピーします。
WL_HOME/server/db/oracle/817 WL_HOME/server/db/oracle/920
Leasingユーザーとしてデータベースに接続します。
leasing.ddlスクリプトをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
Oracle WebLogic Server管理コンソールでリース・テーブルのGridLinkデータ・ソースを作成します。
GridLinkデータ・ソースを作成する手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
「チェンジ・センター」の「ロックして編集」をまだ選択していない場合は選択して、「次へ」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。
「名前」フィールドにデータ・ソースの論理名を入力します。例: Leasing
JNDIの名前を入力します。例: jdbc/leasing
データベース・ドライバには、Oracle Driver (Thin) for GridLink Connections Versions: 11以上を選択します。
「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
次の接続プロパティを入力します。
サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:
soaedg.mycompany.com
ホスト名とポート: 使用中のRACデータベースのSCANアドレスとポートを入力します。このアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せれば識別できます。
SQL>show parameter remote_listener; NAME TYPE VALUE -------------------------------------------------- remote_listener string db-scan.mycompany.com
|
注意: Oracle Database 11g リリース1 (11.1) では、次の例のように、各データベースのインスタンス・リスナーの仮想IPとポートを使用します。 custdbhost1-vip.mycompany.com (port 1521) および custdbhost2-vip.mycompany.com (1521) Oracle Database 10gでは、Oracle RACデータベースへの接続にマルチ・データ・ソースを使用します。マルチ・データ・ソースの構成の詳細は、付録A「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。 |
ポート: データベース・サーバーが接続リクエストをリスニングするポートを入力します。
データベース・ユーザー名: 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=ps5soaedg.mycompany.com))) succeeded.
「次へ」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
ここにも、データベースから報告されたRACデータベースのSCANアドレスおよびONSリモート・ポートを次のように入力し、「追加」をクリックします。
[orcl@db-scan1 ~]$ 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) |
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続が成功したときに表示される通知の一例を示します。
Connection test for db-scan.mycompany.com:6200 succeeded.
「次へ」をクリックします。
「ターゲットの選択」ページでSOA_Clusterをターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
ノード・マネージャと管理サーバー間でのホスト名検証に適切な証明書を作成します。この手順の詳細は、第13.3項「SOAHOST1でのノード・マネージャに対するホスト名検証証明書の有効化」を参照してください。
サーバーが稼働している2つのノード上でノード・マネージャのプロパティ・ファイルを編集します。nodemanager.propertiesファイルは次のディレクトリにあります。
WL_HOME/common/nodemanager
次のプロパティを追加してサーバー移行が正常に動作するようにします。
Interface
Interface=eth0
このプロパティは浮動IP(eth0など)のインタフェース名を指定します。
|
注意:
|
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でノード・マネージャを起動します。
|
注意: 共有記憶域のインストールからノード・マネージャを実行している場合、同じ |
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限を設定します。
表14-1に示すファイルをPATH環境変数で指定していることを確認します。
表14-1 PATH環境変数に必要なファイル
| ファイル | ディレクトリの場所 |
|---|---|
|
|
ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration |
|
|
WL_HOME/common/bin
|
|
|
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
サーバー移行ターゲットを構成します。クラスタ移行を構成することにより、DataSourceForAutomaticMigrationプロパティがtrueに設定されます。
クラスタ内の移行を構成する手順は次のとおりです。
http://<host>:<adminPort>/consoleのOracle WebLogic Server管理コンソールにログインします。通常、adminPortはデフォルトの7001です。
「ドメイン構造」ウィンドウの「環境」を開き、「クラスタ」を選択します。「クラスタの概要」ページが表示されます。
表の「名前」列で、移行を構成するクラスタ(SOA_Cluster)をクリックします。
「移行」タブをクリックします。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。この場合は、「SOAHOST1」と「SOAHOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、リース・データソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
「移行」タブをクリックします。
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。「WLS_SOA1」に対しては「SOAHOST2」を選択します。「WLS_SOA2」に対しては「SOAHOST1」を選択します。
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
「変更のアクティブ化」をクリックします。
管理サーバーと、サーバー移行が構成されているサーバーを再起動します。
管理サーバーを再起動するには、第8.4.3項「SOAHOST1での管理サーバーの起動」の手順を使用します。
|
ヒント: 「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。 |
サーバーの移行が適切に行われていることを確認する手順は次のとおりです。
ノード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コンソールにアクセスします。
管理コンソールを使用して移行を検証することも可能です。
管理コンソールにログインします。
左のコンソールで「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行の状態」の表に、移行の状態に関する情報が表示されます。
|
注意: サーバーの移行後、そのサーバーを元のノード/マシンにフェイルオーバーするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。 |
