1. Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの共通の構成および管理手順
  3. エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

23 エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

Oracle WebLogic Serverの移行フレームワークは、サーバー全体の移行とサービスの移行をサポートしています。次の項では、Oracle Fusion Middlewareエンタープライズ・トポロジでこれらの機能を使用する方法について説明します。

親トピック: エンタープライズ・デプロイメントの共通の構成および管理手順

エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

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は必要ありません。

どの移行でも、管理対象サーバーを完全再起動する必要があるため、サービス移行よりフェイルオーバー時のレイテンシは大きくなります。表23-1に、様々な観点をまとめます。

表23-1 WSMとASMの様々な観点

クラスタの保護 フェイルオーバー時間 キャパシティ・プランニング 信頼性 共有記憶域/DB 管理対象ごとのVIP

WSM

4–5分

完全なサーバー稼働

DBリース

 

はい

 

はい

 

ASM

30秒

 

メモリー/CPU単位のサービス

 

DBリース

 

はい

 

いいえ

 

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

サーバー全体の移行とサービスの移行が必要となる製品およびコンポーネントの理解

表には、推奨されるベスト・プラクティスがリストされています。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントで、これらを使用することはかまいません。

コンポーネント サーバー全体の移行(WSM) 自動サービス移行(ASM)

Oracle Web Services Manager(OWSM)

いいえ

いいえ

Oracle SOA Suite

いいえ

はい

Oracle Service Bus

いいえ

はい

Oracle Business Process Management

いいえ

はい

Oracle Enterprise Scheduler

いいえ

いいえ

Oracle Business Activity Monitoring

いいえ

はい

Oracle B2B

いいえ

はい

Managed File Transfer

いいえ

はい

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行と自動サービス移行について

リース用のGridLinkデータ・ソースの作成

サーバー全体の移行と自動サービス移動には、リポジトリ作成ユーティリティ(RCU)によってOracle WebLogic Serverスキーマの一部として自動的に作成される表領域であるリース表のデータ・ソースが必要です。

注意:

データ・ソースの集計と接続使用状況の緩和を達成するために、データベース・リースと場合と同じようにWLSSchemaDatasourceを再利用できます。このデータ・ソースはすでにFMW1221_WLS_RUNTIMEスキーマで構成されており、そのスキーマにリース表が格納されます。

エンタープライズ・デプロイメントでは、GridLinkデータ・ソースを作成する必要があります。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「チェンジ・センター」で「ロックして編集」をクリックします(まだこれを実行していない場合のみ)。
  3. 「ドメイン構造」ツリーで「サービス」を開き、「データ・ソース」を選択します。
  4. データ・ソースの概要ページで、「新規」をクリックして「GridLinkデータ・ソース」を選択し、次の内容を入力します。

    • 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingと入力します。

    • JNDIの名前を入力します。たとえば、jdbc/leasingです。

    • 「データベース・ドライバ」には、Oracle Driver (Thin) for GridLink Connections Versions: Anyを選択します。

    • 「次」をクリックします。

  5. 「トランザクション・オプション」ページで、「グローバル・トランザクションのサポート」チェック・ボックスを選択解除して「次へ」をクリックします。
  6. 「GridLinkデータ・ソース接続プロパティのオプション」画面で、「個別のリスナー情報の入力」を選択し、「次へ」をクリックします。
  7. 次の接続プロパティを入力します。

    • サービス名: データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。例:

      soaedg.example.com

    • ホスト名とポート: RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。例: 

      db-scan.example.com:1521

      「追加」をクリックして、フィールドの下のリスト・ボックスにホスト名とポートを追加します。

      図23-1 RACデータベースのSCANアドレスの指定

      図23-1の説明が続きます。
      「図23-1 RACデータベースのSCANアドレスの指定」の説明

      SCANアドレスは、TCPプロトコルを使用してデータベース内の適切なパラメータを問い合せると、確認できます。

      SQL>show parameter remote_listener;

NAME                 TYPE        VALUE
 
--------------------------------------------------
 
