19 エンタープライズ・デプロイメントでのサービス移行の使用

Oracle WebLogic Serverの移行フレームワークでは、サーバー全体の移行とサービスの移行がサポートされています。サーバー全体の移行には、より多くのリソースと管理対象サーバーの完全な起動が必要であるため、サービス移行よりフェイルオーバー時のレイテンシは大きくなります。このEDGに含まれる製品は、サービス移行をサポートしています。したがって、サービス移行をお薦めします。このガイドでは、Oracle Fusion Middlewareエンタープライズ・トポロジでサービス移行を使用する方法について説明します。サーバー全体の移行は、このガイドの範囲外です。

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

Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。

サーバー全体の移行とサービスの移行の違いの理解

Oracle WebLogic Serverの移行フレームワークでは、次の2つの種類の自動移行をサポートしています。

  • サーバー全体の移行。障害発生時に、管理対象サーバー・インスタンスが別の物理システムに移行されます。

    サーバー全体の移行では、別の物理マシン上で、サーバー・インスタンスとそのすべてのサービスが自動的に再起動されます。サーバー移行が構成されているクラスタに属するサーバーで問題が発生すると、そのサーバーは、クラスタのメンバーをホストする他のマシンで再起動されます。

    このためには、サーバーはリスニング・アドレスとして浮動IPを使用する必要があり、必要なリソース(トランザクション・ログとJMS永続ストア)が候補マシンで利用できなければなりません。

    Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

  • サービスの移行。特定のサービスが、クラスタ内の別の管理対象サーバーに移行されます。

    サービスの移行を理解するには、固定サービスを理解することが重要です。

    WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連サービスやJTAトランザクション・リカバリ・サービス、ユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個々のサーバー・インスタンスにホストされます。WebLogic Serverの移行フレームワークは、これらのサービスに対して、フェイルオーバーではなく、サービスの移行による障害回復をサポートしています。

    『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解を参照してください。

エンタープライズ・デプロイメントでサーバー全体の移行またはサービスの移行を使用する意味

サーバーまたはサービスが別のシステムで再起動されるときは、必要なリソース(サービス・データ、ログなど)が元のシステムとフェイルオーバー・システムの両方で利用できなければなりません。利用できなければ、サービスは、同じ操作をフェイルオーバー・システムで正常に再開できません。

このような理由から、サーバー全体の移行とサービスの移行の両方で、クラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストア(ファイルベースかデータベースベースかを問わない)にアクセスできる必要があります。

これが、エンタープライズ・デプロイメントで共有記憶域が重要となる、もう1つの理由です。共有記憶域を適切に構成すると、手動フェイルオーバー(管理サーバーのフェイルオーバー)または自動フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生したときに、元のマシンとフェイルオーバー・マシンの両方が、サービスを変更しなくても、確実に同一のファイル・ストアにアクセスできるようになります。

自動サービス移行の場合、固定サービスの再開が必要になったときは、フェイルオーバー前に固定サービスによって使用されていたJMSとJTAのログにアクセスできる必要があります。

サーバー全体の移行の場合、共有記憶域のほかに、仮想IPアドレス(VIP)の入手と割当ても必要になります。管理対象サーバーが別のマシンにフェイルオーバーされると、VIPは新しいマシンに自動的に再割り当てされます。

サービスの移行には、VIPは必要ありません。

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

この表で示すのは、推奨するベスト・プラクティスであることに注意してください。対応するコンポーネントでのサーバー全体の移行または自動サービス移行の使用を禁止するものではありません。

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

Oracle WebCenter Content

はい

はい(推奨)

Oracle SOA Suite

はい

はい(推奨)

Oracle Enterprise Capture

はい

はい(推奨)

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

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

ノート:

データ・ソースの統合および接続使用量の削減を実現するには、データベース・リース用としてWLSSchemaDatasourceをそのまま再使用できます。このデータ・ソースはすでにFMW1412_WLS_RUNTIMEスキーマで構成されており、そのスキーマにリース表が格納されます。

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

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「サービス」を開き、「データ・ソース」を選択します。
  4. 「データ・ソースのサマリー」ページで、「新規」をクリックし、「GridLinkデータ・ソース」を選択します。次のように入力します。

    表19-1 GridLinkデータ・ソースのプロパティ

    プロパティ 説明
    名前 「名前」フィールドに、データ・ソースの論理名を入力します。たとえば、Leasingです。
    JNDI名 JNDIの名前を入力します。たとえば、jdbc/leasingです。
    ターゲット 自動サービス移行用に構成するクラスタを選択し、「選択済」に移動します。
    データ・ソース・タイプ 「GridLinkデータ・ソース」を選択します。
    データベース・ドライバ 「Oracle's Driver (Thin) for GridLink Connections Versions: Any」を選択します。
    グローバル・トランザクション・プロトコル 「なし」を選択します。
    リスナー RACデータベースのSCANアドレスとポートを、コロンで区切って入力します。たとえば、db-scan.example.com:1521です。
    サービス名 データベースのサービス名を小文字で入力します。GridLinkデータ・ソースには、Oracle RACのサービス名を入力します。たとえば、soaedg.example.comです。
    データベース・ユーザー名

    WLSランタイム・スキーマのユーザー名を入力します。たとえば、FMW1412_WLS_RUNTIMEです。この例では、FMW1412は、ドメインを構成する準備をしたときに、スキーマの作成で使用した接頭辞です。

    ノート:

    リース表は、リポジトリ作成ユーティリティ(RCU)でWLSスキーマを作成する際に自動的に作成されます。
    パスワード RCUでWLSスキーマを作成した際に使用したパスワードを入力します。
    プロトコル デフォルト値(TCP)のままにします。
    FANの有効化 このオプションを選択する必要があります。
    ONSノード 空白のままにします。ONSノード・リストは、データベースが12.2以上のバージョンであれば自動的に取得されます。
    ONSウォレットとパスワード このフィールドは空のままにできます。
    構成のテスト このオプションは有効にする必要があります。
  5. 「作成」をクリックします。
  6. ショッピング・カートの変更をコミットします。

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

