|
|
以下の節では、WebLogic Server でサポートされているサービスの移行のメカニズムについて説明します。
これらの節では、障害が発生したサービスの移行について重点的に説明します。WebLogic Server では、サーバで障害が発生した場合に、サーバ全体を移行することも可能です。このサーバ全体の移行では、移行可能なサーバ インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。障害時のサーバ移行の詳細については、「サーバ全体の移行」を参照してください。
WebLogic Server では、アプリケーションレベルでのレプリケーションやフェイルオーバもサポートされています。詳細については、「クラスタのフェイルオーバとレプリケーション」を参照してください。
| 警告 : | サーバの自動移行は Solaris ゾーン機能を使用する Solaris 10 システムではサポートされていません。詳細については、『WebLogic Platform でサポート対象のコンフィグレーション』の「Sun Solaris 10 のマルチゾーン操作におけるサポート」を参照してください。 |
WebLogic Server クラスタでは、ほとんどのサブシステム サービスがクラスタ内のすべてのサーバ インスタンスで均一にホストされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS 関連のサービス、JTA トランザクション回復サービス、およびユーザ定義のシングルトン サービスなどの「固定サービス」は、クラスタ内の個別のサーバ インスタンスでホストされます。WebLogic Server 移行フレームワークでは、これらの固定サービスの障害回復を可能にするため、フェイルオーバに対立する概念として「サービスレベルの移行」がサポートされています。「移行可能サービス」を参照してください。
WebLogic Server におけるサービスレベルの移行とは、あるサーバ インスタンスに固定されているサービスを、クラスタ内の使用可能な別のサーバ インスタンスに移動するプロセスです。サービスレベルの移行は、JMS 関連サービスを論理的にグループ化した「移行可能対象」ごとに制御されます。移行可能対象は、クラスタ内のいずれか 1 つの物理サーバでホストされます。特定の固定サービスを対象指定する場合には、サーバやクラスタを選択する代わりに移行可能対象を選択できます。元のサーバで問題が発生した場合に、あるクラスタ化サーバから別のクラスタ化サーバに移行可能な対象を移行することにより、高可用性が実現します。また、定期的な保守を行うために移行可能対象を手動で移行したり、自動移行が行われるように移行可能対象をコンフィグレーションしたりできます。「クラスタ内の移行可能対象について」を参照してください。
移行フレームワークは、対象をコンフィグレーションおよび移行するためのツールとインフラストラクチャを提供します。また、サービスの自動移行の場合は、WebLogic Server のヘルス モニタ サブシステムを使用して、移行可能対象でホストされているサービスの状態をモニタします。「移行処理ツール」および「サービスの自動移行インフラストラクチャ」を参照してください。サーバおよびサービスの移行に関する用語の定義については、「移行関連の用語」を参照してください。
WebLogic Server では、JMS 関連サービス、JTA トランザクション回復サービス、およびユーザ定義のシングルトン サービスのサービスレベルの移行がサポートされています。これらのサービスは、クラスタ内のあるサーバから別のサーバに移すことができるため「移行可能サービス」と呼ばれます。自動移行または手動移行では、以下の移行可能サービスをコンフィグレーションできます。
JMS サービスはシングルトン サービスであるため、クラスタ内のすべてのサーバ インスタンスでアクティブになるわけではなく、データの一貫性を保持するためにクラスタ内の単一サーバに固定されます。シングルトン JMS サービスが原因で、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しないようにするため、シングルトン サービスを移行可能対象リスト内の任意のサーバ インスタンスに自動または手動で移行できるように WebLogic Server をコンフィグレーションできます。
トランザクション回復サービスは、システム起動時にトランザクションの回復を自動的に試行します。具体的には、すべてのトランザクション ログ レコードを解析し、未完了のトランザクションを完了させます。詳細については、『WebLogic JTA プログラマーズ ガイド』の「サーバに障害が発生した後のトランザクションの回復」を参照してください。
アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン サービスを定義できます。「ユーザ定義のシングルトン サービスの自動移行」を参照してください。
移行可能対象を使用すると、JMS サービスや JTA サービスをコンフィグレーションして可用性を高めることができます。移行可能対象とは、クラスタ内のサーバから別のサーバに移行できる特別な対象です。つまり、移行可能対象を使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能対象を移行すると、その対象によってホストされているすべてのサービスが移行されます。
移行可能な JMS サービスを移行できるようにコンフィグレーションするためには、そのサービスを移行可能対象にデプロイする必要があります。移行可能対象では、対象をホストできるサーバのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバを指定したり、その優先サーバで障害が発生した場合のバックアップ サーバ候補を順序付けしたリストを指定したりできます。ただし、移行可能対象を同時に複数のサーバでホストすることはできません。
移行可能対象を使用するようにコンフィグレーションしたサービスは、現時点でそれをホストしているサーバ メンバーから独立した存在になります。たとえば、ある 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 は同じキューの複数のインスタンスからではなく、1 セットのキューからのみメッセージを消費しようとします。つまり、この環境でクラスタ化を使用しているのは、アプリケーションのためにスケーラビリティ、ロード バランシング、フェイルオーバを実現するためで、JMS サーバのためではありません。したがって、この環境では、JMS サーバを exactly-once サービスとして使用可能なクラスタ メンバーに自動移行するのが適しています。
「JMS 関連サービスの自動移行をコンフィグレーションする手順」を参照してください。
このポリシーでは、UPS が起動されている場合にのみサービスが開始されます。管理者が手動で UPS を停止 (正常停止または強制停止) した場合、failure-recovery サービスは移行されません。ただし、UPS で内部エラーによる障害が発生した場合、failure-recovery サービスは別の候補サーバに移行されます。(手動停止または内部エラーにより) 候補サーバが使用できない場合、移行フレームワークはまず、UPS サーバ上でサービスを再アクティブ化しようとします。UPS サーバがその時点で使用できない場合、サービスは別の候補サーバに移行されます。
JMS サーバでの使用例 :
ドメイン内に 3 つの管理対象サーバから成るクラスタがあります。各メンバー サーバ上に JMS サーバがあり、各 JMS サーバ上には分散キュー メンバーがあります。また、このクラスタには、ローカルのサーバ メンバー上にある分散キュー メンバーからメッセージを消費する MDB が対象指定されています。つまり、この環境では全体的なスケーラビリティ、ロード バランシング、フェイルオーバを実現するためにクラスタ化を使用しています。したがって、この環境では、JMS サーバを failure-recovery サービスとして UPS メンバーに自動移行するのが適しています。
| 警告 : | サーバ全体の自動移行フレームワークを使用するようにサーバがコンフィグレーションされている場合 (このフレームワークでは期限切れのリースが更新されない場合にサーバが停止される)、そのサーバ上でコンフィグレーションされている failure-recovery サービスは、サーバが管理者によって手動停止 (強制停止または正常停止) された場合でも、自動移行されなくなります。詳細については、「サーバ全体の自動移行」を参照してください。 |
「JMS 関連サービスの自動移行をコンフィグレーションする手順」を参照してください。
移行可能対象では、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行するオプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください。
移行可能対象のすべてのオプションのデフォルト値については、『WebLogic Server MBean リファレンス』の「MigratableTargetMBean」を参照してください。
JMS サービスを移行可能対象にデプロイする際には、サービスをホストするユーザの優先サーバ (UPS : User-Preferred Server) 対象を選択できます。また、移行可能対象のコンフィグレーション時には、ユーザの優先サーバで障害が発生したときにサービスをホストできる控えの候補サーバ (CCS : Constrained Candidate Server) を指定することもできます。移行可能対象に控えの候補サーバが指定されていない場合、JMS サーバはクラスタ内で使用可能などのサーバにでも移行できます。
WebLogic Server では、JMS サービスごとに別々の移行可能対象を作成できます。これにより、必要に応じて、クラスタ内の別々のサーバ上で常に各サービスを動作させ続けることが可能になっています。また逆に、JTA と JMS 両方の候補サーバとして同じサーバ群を選択し、両方のサービスが確実にクラスタ内の同じサーバ上に配置されるようにすることもできます。
以下の図では、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 サービスで使用できるカスタム ストア」を参照してください。
移行可能対象を使用しない場合は、SAF エージェントをクラスタ全体に対象指定したり、クラスタ内のサーバ群のリストに対象指定したりできます。ただし、SAF エージェントおよびクラスタ内の各サーバで、デフォルト永続ストアを使用しなければなりません。一方、移行可能対象に対象指定した場合は、SAF エージェントも同じ移行可能対象に対象指定する必要があります。また、JMS サーバと同様、カスタム永続ストアを使用し、そのカスタム ストアで使用する移行可能対象に SAF エージェントを対象指定する必要があります。SAF エージェント、JMS サーバ、およびカスタム ストアは、1 つの移行可能な対象を共有できます。「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 分散送り先のメッセージ順序単位 (UOO) 情報を格納するための拡張ストレージが提供されます。これは、その UOO 情報が、分散送り先メンバーをホストするサーバ インスタンスのみでなく、移行可能対象全体に基づく情報になるためです。
すでに説明したように、すべての JMS 関連サービスには、それと同じ移行可能対象に対象指定されているカスタム永続ストアが必要です。カスタム ストアを移行可能対象に対象指定する場合は、移行可能対象のすべての候補サーバ メンバーからストア ディレクトリにアクセスできるように、ストアの <directory> パラメータをコンフィグレーションする必要があります。
「JMS サービスで使用できるカスタム ストア」を参照してください。
JTA の場合は、JTA 用の移行可能対象がサーバレベルで自動的に定義されるため、自動移行や手動移行のための移行可能対象は必要ありません。JTA のデフォルトの移行ポリシーは手動ですが、これを自動移行用にコンフィグレーションすると、JTA ポリシーは内部的に failure-recovery に設定されます。これは、トランザクション回復サービスが、ユーザの優先サーバ (UPS) の起動時にのみ開始されることを意味します。管理者が UPS を正常停止または強制停止した場合、このサービスは移行されません。
一方、UPS が内部エラーによって停止した場合、このサービスは別の候補サーバに移行されます。(手動停止または内部エラーにより) 候補サーバが使用できない場合、移行フレームワークはまず、UPS サーバ上でサービスを再アクティブ化しようとします。UPS サーバがその時点で使用できない場合、サービスは別の候補サーバに移行されます。
WebLogic Server の移行フレームワークでは、JMS 関連サービスや JTA トランザクション回復サービスの手動移行または自動移行を実行するためのインフラストラクチャと機能を提供しています。デフォルトでは、あるサーバ インスタンスから別のサーバ インスタンスにサービスを正常に移行するために、管理者はこのプロセスを手動で実行する必要があります。ただし、サーバに障害が発生した場合に自動的に移行されるように、これらのサービスを簡単にコンフィグレーションすることもできます。
WebLogic Administration Console を使用すると、移行プロセスをコンフィグレーションしたり実行したりできます。
詳細については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
WLST コマンドライン インタフェース ユーティリティを使用すると、移行プロセスのコンフィグレーションや実行を含め、サーバ インスタンスのライフサイクルを管理できます。
詳細については、『WebLogic Scripting Tool ガイド』の「ライフサイクル コマンド」を参照してください。
サービス移行フレームワークは、以下のコンポーネントを使用してサーバの状態をモニタし、必要に応じて固定サービスを正常なサーバに自動的に移行します。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタワイド エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に 1 つしか存在しません。また、サーバやクラスタの障害時には、リースをフェイルオーバさせることができます。これにより、シングル ポイント障害を回避できます。「リース」を参照してください。
自動移行オプションを使用する場合は、クラスタの [移行基盤] ポリシーを、以下のように [データベース] または [コンセンサス] リースに設定する必要があります。
Oracle RAC などの高可用性データベースを使用してリース情報を管理する場合は、「高可用性データベース リース」の手順に従って、サーバの移行に使用するデータベースをコンフィグレーションします。
[移行基盤] を [データベース] リースに設定するには、有効な JDBC システム リソースに [自動移行に使用するデータ ソース] オプションが設定されている必要があります。この設定は、管理対象サーバでリースに使用するテーブルが、そのリソース上に作成されることを示します。JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
[移行基盤] を [コンセンサス] リースに設定すると、メンバー サーバはリース情報をメモリ内に保持します。これにより、リースを使用するために高可用性データベースを用意する必要がなくなります。このリース方法では、ノード マネージャを使用してクラスタ内のサーバを管理する必要があります。また、移行可能な (または移行可能対象をホストできる) すべてのサーバにノード マネージャを関連付ける必要もあります。ノード マネージャが必要になるのは、関係するメンバー サーバのヘルス モニタ情報を取得するためです。「コンセンサス (非データベース) リース」を参照してください。
サービスの自動移行を使用する場合は、関係するメンバー サーバのヘルス モニタ情報を取得するため、ノード マネージャを以下のように実行する必要があります。
ノード マネージャのコンフィグレーションの詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。
移行中のシングル ポイント障害を排除するため、移行可能サービスの自動移行は、移行中に管理サーバが使用可能かどうかには依存しません。
サービスの移行リクエストに対応するため、移行可能対象にはヘルス モニタ インタフェースが実装されており、デプロイされている移行可能サービスの基本的な状態モニタを実行します。移行可能対象に状態モニタを実行させることの利点は、その実行がローカルに限定される点です。また、移行可能対象はリース システムと直接通信するためのチャネルを備えており、ヘルス状態の悪化が検出されたらリースを解放する (つまり移行をトリガする) ことを要求できます。
JTA において自動移行が有効になっている場合は、JTA サブシステムに異常がある (ヘルス状態が FAILED になった) ことが報告されると、デフォルトではサーバが停止します。JTA のヘルス状態が FAILED に変わるのは、たとえば TLOG へのアクセス時に IO エラーが発生した場合です。
プライマリ サーバで障害が発生すると、移行可能サービス フレームワークがトランザクション回復サービスを自動的にバックアップ サーバに移行します。サービス自動移行フレームワークでは、コンフィグレーションされている候補サーバの中からバックアップ サーバが選択されます。トランザクション回復アクションを完了する前にバックアップ サーバで障害が発生した場合、そのサーバは再起動され、トランザクション回復サービスはクラスタ内の別のサーバに移行されます (その場合、プライマリ サーバによってそのように要求されるか、移行フレームワークからバックアップ サーバのリースの期限切れが通知されます)。
移行が成功した後、バックアップ サーバが正常に停止して再起動されると、そのバックアップ サーバ上でトランザクション回復サービスが再度アクティブになります。この動作は、サービスの手動移行とまったく同じです。サービスの手動移行では、実行中のプライマリ サーバからトランザクション回復サービスを移行することはできません。
JMS 関連サービスの自動移行が有効になっている場合は、以下のように動作します。
FAILED ヘルス状態を報告すると、移行フレームワークによって検出され、移行可能対象でコンフィグレーションされている自動移行ポリシーに基づいて移行プロセスが発生します。通常、移行フレームワークは現在のユーザ優先サーバ上で JMS サーバと移行可能対象のその他のユーザを非アクティブ化し、控えの候補サーバ リストにある正常で使用可能なサーバ上に移行します。FAILED としてマークされ、ヘルス モニタ サブシステムに FAILED と報告されます。この状態が自動移行フレームワークによって検出され、ストアとそのストアに依存しているサブシステム サービスの自動移行がトリガされ、現在のユーザ優先サーバから控えの候補サーバ リストにある正常で使用可能なサーバに移行されます。
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 ディスクなど、高可用性の備わっている共有ストレージ ソリューションを使用してください。BEA_HOME/user_projects/domains/mydomain/bin/service_migration ディレクトリ (mydomain はドメイン固有のディレクトリでドメインと同じ名前) に格納されている移行前/移行後スクリプトを使用して、バックアップ サーバ対象に移行される。 | 注意 : | 移行前/移行後スクリプトを作成する基本的な手順については、このディレクトリ内の readme.txt を参照してください。 |
状況によっては、スクリプトで移行元のサーバからディスクをアンマウントし、バックアップ サーバにマウントしなければならない場合もあります。これらのスクリプトは、『WebLogic Server MBean リファレンス』の「MigratableTargetMBean」の PreScript() および PostScript() メソッド、または Administration Console を使用してノード マネージャにコンフィグレーションします。それ以外にも、スクリプトでカスタム ファイル ストア ディレクトリをバックアップ サーバに (コピーではなく) 移動しなければならない場合もあります。移行元にコンフィグレーションされていたファイル ストア ディレクトリは、移行可能対象が次回その移行元サーバによってホストされるときに残っていてはなりません。したがって、そのファイルを削除するか、別のディレクトリに移動する必要があります。
クラスタ内の障害が発生したサーバから同じクラスタ内の別のサーバ (バックアップ サーバ) に JTA トランザクション回復サービスを移行するには、障害が発生したサーバのトランザクション ログ (TLOG) レコードにバックアップ サーバからアクセスできる必要があります。トランザクション ログ レコードは、サーバのデフォルト永続ストアに格納されています。
障害が発生した場合にサービスを移行する予定がある場合は、障害が発生した移行可能サーバからの移行先となり得るすべてのマシンからアクセスできる共有ストレージ システムに TLOG レコードが格納されるよう、デフォルト永続ストアをコンフィグレーションする必要があります。高い信頼性を実現したい場合は、ストレージ エリア ネットワーク (SAN) やデュアルポート ディスクなど、高可用性の備わっている共有ストレージ ソリューションを使用してください。なお、同じデフォルト ストアを共有できるのは、JTA を始めとする移行可能でないサービスのみです。
必要に応じて、移行前/移行後スクリプトを使用して、共有ストレージのアンマウントとマウントを実行できます。移行前/移行後スクリプトを作成する基本的な手順については、BEA_HOME/user_projects/domains/mydomain/bin/service_migration ディレクトリ内の readme.txt を参照してください。mydomain はドメインに固有のディレクトリで、ドメインと同じ名前です。
自動移行の場合は、現在の (移行元の) サーバで障害が発生すると、移行フレームワークがトランザクション回復サービスを対象のバックアップ サーバに自動的に移行します。
手動移行の場合は、トランザクション回復サービスを実行中のサーバからバックアップ サーバに移行することはできません。トランザクション回復サービスを移行する前に、サーバを停止する必要があります。
WebLogic JMS では、管理者が JMS 関連サービス (JMS サーバや SAF エージェントなど) の移行可能対象を指定できるため、移行フレームワークを有効に活用できます。WebLogic 管理者は、WebLogic Server のヘルス モニタ機能に基づいて、障害が発生したサーバから自動的に移行されるように移行可能サービスをコンフィグレーションすることもできます。
| 注意 : | JMS サービスは JTA トランザクション回復サービスとは関係なく移行できます。ただし、JTA トランザクション回復サービスは他のサブシステム サービスのトランザクション制御を提供するため、通常は他のサブシステム サービスと一緒に移行されます。こうすると、サブシステム サービスの移行前後でトランザクションの整合性が維持されます。 |
クラスタ内の移行可能対象で JMS サービスの自動移行をコンフィグレーションするには、次の手順に従います。
クラスタ内の管理対象サーバを移行用にコンフィグレーションします。たとえば、管理対象サーバをマシンに割り当てる必要があります。特定の状況では、ノード マネージャも実行中でなければなりません。また、サーバの自動移行を許可するようにコンフィグレーションされている必要があります。
これらのタスクを Administration Console で実行する詳しい手順については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
| 注意 : | 移行する JMS サーバをホストすることになる管理対象サーバのインスタンスには、ユニークなリスン アドレス値を設定する必要があります。ユニークな値が設定されていない場合、移行は失敗します。 |
| 注意 : | サービスの自動移行でコンセンサス リースを使用する場合は、ノード マネージャを使用してクラスタ内のサーバを制御し、すべての移行可能サーバにノード マネージャを関連付ける必要があります。データベース リースを使用する場合は、移行前/移行後スクリプトを定義する場合にのみノード マネージャが必要です。移行前/移行後スクリプトを定義しない場合はノード マネージャは必要ありません。 |
ノード マネージャのコンフィグレーションの詳細については、『ノード マネージャ管理者ガイド』の「ノード マネージャを使用したサーバの制御」を参照してください。
[クラスタ｜コンフィグレーション｜移行] ページで、コンフィグレーションされているデータ永続性環境に応じて、クラスタの「移行基盤」(データベース リースとコンセンサス リースのどちらかを使用するか) をコンフィグレーションします。「移行可能サービスのリース」を参照してください。
この手順は、JMS 関連サービスを対象指定したり、JTA トランザクション回復サービスの移行を有効にしたりする前に実行する必要があります。
Administration Console の [移行可能な対象] テーブルには、サーバと同じ名前の移行可能対象が表示されます。これらの移行可能対象は、クラスタ内の実行中のサーバごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、自動移行用に対象指定およびコンフィグレーションする必要があります。
新しい移行可能対象を作成する際は、Administration Console を使用して移行ポリシーを作成、対象指定、および選択します。
Administration Console を使用して新しい移行可能対象を作成する場合は、最初にクラスタ内の優先サーバを選択して対象を関連付けることができます。ユーザ優先サーバとは、移行可能対象をホストするサーバとして最優先されるサーバです。
| 注意 : | 自動的に移行されたサービスは指定されたユーザ優先サーバにホストされない可能性もあります。移行されたサービスをホストしているサーバを確認するには、Administration Console を使用して、[移行可能な対象 : 制御] ページの [現在のホスト サーバ] の情報を参照してください。詳細については、Administration Console オンライン ヘルプの「移行可能な対象 : 制御」を参照してください。 |
移行可能対象のデフォルトの移行ポリシーは [サービスの手動での移行のみ] であるため、以下のいずれかの自動移行ポリシーを選択する必要があります。
| 注意 : | この値を使用すると対象のグループ化につながる可能性があります。たとえば、「必ず 1 回」の移行可能対象が 5 つあるときに、クラスタ内の 1 つの管理対象サーバのみを起動すると、5 つの対象すべてがそのサーバ上でアクティブ化されます。 |
「手動および自動のサービス移行ポリシー」を参照してください。
exactly-once サービス移行ポリシーを使用する移行可能対象を作成する場合は、JMS サーバの移行先になる可能性のあるメンバー サーバを制限することもできます。推奨されるベスト プラクティスは、各移行可能対象の候補サーバ セットを 1 番目、2 番目、あるいは 3 番目のサーバまでに制限することです。各サーバが起動しているとき、移行可能対象では、最初にオンラインになったサーバが割り当てられるのではなく、その候補サーバに制限されます。管理者はサービスを手動でアイドル状態のサーバに移行できます。
一方、クラスタのパス サービスの場合は、移行可能対象の候補サーバをクラスタ全体にする必要があり、これがデフォルトの設定です。
移行可能対象の [コンフィグレーション｜移行] ページにある控えの候補サーバの [使用可能] ボックスには、移行可能対象をサポートできる管理対象サーバの一覧が表示されます。これらのサーバは、[選択済み] ボックスに移動すると有効な候補サーバになります。
移行可能対象を作成したら、必要に応じて共有カスタム ファイル ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前/移行後スクリプトは、BEA_HOME/user_projects/domains/mydomain/bin/service_migration ディレクトリに配置する必要があります。mydomain はドメインに固有のディレクトリで、ドメインと同じ名前です。利便性のために、このディレクトリには移行前/移行後スクリプトのサンプルが用意されています。
移行可能対象では、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行する「インプレースでの再起動」オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください。
「JMS サービスで使用できるカスタム ストア」で説明したように、JMS 関連サービスの場合はカスタム永続ストアをコンフィグレーションする必要があります。このストアは、JMS 関連サービスと同じ移行可能対象に対象指定し、以下のいずれかの条件を満たす必要があります。
移行可能対象を使用する場合は、JMS サービスをカスタム永続ストアと同じ移行可能対象に対象指定する必要があります。移行可能対象を使用する JMS サービスのカスタム ストアが指定されていない場合は、JMS サーバのデプロイメントと WebLogic Server の起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト ファイル ストアを使用する JMS サーバを移行可能対象に対象指定しようとすると、次のようなメッセージが生成されます。
JMS サーバの対象が移行可能対象に指定されているため、デフォルト ストアは使用できません。
移行可能対象に対象指定されている SAF エージェントまたはパス サービスでデフォルト ストアを使用しようとした場合も、同様のメッセージが生成されます。また、カスタム ストアが移行可能サービスと同じ移行可能対象に対象指定されていない場合は、JMS サーバのデプロイメントと WebLogic Server の起動に失敗した後に、次のような検証ログ メッセージが生成されます。
JMS サーバの対象が永続ストアの対象と同じではありません。
SAF エージェントまたはパス サービスを移行可能対象に対象指定する場合には、いくつか特別に考慮すべき事項があります。詳細については、「SAF エージェントの対象指定ルール」および「パス サービスの対象指定ルール」を参照してください。
JMS サービスを自動移行用にコンフィグレーションしたら、管理サーバを再起動する必要があります。また、移行ポリシーを変更した管理対象サーバも再起動する必要があります。
移行元のプライマリ サーバが復旧したら、JMS サービスをもう一度移行して元のサーバに戻したい場合もあります。自動的にプライマリ サーバに移行される JTA トランザクション回復サービスとは異なり、JMS サービスは自動的には戻されないため手動で移行する必要があります。
Administration Console を使用して JMS 関連サービスを手動移行する手順については、Administration Console オンライン ヘルプの「JMS 関連サービスの手動移行」を参照してください。
WLST を使用して JMS 関連サービスを手動移行する手順については、『WebLogic Scripting Tool ガイド』の「WLST コマンドおよび変数リファレンス」を参照してください。
WebLogic JMS では、管理者が JMS 関連サービスの移行可能対象を指定できるため、移行フレームワークを有効に活用できます。正しくコンフィグレーションされている JMS サービスであれば、クラスタ内の別の WebLogic Server に手動で移行できます。移行には、予定されている移行のほかに、クラスタ内の WebLogic Server の障害に対応して行われる手動移行があります。
JMS 関連サービスをクラスタ内の移行可能対象に手動で移行できるようにコンフィグレーションするには、次の手順に従います。
クラスタ内の管理対象サーバを移行用にコンフィグレーションします。たとえば、管理対象サーバをマシンに割り当てる必要があります。
これらのタスクを Administration Console で実行する詳しい手順については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
| 注意 : | 移行する JMS サーバをホストすることになる管理対象サーバのインスタンスには、ユニークなリスン アドレス値を設定する必要があります。ユニークな値が設定されていない場合、移行は失敗します。 |
この手順は、JMS 関連サービスを対象指定したり、JTA トランザクション回復サービスの移行を有効にしたりする前に実行する必要があります。
Administration Console の [移行可能な対象] テーブルには、サーバと同じ名前の移行可能対象が表示されます。これらの移行可能対象は、クラスタ内の実行中のサーバごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、移行用に対象指定およびコンフィグレーションする必要があります。
新しい移行可能対象を作成する際は、Administration Console を使用して移行ポリシーを作成、対象指定、および選択します。
Administration Console を使用して新しい移行可能対象を作成する場合は、最初にクラスタ内の優先サーバを選択して対象を関連付けることができます。優先サーバとは、移行可能対象をホストするサーバとして最優先されるサーバです。
すべての移行可能対象のデフォルトの移行ポリシーは [サービスの手動での移行のみ] であるため、変更する必要はありません。
移行可能対象を作成する際は、JMS 関連サービスの移行先となり得るサーバを、その JMS 関連サービスと同じ移行可能対象に対象指定されたカスタム永続ストアにアクセスできるサーバに限定したい場合もあります。
一方、クラスタのパス サービスの場合は、移行可能対象の候補サーバをクラスタ全体にする必要があり、これがデフォルトの設定です。
移行可能対象の [コンフィグレーション｜移行] ページにある控えの候補サーバの [使用可能] ボックスには、移行可能対象をサポートできる管理対象サーバの一覧が表示されます。これらのサーバは、[選択済み] ボックスに移動すると有効な候補サーバになります。
移行可能対象を作成したら、必要に応じて共有カスタム ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前/移行後スクリプトは、BEA_HOME/user_projects/domains/mydomain/bin/service_migration ディレクトリに配置する必要があります。mydomain はドメインに固有のディレクトリで、ドメインと同じ名前です。移行前/移行後スクリプトを作成する基本的な手順については、このディレクトリ内の readme.txt を参照してください。
移行可能対象では、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行する「インプレースでの再起動」オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください。
「JMS サービスで使用できるカスタム ストア」で説明したように、JMS 関連サービスの場合はカスタム永続ストアをコンフィグレーションする必要があります。このストアは、JMS 関連サービスと同じ移行可能対象に対象指定し、以下のいずれかの条件を満たす必要があります。
移行可能対象を使用する場合は、JMS サービスをカスタム永続ストアと同じ移行可能対象に対象指定する必要があります。移行可能対象を使用する JMS サービスのカスタム ストアが指定されていない場合は、JMS サーバのデプロイメントと WebLogic Server の起動に失敗した後に検証メッセージが生成されます。たとえば、デフォルト ファイル ストアを使用する JMS サーバを移行可能対象に対象指定しようとすると、次のようなメッセージが生成されます。
JMS サーバの対象が移行可能対象に指定されているため、デフォルト ストアは使用できません。
移行可能対象に対象指定されている SAF エージェントまたはパス サービスでデフォルト ストアを使用しようとした場合も、同様のメッセージが生成されます。
また、カスタム ストアが移行可能サービスと同じ移行可能対象に対象指定されていない場合は、JMS サーバのデプロイメントと WebLogic Server の起動に失敗した後に、次のような検証ログ メッセージが生成されます。
JMS サーバの対象が永続ストアの対象と同じではありません。
SAF エージェントまたはパス サービスを移行可能対象に対象指定する場合には、いくつか特別に考慮すべき事項があります。詳細については、「SAF エージェントの対象指定ルール」および「パス サービスの対象指定ルール」を参照してください。
JMS サービスを手動移行用にコンフィグレーションしたら、管理サーバを再起動する必要があります。
また、移行ポリシーを変更した管理対象サーバも再起動する必要があります。
Administration Console を使用して JMS 関連サービスを手動移行する手順については、Administration Console オンライン ヘルプの「JMS 関連サービスの手動移行」を参照してください。
WLST を使用して JMS 関連サービスを手動移行する手順については、『WebLogic Scripting Tool ガイド』の「WLST コマンドおよび変数リファレンス」を参照してください。
| 注意 : | 移行元のプライマリ サーバが復旧したら、JMS サービスをもう一度移行して元のサーバに戻したい場合もあります。自動的にプライマリ サーバに移行される JTA トランザクション回復サービスとは異なり、JMS サービスは自動的には戻されないため手動で移行する必要があります。 |
JTA トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に行うために設計されたものです。サーバ ヘルス モニタ サービスを使用することで、トランザクション回復サービスを異常のあるサーバ インスタンスから正常なサーバ インスタンスに自動的に移行できます。これにより、障害が発生したサーバのトランザクション処理をバックアップ サーバで完了できます。
トランザクション回復サービスがクラスタ内の移行可能対象に自動移行されるようにコンフィグレーションするには、次の手順に従います。
クラスタ内の管理対象サーバを移行用にコンフィグレーションします。たとえば、管理対象サーバをマシンに割り当てる必要があります。ノード マネージャも実行中でなければなりません。また、サーバの自動移行を許可するようにコンフィグレーションされている必要があります。ノード マネージャが必要になるのは、関係するサーバの活性情報を取得するためです。
これらのタスクを Administration Console で実行する詳しい手順については、Administration Console オンライン ヘルプの以下のトピックを参照してください。
| 注意 : | プライマリ サーバと回復モードの別のバックアップ サーバが同時に TLOG にアクセスすることを防ぐため、プライマリ サーバが管理対象サーバ独立モード (MSI : Managed Server Independence) で起動しないようにコンフィグレーションする方法については、『WebLogic JTA プログラマーズ ガイド』の「管理対象サーバの独立性」を参照してください。 |
| 注意 : | サービスの自動移行でコンセンサス リースを使用する場合は、ノード マネージャを使用してクラスタ内のサーバを制御し、すべての移行可能サーバにノード マネージャを関連付ける必要があります。データベース リースを使用する場合は、移行前/移行後スクリプトを定義する場合にのみノード マネージャが必要です。移行前/移行後スクリプトを定義しない場合はノード マネージャは必要ありません。 |
ノード マネージャのコンフィグレーションの全般情報については、『ノード マネージャ管理者ガイド』の「ノード マネージャの概要」を参照してください。
[クラスタ｜コンフィグレーション｜移行] ページで、コンフィグレーションされているデータ永続性環境に応じて、クラスタの「移行基盤」(データベース リースとコンセンサス リースのどちらかを使用するか) をコンフィグレーションします。「移行可能サービスのリース」を参照してください。
[サーバ｜コンフィグレーション｜移行] ページの [JTA 移行のコンフィグレーション] セクションで、以下のオプションをコンフィグレーションします。
[JTA の自動移行を有効化] チェック ボックスをチェックして、JTA トランザクション回復サービスの自動移行をコンフィグレーションします。
トランザクション回復サービスの移行先となり得るサーバを、現在のサーバのデフォルト WebLogic ストアに格納されているトランザクション ログ ファイルにアクセスできるサーバのみに制限することもできます。候補サーバを選択しない場合は、クラスタ内のいずれかのサーバが候補サーバとして選択されます。
候補サーバの [使用可能] ボックスから、JTA ログ ファイルにアクセスできる管理対象サーバを選択します。これらのサーバは、[選択済み] ボックスに移動すると有効な候補サーバになります。
| 注意 : | 必要に応じてトランザクション回復サービスを手動で移行して元のサーバに戻せるように、[選択済み] リストに移行元のサーバを含めておく必要があります。Administration Console では、この規則に従わなくてはなりません。 |
共有ストレージのアンマウントおよびマウントを実行する移行前/移行後スクリプトを使用するかどうかを指定します。
移行前/移行後スクリプトは、BEA_HOME/user_projects/domains/mydomain/bin/service_migration ディレクトリに配置する必要があります。mydomain はドメインに固有のディレクトリで、ドメインと同じ名前です。移行前/移行後スクリプトを作成する基本的な手順については、このディレクトリ内の readme.txt を参照してください。
「JTA で使用できるデフォルト ファイル ストア」で説明したように、トランザクション マネージャはデフォルト永続ストアを使用してトランザクション ログ ファイルを格納します。トランザクション回復サービスの移行を有効化するには、移行元のサーバで障害が発生した場合に、クラスタ内の別のサーバから使用できる永続ストレージ ソリューションにデータ ファイルが格納されるよう、デフォルト永続ストアをコンフィグレーションする必要があります。
JTA トランザクション回復サービスを自動移行用にコンフィグレーションしたら、管理サーバを再起動する必要があります。
また、移行ポリシーを変更した管理対象サーバも再起動する必要があります。
バックアップ サーバは、障害が発生したサーバのトランザクションの回復が完了すると、トランザクション回復サービスの所有権を解放します。そのため、元のサーバは再起動時にその所有権の返還を要求できます。トランザクションの回復が完了する前にバックアップ サーバが停止 (クラッシュ) した場合は、そのリースが期限切れになります。これにより、プライマリ サーバが起動時に所有権の返還を要求することが可能になります。
トランザクション回復サービスのプライマリ サーバへの自動フェイルバックには、以下の 2 つのシナリオがあります。
JTA トランザクション回復サービスは、クラッシュ後にトランザクションの回復を正常に行うために設計されたものです。サーバ ヘルス モニタ サービスを使用することで、トランザクション回復サービスを異常のあるサーバ インスタンスから正常なサーバ インスタンスに手動で移行できます。これにより、障害が発生したサーバのトランザクション処理をバックアップ サーバで完了できます。
また、移行先サーバとして元のサーバを選択すると、トランザクション回復サービスを手動で移行して元のサーバに戻すことができます。ただし、バックアップ サーバが実行中である場合は、トランザクション回復サービスを手動で移行して元のサーバに戻すことはできません。
| 注意 : | 以下の点に注意してください。 |
Administration Console を使用してトランザクション回復サービスを手動で移行する手順については、Administration Console オンライン ヘルプの「トランザクション回復サービスの手動移行」を参照してください。
シングルトン サービスの自動移行では、シングルトン サービスのヘルス モニタと移行を自動化できます。シングルトン サービスとは、クラスタ内の複数のサーバで同時に実行できないサービスです。移行可能サービスで障害が発生した場合や、何らかの理由 (サービス コードのバグ、サーバの障害、ネットワークの障害など) で使用不能になった場合、その移行可能サービスは現在のサーバで非アクティブ化され、新しいサーバでアクティブ化されます。これらのサービスを別のサーバに移行するプロセスは、シングルトン マスターによって処理されます。「シングルトン マスター」を参照してください。
WebLogic Server では、ユーザ定義のシングルトン サービスを自動的に移行できます。
| 注意 : | JTA トランザクション回復サービスも、クラスタ内の複数のノードで同時に実行できないシングルトン サービスですが、その自動移行をコンフィグレーションする方法はユーザ定義のシングルトン サービスとは異なります。JMS および JTA サービスも手動で移行できます。「サービスの移行フレームワークについて」を参照してください。 |
この節では、シングルトン サービスの自動移行を WebLogic Server に実装する方法の概略を示します。
シングルトン マスターは、自動移行可能な他のサービスをモニタする軽量シングルトン サービスです。その時点でシングルトン マスターをホストしているサーバは、各移行可能サービスに関連付けられた移行タスクを開始および停止する役割を担います。
| 注意 : | 移行可能サービスは、シングルトン マスターと同じサーバでホストする必要はありませんが、同じクラスタ内でホストする必要があります。 |
シングルトン マスターは、リースの競合によって維持される点や、同時に複数のサーバで実行できない点で、クラスタ マスターとよく似ています。クラスタ内の各サーバは、シングルトン マスターのリースの登録を継続的に試行します。現時点でシングルトン マスターをホストしているサーバに障害が発生すると、キュー内の次のサーバがそのリースを引き継ぎ、シングルトン マスターのホストを開始します。
クラスタ マスターの詳細については、「サーバ全体の移行におけるクラスタ マスターの役割」を参照してください。
| 注意 : | シングルトン マスターとクラスタ マスターは、それぞれ独立して機能するため、同じサーバでホストする必要はありません。 |
シングルトン マスターをホストするサーバには、実行されたすべての移行の記録 (対象名、移行元サーバ、移行先サーバ、タイムスタンプなど) が保持されます。
シングルトン サービスの移行がクラスタ内のすべての候補サーバで失敗すると、サービスは非アクティブ化されたままになります。シングルトン マスターがクラスタ内のサーバを再試行する回数をコンフィグレーションすることもできます。
| 注意 : | 候補サーバのリストを明示的に指定していない場合は、クラスタ内のすべてのメンバーが候補サーバと見なされます。 |
シングルトン サービスはアプリケーションの一部として、またはスタンドアロン サービスとして定義できます。シングルトン サービスは一度に 1 つのサーバ上でのみアクティブになるので、クラスタ内の 1 つのメンバーでのみ実行させるタスクに使用できます。
シングルトン サービスを作成するには、シングルトン サービスで実行するタスクに加えて、weblogic.cluster.singleton.SingletonService インタフェースを実装するクラスを作成する必要があります。
SingletonService インタフェースには、移行のプロセスで使用する以下のメソッドが含まれています。
SingletonService インタフェースを使用してシングルトン サービスを定義した方法に応じて、以下の手順を実行してシングルトン サービスをデプロイする必要があります。
アプリケーション内にパッケージ化されるシングルトン サービスでは、SingletonService インタフェースを実装するクラスを、デプロイメント用の EAR ファイル内の APP-INF/lib または APP-INF/classes ディレクトリに格納してください。
また、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 要素からの抜粋は、シングルトン サービスをどのように定義するかを示しています。
<SingletonService
Name="SingletonTestServiceName"
ClassName="mycompany.myprogram.subpackage.SingletonTestServiceImpl"
Cluster="mycluster-"
/>
シングルトン サービスは自動的に exactly-once サービスとしてコンフィグレーションされます。つまり、候補リスト内の少なくとも 1 つの管理対象サーバが実行されていれば、サービスはクラスタ内のどこかでアクティブになります。以下の方法を使用して、シングルトン サービスの移行に関する特定のパラメータを変更できます。
  
|