remote_listener     string      db-scan.example.com

      注意:

      Oracle Database 11gリリース1 (11.1)の場合は、各データベース・インスタンス・リスナーの仮想IPとポートを使用します。例: 

      dbhost1-vip.mycompany.com (port 1521)

      および

      dbhost2-vip.mycompany.com (1521)

      Oracle Database 10gの場合は、マルチ・データ・ソースを使用してOracle RACデータベースに接続します。マルチ・データ・ソースの構成の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

    • データベース・ユーザー名: 次を入力します。 

      FMW1221_WLS_RUNTIME

      この例では、FMW1221は、最初のエンタープライズ・マネージャ・ドメインを構成する際、スキーマの作成時に使用した接頭辞です。

      Oracle Fusion Middlewareの前のバージョンでは、移行リース表のために手動でユーザーと表領域を作成する必要がありました。Fusion Middleware 12c (12.2.1)では、リース表はリポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成する際に自動的に作成されます。

    • パスワード: RCUでWLSスキーマを作成した際に使用したパスワードを入力します。

    • パスワードの確認: もう一度パスワードを入力し、「次へ」をクリックします。

  8. 「GridLinkデータベース接続のテスト」ページで、接続パラメータを確認して、「すべてのリスナーのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=db-scan.example.com)
(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=soaedg.example.com))) succeeded.

    「次」をクリックします。

  9. 「ONSクライアント構成」ページで、次の手順を実行します。

    • 「FANの有効化」を選択してOracle FANイベントに登録し、それらのイベントを処理できるようにします。

    • 「ONSホスト」と「ポート」フィールドにSCANアドレスを入力し、「追加」をクリックします。

      この値は、RACデータベースのONSホストとONSリモート・ポートである必要があります。データベースの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.example.com (port 6200)

    および

    custdbhost2.example.com (6200)
  10. 「ONSクライアント構成のテスト」ページで、接続パラメータを確認して、「すべてのONSノードのテスト」をクリックします。

    接続が成功したときに表示される通知の一例を示します。

    Connection test for db-scan.example.com:6200 succeeded.

    「次」をクリックします。

  11. 「ターゲットの選択」ページで、サーバー全体の移行または自動サービス移行を構成するクラスタ選択し、「クラスタのすべてのサーバー」を選択します。
  12. 「終了」をクリックします。
  13. 「変更のアクティブ化」をクリックします。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

エンタープライズ・デプロイメント用のサーバー全体の移行の構成

サーバー全体の移行または自動サービス移行用にドメインを準備した後、クラスタ内の特定の管理対象サーバーに対してサーバー全体の移行を構成できます。

注意:

前述のように、移行を成功させるには、サーバーがリスニング・アドレスとして浮動IPと一致するホスト名を使用する必要があります。リスニング・アドレスは、構成ウィザードで直接指定したり、管理コンソールで更新したりできます。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

ノード・マネージャのプロパティ・ファイルを編集してサーバー全体の移行を有効化

この項では、サーバーが実行されている2つのノード上のノード・マネージャのプロパティ・ファイルを編集します。

  1. 次のファイルを探してテキスト・エディタで開きます。
    MSERVER_HOME/nodemanager/nodmeanager.properties
  2. nodemanager.propertiesファイルのStartScriptEnabledプロパティをtrueに設定していない場合はtrueに設定します。

    これは、ノード・マネージャが管理対象サーバーを起動するために必要です。

  3. 次のプロパティをnodemanager.propertiesファイルに追加して、サーバー移行が正常に動作するようにします。

    • Interface

      Interface=eth0

      このプロパティは浮動IP (eth0など)のインタフェース名を指定します。

      注意:

      サブ・インタフェース(eth0:1、eth0:2など)を指定しないでください。このインタフェースは、:0または:1なしに使用されます。

      ノード・マネージャのスクリプトは、別の:X対応のIPを移動して、追加または削除するものを決定します。たとえば、Linux環境で有効な値は、構成済のインタフェースの数に応じて、eth0、eth1、eth2、eth3、ethnとなります。

    • NetMask

      NetMask=255.255.255.0

      このプロパティでは、インタフェースの浮動IPのネット・マスクを指定します。

    • UseMACBroadcast

      UseMACBroadcast=true

      このプロパティは、ARPパケットの送信時にノードのMACアドレスを使用するかどうか、言い換えれば、arpingコマンドで-bフラグを使用するかどうかを指定します。

  4. ノード・マネージャを再起動します。
  5. これらのプロパティが適用されていることをノード・マネージャの出力(ノード・マネージャが起動したシェル)で確認します。それ以外の場合、移行中に問題が発生する可能性があります。出力は次のようになります。
    ...
SecureListener=true
LogCount=1
eth0=*,NetMask=255.255.255.0
...

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行の構成

