この章の内容は次のとおりです。
この章では、主に障害が発生したサービスの移行について説明します。WebLogic Serverでは、サーバーで障害が発生した場合に、サーバー全体を移行することも可能です。このサーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。失敗したサーバー移行の詳細は、「サーバー全体の移行」を参照してください。
WebLogic Serverでは、アプリケーション・レベルでのレプリケーションやフェイルオーバーもサポートされています。詳細は、「クラスタのフェイルオーバーとレプリケーション」を参照してください。
注意:
Solarisゾーン機能を使用してSolaris 10システムでのサーバー全体の自動移行のサポートは、http://www.oracle.com/technetwork/middleware/ias/oracleas-supported-virtualization-089265.html
の注意3:「Sun Solaris 10のマルチ・ゾーン操作におけるサポート」を参照してください。
WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連のサービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個別のサーバー・インスタンスでホストされます - これらのサービスについて、WebLogic Server移行フレームワークでは、フェイルオーバーとは対照的なサービス移行による障害リカバリがサポートされています。「移行可能サービス」を参照してください。
WebLogic Serverにおけるサービス・レベルの移行とは、あるサーバー・インスタンスに固定されているサービスを、クラスタ内の使用可能な別のサーバー・インスタンスに移動するプロセスです。サービス・レベルの移行は、論理的な移行可能ターゲットにより制御されます。移行可能ターゲットは、クラスタ内のいずれか1つの物理サーバー・インスタンスでホストされているサービスのグループとして機能します。特定の固定サービスをターゲット指定する場合には、サーバー・インスタンスやクラスタを選択するかわりに移行可能ターゲットを選択できます。元のサーバー・インスタンスで問題が発生した場合に、移行可能なターゲットをあるクラスタ化サーバー・インスタンスから別のクラスタ化サーバー・インスタンスに移行することにより、高可用性が実現します。また、定期的な保守を行うために移行可能ターゲットを手動で移行したり、自動移行が行われるように移行可能ターゲットを構成したりできます。「クラスタ内の移行可能ターゲットの理解」を参照してください
移行フレームワークは、ターゲットを構成および移行するためのツールとインフラストラクチャを提供します。また、サービスの自動移行の場合は、WebLogic Serverのヘルス・モニタリング・サブシステムを使用して、移行可能ターゲットでホストされているサービスの状態をモニターします。「移行処理ツール」および「サービス自動移行インフラストラクチャ」を参照してくださいサーバーおよびサービスの移行に関する用語の定義は、「移行関連の用語」を参照してください
WebLogic Serverでは、JMS関連サービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスのサービス・レベルの移行がサポートされています。これらのサービスは、クラスタ内のあるサーバー・インスタンスから別のサーバー・インスタンスに移すことができるため移行可能サービスと呼ばれます。自動移行または手動移行では、次の移行可能サービスを構成できます。
これらは移行可能なJMSサービスです。
JMSサーバー - ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。『Oracle WebLogic Server JMSリソースの管理』のJMSサーバー構成に関する項を参照してください。
ストア・アンド・フォワード(SAF)サービス - メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』を参照してください。
パス・サービス - JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングを保持するために使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー・メンバーまたはストア・アンド・フォワード・エージェントにメッセージを固定することによって順序付けを実現できます。パス・サービスは、クラスタごとに1つずつ構成します。『Oracle WebLogic Server JMSリソースの管理』のWebLogicパス・サービスの使用に関する項を参照してください。
カスタム永続ストア - ユーザーが定義するディスク・ベースのファイル・ストアまたは永続JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するためのJDBC対応データベースです。WebLogic永続ストアの管理を参照してください。
クラスタのターゲット指定JMSサービスは、クラスタのメンバーに分散されます。クラスタのターゲット指定サービスをクラスタ・メンバー間で動的に自動で移行するようにWeblogic Serverを構成できます。『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。
シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスを移行可能ターゲット・リスト内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。「JMS関連サービスの自動移行を構成する手順」および「JMS関連サービスの手動移行を構成する手順」を参照してください。
トランザクション・リカバリ・サービスは、システム起動時にトランザクションのリカバリを自動的に試行します。すべてのトランザクション・ログ・レコードを解析し、未完了のトランザクションを完了させます。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』のサーバーに障害が発生した場合のトランザクション・リカバリに関する項を参照してください。
アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。「ユーザー定義のシングルトン・サービスの自動移行」を参照してください
注意:
動的クラスタを構成する場合、JMSサービスの移行動作を決定する移行ポリシーをカスタム永続ストア・レベルで指定できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。
移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して高可用性を得ることもできます。移行可能ターゲットとは、クラスタ内のサーバー・インスタンスから別のサーバー・インスタンスに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。
移行可能ターゲットでは、ターゲットをホストできるサーバー・インスタンスのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバー・インスタンスを指定したり、その優先サーバー・インスタンスで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。どの時点でも、これらのサーバー・インスタンスのうち1つのみが、移行可能ターゲットをホストできます。
移行可能ターゲットを使用するように構成したサービスは、現時点でそれをホストしているサーバー・メンバーから独立した存在になります。たとえば、あるJMSサーバーにJMSキューがデプロイされているとします。このJMSキューは、移行可能ターゲットを使用するように構成することで、特定のサーバー・メンバーが使用できるかどうかに関係なく動作できるようになります。つまり、このキューは、その移行可能ターゲットがクラスタ内のいずれかのサーバー・インスタンスでホストされていれば常に使用できます。
管理者は、サーバー障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにでも移行できます。「JMS関連サービスの手動移行を構成する手順」を参照してください
移行可能ターゲットでは、ヘルス・モニタリング・サブシステムを利用して、ホストしているサービスが異常なホスト・サーバー・インスタンスから正常なアクティブ・サーバー・インスタンスに手動で移行されるか(システムのデフォルト)、自動で移行されるかを定義した移行ポリシーを提供しています。自動サービス移行ポリシーには、次の項で説明するように2つのタイプがあります。
移行可能ターゲットでmanual
ポリシー(システムのデフォルト)を使用している場合、管理者は、サーバーの障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。
「JMS関連サービスの手動移行を構成する手順」を参照してください
このポリシーでは、候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバー・インスタンスで障害が発生するかサーバー・インスタンスが停止(正常停止または強制停止)されても、サービスはクラスタ内のどこかでアクティブになります。この値を使用すると、ターゲットのグループ化が生じることに注意してください。たとえば、exactly-once
の移行可能ターゲットが5つあるときに、クラスタ内の1つの管理対象サーバーのみを起動すると、5つのターゲットすべてがそのサーバー・インスタンス上でアクティブ化されます。
注意:
ベスト・プラクティスとして、パス・サービスをホストする移行可能ターゲットは常にexactly-once
に設定してください。そのホスト・サーバー・メンバーで障害が発生するかサーバー・メンバーが停止した場合、パス・サービスは自動的に別のサーバー・インスタンスに移行されるので、クラスタ内で常にアクティブになります。
JMSサーバーでのサンプル・ユース・ケース:
ドメイン内に3つの管理対象サーバーから成るクラスタがあり、1つのJMSサーバーがクラスタ内の1つのメンバー・サーバーにデプロイされています。クラスタにデプロイされているアプリケーションはそのJMSサーバーにターゲット指定されているキューにメッセージを送信します。他のドメインのMDBは、JMSサーバーに関連付けられているキューを消費します。MDBは同一のキューの複数のインスタンスではなく、キューの一つのセットから消費します。つまり、この環境でクラスタリングを使用しているのは、アプリケーションのためにスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためで、JMSサーバーのためではありません。したがって、この環境では、JMSサーバーをExactly-Once
サービスとして使用可能なクラスタ・メンバーに自動移行するのが適しています。
「JMS関連サービスの自動移行を構成する手順」を参照してください
このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者が手動でUPSを停止(正常停止または強制停止)した場合、failure-recovery
サービスは移行されません。ただし、UPSで内部エラーによる障害が発生した場合、failure-recovery
サービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。
クラスタのターゲット指定JMSサービスの移行の場合、障害リカバリ・パラメータでストアを構成できます。
JMSサーバーでのサンプル・ユース・ケース:
ドメイン内に3つの管理対象サーバーから成るクラスタがあります。各メンバー・サーバー上にJMSサーバーがあり、各JMSサーバー上には分散キュー・メンバーがあります。また、このクラスタには、ローカルのサーバー・メンバー上にある分散キュー・メンバーからメッセージを消費するMDBがターゲット指定されています。つまり、この環境では全体的なスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためにクラスタリングを使用しています。したがって、この環境では、JMSサーバーをfailure-recovery
サービスとしてUPSメンバーに自動移行するのが適しています。
注意:
サーバー全体の自動移行フレームワークを使用するようにサーバー・インスタンスが構成されている場合、期限切れのリースが更新されないとサーバーが停止されます。そのとき、サーバー・インスタンス上で構成されているfailure-recovery
サービスは、サーバー・インスタンスが管理者によって手動停止(強制停止または正常停止)された場合でも、自動移行されなくなります。詳細は、「サーバー全体の自動移行」を参照してください
「JMS関連サービスの自動移行を構成する手順」を参照してください
移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するオプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください
移行可能ターゲットのすべてのオプションのデフォルト値は、Oracle WebLogic Server MBeanリファレンスのMigratableTargetMBeanに関する項
を参照してください。
JMSサービスを移行可能ターゲットにデプロイする際には、サービスをホストするユーザー優先サーバー(UPS: User-Preferred Server)ターゲットを選択できます。また、移行可能ターゲットの構成時には、ユーザー優先サーバーで障害が発生したときにサービスをホストできる制約付き候補サーバー(CCS: Constrained Candidate Server)を指定することもできます。移行可能ターゲットに控えの候補サーバーが指定されていない場合、JMSサーバーはクラスタ内で使用可能な任意のサーバー・インスタンスに移行できます。
WebLogic Serverでは、JMSサービスごとに別々の移行可能ターゲットを作成できます。これにより、必要に応じて、クラスタ内の別々のサーバー・インスタンス上で常に各サービスを動作させ続けることが可能になっています。また逆に、JTAとJMS両方の控えの候補サーバーとして同じサーバー・インスタンス群を選択し、両方のサービスが確実にクラスタ内の同じサーバー・インスタンス上に配置されるように構成することもできます。
図8-1では、3つの管理対象サーバーから成るクラスタを示しています。すべての管理対象サーバーが移行可能ターゲットをホストしています。サーバーAは、JMSサーバーA (と2つのキュー)とカスタム・ストアに対する移行可能ターゲット(MT1)をホストしています。サーバーBは、パス・サービスとカスタム・ストアに対するMT2をホストし、JMSサーバーB (と2つのキュー)とカスタム・ストアに対するMT3もホストしています。サーバーCは、JMSサーバーC (と2つのキュー)とカスタム・ストアに対するMT4をホストしています。
すべての移行可能ターゲットが自動的に移行されるように構成されており、MT1、MT3、MT4ターゲットではfailure-recovery
ポリシーが、MT2ターゲットではexactly-once
ポリシーが使用されます。
上の例では、MT2 exactly-once
ターゲットによって、候補リスト内の実行中の管理対象サーバー上で自動的にパス・サービスとストアが開始されます。このように、ホスト・サーバーで障害が発生した場合、ターゲットのユーザー優先サーバー(UPS)が正常停止されたとしても、サービスは常にクラスタ内のどこかでアクティブなることが保証されています。ただし、「手動および自動のサービス移行ポリシー」,で説明したように、このポリシーを使用すると、1つのサーバー・インスタンスにホストされている複数のJMSサービスでターゲットのグループ化が生じる可能性があります。
一方、UPSが正常停止または強制停止された場合、failure-recovery
ターゲットであるMT1、MT3、MT4はUPS上で自動的にJMSサーバーとストア・サービスを開始しますが、固定サービスはどこにも移行されません。ただし、UPSが内部エラーによって停止した場合、サービスは別の候補サーバーに移行されます。
移行可能ターゲットを使用しない場合、JMSサーバーは、動的クラスタまたは特定のクラスタ・メンバーにターゲット指定でき、カスタム・ストアを使用できます。一方、移行可能ターゲットにターゲット指定する場合は、JMSサーバーでカスタム永続ストアを使用し、そのカスタム・ストアで使用する移行可能ターゲットにJMSサーバーをターゲット指定する必要があります。JMSサーバー、SAFエージェント、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。「JMSサービスで使用できるカスタム・ストア」を参照してください
WebLogic Serverは、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、JMSシステム・リソース・ターゲットがそのクラスタである場合は、移行可能なターゲットそれぞれに個別にターゲット指定される別々のJMSサーバーを作成します。
移行可能ターゲットを使用しない場合は、SAFエージェントをクラスタ全体にターゲット指定したり、クラスタ内のサーバー・インスタンス群のリストにターゲット指定したりできます。ただし、SAFエージェントおよびクラスタ内の各サーバー・インスタンスで、デフォルト永続ストアを使用する必要があります。一方、移行可能ターゲットにターゲット指定する場合は、JMSサーバーの場合と同様、SAFエージェントでカスタム永続ストアを使用し、そのカスタム・ストアで使用する移行可能ターゲットにSAFエージェントをターゲット指定する必要があります。SAFエージェント、JMSサーバー、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。「SAFエージェントまたはパス・サービスをターゲット指定する場合の特別な考慮事項」を参照してください
WebLogic Serverは、クラスタ内のサーバーごとに移行可能ターゲットを作成し、移行可能なターゲットそれぞれに個別にターゲット指定される別々のSAFエージェントを作成します。この処理により、スループットと高可用性が向上します。
さらに、SAFエージェントを移行可能ターゲットにターゲット指定する際には、次の点も考慮に入れてください。
SAFメッセージの一貫性を保持するために、WebLogic Serverでは既存のSAFエージェントを移行可能ターゲットに再割当てすることはできません。かわりに、既存のSAFエージェントを削除し、同じ値で構成した新しいSAFエージェントを移行可能ターゲットに割り当てる必要があります。
移行可能ターゲットを使用しない場合は、SAFエージェントをクラスタ全体またはクラスタ内の複数のサーバー・インスタンスにターゲット指定してメッセージ・スループットを向上させることができます。しかし、いったん1つの移行可能ターゲットにターゲット指定したSAFエージェントは、クラスタ内の他のサーバー・インスタンスにもクラスタ全体にもターゲット指定できなくなります。したがって、クラスタ内の別々のサーバー・インスタンス上の複数のSAFエージェントにJMS宛先をインポートしてスループットを向上させたい場合は、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、それぞれの移行可能ターゲットに個別にターゲット指定する複数のSAFエージェントを作成する必要があります。
WebLogic Server管理者は同じクラスタ内や同じサーバー・インスタンス上に、任意の数のSAFエージェントを構成およびデプロイできます。したがって、移行可能なSAFエージェントと移行可能でないSAFエージェントが、1つのサーバー・インスタンスに混在する状況も考えられます。そのような場合、どちらのSAFエージェントがメッセージを処理するかによって、JMSクライアント・アプリケーションの動作が異なる可能性があります。
たとえば、インポートした宛先を複数のSAFエージェントにデプロイできる場合、その宛先に送信されたメッセージはすべてのSAFエージェントの間でロード・バランシングされます。SAFエージェントのリストに移行可能でないエージェントが含まれていると、そのJMSクライアント・アプリケーションの高可用性は限定的なものになります。したがってベスト・プラクティスとしては、インポートした宛先を、同じレベルの高可用性機能を提供する1つまたは複数のSAFエージェントにデプロイすることをお薦めします。つまり、転送の品質と動作を確実に安定させるには、インポートした宛先をターゲット指定する複数のSAFエージェントが、すべて移行可能ターゲットにターゲット指定されているか、すべて移行可能でないターゲットにターゲット指定されている必要があるということです。
移行可能ターゲットを使用しない場合は、パス・サービスをクラスタ内の1つのメンバーにターゲット指定し、デフォルト・ファイル・ストアまたはカスタム・ストアのいずれかを使用できます。ただし、移行可能ターゲットにターゲット指定したパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。一方、JMSサーバー、SAFエージェント、およびカスタム・ストアは、1つの移行可能ターゲットを共有できます。
すべてのJMS関連サービスには、それと同じ移行可能ターゲットにターゲット指定されているカスタム永続ストアが必要です。カスタム・ストアを移行可能ターゲットにターゲット指定する場合は、移行可能ターゲットのすべての候補サーバー・メンバーからストア・ディレクトリにアクセスできるように、ストアの<directory>
パラメータを構成する必要があります。
WebLogic Serverは、クラスタ内のサーバー・インスタンスごとに移行可能ターゲットを作成し、JMSシステム・リソース・ターゲットがそのクラスタである場合は、移行可能なターゲットそれぞれに個別にターゲット指定される別々のJMSサーバーおよびファイル・ストアを作成します。
「JMSサービスで使用できるカスタム・ストア」を参照してください
JTAの場合は、JTA用の移行可能ターゲットがサーバー・レベルで自動的に定義されるため、移行可能ターゲットを構成する必要はありません。JTA自動移行を有効にするには、管理コンソールで「JTA移行ポリシー」を選択します。JTAのデフォルト移行ポリシーは「手動」です。自動サービス移行の場合、「障害リカバリ」または「停止リカバリ」のいずれかの移行ポリシーを選択します。これは、トランザクション・リカバリ・サービスが、ユーザー優先サーバー(UPS)の起動時にのみ開始されることを意味します。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。
一方、UPSが内部エラーによって停止した場合、このサービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー・インスタンス上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。
WebLogic Serverの移行フレームワークでは、JMS関連サービスやJTAトランザクション・リカバリ・サービスの手動移行または自動移行を実行するためのインフラストラクチャと機能を提供しています。デフォルトでは、あるサーバー・インスタンスから別のサーバー・インスタンスにサービスを正常に移行するために、管理者はこのプロセスを手動で実行する必要があります。ただし、サーバーに障害が発生した場合に自動的に移行されるように、これらのサービスを簡単に構成することもできます。
管理者はWebLogic Server管理コンソールを使用して、移行プロセスを構成し実行できます。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
サービス移行フレームワークは、次のコンポーネントを使用してサーバーのヘルス状態の問題をモニターし、固定サービスを正常なサーバー・インスタンスに自動的に移行します。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時には、リースをフェイルオーバーさせることができます。これにより、シングル・ポイント障害を回避できます。「リース」を参照してください。
自動移行
オプションを使用する場合は、クラスタの「移行基盤」
ポリシーを、次のように「データベース」
または「コンセンサス」
リースに設定する必要があります。
Oracle RACなどの高可用性データベースを使用してリース情報を管理する場合は、「高可用性データベース・リース」の手順に従って、サーバーの移行に使用するデータベースを構成します
「移行基盤」
を「データベース」
リースに設定するには、有効なJDBCシステム・リソースに「自動移行に使用するデータ・ソース」
オプションが設定されている必要があります。この設定は、管理対象サーバーでリースに使用する表が、そのリソース上に作成されていることを示します。JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの構成に関する項を参照してください。
「移行基盤」
を「コンセンサス」
リースに設定すると、メンバー・サーバーはリース情報をメモリー内に保持します。これにより、リースを使用するために高可用性データベースを用意する必要がなくなります。このバージョンのリースでは、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを管理する必要があります。また、移行可能な(または移行可能ターゲットをホストできる)すべてのサーバー・インスタンスにノード・マネージャを関連付ける必要もあります。ノード・マネージャは、関係するメンバー・サーバー・インスタンスに関するヘルス・モニター情報の取得の際に必要です。「コンセンサス(非データベース)リース」を参照してください
サービスの自動移行を使用する場合、次のように、メンバー・サーバーのヘルス・モニタリング情報を取得するため、ノード・マネージャが必要です。
コンセンサス・リース - クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。
データベース・リース - 移行前/移行後スクリプトが定義されている場合のみ、クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。
サービス移行リクエストに対応するため、移行可能ターゲットでは、デプロイされているヘルス・モニタリング・インタフェースを実装する移行可能サービスの基本的なヘルス・モニタリングを実行します。移行可能ターゲットにこのジョブを実行させることの利点は、その実行がローカルに限定される点です。また、移行可能ターゲットはリース・システムと直接通信するためのチャネルを備えており、ヘルス状態の悪化が検出された場合、リースを解放する(つまり移行をトリガーする)ことをリクエストできます。
JTAにおいて自動移行が有効になっている場合は、JTAサブシステムのヘルス状態が悪い(FAILED
)ことが報告されると、デフォルトではサーバーが停止します。たとえばトランザクション・ログへのアクセス時にI/Oエラーが発生した場合、JTAのヘルス状態がFAILED
に変わります。
プライマリ・サーバーで障害が発生すると、移行可能サービス・フレームワークがトランザクション・リカバリ・サービスを自動的にバックアップ・サーバーに移行します。サービス自動移行フレームワークでは、構成されている候補サーバーの中からバックアップ・サーバーが選択されます。トランザクション・リカバリ・アクションを完了する前にバックアップ・サーバーで障害が発生し、その後再起動された場合、トランザクション・リカバリ・サービスはクラスタ内の別のサーバー・インスタンスに移行されることになります(プライマリ・サーバーがその返還を要求するか、移行フレームワークがバックアップ・サーバー・インスタンスのリースの期限切れを通知します)。
移行が成功した後、バックアップ・サーバーが正常に停止して再起動されると、そのバックアップ・サーバー上でトランザクション・リカバリ・サービスが再度アクティブ化になります。この動作は、サービスの手動移行とまったく同じです。サービスの手動移行では、実行中のプライマリ・サーバーからトランザクション・リカバリ・サービスを移行することはできません。
JMS関連サービスの自動移行が有効になっている場合:
JMSサーバー - 実行時の自身のヘルス状態を保持して、ヘルス・モニタリング・サブシステムに登録および更新します。JMSサーバーのターゲット指定された永続ストアなど、JMSサーバーが依存しているサービスがFAILED
ヘルス状態を報告した場合、それは移行フレームワークによって検出されます。移行プロセスは、移行可能ターゲットの構成済自動移行ポリシーに基づいて実行されます。通常、移行フレームワークは現在のユーザー優先サーバー上でJMSサーバーと移行可能ターゲットのその他のユーザーを非アクティブ化し、控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンス上に移行します。
SAFサービス - 構成済のSAFエージェントからSAFサービスのヘルス状態が取得されます。SAFサービスが異常なヘルス状態を検出すると、SAFエージェント・インスタンス全体が異常であると報告されます。SAFエージェントにはJMSサーバーと同じヘルス・モニタリング機能があります。通常、移行フレームワークは現在のユーザー優先サーバー上でSAFエージェントを非アクティブ化し、控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンス上に移行します。
パス・サービス - パス・サービス自体は自身のヘルス状態を変更しませんが、そのかわりに、サーバー・インスタンスとそのカスタム・ストアに依存して移行をトリガーします。
永続ストア - 自身のヘルス状態をヘルス・モニタリング・サブシステムに登録します。永続ストアが読み書きを続行できず、再起動しないとデータの一貫性が保証されないような場合に、I/Oレイヤーによってエラーが報告されると、ストアのヘルス状態はFAILED
としてマークされ、ヘルス・モニタリング・サブシステムにFAILED
と報告されます。この状態が自動移行フレームワークによって検出され、ストアとそのストアに依存しているサブシステム・サービスの自動移行がトリガーされ、現在のユーザー優先サーバー・インスタンスから控えの候補サーバー・リストにある正常で使用可能なサーバー・インスタンスに移行されます。
JMSのような一部の移行可能サービスは、場合によってはサービスを移行するよりもその場所(インプレース)で再起動する方が利点があるという独自の要件を備えています。そのため、移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するためのrestart-in-place
オプションが提供されています。動的クラスタにターゲット指定されたカスタム・ストアでは、クラスタのターゲット指定JMSサービスに対してrestart-in-place
構成オプションも提供されます。
移行フレームワークは、サーバー・インスタンスのヘルス状態が正常(RUNNING
など)である場合にのみ、サービスの再起動を試行します。サーバー・インスタンスがなんらかの理由で正常でない場合、フレームワークはすべてのインプレース再起動をスキップして、ただちに移行段階に進みます。
クラスタのシングルトン・モニターはサービスのMigratableTargetMBean
のRestartOnFailure
値を確認します。値がfalse
の場合、サービスは移行されます。値がtrue
の場合、移行フレームワークはインプレースで非アクティブ化とアクティブ化を試行します。再アクティブ化が失敗すると、移行フレームワークはユーザーが指定したSecondsBetweenRestarts
の秒数休止します。指定されたNumberOfRestartAttempts
の回数、この試行が繰り返されます。すべての再起動の試行が失敗すると、サービスは正常なサーバー・メンバーに移行されます。
クラッシュした、または管理サーバーからアクセスできないサーバー・インスタンスからサービスを移行する場合は、特別な考慮事項があります。移行を行う時点で以前にアクティブだったサービスのホストに管理サーバーからアクセスできない場合、その管理対象サーバーのローカル構成情報(たとえば移行可能ターゲット)は、それがサービスのアクティブなホストでなくなっていることを反映して更新されることはありません。この場合は、アクセス不能な管理対象サーバーのローカル構成キャッシュを再起動前にパージする必要があります。そうすれば、以前にアクティブだったホストが、別の管理対象サーバーに移行しているサービスをホストするのを防ぐことができます。
サービスの自動移行では場合によって、コミットされていないトランザクションの進行中に、JMSサービスとJTAトランザクション・リカバリ・サービスの移行可能ターゲットが別々の候補サーバーに移行される可能性があります。しかし、JMSおよびJTAサービスの状態は時間や場所に依存していないため、JMSサービスが使用できるかどうかは、JTAトランザクションのリカバリが完了しているかどうかに依存しません。
ただし、両方のサービスが実行され、通信を再確立できるようになるまで、不明なトランザクションは解決されません。不明なトランザクションとは、複数の参加リソース(JMSサーバーやデータベースなど)が関与する不完全なトランザクションのことで、1つまたは複数のリソースが、トランザクション・マネージャからロールバック、コミット、あるいはトランザクションの一部であることを無視するように指示されるのを待機しています。トランザクション・マネージャまたは参加リソースがクラッシュしたときにトランザクションが進行中である場合、そのトランザクションは「不明」になる可能性があります。
リソースが使用可能でない場合、JTAはリカバリ中止期限(デフォルトは24時間)が切れるまで、トランザクションのリカバリを試行し続けます。
WebLogic Serverでは、サービスの移行をサポートするために、サービスの構成に一定の制約と前提条件が課されます。これらはサービス固有の制約で、採用しているエンタープライズ・アプリケーション・アーキテクチャによって異なります。
移行可能なJMS関連サービスでは、デフォルト永続ストアを使用することはできないため、カスタム・ストアを構成し、JMSサービスまたはSAFエージェントと同じ移行可能ターゲットにそれをターゲット指定する必要があります。パス・サービスの場合は、専用のカスタム・ストアと移行可能ターゲットを使用するのがベスト・プラクティスです。
カスタム・ファイル・ストアまたはJDBCストアは次のいずれかである必要があります。
移行可能ターゲットのすべての候補サーバー・メンバーからアクセス可能です。
アプリケーションでファイル・ベースの永続性(ファイル・ストア)を使用する場合は、移行可能ターゲットのすべての候補サーバー・メンバーからストア・ディレクトリにアクセスできるように、ストアの<directory>
パラメータを構成する必要があります。高い信頼性を実現したい場合は、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポートSCSIディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。
アプリケーションでJDBCベースの永続性(JDBCストア)を使用する場合は、すべての候補サーバー・メンバーからそのデータベース・インスタンスのJDBC接続情報(データ・ソース、接続プールなど)を使用できるようにする必要があります。
ORACLE_HOME/user_projects/domains/
mydomain
/bin/service_migration
ディレクトリ(mydomain
はドメイン固有のディレクトリでドメインと同じ名前)に格納されている移行前および移行後スクリプトを使用して、バックアップ・サーバー・ターゲットに移行されています。
注意:
移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txt
を参照してください。
状況によっては、スクリプトで移行元のサーバーからディスクをアンマウントし、バックアップ・サーバーにマウントする必要があります。これらのスクリプトは、Oracle WebLogic Server MBeanリファレンスに記載されたMigratableTargetMBean
のPreScript()
メソッドおよびPostScript()
メソッド、またはWebLogic Server管理コンソールを使用して、ノード・マネージャ上で構成されます。別のケースでは、カスタム・ファイル・ストアのディレクトリをバックアップ・サーバー・インスタンスに移動(コピーではなく)するためにスクリプトが必要となる場合があります。古いサーバー・インスタンスが次にその移行可能ターゲットをホストするときまで、古い構成済ファイル・ストア・ディレクトリを残さないでください。そのため、WebLogic Server管理者はこのファイルを削除するか、別のディレクトリに移動する必要があります。
クラスタ内の障害が発生したサーバー・インスタンスから同じクラスタ内の別のサーバー・インスタンス(バックアップ・サーバー・インスタンス)にJTAトランザクション・リカバリ・サービスを移行するには、障害が発生したサーバーのトランザクション・ログ(TLOG)レコードにバックアップ・サーバーからアクセスできる必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。
障害が発生した場合にサービスを移行する予定がある場合は、障害が発生した移行可能サーバーからの移行先となり得るすべてのマシンからアクセスできる共有ストレージ・システムにレコードが格納されるよう、デフォルト永続ストアを構成する必要があります。高い信頼性を実現したい場合は、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポート・ディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。なお、同じデフォルト・ストアを共有できるのは、JTAを始めとする移行可能でないサービスのみです。
必要に応じて、移行前スクリプトおよび移行後スクリプトを使用して、共有ストレージのアンマウントとマウントを実行できます。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、ORACLE_HOME/user_projects/domains/
mydomain
/bin/service_migration
ディレクトリ内のreadme.txt
ファイルを参照してください。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。
自動移行の場合は、現在の(移行元の)サーバーで障害が発生すると、移行フレームワークがトランザクション・リカバリ・サービスをターゲット・バックアップ・サーバーに自動的に移行します。
手動の移行の場合、トランザクション・リカバリ・サービスを、実行中のサーバー・インスタンスからバックアップ・サーバー・インスタンスに移行できません。トランザクション・リカバリ・サービスを移行する前に、サーバー・インスタンスを停止する必要があります。
表8-1に、実行状態に基づく移行のサポートを示します。
表8-1 サーバーの実行状態と手動移行のサポート
現在のサーバーのサーバー状態情報 | バックアップ・サーバーのサーバー状態情報 | メッセージング移行の許可 | JTA移行の許可 |
---|---|---|---|
実行中 |
実行中 |
はい |
いいえ |
実行中 |
スタンバイ |
はい |
いいえ |
実行中 |
実行されていない |
はい |
いいえ |
スタンバイ |
実行中 |
はい |
いいえ |
スタンバイ |
スタンバイ |
はい |
いいえ |
スタンバイ |
実行されていない |
はい |
いいえ |
実行されていない |
実行中 |
はい |
はい |
実行されていない |
スタンバイ |
はい |
いいえ |
実行されていない |
実行されていない |
はい |
はい |
動的または混在クラスタでは、JMS関連サービスの自動移行の簡単な構成も可能です。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理』のJMSクラスタと高可用性の簡略化された構成に関する項を参照してください。
自動移行の場合、WebLogic管理者は、JMSサーバーやSAFエージェントなどのJMS関連サービスに移行可能ターゲットを指定することもできます。管理者は、WebLogic Serverのヘルス・モニタリング機能に基づいて、障害が発生したサーバーから自動的に移行されるように移行可能サービスを構成することもできます。
注意:
JMSサービスはJTAトランザクション・リカバリ・サービスとは関係なく移行できます。ただし、JTAトランザクション・リカバリ・サービスは他のサブシステム・サービスのトランザクション制御を提供するため、通常は他のサブシステム・サービスと共に移行されます。これによって、サブシステム・サービスの移行前後でトランザクションの整合性が維持されます。
クラスタ内の移行可能ターゲットでJMSサービスの自動移行を構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。特定の状況では、ノード・マネージャも実行中でなければなりません。また、サーバーの自動移行を許可するように構成されている必要があります。
これらのタスクをWebLogic Server管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
注意:
移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス
値を設定する必要があります。そうしないと、移行は失敗します。
注意:
サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを制御し、すべての移行可能サーバーにノード・マネージャのインスタンスを関連付ける必要があります。データベース・リースを使用する場合は、移行前スクリプトおよび移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。
WebLogic Server管理コンソールの「クラスタ」→「構成」→「移行」ページで、データ永続性環境の構成方法に応じて、データベース・リーシング
またはコンセンサス・リーシング
のいずれかを選択して、クラスタの「移行基盤」
を構成します。「移行可能サービスのリース」を参照してください
この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。
WebLogic Server管理コンソールの移行可能ターゲットのサマリー表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバー・インスタンスごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、自動移行用にターゲット指定および構成する必要があります。
新しい移行可能ターゲットを作成する際は、WebLogic Server管理コンソールを使用して移行ポリシーを作成、ターゲット指定および選択します。
WebLogic Server管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバー・インスタンスを選択してターゲットを関連付けることができます。ユーザー優先サーバーとは、移行可能ターゲットのホストに最適なサーバー・インスタンスです。
注意:
自動的に移行されたサービスは指定されたユーザー優先サーバーにホストされない可能性もあります。移行されたサービスをホストしているサーバーを確認するには、WebLogic Server管理コンソールを使用して、「移行可能なターゲット」→「制御」ページの「現在のホスト・サーバー」
情報を参照してください。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「移行可能ターゲット: 制御」を参照してください。
移行可能ターゲットのデフォルトの移行ポリシーは「サービスの手動での移行のみ」
であるため、次のいずれかの自動移行ポリシーを選択する必要があります。
必ず1回のサービスを自動移行 - 候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバー・インスタンスで障害が発生するかサーバー・インスタンスが停止(正常停止または強制停止)しても、サービスはクラスタ内のどこかでアクティブになります。
注意:
この値を使用するとターゲットのグループ化が生じる可能性があります。たとえば、exactly-once
の移行可能ターゲットが5つあるときに、クラスタ内の1つの管理対象サーバーのみを起動すると、5つのターゲットすべてがそのサーバー・インスタンス上でアクティブ化されます。
障害リカバリ・サービスの自動移行 - このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。ただしUPSで内部エラーによる障害が発生した場合、サービスは別の候補サーバー・インスタンスに移行されます。手動停止または内部エラーにより候補サーバー・インスタンスが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバー・インスタンスに移行されます。
「手動および自動のサービス移行ポリシー」を参照してください
exactly-once
サービス移行ポリシーを使用する移行可能ターゲットを作成する場合は、JMSサーバーの移行先になる可能性のあるメンバー・サーバーを制限することもできます。推奨されるベスト・プラクティスは、各移行可能ターゲットの候補サーバー・セットを1番目、2番目または3番目のサーバー・インスタンスに制限することです。各サーバーが起動しているとき、移行可能ターゲットでは最初にオンラインになったサーバー・インスタンスが割り当てられるのではなく、その候補のサーバー・インスタンスに制限されます。管理者はサービスを手動でアイドル状態のサーバー・インスタンスに移行できます。
一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバー・インスタンスをクラスタ全体にする必要があり、これがデフォルトの設定です。
WebLogic Server管理コンソールの移行可能ターゲットの「構成」→「移行」ページで、控えの候補サーバーの「使用可能」
ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。管理対象サーバーは、「選択済み」
ボックスに移動すると有効な候補サーバーになります。
移行可能ターゲットを作成したら、必要に応じて共有カスタム・ファイル・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME
/user_projects/domains/
mydomain
/bin/service_migration
ディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。便宜を図るため、移行前スクリプトと移行後スクリプトのサンプルは、このディレクトリ内に置かれています。
移行可能ターゲットでは、サービスを移行せずに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するrestart-in-place
オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください
「JMSサービスで使用できるカスタム・ストア」で説明したように、JMS関連サービスの場合、動的クラスタ、またはJMSサービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアを構成する必要があります。ストアが次のいずれかであることを確認します。
移行可能ターゲット内のすべての候補サーバー・インスタンスからアクセスできるように構成されていること。
移行前スクリプトおよび移行後スクリプトで移行されていること。「移行前/移行後スクリプトを指定する(オプション)」を参照してください
移行可能ターゲットを使用する場合は、JMSサービスをカスタム永続ストアと同じ移行可能ターゲットにターゲット指定する必要があります。移行可能ターゲットを使用するJMSサービスのカスタム・ストアが指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト・ファイル・ストアを使用するJMSサーバーを移行可能ターゲットにターゲット指定しようとすると、次のようなメッセージが生成されます。
Since the JMS server is targeted to a migratable target, it cannot use the default store.
移行可能ターゲットにターゲット指定されているSAFエージェントまたはパス・サービスでデフォルト・ストアを使用しようとした場合も、同様のメッセージが生成されます。また、カスタム・ストアが移行可能サービスと同じ移行可能ターゲットにターゲット指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に、次のような検証ログ・メッセージが生成されます。
The JMS server is not targeted to the same target as its persistent store.
SAFエージェントまたはパス・サービスを移行可能ターゲットにターゲット指定する場合には、いくつか特別に考慮すべき事項があります。詳細は、「SAFエージェントのターゲット指定ルール」および「パス・サービスのターゲット指定ルール」を参照してください
JMSサービスを自動移行用に構成したら、管理サーバーを再起動する必要があります。また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。
移行元のプライマリ・サーバー・インスタンスが復旧したら、JMSサービスをもう一度移行して元のサーバー・インスタンスに戻す場合もあります。自動的にプライマリ・サーバー・インスタンスに移行されるJTAトランザクション・リカバリ・サービスとは異なり、JMSサービスは自動的には戻されないため手動で移行する必要があります。
WebLogic Server管理コンソールを使用してJMS関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。
WLSTを使用してJMS関連サービスを手動で移行する手順は、『WebLogic Server WLSTコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。
サーバー・インスタンスのデフォルトの移行可能ターゲットを使用すればほぼ問題ありません。サーバー・インスタンスごとに1つのデフォルトの移行可能ターゲットが存在します。または、サーバー・インスタンスごとに1つの移行可能ターゲットを構成することもできます。「ステップ3: 移行可能ターゲットを構成する」を参照してください
移行可能ターゲットごとに1つのカスタム・ストアを構成し、そのカスタム・ストアを移行可能ターゲットにターゲット指定します。「ステップ4: カスタム・ストアを構成およびターゲット指定する」を参照してください
各移行可能ターゲットにJMSサービス(JMSサーバーとSAFエージェント)を構成する際は、そのサービスが対応するカスタム・ストアを参照していることを確認します。その後、それらのサービスを各移行可能ターゲットにターゲット指定します。「ステップ5: JMSサービスをターゲット指定する」を参照してください
デプロイメント・モジュールではなく、JMSシステム・モジュールを使用します。WebLogic Server管理コンソールでは、システム・モジュールのみ構成できます。『Oracle WebLogic Server JMSリソースの管理』のJMSシステム・モジュール構成に関する項を参照してください。
予想されるターゲット・セットごとにシステム・モジュールを1つ作成し、そのモジュールを1つのクラスタにターゲット指定します。たとえば、1つの宛先が1つのJMSサーバーにまたがり、別の宛先が6つのJMSサーバーにまたがるようにするには、2つのモジュールを作成し、それらを同じクラスタにターゲット指定します。
モジュールごとにサブデプロイメントを1つ構成し、そのサブデプロイメントに同種のJMSサーバーまたはJMS SAFエージェントのターゲット・セットを設定します。サブデプロイメントにはWebLogic Serverやクラスタの名前を含めないでください。
接続ファクトリを同じクラスタ上で動作しているアプリケーションのクラスタにターゲット指定します。デフォルトのターゲット指定を使用して、モジュールのターゲットを継承させることができます。クラスタから離れた場所で実行しているアプリケーションを使用するには、WebLogic Server管理コンソール上で「高度なターゲット指定」を選択して接続ファクトリをサブデプロイメントにターゲット指定します。
宛先など、他のJMSモジュール・リソースについては、サブデプロイメントを使用してターゲット指定します。デフォルトのターゲット指定は利用しないでください。サブデプロイメントのターゲット指定は、WebLogic Server管理コンソールの「高度なターゲット指定」を選択すると実行できます。
JMSサーバーやSAFエージェントを追加または削除したら、モジュールのサブデプロイメントでも必ず追加または削除してください。
ロード・バランシングなど、クライアントの動作を制御する際にカスタム接続ファクトリを使用します。カスタム接続ファクトリは、他のリソースと同様にターゲット指定できますが、接続ファクトリのターゲット・セットは特別な意味を持ちます。接続ファクトリは、クラスタ、WebLogic Server、またはJMSサーバーやSAFエージェントに(サブデプロイメントを使用して)ターゲット指定できます。クライアントが使用するJMSサーバーやSAFエージェントに接続ファクトリをターゲット指定すると、パフォーマンス上のメリットがあります。これは、接続ファクトリのターゲット・セットにより、クライアント接続の候補ホスト・サーバー・インスタンスが決まるためです。JMSサーバーやSAFエージェントにターゲット指定すると、どのクラスタ・サーバー・インスタンス上にもSAFエージェントが存在しない場合に、JMSサーバーやSAFエージェントを持たないサーバー・インスタンスにクライアント接続が接続される可能性が低くなります。JMSサーバーやSAFエージェントが接続ホスト上に存在しない場合、クライアントからのリクエストは、最終的にJMSサーバーやSAFエージェントに届くまで、クライアントから接続ホスト・サーバーへのルートを常にダブル・ホップすることになります。
『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。
WebLogic JMSでは、管理者がJMS関連サービスの移行可能ターゲットを指定できるため、移行フレームワークを有効に活用できます。正しく構成されているJMSサービスであれば、クラスタ内の別のWebLogic Serverに手動で移行できます。移行には、予定されている移行の他に、クラスタ内のWebLogic Serverの障害に応じて行われる手動移行があります。
JMS関連サービスをクラスタ内の移行可能ターゲットに手動で移行できるように構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。
これらのタスクをWebLogic Server管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプにある次のトピックを参照してください。
注意:
移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス
値を設定する必要があります。そうしないと、移行は失敗します。
この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。
WebLogic Server管理コンソールの移行可能ターゲットのサマリー表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバー・インスタンスごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、移行用にターゲット指定および構成する必要があります。
新しい移行可能ターゲットを作成する際は、WebLogic Server管理コンソールを使用して移行ポリシーを作成、ターゲット指定および選択します。
WebLogic Server管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバーを選択してターゲットを関連付けることができます。優先サーバー・インスタンスは、移行可能ターゲットのホストに最適なサーバー・インスタンスです。
移行可能ターゲットを作成する際には、JMS関連サービスの移行先となり得るサーバー・インスタンスを、そのJMS関連サービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアにアクセスできるサーバーに限定することもできます。
一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバー・インスタンスをクラスタ全体にする必要があり、これがデフォルトの設定です。
WebLogic Server管理コンソールの移行可能ターゲットの「構成」→「移行」ページで、控えの候補サーバーの「使用可能」
ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。管理対象サーバーは、「選択済み」
ボックスに移動すると有効な候補サーバーになります。
移行可能ターゲットを作成したら、必要に応じて共有カスタム・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME
/user_projects/domains/
mydomain
/bin/service_migration
ディレクトリに配置する必要があります。mydomain
はドメインに固有のディレクトリで、ドメインと同じ名前です。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txt
を参照してください。
移行可能ターゲットでは、サービスを移行せずに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するrestart-in-place
オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください
「JMSサービスで使用できるカスタム・ストア」で説明したように、JMS関連サービスの場合、JMSサービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアを構成する必要があります。ストアが次のいずれかであることを確認します。
移行可能ターゲット内のすべての候補サーバー・インスタンスからアクセスできるように構成されていること。
移行前スクリプトおよび移行後スクリプトで移行されていること。「移行前/移行後スクリプトを指定する(オプション)」を参照してください
使用されるカスタム・ストアも同じ動的クラスタにターゲット指定される場合、JMSサービスを動的クラスタにターゲット指定できます。
移行可能ターゲットを使用する場合は、JMSサービスをカスタム永続ストアと同じ移行可能ターゲットにターゲット指定する必要があります。移行可能ターゲットを使用するJMSサービスのカスタム・ストアが指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト・ファイル・ストアを使用するJMSサーバーを移行可能ターゲットにターゲット指定しようとすると、次のようなメッセージが生成されます。
Since the JMS server is targeted to a migratable target, it cannot use the default store.
移行可能ターゲットにターゲット指定されているSAFエージェントまたはパス・サービスでデフォルト・ストアを使用しようとした場合も、同様のメッセージが生成されます。
また、カスタム・ストアが移行可能サービスと同じ移行可能ターゲットにターゲット指定されていない場合は、JMSサーバーのデプロイメントとWebLogic Serverの起動に失敗した後に、次のような検証ログ・メッセージが生成されます。
The JMS server is not targeted to the same target as its persistent store.
SAFエージェントまたはパス・サービスを移行可能ターゲットにターゲット指定する場合には、いくつか特別に考慮すべき事項があります。詳細は、「SAFエージェントのターゲット指定ルール」および「パス・サービスのターゲット指定ルール」を参照してください
JMSサービスを手動移行用に構成したら、管理サーバーを再起動する必要があります。
また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。
WebLogic Server管理コンソールを使用してJMS関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。
WLSTを使用してJMS関連サービスを手動移行する手順については、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。
注意:
移行元のプライマリ・サーバー・インスタンスが復旧したら、JMSサービスをもう一度移行して元のサーバー・インスタンスに戻す場合もあります。自動的にプライマリ・サーバー・インスタンスに移行されるJTAトランザクション・リカバリ・サービスとは異なり、JMSサービスは自動的には戻されないため手動で移行する必要があります。
JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバー・インスタンスのトランザクション処理をバックアップ・サーバー・インスタンスで完了できます。
トランザクション・リカバリ・サービスがクラスタ内の移行可能ターゲットに自動移行されるように構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。ノード・マネージャも実行中で、サーバーの自動移行ができるように構成されている必要があります。ノード・マネージャは、関係するサーバー・インスタンスに関するヘルス・ステータス情報の取得の際に必要です。
これらのタスクをWebLogic Server管理コンソールで実行する詳しい手順は、管理コンソールオンライン・ヘルプの次のトピックを参照してください。
注意:
JTAトランザクション回復サービスをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。そうしないと、移行は失敗します。
プライマリ・サーバー・インスタンスとリカバリ・モードの別のバックアップ・サーバー・インスタンスが同時にトランザクション・ログにアクセスすることを防止するために、プライマリ・サーバー・インスタンスが管理対象サーバー独立モード(MSI)で起動しないよう構成する方法は、『Oracle WebLogic Server JTAアプリケーションの開発』の管理対象サーバーの独立性に関する項を参照してください。
注意:
サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバー・インスタンスを制御し、すべての移行可能サーバーにノード・マネージャのインスタンスを関連付ける必要があります。データベース・リースを使用する場合は、移行前スクリプトおよび移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前スクリプトおよび移行後スクリプトが定義されていない場合、ノード・マネージャは必要ありません。
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。
WebLogic Server管理コンソールの「クラスタ」→「構成」→「移行」ページで、データ永続性環境の構成方法に応じて、データベース・リーシング
またはコンセンサス・リーシング
のいずれかを選択して、クラスタの「移行基盤」
を構成します。「移行可能サービスのリース」を参照してください
WebLogic Server管理コンソールの「サーバー」→「構成」→「移行」ページの「JTA移行の構成」セクションで、次のオプションを構成します。
JTA移行可能なターゲットでホストされるサービスに対して移行ポリシーを選択します。有効なオプションは次のとおりです。
手動
障害リカバリ
停止リカバリ
注意:
JTAの場合、「1回のみ」移行ポリシーは適用されません。
これらのポリシーの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Administration Consoleオンラインヘルプ』のサーバー: 構成: 移行に関する項を参照してください。
「JTA移行ポリシー」ドロップダウン・リストから、JTA移行可能ターゲットによってホストされているサービスの移行ポリシーを選択してJTAトランザクション・リカバリ・サービスの自動移行を構成します。
トランザクション・リカバリ・サービスの移行先となり得るサーバー・インスタンスを、現在のサーバー・インスタンスのデフォルトWebLogicストアに格納されているトランザクション・ログ・ファイルにアクセスできるサーバー・インスタンスのみに制限することもできます。候補サーバー・インスタンスを選択しない場合は、クラスタ内のいずれかのサーバー・インスタンスが候補サーバー・インスタンスとして選択されます。
候補サーバーの「使用可能」
ボックスから、JTAログ・ファイルにアクセスできる管理対象サーバーを選択します。管理対象サーバーは、「選択済み」
ボックスに移動すると有効な候補サーバーになります。
注意:
必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻せるように、選択済のリストに移行元のサーバー・インスタンスを含めておく必要があります。WebLogic Server管理コンソールでこのルールが実行されます。
共有ストレージのアンマウントおよびマウントを実行する移行前/移行後スクリプトを使用するかどうかを指定します。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前スクリプトおよび移行後スクリプトは、ORACLE_HOME
/user_projects/domains/
mydomain
/bin/service_migration
ディレクトリに配置する必要があります。mydomain
はドメインに固有のディレクトリで、ドメインと同じ名前です。移行前スクリプトおよび移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txt
を参照してください。
「JTAで使用できるデフォルト・ファイル・ストア」で説明したように、トランザクション・マネージャはデフォルト永続ストアを使用してトランザクション・ログ・ファイルを格納します。トランザクション・リカバリ・サービスの移行を有効化するには、移行元のサーバー・インスタンスで障害が発生した場合に、クラスタ内の別のサーバー・インスタンスから使用できる永続ストレージ・ソリューションにデータ・ファイルが格納されるよう、デフォルト永続ストアを構成する必要があります。
JTAトランザクション・リカバリ・サービスを自動移行用に構成したら、管理サーバーを再起動する必要があります。
また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。
障害が発生したサーバー・インスタンスでトランザクションのリカバリが完了すると、トランザクション・リカバリ・サービスの所有権がバックアップ・サーバー・インスタンスにより解放されるため、ターゲット・サーバー・インスタンスが再起動される際に、元のサーバー・インスタンスはこの所有権の返還を要求できます。トランザクションのリカバリが完了する前にバックアップ・サーバーが停止(クラッシュ)した場合は、そのリースが期限切れになります。これにより、プライマリ・サーバー・インスタンスは起動時に所有権の変換を要求できるようになります。
トランザクション・リカバリ・サービスのプライマリ・サーバー・インスタンスへの自動フェイルバックには、次の2つのシナリオがあります。
リカバリが完了した後に自動フェイルバック:
プライマリ・サーバー・インスタンスが再起動する前にバックアップ・サーバー・インスタンスがトランザクション・ログのトランザクション・リカバリを完了した場合は、トランザクション・リカバリ・サービスのプライマリ・サーバー・インスタンスへの移行が暗黙的に開始されます。
非アクティブ化後のスクリプトは、手動移行か自動移行かに関係なく自動的に実行されます。
リカバリが完了する前に自動フェイルバック:
プライマリ・サーバー・インスタンスが起動したときにトランザクション・ログのトランザクションのリカバリが進行中だった場合は、プライマリ・サーバーの起動時にトランザクション・リカバリ・サービスを開始する間に、バックアップ・サーバー・インスタンスからのトランザクション・リカバリ・サービスの暗黙的な移行が開始されます。
JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに手動で移行できます。この方法で、障害が発生したサーバー・インスタンスのトランザクション処理をバックアップ・サーバー・インスタンスで完了できます。
移行先サーバー・インスタンスとして元のサーバー・インスタンスを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻すことができます。ただし、バックアップ・サーバー・インスタンスが実行中である場合は、トランザクション・リカバリ・サービスを手動で移行して元のサーバー・インスタンスに戻すことはできません。
次に注意してください:
トランザクション・リカバリ・アクションが完了する前にバックアップ・サーバー・インスタンスで障害が発生した場合は、プライマリ・サーバー・インスタンスがトランザクション・リカバリ・サービスの所有権の変換を要求できないため、リカバリはサーバー・インスタンスの再起動時に再試行されません。したがって、この場合はトランザクション・リカバリ・サービスを別のバックアップ・サーバー・インスタンスに手動で移行しなおす必要があります。
バックアップ・サーバー・インスタンスによるトランザクションのリカバリ中に元のサーバー・インスタンスを再起動した場合は、バックアップ・サーバー・インスタンスが正常にトランザクション・リカバリ・サービスの所有権を解放します。バックアップ・サーバー・インスタンスを停止する必要はありません。詳細は、『Oracle WebLogic Server JTAアプリケーションの開発』の障害が発生したクラスタ・サーバーのトランザクションの回復に関する項を参照してください。
プライマリ・サーバー・インスタンスとリカバリ・モードの別のバックアップ・サーバー・インスタンスが同時にトランザクション・ログにアクセスすることを防止するために、プライマリ・バックアップ・サーバー・インスタンスが管理対象サーバー独立モード(MSI)で起動しないよう構成する方法は、『Oracle WebLogic Server JTAアプリケーションの開発』の管理対象サーバーの独立性に関する項を参照してください。
WebLogic Server管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・リカバリ・サービスの手動移行に関する項を参照してください。
シングルトン・サービスの自動移行では、シングルトン・サービスのヘルス・モニタリングと移行を自動化できます。シングルトン・サービスとは、クラスタ内の複数のサーバー・インスタンスで同時に実行できないサービスです。移行可能サービスで障害が発生した場合や、サービス・コードのバグ、サーバーの障害、ネットワークの障害などの理由で使用不能になった場合、その移行可能サービスは現在のサーバー・インスタンスで非アクティブ化され、新しいサーバー・インスタンスでアクティブ化されます。これらのサービスを別のサーバー・インスタンスに移行するプロセスは、シングルトン・マスターによって処理されます。「シングルトン・マスター」を参照してください。
WebLogic Serverでは、ユーザー定義のシングルトン・サービスを自動的に移行できます。
注意:
JTAトランザクション・リカバリ・サービスも、クラスタ内の複数のノードで同時に実行できないシングルトン・サービスですが、その自動移行を構成する方法はユーザー定義のシングルトン・サービスとは異なります。JMSおよびJTAサービスも手動で移行できます。「サービスの移行フレームワークの理解」を参照してください
この項では、シングルトン・サービスの自動移行をWebLogic Serverに実装する方法の概略を示します。
シングルトン・マスターは、自動移行可能な他のサービスをモニターする軽量シングルトン・サービスです。その時点でシングルトン・マスターをホストしているサーバー・インスタンスは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。
注意:
移行可能サービスは、シングルトン・マスターと同じサーバー・インスタンスでホストする必要はありませんが、同じクラスタ内でホストする必要があります。
シングルトン・マスターは、リースの競合によって維持される点や、同時に複数のサーバー・インスタンスで実行できない点で、クラスタ・マスターと似ています。クラスタ内の各サーバー・インスタンスは、シングルトン・マスターのリースの登録を継続的に試行します。現時点でシングルトン・マスターをホストしているサーバー・インスタンスに障害が発生すると、キュー内の次のサーバー・インスタンスがそのリースを引き継ぎ、シングルトン・マスターのホストを開始します。
クラスタ・マスターの詳細は、「サーバー全体の移行におけるクラスタ・マスターの役割」を参照してください
注意:
シングルトン・マスターとクラスタ・マスターはそれぞれ独立して機能するため、同じサーバー・インスタンスでホストする必要はありません。
シングルトン・マスターをホストするサーバー・インスタンスには、実行されたすべての移行の記録(ターゲット名、移行元サーバー、移行先サーバー、タイムスタンプなど)が保持されます。
シングルトン・サービスはアプリケーションの一部として、またはスタンドアロン・サービスとして定義できます。シングルトン・サービスは一度に1つのサーバー・インスタンス上でのみアクティブになるので、クラスタ内の1つのメンバーでのみ実行させるタスクに使用できます。
シングルトン・サービスを作成するには、シングルトン・サービスで実行するタスクに加えて、weblogic.cluster.singleton.SingletonService
インタフェースを実装するクラスを作成する必要があります。
SingletonService
インタフェースには、移行のプロセスで使用する次のメソッドが含まれています。
public void activate()
このメソッドは、シングルトン・サービスがリクエストの処理を開始するために必要なシステム・リソースの取得とサービスの開始を行います。このメソッドは次の場合に呼び出されます。
新たにデプロイされたアプリケーションが起動したとき
サーバーの起動中
サービス移行のアクティブ化段階
public void deactivate()
このメソッドは、サーバーの停止中、およびシングルトン・サービスの移行の非アクティブ化段階に呼び出されます。このメソッドを呼び出すことで、activate()
メソッドで取得したすべてのリソースが解放されます。また、クラスタの1つのメンバーからしか使用できないサービスはすべて停止します。
SingletonService
インタフェースを使用してシングルトン・サービスを定義した方法に応じて、次の手順を実行してシングルトン・サービスをデプロイする必要があります。
アプリケーション内にシングルトン・サービスをパッケージ化してデプロイします(アプリケーション・スコープ)。
~または~
シングルトン・サービスをWebLogic Server内にスタンドアロン・サービスとしてデプロイします(ドメイン全体)。
また、シングルトン・サービスの移行動作を構成できます。
注意:
アプリケーション・スコープのシングルトン・サービスをパッケージ化してデプロイする場合は、WebLogic Server管理コンソールを使用して、どの管理対象サーバーでサービスがホストされるかを制御できません。ただし、ドメイン全体のシングルトン・サービスをデプロイする場合は、WebLogic Server管理コンソールでサーバー名、クラス名および優先管理対象サーバーを指定できます。
次の項では、これらの詳細手順の概要を示します。
アプリケーション内にパッケージ化されるシングルトン・サービスでは、SingletonService
インタフェースを実装するクラスが、デプロイメント用のJARファイル内のAPP-INF/lib
またはAPP-INF/classes
ディレクトリ、あるいはEAR-level内のlib
ディレクトリに格納される必要があります。アプリケーション・スコープのシングルトン・サービスのJNDIバインドは、SingletonService
インタフェースでプログラムによって実行されます。アプリケーション・スコープのシングルトン・サービスのライフサイクルは、そのアプリケーションのライフサイクルと関連しています。
スタンドアロン・シングルトン・サービスのクラスは、WebLogic Serverシステムのクラスパスで使用できるようにする必要があります。
また、weblogic-application.xml
記述子ファイルに次のエントリを追加します。
<weblogic-application> ... <singleton-service> <class-name>mypackage.MySingletonServiceImpl</class-name> <name>Appscoped_Singleton_Service</name> </singleton-service> ... </weblogic-application>
注意:
<class-name>
および<name>
要素は必須です。
アプリケーション・スコープのシングルトン・サービスのデプロイメントは、アプリケーション・デプロイメントの一環として自動的に行われます。アプリケーションがデプロイされるクラスタ・メンバーがシングルトン・サービスの候補サーバー・インスタンスとなります。
SingletonService
インタフェースを使用するシングルトン・サービス・クラスを作成した後で、そのクラスをWebLogic Server内でシングルトン・サービスとして定義する必要があります。このシングルトン・サービス・オブジェクトには次の情報が格納されます。
シングルトン・サービスとしてロードするクラスのパス
シングルトン・サービスの優先サーバー・インスタンスとその他の候補サーバー・インスタンス
次に示すconfig.xml
ファイルの<cluster>
要素からの抜粋は、シングルトン・サービスをどのように定義するかを示しています。
<singleton-service> <name>SingletonTestServiceName</name> <user-preferred-server>myManaged1</user-preferred-server> <class-name>mycompany.myprogram.subpackage.SingletonTestServiceImpl</class-name> <cluster>myCluster</cluster> </singleton-service>
シングルトン・サービスは自動的にExactly-Once
サービスとして構成されます。つまり、候補リスト内の少なくとも1つの管理対象サーバーが実行されている場合は、サービスはクラスタ内のどこかでアクティブになります。次の方法を使用して、シングルトン・サービスの移行に関する特定のパラメータを変更できます。
WebLogic Server管理コンソール - シングルトン・サービスを作成して構成できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシングルトン・サービスの構成に関する項を参照してください。
WebLogic Scripting Tool (WLST) - MigratableTargetManagementMBean
を使用してサービスの自動移行を構成できます。『WebLogic Server WLSTコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。