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

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

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

  • エンタープライズ・デプロイメントでの自動サービス移行について
    Oracle WebLogic Serverは、可用性の高い環境にとって不可欠な要素である移行フレームワークを備えています。次の項では、エンタープライズ・デプロイメントでこのフレームワークを効果的に使用する方法を詳しく説明します。
  • リース用のGridLinkデータ・ソースの作成
    自動サービス移行では、リース表のデータ・ソースが必要です。リース表は、リポジトリ作成ユーティリティ(RCU)によって、Oracle WebLogic Serverスキーマの一部として自動的に作成される表領域およびスキーマに存在する表です。
  • エンタープライズ・デプロイメントでの自動サービス移行の構成
    このエンタープライズ・デプロイメント・ガイドの様々なSOAコンポーネントで使用されるサービスは、このガイドに記載されている構成ウィザードのステップに従うことで、自動サービス移行ですでに構成されています。その他のカスタム・サービスについては、次のステップを使用してサービス移行を構成できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サーバー全体の移行には、自動サービス移行よりも多くのリソース(仮想IPおよび仮想ホスト名)が必要です。また、移行された管理対象サーバーの完全な起動も伴うため、リカバリ時間目標が低下します。Oracle FMW SOA Suiteのすべての異なるコンポーネントで自動サービス移行がサポートされます。これは、このエンタープライズ・デプロイメント・ガイドで推奨および説明されている推奨フェイルオーバー・アプローチです。サーバー全体の移行は、このガイドの範囲外です。

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

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

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

意味:

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

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

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

  • リース・データソース

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

    ノート:

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

表20-1に、様々な観点をまとめます。

表20-1 ASMの観点のサマリー

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

ASM

30秒

 

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

 

DBリース

 

はい

 

いいえ

 

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

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

次の表に、自動サービス移行を使用した最適な高可用性のための推奨ベスト・プラクティスを示します。前の項で説明したように、これらのすべてのコンポーネントで自動サーバー移行を使用することもできますが、フェイルオーバー時間が長くなり、より多くのリソースが必要になります。

コンポーネント 自動サービス移行(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スキーマの一部として自動的に作成される表領域およびスキーマに存在する表です。

ノート:

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

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

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

    表20-2 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サービスをエンタープライズ・デプロイメントの一部としてデプロイする場合にのみ該当します。

各クラスタで管理対象サーバーの移行設定を変更するには:
  1. WebLogicリモート・コンソールにログインします。
  2. 「ツリーの編集」に移動します。
  3. 構造ツリーで、「環境」ノードを開き、「サーバー」をクリックします。

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

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

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

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

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

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

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

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

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

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

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

  • SOA_Cluster: 障害リカバリ

  • OSB_Cluster: 障害リカバリ

  • BAM_Cluster: 必ず1回

  • MFT_Cluster: 障害リカバリ

『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コマンド・リファレンス』を参照してください。