wlsifconfig.shスクリプトの環境とスーパーユーザー権限の設定

この項では、wlsifconfig.shスクリプトの環境とスーパーユーザー権限を設定します。このスクリプトは、移行中に、IPアドレスをマシンからマシンに転送するために使用します。通常スーパーユーザーのみが利用可能なifconfigの実行が可能でなければなりません。

wlsifconfig.shスクリプトの詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の自動移行の構成に関する項を参照してください。

wlsifconfig.shスクリプトを実行するためにシステムを準備する手順は、次の項を参照してください。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行の構成

wlsifconfig.shスクリプトのPATH環境変数の設定

次の表に記載されているコマンドは、各ホスト・コンピュータのPATH環境変数に必ず含めてください。

ファイル ディレクトリの場所

wlsifconfig.sh

 
MSERVER_HOME/bin/server_migration

wlscontrol.sh

 
WL_HOME/common/bin

nodemanager.domains

 
MSERVER_HOME/nodemanager
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

サーバー移行ターゲットの構成

クラスタ内の移行を構成する手順は次のとおりです。

  1. Oracle WebLogic Server管理コンソールにサインインします。

  2. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。「クラスタのサマリー」ページが表示されます。

  3. 移行を構成するクラスタを、表の「名前」列でクリックします。

  4. 「移行」タブをクリックします。

  5. 「ロックして編集」をクリックします。

  6. 「移行基盤」として「データベース」を選択します。ドロップダウン・リストから、「自動移行に使用するデータ・ソース」として「リース」を選択します。

  7. 「移行可能サーバーの候補マシン」の「使用可能」フィールドでクラスタ内の管理対象サーバーを選択し、右矢印をクリックして「選択済み」に移動します。

  8. 「保存」をクリックします。

  9. サーバー移行の候補となるマシンを設定します。管理対象サーバーすべてについてこのタスクを次のように実行する必要があります。

    1. Oracle WebLogic Server管理コンソールの「ドメイン構造」ウィンドウで、「環境」を開き、「サーバー」を選択します。

    2. 移行を構成するサーバーを選択します。

    3. 「移行」タブをクリックします。

    4. 「サーバーの自動移行を有効化」を選択し、「保存」をクリックします。

      これにより、ノード・マネージャはターゲット・ノード上の障害発生サーバーを自動的に起動できます。

      アプリケーションとリソースのターゲット設定の詳細は、「Oracle RACでのマルチ・データ・ソースの使用」を参照してください。

    5. 「移行の構成」セクションにある「使用可能」フィールドで、移行先のマシンを選択し、右向き矢印をクリックします。

      このステップでは、現在のホストを使用できなくなったときの、管理対象サーバーのフェイルオーバー先のホストを識別します。たとえば、HOST1上の管理対象サーバーにはHOST2を選択し、HOST2の管理対象サーバーにはHOST1を選択します。

    ヒント:

    「サーバーの概要」ページの「この表のカスタマイズ」をクリックし、「現在のマシン」を「使用可能」ウィンドウから「選択済み」ウィンドウへ移動すると、サーバーを実行しているマシンを確認できます。このサーバーが自動的に移行すると、構成と異なる内容になります。

  10. 「変更のアクティブ化」をクリックします。

  11. 管理サーバーと、サーバー移行が構成されたサーバーを再起動します。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行の構成

サーバー全体の移行のテスト

この項のステップを実行して、サーバー全体の自動移行が適切に機能していることを確認します。

ノード1からテストする手順は次のとおりです。

  1. 管理対象サーバーのプロセスを停止します。

    kill -9 pid

    pidには、管理対象サーバーのプロセスIDを指定します。次のコマンドを実行すると、ノード内のpidを確認できます。

  2. ノード・マネージャのコンソール(killコマンドを実行したターミナル・ウィンドウ)を確認します。管理対象サーバーの浮動IPが無効になっていることを示すメッセージが表示されているはずです。

  3. ノード・マネージャが管理対象サーバーの2回目の再起動を試行するのを待ちます。ノード・マネージャは30秒間待機してからこの再起動を試行します。

  4. ノード・マネージャがサーバーを再起動した後、サーバーが実行中状態になる前に、関連するプロセスを再度強制終了します。

    サーバーが再びローカルで再起動されないことを示すメッセージがノード・マネージャによってログに記録されるようになります。

    注意:

    必要な再起動回数は、次の構成ファイルのRestartMaxパラメータで設定されます。

    デフォルト値はRestartMax=2です。