このエンタープライズ・デプロイメント・ガイドの様々なSOAコンポーネントで使用されるサービスは、このガイドに記載されている構成ウィザードのステップに従うことで、自動サービス移行ですでに構成されています。その他のカスタム・サービスについては、次のステップを使用してサービス移行を構成できます。

エンタープライズ・デプロイメント・クラスタでのリース・メカニズムとデータ・ソースの設定

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

ノート:

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

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

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

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

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

たとえば、このタスクはOracle WebCenter Contentエンタープライズ・デプロイメントでは必要ありません。
各クラスタの管理対象サーバーについて移行設定を変更するには:
  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「環境」ノードを開き、「サーバー」をクリックします。

    「サーバーのサマリー」ページが表示されます。

  4. 変更するサーバーの名前を展開します。
  5. 「JTA移行可能ターゲット」に移動します。
  6. 「JTA移行ポリシー」ドロップダウン・メニューで、「障害リカバリ」を選択します。

    このページの「JTA候補サーバー」セクションで、「選択済」リスト・ボックスは空のままにしておきます。「使用可能」リスト・ボックスからサーバーを選択しない場合、クラスタ内で使用可能なすべてのサーバーがサービス移行の候補になります。

  7. 「保存」をクリックします。
  8. ショッピング・カートの変更をコミットします。
  9. 変更が有効になるように、管理対象サーバーと管理サーバーを再起動します。

    同じ構成変更セッションでASMの他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。

サービス移行ポリシーの選択について

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

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

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

その他のFusion Middlewareコンポーネントでは、「障害リカバリ」ポリシーの方が適しています。

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

クラスタ内の各管理対象サーバーでのサービス移行ポリシーの設定

クラスタ内の各サーバーのJTA移行設定を変更した後、WebLogicリモート・コンソールを使用し、サービスを識別してクラスタ内の各管理対象サーバーの移行ポリシーを設定できます:
  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「環境」→「移行可能ターゲット」を開きます。
  4. クラスタ内の最初の管理対象サーバーの名前をクリックします。
  5. 「サービス移行ポリシー」ドロップダウン・メニューで、クラスタに適したポリシーを選択します。「サービス移行ポリシーの選択について」を参照してください。
  6. 「候補」タブで、「選択済」リスト・ボックスは空のままにしておきます。「使用可能」リスト・ボックスからサーバーを選択しない場合、クラスタ内で使用可能なすべてのサーバーがサービス移行の候補になります。
  7. 「保存」をクリックします。
  8. クラスタ内の追加の管理対象サーバーごとにステップ2からステップ6を繰り返します。
  9. ショッピング・カートの変更をコミットします。
  10. 管理対象サーバーを再起動して、変更内容を有効にします。

    同じ構成変更セッションでASMの他の部分も構成している場合は、再起動を最後の1回のみにすることで、ダウンタイムを短くできます。

自動サービス移行の検証

クラスタと管理対象サーバーの自動サービス移行を構成した後で、次のように構成を検証します。
  1. まだログインしていない場合は、WebLogicリモート・コンソールにログインします。
  2. 「モニタリング・ツリー」に移動します。
  3. 構造ツリーで、「環境」→「移行」を開きます。
  4. 「サービス移行データ・ランタイム」をクリックします。

    コンソールには、移行可能なターゲットと現在のホスティング・サーバーのリストが表示されます。

  5. 「移行可能なターゲット」表で、移行可能なターゲットのいずれか1つの行を選択します。
  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. WebLogicリモート・コンソールに戻って、サービス移行データ・ランタイムの表をリフレッシュします。移行可能なターゲットがクラスタ内の残りの実行中の管理対象サーバーに転送されていることを確認します:

    • 強制終了したプロセスの「移行先」の値が更新され、それが別のホストに移行されたことを確認します。

    • プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。
  10. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認します。JTAまたはJMSエラーがないか調べます。

    ノート:

    JMSテストの場合、宛先からメッセージ数を取得して、すべての移行可能なターゲットにスタック・メッセージがないことを確認するのが適切な方法です。

    たとえば、共通分散宛先(UDD)の場合は次のとおりです。

    1. WebLogicリモート・コンソールにログインし、「モニタリング・ツリー」に移動します。

    2. 「ダッシュボード」に移動し、「JMS宛先」をクリックします。

    3. 宛先名で並べ替えて、宛先を検索します。

      ヒント:

      このダッシュボードをコピーして、特定の宛先名でフィルタするためのカスタム・ダッシュボードを作成できます。

    4. 「現在のメッセージ数」および「保留メッセージ数」の値を確認します。

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

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

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

サービスを元のサーバーにフェイルバックするには、WLST migrateコマンドを使用します。詳細は、『Oracle WebLogic Server WLSTコマンド・リファレンス』を参照してください。