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

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クラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。

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

エンタープライズ・デプロイメントで自動サービス移行(ASM)を使用する場合、インフラストラクチャと構成要件の点で次の意味があります。

それは次のとおりです。

  • サーバーによって使用されるリソースは、元のシステムからもフェイルオーバー・システムからもアクセスできる必要があります

    初期状態では、リソースには元のサーバーまたはサービスからアクセスできます。サーバーまたはサービスが、フェイルオーバーになって別のシステムで再起動される場合、同じリソース(外部リソース、データベースおよびストア)をフェイルオーバー・システムで使用できる必要があります。そうでない場合、サービスで同じ操作は再開できません。このような理由から、サーバー全体の移行とサービスの移行の両方で、WebLogicクラスタのすべてのメンバーが、同一のトランザクションとJMS永続ストアにアクセスできる必要があります。

    Oracleで使用できるJDBCストアは、Oracleデータベースの一貫性、データ保護および高可用性の機能を活用して、クラスタのすべてのサーバーでリソースを利用できるようにします。あるいは、共有記憶域を使用できます。データベースまたは共有記憶域で永続ストアを適切に構成する際には、フェイルオーバー(サーバー全体の移行またはサービスの移行)が発生した場合に、手動操作を必要とせずにフェイルオーバー・システムが同じストアにアクセスできる必要があります。

  • リース・データソース

    サービス移行では、サーバーが有効タイムスタンプを格納する際に使用する、リース・データソースの構成が必要です。このタイムスタンプは、サーバーまたはサービスの状態を判定するためのもので、サーバー移行とサービス移行の正しい動作(サーバーまたはサービスを停止とマークしてフェイルオーバーを発動する)に不可欠です。

    ノート:

    HAの目的でコンセンサス・リーシングを使用するのは、お薦めできません。

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

次の表に、移行機能の使用が役立つFMW製品およびコンポーネントと、このリリースでのベストプラクティス推奨をまとめます。移行可能と記載されたコンポーネントでは、サーバー全体の移行または自動サービス移行を使用できます。

この表は、推奨されるベスト・プラクティスを示していることに注意してください。サーバー全体の移行または自動サーバー移行をサポートするコンポーネントでこれらの機能を使用できなくなるわけではありません。

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

Oracle Web Services Manager(OWSM)

いいえ

いいえ

Oracle WebCenter Portal

いいえ

いいえ

Oracle WebCenter Portalのポートレットおよびページレット・プロデューサ

いいえ

いいえ

Oracle WebCenter Content

はい

はい(推奨)

Oracle WebCenter Inbound Refinery

いいえ

いいえ

Oracle SOA Suite

はい

はい(推奨)

Oracle Enterprise Scheduler

いいえ

いいえ

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

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

ノート:

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

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

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

    表18-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. ショッピング・カートの変更をコミットします。

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

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

ノート:

自動サービス移行機能は、Oracle Integration Continuous Availabilityの一部です。Middlewareオプション用のOracle SOA Suiteの詳細は、Oracle Fusion Middlewareライセンス情報を参照してください。

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

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

ノート:

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

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

  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「環境」→「クラスタ」を開きます。

    「クラスタのサマリー」ページが表示されます。

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

データベース・リースの構成が完了したら、サービス移行の構成を続けます:

自動サービス移行の構成

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

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

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

クラスタ内の管理対象サーバーの移行設定を変更するには:
  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「環境」ノードを開き、「サーバー」をクリックします。
    「サーバーのサマリー」ページが表示されます。
  4. 変更するサーバーの名前を展開します。
  5. 「JTA移行可能ターゲット」に移動します。
  6. 「JTA移行ポリシー」ドロップダウン・メニューで、「障害リカバリ」を選択します。

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

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

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

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

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

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

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

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

これらのガイドラインに基づき、Oracle WebCenterエンタープライズ・トポロジには次のポリシーをお薦めします。

  • SOA_Cluster: 障害リカバリ

  • WCC_Cluster: 障害時リカバリ

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

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

クラスタ内の各サーバーのJTA移行設定を変更した後、WebLogicリモート・コンソールを使用し、サービスを識別してクラスタ内の各管理対象サーバーの移行ポリシーを設定できます:

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

    同じ構成変更セッションで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. Oracle WebLogicリモート・コンソールに戻り、移行可能なターゲットの表をリフレッシュします。移行可能なターゲットは、クラスタで実行している残りの管理対象サーバーに転送されることを確認します。
    • 強制終了したプロセスの「移行先」の値が更新されて、それが別のホストに移行されたことを確認します。
    • プロセスの「最後の移行のステータス」列の値が「成功」であることを確認します。
  10. 現在サービスをホストしている管理対象サーバーのログ・ファイルを開いて確認し、JTAエラーまたはJMSエラーを探します。

    ノート:

    JMSテストの場合は、宛先からメッセージ数を取得し、移行可能ターゲットにスタック・メッセージがないことを確認することをお薦めします。

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

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

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

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

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

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

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

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

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