ノード2からテストする手順は次のとおりです。

  1. ローカルのノード・マネージャのコンソールを確認します。ノード1で最後に管理対象サーバーの再起動が試行されてから30秒経過した後、ノード2のノード・マネージャによって、管理対象サーバーの浮動IPが有効になっていること、またこのノードでサーバーが再起動されていることが表示されます。

  2. 同じIPアドレスを使用して製品URLにアクセスします。URLが正常な場合、移行は成功です。

管理コンソールからの検証

Oracle WebLogic Server管理コンソールを使用して、移行を検証することもできます。

  1. 管理コンソールにログインします。
  2. 左側のコンソールで、「ドメイン」をクリックします。
  3. 「監視」タブをクリックし、「移行」サブタブをクリックします。

    「移行の状態」の表に、移行の状態に関する情報が表示されます。

注意:

サーバーの移行後、そのサーバーを元のマシンにフェイルバックするには、Oracle WebLogic管理コンソールから管理対象サーバーを停止し、再起動します。適切なノード・マネージャが、もともと割り当てられていたマシン上の管理対象サーバーを起動します。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行の構成

エンタープライズ・デプロイメントでの自動サービス移行の構成

エンタープライズ・デプロイメント内の特定のサービスに対する自動サービス移行を構成する必要がある場合があります。

親トピック: エンタープライズ・デプロイメントでのサーバー全体の移行とサービスの移行の使用

エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定

自動サービス移行を構成する前に、自動サービス移行機能によって使用されるリーシング・メカニズムおよびデータ・ソースを確認する必要があります。リース・メカニズムとデータ・ソースを、静的クラスタにも動的クラスタにも構成する必要があります。

注意:

データ・ソースの集計と接続使用状況の緩和を達成するために、データベース・リースと場合と同じようにWLSSchemaDatasourceデータ・ソースを再利用できます。このデータ・ソースはすでにFMW1221_WLS_RUNTIMEスキーマで構成されており、そのスキーマにリース表が格納されます。

次の手順は、WLSSChemaDatasourceまたは「リース用のGridLinkデータ・ソースの作成」の説明に従って作成したカスタム・データソースを再利用することによってリース・データ・ソースが構成されていることを前提としています。

  1. Oracle WebLogic Server管理コンソールにログインします。
  2. 「ロックして編集」をクリックします。
  3. 「ドメイン構造」ウィンドウで、「環境」を開き、「クラスタ」を選択します。
    「クラスタのサマリー」ページが表示されます。
  4. 表の「名前」列で、移行を構成するクラスタをクリックします。
  5. 「移行」タブをクリックします。
  6. 「移行基盤」ドロップダウン・メニューでデータベースが選択されていることを確認します。
  7. 「自動移行に使用するデータ・ソース」ドロップダウン・メニューから「リース用のGridLinkデータ・ソースの作成」で作成したリース・データ・ソースを選択します。データ・ソース集計の場合は、WLSSchemaDatasourceを選択します。
  8. 「保存」をクリックします。
  9. 変更をアクティブ化します。
  10. 管理対象サーバーを再起動して、変更内容を有効にします。同じ構成変更セッションでASMの他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。

データベース・リースの構成が完了したら、静的クラスタまたは動的クラスタでのサービス移行の構成を続けます。

親トピック: エンタープライズ・デプロイメントでの自動サービス移行の構成

静的クラスタに対する自動サービス移行の構成

「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」での説明に従ってクラスタのリースを構成すると、エンタープライズ・デプロイメントで特定のサービスについて自動サービス移行を構成できます。次の項では、静的クラスタに対して自動サービス移行を構成して検証する方法について説明します。

親トピック: エンタープライズ・デプロイメントでの自動サービス移行の構成

クラスタ内の管理対象サーバーの移行設定の変更

クラスタにリース・メカニズムとデータ・ソースを設定した後、サービス移行を構成する管理対象サーバーに対して、自動JTA移行を有効化できます。この項は、JTAサービスをエンタープライズ・デプロイメントの一部としてデプロイする場合にのみ該当します。

