| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1) B66703-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11gリリース1 (11.1.1) B66703-08 |
|
前 |
次 |
この章では、エンタープライズ・デプロイメント用にサーバー移行を構成する手順を説明します。
この章には次の項が含まれます:
Oracle WebLogic Serverの管理対象サーバーではサーバー移行を構成できます。サーバー移行が構成された状態で障害が発生した場合は、各管理対象サーバーを別のホスト・マシン上で再起動できます。管理対象サーバーは、WebLogic Serverによってフェイルオーバーされた特定の浮動IPアドレスをリスニングします。
|
注意: サーバー移行を使用するかどうかまたはサーバー移行が必要かどうかの詳細は、各コンポーネントの章を参照してください。 |
この章に記載されている手順は、第1.1.1項「このガイドに記載されている参照用トポロジ」で説明しているエンタープライズ・デプロイメント・トポロジの様々なコンポーネントで実行する必要があります。
この章では、次の変数を使用して、コンポーネント固有の項目を区別します。
WLS_SERVER1およびWLS_SERVER2は、エンタープライズ・デプロイメント・コンポーネントのWebLogic Server管理対象サーバーを指します。
HOST1およびHOST2は、エンタープライズ・デプロイメント・コンポーネントのホスト・マシンを指します。
CLUSTERは、エンタープライズ・デプロイメント・コンポーネントと関連付けされたクラスタを指します。
これらの変数に使用する値は、このEDGのコンポーネント固有の章に記載されています。
このエンタープライズ・トポロジでは、WLS_SERVER1およびWLS_SERVER2の管理対象サーバーに対してサーバー移行を構成する必要があります。WLS_SERVER1の管理対象サーバーは、障害発生時にHOST2で再起動するように構成されています。WLS_SERVER2の管理対象サーバーは、障害発生時にHOST1で再起動するように構成されています。この構成では、WLS_SERVER1サーバーとWLS_SERVER2サーバーは、WebLogic Serverの移行によりフェイルオーバーされた特定の浮動IPアドレスをリスニングしています。
表17-1は、WebLogic Server管理対象サーバー用のサーバー移行を構成する手順を説明しています。
表17-1 サーバー移行の構成手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
ユーザー、表領域および移行表を設定します。 |
|
第17.2項「サーバー移行leasing表のユーザーと表領域の設定」 |
|
|
Oracle RACデータベースの各インスタンスにデータ・ソースを作成するほか、管理コンソールでグローバルな |
第17.3項「管理コンソールを使用したleasingのGridLinkデータ・ソースの作成」 |
|
ノード・マネージャのプロパティに、移行用の値を指定します。 |
各ホストで |
第17.4項「ノード・マネージャのプロパティ・ファイルの編集」 |
|
環境を設定し、oracleユーザーにスーパー・ユーザー権限を指定します。 |
|
第17.5項「wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定」 |
|
クラスタの移行を構成します。 |
移行ターゲットとして利用可能なノードを割り当て、各サーバーに候補となるマシンを指定します。 |
|
|
サーバー移行のテストを実行します。 |
ノード・マネージャまたは管理コンソールからホスト間のサーバー移行を検証します。 |
|
create tablespace Leasingコマンドを使用して、サーバー移行leasing表のユーザーおよび表領域を設定します。
|
注意: 同じドメイン内の他のサーバーがすでにサーバー移行で構成されている場合、同じ表領域とデータ・ソースを使用できます。その場合、データベース表leasing用のデータ・ソースおよびGridLinkデータ・ソースを再作成する必要はありませんが、サーバー移行用に構成されているクラスタを再度ターゲットに設定する必要があります。 |
サーバー移行リース表のユーザーおよび表領域を設定する手順は次のとおりです。
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 password;
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表を作成します。
次のいずれかのディレクトリにあるleasing.ddlファイルを、データベース・ノードにコピーします。
WL_HOME/server/db/oracle/817/ WL_HOME/server/db/oracle/920/
leasingユーザーとしてデータベースに接続します。
leasing.ddlをSQL*Plusで実行します。
SQL> @copy_location/leasing.ddl;
データベースに加えた変更をコミットします。
SQL> commit;
Oracle WebLogic Server管理コンソールでleasing表のGridLinkデータ・ソースを作成します。
GridLinkデータ・ソースを作成する手順は次のとおりです。
WebLogicサーバーの管理コンソールにログインします。
「チェンジ・センター」の「ロックして編集」をまだクリックしていない場合はこれをクリックし、「次へ」をクリックします。
「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
データ・ソースのサマリー・ページで、「新規」をクリックし、「GridLinkデータ・ソース」を選択して、次の手順を実行します。
「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、leasingと入力します。
JNDIの名前を入力します。たとえば、jdbc/leasingと入力します。
「データベース・ドライバ」では、OracleのGridLink接続用ドライバ(Thin)、バージョン11以降を選択します。
「次へ」をクリックします。
「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」を選択解除して「次へ」をクリックします。
「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
次の接続プロパティを入力します。
サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースの場合は、Oracle RACサービス名を入力する必要があります。例:
wccedg.example.com
ホスト名とポート: 使用するRACデータベースのSCANアドレスとポートを入力して、「追加」をクリックます。このアドレスは、TCPプロトコルを使用してデータベース内の該当のパラメータを問い合せることによって特定できます。
SQL>show parameter remote_listener; NAME TYPE VALUE -------------------------------------------------- remote_listener string db-scan.example.com
|
注意: Oracle Database 11gの場合は、次の例に示すように、各データベース・インスタンス・リスナーの仮想IPアドレスとポートを使用します。wccdbhost1-vip.example.com (port 1521) wccdbhost2-vip.example.com (1521) |
データベース・ユーザー名: leasing
パスワード: leasingユーザーのパスワードを入力します。
パスワードの確認: パスワードを再入力し、「次へ」をクリックします。
「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。接続に成功した場合の通知の例を次に示します。
Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com) (PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=wccedg.example.com))) succeeded.
「次へ」をクリックします。
「ONSクライアント構成」ページで、次の手順を実行します。
「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。
データベースによって報告されるRACデータベースのホスト名とONSリモート・ポートを入力し、「追加」をクリックします。
次の例は、ONSリモート・ポートの番号を表示しています。
[orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
「次へ」をクリックします。
|
注意: Oracle Database 11gの場合は、次の例に示すように、各データベースのONSサービスのホスト名とポートを使用します。wccdbhost1.example.com (port 6200) wccdbhost2.example.com (6200) |
「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。
接続に成功した場合の通知の例を次に示します。
Connection test for db-scan.example.com:6200 succeeded.
「次へ」をクリックします。
「ターゲットの選択」ページで、サーバーを移行中のIMG_Cluster、CPT_ClusterおよびSOA_Clusterをターゲットとして選択し、「クラスタのすべてのサーバー」を選択します。
「終了」をクリックします。
「変更のアクティブ化」をクリックします。
3番目の手順では、ノード・マネージャのプロパティ・ファイルを編集します。これは、サーバー移行が構成されている両方のノード上のノード・マネージャに対して行う必要があります。
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に設定します。これは、ノード・マネージャが起動スクリプトを使用して管理対象サーバーを起動するために必要です。
|
注意: 共有記憶域のインストールからノード・マネージャを実行すると、同じnodemanager.propertiesファイルを使用して複数のノードが起動します。ただし、ノードごとに異なるNetMaskプロパティまたはInterfaceプロパティが必要な場合があります。この場合、環境変数を使用して、ノードごとに個々のプロパティを指定します。たとえば、HOSTnで別のインタフェース(eth3)を使用するには、Interface環境変数を次のように使用します。export JAVA_OPTIONS=-DInterface=eth3さらに、ノード・マネージャを起動する前に、この変数をシェルに設定しておきます。 各ノードで、他のJavaオプションを指定することによって、ノード・マネージャに渡すプロパティを指定できます。たとえば、管理サーバーをホストするWCCHOST1では、 |
4番目の手順では、(oracleユーザーに対して)wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。
スクリプトの環境とスーパーユーザー権限を設定する手順は次のとおりです。
表17-2に一覧表示されているファイルがPATH環境変数に含まれていることを確認します。
wlsifconfig.shスクリプトに対するsudo構成権限を付与します。
パスワード・プロンプトを使用しないで機能するsudoを構成します。
セキュリティ上の理由から、sudoを、wlsifconfig.shスクリプトの実行に必要なコマンドのサブセットに限定する必要があります。たとえば、wlsifconfig.shスクリプトのenvironmentとsuperuser権限を設定するには、次の手順を実行します。
WebLogic Serverユーザー(oracle)に、パスワード制限のないsudo権限を付与し、さらに/sbin/ifconfigと/sbin/arpingバイナリのexecute権限を付与します。
WebLogic Serverユーザー(oracle)がこのスクリプトを実行できることを確認します。/etc/sudoers内の次のエントリ例では、oracleのsudo実行権限を、ifconfigとarpingに対しても付与しています。
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
|
注意: この手順に必要なsudo権限とsystem権限についてはシステム管理者に問い合せてください。 |
WL_HOME/server/bin/ディレクトリにあるstartNodeManager.shスクリプトを実行して、HOST1およびHOST2のノード・マネージャを起動します。
nohup ./startNodeManager.sh > nm.out&
5番目の手順は、サーバー移行ターゲットを構成することです。まず、クラスタのメンバーに対して使用可能なすべてのノードを割り当て、サーバー移行で構成される各サーバー用の候補サーバーを(適切な順に)指定します。
クラスタ内の移行でクラスタ移行を構成する手順は次のとおりです。
WebLogic Server管理コンソール(http//ADMINVHN:7001/console)にログインします。
左側の「ドメイン構造」ツリーで「環境」を開き、「クラスタ」を選択します。
「クラスタのサマリー」ページで、表の「名前」列内から移行を構成するクラスタ(CLUSTER)をクリックします。
|
注意: このドキュメントの手順では、Imaging、CaptureおよびOracle SOA Suiteクラスタのサーバー移行を構成します。 |
「移行」タブを開きます。
「ロックして編集」をクリックします。
「使用可能」フィールドで、移行を許可する移行先マシンを選択し、右矢印ボタンをクリックします。この場合は、「HOST1」と「HOST2」を選択します。
自動移行に使用するデータ・ソースを選択します。この場合は、leasingデータ・ソースを選択します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
「ロックして編集」をクリックします。
サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。
WebLogic Server管理コンソールの左側の「ドメイン構造」ツリーで、「環境」ノードを開き、「サーバー」を選択します。
移行を構成するサーバーを選択します。
|
注意: このドキュメントの手順では、Imaging、CaptureおよびOracle SOA Suiteクラスタのサーバー移行を構成します。 |
「移行」タブを開きます。
「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。WLS_SERVER1には「HOST2」を選択します。WLS_SERVER2には「HOST1」を選択します。
「サーバーの自動移行を有効化」を選択します。これにより、ノード・マネージャが、障害の発生したサーバーをターゲット・ノード上で自動的に起動できるようになります。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
ノード・マネージャ、管理サーバーおよびサーバー移行が構成されているサーバーを再起動します。
まず、管理コンソールを使用して管理対象サーバーを停止します。
次に、ノード・マネージャと管理サーバーを再起動します(第8.4.5項「ホスト名検証の無効化」の手順11を参照)。
最後に、管理コンソールを使用して管理対象サーバーを再度起動します。
6番目と最後の手順として、サーバー移行のテストを実行します。
サーバー移行が適切に機能していることをHOST1から確認する手順は次のとおりです。
WLS_SERVER1管理対象サーバーを停止します。これを行うには、HOST1で次のコマンドを実行します。
kill -9 pid
pidは、その管理対象サーバーのプロセスID (PID)を指定します。次のコマンドを実行すると、ノードのプロセスIDを識別できます。
ps -ef | grep WLS_SERVER1
ノード・マネージャのコンソールを確認します。WLS_SERVER1の浮動IPアドレスが無効化されたことを示すメッセージが表示されます。
ノード・マネージャがWLS_SERVER1の2回目の再起動を試行するまで待ちます。この再起動を試行するまでに30秒間待機します。
ノード・マネージャがサーバーを再起動したら、サーバーを再び停止します。サーバーが再びローカルに再起動しないことを示すメッセージがノード・マネージャによってログに記録されます。
サーバー移行が適切に機能していることをHOST2から確認する手順は次のとおりです。
ローカルのノード・マネージャのコンソールを確認します。ノード1で最後にWLS_SERVER1の再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、WLS_SERVER1の浮動IPアドレスが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
同じIPアドレスでサーバーのコンソールにアクセスします。
サーバー移行が適切に機能していることを管理コンソールから確認する手順は次のとおりです。
管理コンソールにログインします。
左側の「ドメイン」をクリックします。
「監視」タブをクリックし、「移行」サブタブをクリックします。
「移行ステータス」表に、移行のステータスに関する情報が表示されます(図17-1)。
|
注意: サーバーの移行後、そのサーバーを元のノードまたはマシンにフェイルオーバーするには、WebLogic Server管理コンソールから管理対象サーバーを停止し、再起動します。管理対象サーバーは、適切なノード・マネージャによって以前に割り当てられていたマシン上で起動されます。 |
