20 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用
Oracle WebLogic Serverの移行フレームワークでは、サーバー全体の移行とサービスの移行をサポートしています。次の各項では、Oracle Fusion Middlewareエンタープライズ・トポロジでのこれらの機能の使用方法について説明します。
- エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。 - リース用のGridLinkデータ・ソースの作成
サーバー全体の移行と自動サービス移動には、リポジトリ作成ユーティリティ(RCU)によってOracle WebLogic Serverスキーマの一部として自動的に作成される表領域であるリース表のデータ・ソースが必要です。 - エンタープライズ・デプロイメント用のサーバー全体の移行の構成
サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。 - エンタープライズ・デプロイメントでの自動サービス移行の構成
エンタープライズ・デプロイメントでの特定のサービスに対して自動サービス移行を構成することが必要になる場合があります。
エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について
Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。
サーバー全体の移行とサービスの移行の違いの理解
Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。
-
サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。
サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。
このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。
Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。
-
サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。
サービスの移行を理解するには、固定サービスを理解することが重要です。
WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。
『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。
エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味
エンタープライズ・デプロイメントでサーバー全体の移行(WSM)または自動サービス移行(ASM)を使用する場合、インフラストラクチャと構成要件の点で次の意味があります。
意味:
-
サーバーによって使用されるリソースは、元のシステムからもフェイルオーバー・システムからもアクセスできる必要があります
初期状態では、リソースには元のサーバーまたはサービスからアクセスできます。サーバーまたはサービスが、フェイルオーバーになって別のシステムで再起動される場合、同じリソース(外部リソース、データベースおよびストア)をフェイルオーバー・システムで使用できる必要があります。そうでない場合、サービスで同じ操作は再開できません。このような理由から、サーバー全体の移行とサービスの移行の両方で、WebLogicクラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。
Oracleで使用できるJDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにします。あるいは、共有記憶域を使用できます。データベースまたは共有記憶域で永続ストアを適切に構成する際には、フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生した場合に、手動操作を必要とせずにフェイルオーバー・システムが同じストアにアクセスできる必要があります。
-
リース・データソース
サーバー移行とサービス移行(静的クラスタまたは動的クラスタでの)のどちらでも、サーバーが有効タイムスタンプを格納する際に使用するリース・データソースの構成が必要です。このタイムスタンプは、サーバーまたはサービスの状態を判定するためのもので、サーバー移行とサービス移行の正しい動作(サーバーまたはサービスを停止とマークしてフェイルオーバーを発動する)に不可欠です。ノート:
HAの目的でコンセンサス・リーシングを使用するのは、お薦めできません。
-
仮想IPアドレス
サーバー全体の移行の場合、共有記憶域のほかに、サーバーごとの仮想IPアドレス(VIP)の入手と割当ても必要になります。このIPにマップに対応しており、関係するサーバーのリスニング・アドレスとして使用されます。管理対象サーバーが他のマシンにフェイルオーバーすると、ノード・マネージャによって、フェイルオーバー・ノードでVIPが有効になります。サービスの移行には、VIPは必要ありません。
どの移行でも、管理対象サーバーを完全再起動する必要があるため、サービス移行よりフェイルオーバー時のレイテンシは大きくなります。表20-1に、様々な観点をまとめます。
表20-1 WSMとASMの様々な観点
クラスタの保護 | フェイルオーバー時間 | 容量計画 | 信頼性 | 共有記憶域/DB | 管理対象ごとのVIP |
---|---|---|---|---|---|
WSM |
4–5分 |
完全なサーバー稼働 |
DBリース |
はい |
はい |
ASM |
30秒 |
メモリー/CPU単位のサービス |
DBリース |
はい |
いいえ |
リース用のGridLinkデータ・ソースの作成
サーバー全体の移行および自動サービス移行では、リーシング表のデータ・ソースが必要です。リーシング表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域です。
ノート:
データ・ソース連結を実行し、接続の使用を削減するには、データベース・リースにWLSSchemaDatasource
を現状のまま再利用できます。このデータ・ソースはFMW1221_WLS_RUNTIME
スキーマを使用して構成済であり、このスキーマにリース表が格納されています。
エンタープライズ・デプロイメントでは、GridLinkのデータ・ソースを作成する必要があります。
エンタープライズ・デプロイメント用のサーバー全体の移行の構成
サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。
ノート:
前述のように、移行を成功させるには、サーバーがリスニング・アドレスとして浮動IPと一致するホスト名を使用する必要があります。リスニング・アドレスは、構成ウィザードで直接指定したり、管理コンソールで更新したりできます。
wlsifconfig.shスクリプトの環境およびスーパーユーザー権限の設定
この項では、wlsifconfig.sh
スクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfig
の実行が可能でなければなりません。
wlsifconfig.sh
スクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。
wlsifconfig.sh
スクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。
wlsifconfig.shスクリプトのPATH環境変数の設定
次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。
ファイル | ディレクトリの場所 |
---|---|
|
|
|
|
|
|
wlsifconfig.shスクリプトに対する権限の付与
オペレーティング・システム・ユーザー(oracle
)にパスワード制限のないsudo権限を付与し、さらに/sbin/ifconfig
と/sbin/arping
バイナリの実行権限を付与します。
ノート:
セキュリティ上の理由から、sudo
を、wlsifconfig.sh
スクリプトの実行に必要なコマンドのサブセットに限定する必要があります。
この必須の構成タスクを実行するためのsudo権限とsystem権限については、必要に応じてシステム管理者に問い合せてください。
/etc/sudoers内の次のエントリ例では、ifconfig
とarping
を実行するために、oracle
に対してsudo実行権限を付与しています。
Defaults:oracle !requiretty oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
サーバー移行ターゲットの構成
クラスタ内の移行を構成するには:
-
Oracle WebLogic Server管理コンソールにサインインします。
-
「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。
-
移行を構成するクラスタを、表の「名前」列でクリックします。
-
「移行」タブをクリックします。
-
「ロックして編集」をクリックします。
-
「移行基盤」に「データベース」を選択します。「自動移行に使用するデータ・ソース」としてドロップダウン・リストからリースを選択します。
-
「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。
-
「保存」をクリックします。
-
サーバー移行の候補となるマシンを設定します。この作業は、次の手順に従ってすべての管理対象サーバーで実行する必要があります。
-
Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。
-
移行を構成するサーバーを選択します。
-
「移行」タブをクリックします。
-
「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。
これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。
-
「移行の構成」セクションの「使用可能」フィールドで、移行先として許可するマシンを選択して、右向き矢印をクリックします。
このステップでは、現在のホストを使用できない場合に管理対象サーバーのフェイルオーバー先となるホストを識別します。たとえば、HOST1の管理対象サーバーの場合はHOST2を選択し、HOST2の管理対象サーバーの場合はHOST1を選択します。
ヒント:
「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。
-
-
「変更のアクティブ化」をクリックします。
-
管理サーバーと、サーバー移行が構成されたサーバーを再起動します。
サーバー全体の移行のテスト
この項のステップを実行して、サーバー全体の自動移行が適切に機能していることを確認します。
ノード1からテストするには:
-
管理対象サーバーのプロセスを停止します。
kill -9 pid
PIDには管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。
-
ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。
-
ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。
-
ノード・マネージャがサーバーを再起動し、サーバーが実行中状態になる前に、関連するプロセスを再度強制終了します。
サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。
ノート:
必要な再起動回数は、次の構成ファイルの
RestartMax
パラメータで設定されます。デフォルト値は
RestartMax=2
です。
ノード2からテストするには:
-
ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。
-
同じIPアドレスを使用して、製品URLにアクセスします。URLが正常な場合は、移行が成功したことを示します。
管理コンソールからの検証
Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。
ノート:
サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。
エンタープライズ・デプロイメントでの自動サービス移行の構成
エンタープライズ・デプロイメント内の特定のサービスに対して自動サービス移行を構成することが必要になる場合があります。
エンタープライズ・デプロイメント・クラスタのリーシング・メカニズムとデータ・ソースの設定
ノート:
次の手順は、「リース用のGridLinkデータ・ソースの作成」の説明に従ってリーシング・データ・ソースを作成していることを前提としています。
静的クラスタに対する自動サービス移行の構成
「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」での説明に従ってクラスタのリースを構成すると、エンタープライズ・デプロイメントで特定のサービスについて自動サービス移行を構成できます。次の項では、静的クラスタに対して自動サービス移行を構成して検証する方法について説明します。
クラスタ内の管理対象サーバーの移行設定の変更
クラスタのリース・メカニズムとデータ・ソースを設定したら、サービス移行を構成する管理対象サーバーについて自動JTA移行を有効化できます。このトピックが適用されるのは、JTAサービスをエンタープライズ・デプロイメントの一部としてデプロイしている場合のみです。
親トピック: 静的クラスタに対する自動サービス移行の構成
サービス移行ポリシーの選択について
自動サービス移行を構成するとき、クラスタごとにサービス移行ポリシーを選択します。ここでは、サービス移行ポリシーを選択する際のガイドラインと考慮事項を説明します。
たとえば、シングルトンを実行するか、またはパス・サービスを使用する製品やコンポーネントには、必ず1回の自動移行ポリシーが役立ちます。このポリシーでは、候補サーバーのリストにある管理対象サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされた場合に、クラスタ内のいずれかの場所でアクティブ化されます。これにより、起動時に複数の同種サービスが1つのサーバーに存在する場合があります。
このポリシーを使用する場合は、クラスタの起動を監視して、各サーバーで実行されているサーバーを識別する必要があります。その後、必要に応じて手動のフェイルバックを実行して、バランスの取れた構成にシステムを配置できます。
その他のFusion Middlewareコンポーネントには、障害回復サービスの自動移行ポリシーの方が適しています。
『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。
親トピック: 静的クラスタに対する自動サービス移行の構成
クラスタ内の各管理対象サーバーのサービス移行ポリシーの設定
親トピック: 静的クラスタに対する自動サービス移行の構成
自動サービス移行後のサービスのフェイルバック
自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。
そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。
サービスを元のサーバーにフェイルバックするには、次のステップを実行します。
-
まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
-
「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。
-
1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。
-
「制御」タブをクリックします。
-
チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。
-
「移行」をクリックします。
-
「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。
-
「OK」をクリックします。
JMS関連サービスを移行するリクエストが発行されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。
-
移行が成功したら、編集ロックを解放します。
-
親トピック: 静的クラスタに対する自動サービス移行の構成
動的クラスタの自動サービス移行の構成
「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」の説明に従ってクラスタのリースを構成すると、サービス移行の構成を続行できます。
動的クラスタは、クラスタ全体がサービスのターゲットになるため、サービス移行の構成が簡単になります。ただし、カスタム永続ストア・レベルとJTAサービスに対する移行ポリシーを構成する必要はあります。これらのポリシーによって、ぞれぞれJMSサービスとJTAサービスの移行動作が決まります。
動的クラスタに対するサービス移行ポリシーの選択について
動的クラスタに対してサービス移行を構成するとき、永続ストアごとにサービス移行ポリシーを選択します。この項では、サービス移行ポリシーを選択する際のガイドラインと考慮事項を示します。次のオプションを使用できます。
-
オフ: 障害の発生した永続ストア・インスタンスおよび関連サービスの再起動の機能を含む、クラスタのターゲットとして指定されたJMSサービス・オブジェクトの移行および再起動サポートを無効にします。このポリシーをシングルトン移行ポリシーと組み合せることはできません。
-
失敗時: サブシステム・サービスまたはWebLogic Serverインスタンスの失敗時に、インスタンスの自動フェイルバックおよびロード・バランシングを含む、インスタンスの自動移行および再起動を有効にします。
-
常時: 「失敗時」と同じように動作し、正常な停止または部分クラスタの開始の場合でも、自動的にインスタンスを移行します。
シングルトンを実行する、またはPathサービスを使用する製品やコンポーネントでは、「常時」ポリシーのメリットがあります。このポリシーでは、1つ以上の管理対象サーバーが実行中の場合に、サーバーで障害が発生した、あるいは管理者によって(正常または強制的に)シャットダウンされた場合に、インスタンスがどこかでアクティブなままになります。このタイプの障害またはシャットダウンにより、複数の同種のサービスが起動時に1つのサーバー上で終了することがあります。
その他のFusion Middlewareコンポーネントでは、「失敗時」ポリシーのほうが適しています。
これらのガイドラインに基づき、Oracle SOA Suiteエンタープライズ・トポロジには次のポリシーが推奨されます。
-
SOA_Cluster: 失敗時
-
OSB_Cluster: 失敗時
-
MFT_Cluster: 失敗時
高可用性のためのJMS構成の詳細は、「簡略化されたJMSクラスタと高可用性の構成」を参照してください。
親トピック: 動的クラスタの自動サービス移行の構成
永続ストアに関する移行設定の変更
親トピック: 動的クラスタの自動サービス移行の構成
JTAサービスに関する移行設定の変更
親トピック: 動的クラスタの自動サービス移行の構成
自動サービス移行後のサービスのフェイルバック
動的クラスタリングでは、分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイル・バックを試みます。そのため、フェイルオーバー中に、サービス移行プロセスによって特定の永続ストアがバックアップ・サーバーに移行された後は、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。
親トピック: 動的クラスタの自動サービス移行の構成