各クラスタで管理対象サーバーの移行設定を変更するには:
  1. まだ行っていない場合、管理コンソールにログインして「ロックして編集」をクリックします。
  2. 「ドメイン構造」ペインで「環境」ノードを開き、「サーバー」をクリックします。
    「サーバーのサマリー」ページが表示されます。
  3. 表の「名前」列で、変更するサーバーの名前をクリックします。
    選択したサーバーの設定ページが開き、「構成」タブがデフォルトで表示されます。
  4. 「移行」タブをクリックします。
  5. 「JTA移行ポリシー」ドロップダウン・メニューで「障害リカバリ」を選択します。
  6. ページの「JTA候補サーバー」セクションの「使用可能」リスト・ボックスで管理対象サーバーを選択し、移動ボタンをクリックして「選択済み」リストに移動します。
  7. ページの「JMSサービスの候補サーバー」セクションの「使用可能」リスト・ボックスで管理対象サーバーを選択し、移動ボタンをクリックして「選択済み」リスト・ボックスに移動します。
  8. 「保存」をクリックします。
  9. 変更が有効になるように、管理対象サーバーと管理サーバーを再起動します。同じ構成変更セッションでASMの他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。
サービス移行ポリシーの選択について

自動サービス移行を構成する際は、クラスタごとにサービス移行ポリシーを選択します。この項では、サービス移行ポリシーを選択する際のガイドラインと考慮事項を示します。

たとえば、シングルトンを実行するまたはパス・サービスを使用する製品またはコンポーネントは、必ず1回自動移行ポリシーのメリットを享受することができます。このポリシーでは、候補サーバーのリストにある管理対象サーバーが1つ以上動作している場合、この移行可能ターゲットでホストされるサービスは、サーバーが失敗するか管理者によって(正常または強制的に)シャットダウンされると、クラスタ内のいずれかの場所でアクティブ化されます。これにより、複数の同種のサービスが起動時に1つのサーバー上で終了することがあります。

このポリシーを使用している場合は、クラスタの起動を監視して、各サーバー上でどのサーバーが実行されているかを特定する必要があります。その後、必要に応じて手動フェイルバックを実行し、システムをバランスのとれた構成にすることができます。

他のFusion Middlewareコンポーネントは、自動移行障害リカバリ・サービス・ポリシーに適しています。

これらのガイドラインに基づき、Oracle SOA Suiteエンタープライズ・トポロジには次のポリシーが推奨されます。

  • SOA_Cluster: 自動移行障害リカバリ・サービス

  • OSB_Cluster: 自動移行障害リカバリ・サービス

  • BAM_Cluster: 必ず1回のサービスを自動移行

  • MFT_Cluster: 自動移行障害リカバリ・サービス

『Oracle WebLogic Serverクラスタの管理』の手動および自動サービス移行のポリシーに関する項を参照してください。

クラスタ内の各管理対象サーバーに対するサービス移行ポリシーの設定
クラスタ内の各サーバーの移行設定を変更したら、WebLogic管理コンソールを使用してサービスを識別し、クラスタ内の各管理対象サーバーの移行ポリシーを設定できます。
  1. まだ行っていない場合、管理コンソールにログインして「ロックして編集」をクリックします。
  2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に展開して「移行可能なターゲット」を選択します。
  3. クラスタ内の最初の管理対象サーバーの名前をクリックします。
  4. 「移行」タブをクリックします。
  5. 「サービス移行ポリシー」ドロップダウン・メニューで、クラスタに適したポリシーを選択します。
  6. 「保存」をクリックします。
  7. クラスタの他の管理対象サーバーそれぞれについて、ステップ2から6までを繰り返します。
  8. 変更をアクティブ化します。
  9. 管理対象サーバーを再起動して、変更内容を有効にします。同じ構成変更セッションでASMの他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。
静的クラスタでの自動サービス移行の検証
クラスタおよび管理対象サーバーの自動サービス移行を構成後、次のように構成を検証します。
  1. まだログインしていない場合は、管理コンソールにログインします。
  2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に開きます。
  3. 「移行可能なターゲット」をクリックします。
  4. 「制御」タブをクリックします。
    コンソールに、移行可能なターゲットとその現在のホスト・サーバーがリストされます。
  5. 「移行可能なターゲット」表で、いずれかの移行可能なターゲットの行を選択します。
  6. 「現在のホスト・サーバー」列の値を書き留めます。
  7. オペレーティング・システムのコマンドラインを使用して、最初の管理対象サーバーを停止します。

    次のコマンドを使用して管理対象サーバーのプロセスを終了し、クラッシュ・シナリオをシミュレートします。

    kill -9 pid

    この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。 

    ps -ef | grep managed_server_name

    注意:

    プロセスの停止後、管理対象サーバーを自動的に起動するように構成されている場合があります。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

  8. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。

    選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。メッセージは次のようになります。

    <INFO> <domain_name> <server_name> 
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name> 
<Server failed during startup. It may be retried according to the auto restart configuration.>
<INFO> <domain_name> <server_name>
<Server failed but will not be restarted because the maximum number of restart attempts has been exceeded.>
  9. Oracle WebLogic Server管理コンソールに戻って、移行可能なターゲットの表をリフレッシュします。移行可能なターゲットが、残りの実行中のクラスタ内の管理対象サーバーに転送されることを確認します。
    • 強制終了したプロセスの現在のホスト・サーバーが更新され、別のホストに移行されたことを示すことを確認します。
    • プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。
  10. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAまたはJMSエラーがないかどうか探します。

    注意:

    JMSテストの場合、宛先からメッセージ・カウントを取得し、移行可能なターゲットにスタック・メッセージがないことを確認することが推奨されます。

    たとえば、共通分散送り先(UDD)の場合:

    1. 管理コンソールでJMSサブデプロイメント・モジュールにアクセスします。

      「ドメイン構造」ペインで、「サービス」、「メッセージング」、「JMSモジュール」の順に選択します。

    2. 「JMSモジュール」をクリックします。

    3. 「リソースのサマリー」表で、「宛先」をクリックしてから「モニタリング」タブをクリックします。

    4. 「メッセージ総数」と「保留メッセージ数」の値を確認します。表に表示されていない値がある場合は、「表のカスタマイズ」をクリックしてその列を表に追加します。

自動サービス移行後のサービスのフェイルバック

自動サービス移行が発生した場合、Oracle WebLogic Serverでは、サーバーがオンラインに戻りクラスタに再度参加するときに、サービスが元のサーバーにフェイルバックすることはサポートされません。

そのため、フェイルオーバー中に、自動サービス移行によって特定のJMSサービスがバックアップ・サーバーに移行されたあとは、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。かわりに、サービスを元のサーバーに手動で移行する必要があります。

サービスを元のサーバーにフェイルバックするには、次のステップを実行します。

  1. まだ行っていない場合は、管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

  2. 「ドメイン構造」ツリーで、「環境」、「クラスタ」の順に開き、「移行可能なターゲット」を選択します。

  3. 1つ以上の移行可能なターゲットを一度に移行するには、「移行可能なターゲットのサマリー」ページで次を実行します。

    1. 「制御」タブをクリックします。

    2. チェック・ボックスを使用して、移行する1つまたは複数の移行可能なターゲットを選択します。

    3. 「移行」をクリックします。

    4. 「新しいホスト・サーバー」ドロップダウンを使用して、元の管理対象サーバーを選択します。

    5. 「OK」をクリックします。

      JMS関連サービスを移行するリクエストが発行されます。「移行可能なターゲット」表の「最後の移行のステータス」列に、リクエストされた移行が成功したのか、失敗したのかが示されます。

    6. 移行が成功したら、編集ロックを解放します。

動的クラスタの自動サービス移行の構成

「エンタープライズ・デプロイメント・クラスタに対するリース・メカニズムおよびデータ・ソースの設定」の説明に従ってクラスタのリースを構成すると、サービス移行の構成を続行できます。

動的クラスタは、クラスタ全体がサービスのターゲットになるため、サービス移行の構成が簡単になります。ただし、カスタム永続ストア・レベルとJTAサービスに対する移行ポリシーを構成する必要はあります。これらのポリシーによって、ぞれぞれJMSサービスとJTAサービスの移行動作が決まります。

親トピック: エンタープライズ・デプロイメントでの自動サービス移行の構成

動的クラスタに対するサービス移行ポリシーの選択について

動的クラスタに対してサービス移行を構成するとき、永続ストアごとにサービス移行ポリシーを選択します。この項では、サービス移行ポリシーを選択する際のガイドラインと考慮事項を示します。次のオプションを使用できます。

  • オフ: 障害の発生した永続ストア・インスタンスおよび関連サービスの再起動の機能を含む、クラスタのターゲットとして指定されたJMSサービス・オブジェクトの移行および再起動サポートを無効にします。このポリシーをシングルトン移行ポリシーと組み合せることはできません。

  • 失敗時: サブシステム・サービスまたはWebLogic Serverインスタンスの失敗時に、インスタンスの自動フェイルバックおよびロード・バランシングを含む、インスタンスの自動移行および再起動を有効にします。

  • 常時: 「失敗時」と同じように動作し、正常な停止または部分クラスタの開始の場合でも、自動的にインスタンスを移行します。

シングルトンを実行する、またはPathサービスを使用する製品やコンポーネントでは、「常時」ポリシーのメリットがあります。このポリシーでは、1つ以上の管理対象サーバーが実行中の場合に、サーバーで障害が発生した、あるいは管理者によって(正常または強制的に)シャットダウンされた場合に、インスタンスがどこかでアクティブなままになります。このタイプの障害またはシャットダウンにより、複数の同種のサービスが起動時に1つのサーバー上で終了することがあります。

その他のFusion Middlewareコンポーネントでは、「失敗時」ポリシーのほうが適しています。

これらのガイドラインに基づき、Oracle SOA Suiteエンタープライズ・トポロジには次のポリシーが推奨されます。

  • SOA_Cluster: 失敗時

  • OSB_Cluster: 失敗時

  • MFT_Cluster: 失敗時

高可用性のためのJMS構成の詳細は、「簡略化されたJMSクラスタと高可用性の構成」を参照してください。

永続ストアに関する移行設定の変更
各クラスタについて移行ポリシーを選択すると、クラスタの永続ストアを指定し、WebLogic管理コンソールを使用して各クラスタの移行ポリシーを設定できます。
  1. 管理コンソールにログインし(ログインしていない場合)、「ロックして編集」をクリックします。
  2. 「ドメイン構造」ペインで、「環境」、「サービス」の順に開き、「永続ストア」をクリックします。
  3. 変更する永続ストアの名前をクリックします。

    注意:

    JDBC永続ストアを使用すると、余分な未使用のファイル・ストアが自動的に作成されますが、クラスタをターゲットとしたものではありません。こうしたファイル・ストアは無視してください。

  4. 「高可用性」タブをクリックします。
  5. 「移行ポリシー」ドロップダウン・メニューで、クラスタに適したポリシーを選択します。「動的クラスタに対するサービス移行ポリシーの選択について」を参照してください。
  6. 「保存」をクリックします。
  7. クラスタの永続ストアごとにステップ2から6を繰り返します。
  8. 「変更のアクティブ化」をクリックします。
  9. 管理対象サーバーを再起動して、変更内容を有効にします。同じ構成変更セッションでサービス移行の他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。
JTAサービスに関する移行設定の変更
動的クラスタのいずれかのメンバーで障害またはシャットダウンが発生した場合にクラスタのメンバーがXAログを再開できるように、各サーバーのJTAサービスについて、適切な移行ポリシーを設定する必要があります。動的クラスタのサーバーに対し移行ポリシーを設定するには、次のステップを実行します。
  1. ADMINVHN:7001/emにアクセスし、必要な資格証明を使用してFMW Controlコンソールにログインします。
  2. 右上隅にあるロック・アイコンをクリックし、「ロックして編集」をクリックします。
  3. 左側のターゲット・ナビゲーション・ツリーで、該当するドメインをクリックします。
  4. 「WebLogicドメイン」→「環境」→「サーバー・テンプレート」をクリックします。
  5. 該当するテンプレートをクリックして、「移行」タブをクリックします。
  6. 「JTA移行ポリシー」ドロップダウン・リストから、サービスに必要な移行ポリシーを選択します。各SOAコンポーネントで必要な設定は、次のとおりです。(インストールされている環境によっては、表示されないものもあります。)

    • SOA_Cluster: 障害リカバリ

    • OSB_Cluster: 障害リカバリ

    • MFT_Cluster: 障害リカバリ

  7. 「保存」をクリックします。
  8. 右上隅にあるロック・アイコンをクリックし、「変更のアクティブ化」をクリックします。
  9. 変更が有効になるように、管理対象サーバーと管理サーバーを再起動します。
動的クラスタでの自動サービス移行の検証
動的クラスタのサービス移行を構成した後で、次のように構成を検証します。
  1. 管理コンソールにログインします(ログインしていない場合)。
  2. 「ドメイン構造」ペインで、「環境」、「クラスタ」の順に選択します。
  3. クラスタ内で、サービス移行を確認するクラスタをクリックします。
  4. 「モニタリング」タブ、「ヘルス」の順にクリックします。
    コンソールに、クラスタのサーバーとその状態のリストが表示されます。
  5. 各管理対象サーバーを開き、その永続ストアが正常であることを確認します。
  6. 「ドメイン構造」ペインで、「環境」→「サービス」→「メッセージング」→「JMSサーバー」の順に選択します。
  7. クラスタのJMSサーバーをいずれかクリックし、「モニタリング」タブをクリックします。

    2つのインスタンス(動的サーバーごとに1つ)が表示され、各インスタンスが動的サーバーの1つで稼働していることを確認します。

  8. オペレーティング・システムのコマンドラインを使用して、最初の管理対象サーバーを停止します。次のコマンドを使用して、管理対象サーバー・プロセスを終了し、クラッシュ・シナリオをシミュレートします。
    kill -9 pid
    この例では、pidを、管理対象サーバーのプロセスID (PID)に置き換えます。次のUNIXコマンドを実行すると、PIDを確認できます。
    ps -ef | grep managed_server_name

    注意:

    最初にプロセスを停止した後で自動的に起動するように、管理対象サーバーを構成することができます。この場合、再度kill –9コマンドを使用して、2番目のプロセスを強制終了する必要があります。

  9. ノード・マネージャが動作しているターミナル・ウィンドウ(コンソール)を確認します。
    選択した管理対象サーバーでエラーが発生したことを示すメッセージが表示されます。次のようなメッセージが表示されます。
    <INFO> <domain_name> <server_name>
<The server 'server_name' with process id 4668 is no longer alive; waiting for the process to die.>
<INFO> <domain_name> <server_name>
<Server failed during startup. It may be retried according to the auto restart configuration.>
<INFO> <domain_name> <server_name>
<Server failed but will not be restarted because the maximum number of restart attempts has been exceeded.>
  10. Oracle WebLogic Server管理コンソールに戻り、「クラスタ」→「モニタリング」→「ヘルス」の表をリフレッシュします。まだ稼働している残りの管理対象サーバーで、永続ストアが実行されていることを確認します。
  11. 「ドメイン構造」ペインで、「環境」→「サービス」→「メッセージング」→「JMSサーバー」の順に選択します。
  12. クラスタのJMSサーバーをいずれかクリックし、「モニタリング」タブをクリックします。

    まだ稼働している残りの管理対象サーバーで、2つのインスタンスが引き続き稼働していることを確認します。

  13. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認します。JTAまたはJMSエラーがないかどうか確認します。

    注意:

    JMSテストの場合、宛先からメッセージ・カウントを取得し、移行可能なターゲットにメッセージがスタックしていないことを確認することが推奨されます。たとえば、共通分散送り先(UDD)の場合:

    1. 管理コンソールでJMSサブデプロイメント・モジュールにアクセスします。

    2. 「ドメイン構造」ペインで、「サービス」→「メッセージング」→「JMSモジュール」を選択します。

    3. 「JMSモジュール」をクリックします。

    4. 「リソースのサマリー」表で、「宛先」をクリックしてから「モニタリング」タブをクリックします。「メッセージ総数」と「保留メッセージ数」の値を確認します。

    表に表示されていない値がある場合は、「表のカスタマイズ」をクリックしてその列を表に追加します。

  14. ログを確認します。残りのサーバーで、次のようなメッセージが表示されます。
    <Info> <Cluster> <soahost1> <WLS_SOA1> <[STANDBY] ExecuteThread: 
'43' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
<> <49c99f17-a5d6-487d-a710-65eef0262ebc-0000063c> <1489481002608> 
<[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000189> 
<The Singleton Service UMSJMSJDBCStore_auto_1_WLS_SOA2 is now active on this server.>

<Info> <Cluster> <soahost1> <WLS_SOA1> <[STANDBY] ExecuteThread: 
'43' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
<> <49c99f17-a5d6-487d-a710-65eef0262ebc-0000063c> <1489481002609> 
<[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-003130> 
<UMSJMSJDBCStore_auto_1_WLS_SOA2 successfully activated on server WLS_SOA1.>

    詳細は、次のフラグを使用してデバッグできます。

    -Dweblogic.debug.DebugSingletonServices=true -
Dweblogic.debug.DebugServerMigration=true
自動サービス移行後のサービスのフェイルバック

動的クラスタリングでは、分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイル・バックを試みます。そのため、フェイルオーバー中に、サービス移行プロセスによって特定の永続ストアがバックアップ・サーバーに移行された後は、元のサーバーがオンラインに戻っても、サービスが元のサーバーに移行されることはありません。