| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 11gリリース1 (10.3.6) B60992-06 |
|
 前 |
 次 |
この章では、WebLogic Serverでサポートされているサービス移行メカニズムについて説明します。
これらの項では、障害が発生したサービスの移行について重点的に説明します。WebLogic Serverでは、サーバーで障害が発生した場合に、サーバー全体を移行することも可能です。このサーバー全体の移行では、移行可能なサーバー・インスタンスとそのすべてのサービスを、物理的に別のマシンに移行します。障害時のサーバー移行の詳細は、第7章「サーバー全体の移行」を参照してください。
WebLogic Serverでは、アプリケーション・レベルでのレプリケーションやフェイルオーバーもサポートされています。詳細は、第6章「クラスタのフェイルオーバーとレプリケーション」を参照してください。
|
警告: Solarisゾーン機能を使用してSolaris 10システムでのサーバー全体の自動移行のサポートは、 |
WebLogic Serverクラスタでは、ほとんどのサブシステム・サービスがクラスタ内のすべてのサーバー・インスタンスで均一にホストされます。これにより、サーバー間の透過的なフェイルオーバーが可能になります。対照的に、JMS関連のサービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスなどの固定サービスは、クラスタ内の個別のサーバー・インスタンスでホストされます - これらのサービスについて、WebLogic Server移行フレームワークでは、フェイルオーバーとは対照的なサービス移行による障害リカバリがサポートされています。「移行可能サービス」を参照してください。
WebLogic Serverにおけるサービス・レベルの移行とは、あるサーバー・インスタンスに固定されているサービスを、クラスタ内の使用可能な別のサーバー・インスタンスに移動するプロセスです。サービス・レベルの移行は、論理的な移行可能ターゲットにより制御されます。移行可能ターゲットは、クラスタ内のいずれか1つの物理サーバーでホストされているサービスのグループとして機能します。特定の固定サービスをターゲット指定する場合には、サーバーやクラスタを選択する代わりに移行可能ターゲットを選択できます。元のサーバーで問題が発生した場合に、あるクラスタ化サーバーから別のクラスタ化サーバーに移行可能なターゲットを移行することにより、高可用性が実現します。また、定期的な保守を行うために移行可能ターゲットを手動で移行したり、自動移行が行われるように移行可能ターゲットを構成したりできます。「クラスタ内の移行可能ターゲットの理解」を参照してください。
移行フレームワークは、ターゲットを構成および移行するためのツールとインフラストラクチャを提供します。また、サービスの自動移行の場合は、WebLogic Serverのヘルス・モニタリング・サブシステムを使用して、移行可能ターゲットでホストされているサービスの状態をモニターします。「移行処理ツール」および「サービス自動移行インフラストラクチャ」を参照してください。サーバーおよびサービスの移行に関する用語の定義は、「移行関連の用語」を参照してください。
WebLogic Serverでは、JMS関連サービス、JTAトランザクション・リカバリ・サービス、およびユーザー定義のシングルトン・サービスのサービス・レベルの移行がサポートされています。これらのサービスは、クラスタ内のあるサーバーから別のサーバーに移すことができるため移行可能サービスと呼ばれます。自動移行または手動移行では、次の移行可能サービスを構成できます。
JMSサービスはシングルトン・サービスであるため、クラスタ内のすべてのサーバー・インスタンスでアクティブになるわけではありません。かわりに、それらはデータの一貫性を保持するために1つのクラスタ内の単一サーバーに固定されます。シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、シングルトン・サービスを移行可能ターゲット・リスト内の任意のサーバー・インスタンスに自動または手動で移行できるようにWebLogic Serverを構成できます。
JMSサーバー - ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。『Oracle WebLogic Server JMSの構成と管理』のJMSサーバーの構成に関する項を参照してください。
ストア・アンド・フォワード(SAF)サービス - メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワードの構成と管理』を参照してください。
パス・サービス - JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングを保持するために使用できる永続マップです。サーブレットをホストするクラスタのメンバー、分散キュー・メンバーまたはストア・アンド・フォワード・エージェントにメッセージを固定することによって順序付けを実現できます。パス・サービスは、クラスタごとに1つずつ構成します。『Oracle WebLogic Server JMSの構成と管理』のWebLogicパス・サービスの使用方法に関する項を参照してください。
カスタム永続ストア - ユーザーが定義するディスク・ベースのファイル・ストアまたは永続JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するためのJDBC対応データベースです。『Oracle WebLogic Serverサーバー環境の構成』のWebLogic永続ストアの使用方法に関する項を参照してください。
トランザクション・リカバリ・サービスは、システム起動時にトランザクションのリカバリを自動的に試行します。すべてのトランザクション・ログ・レコードを解析し、未完了のトランザクションを完了させます。詳細は、『Oracle WebLogic Server JTAのプログラミング』のサーバーに障害が発生した後のトランザクションのリカバリに関する項を参照してください。
アプリケーション内に、クラスタの複数のメンバーで同時に実行したくないタスクを実行するためのシングルトン・サービスを定義できます。「ユーザー定義のシングルトン・サービスの自動移行」を参照してください。
移行可能ターゲットを使用すると、JMSサービスやJTAサービスを構成して高可用性を得ることができます。移行可能ターゲットとは、クラスタ内のサーバーから別のサーバーに移行できる特別なターゲットです。つまり、移行可能ターゲットを使用することで、一緒に移行する必要のある移行可能サービスをグループ化できます。移行可能ターゲットを移行すると、そのターゲットによってホストされているすべてのサービスが移行されます。
移行可能なJMSサービスを移行できるように構成するためには、そのサービスを移行可能ターゲットにデプロイする必要があります。移行可能ターゲットでは、ターゲットをホストできるサーバーのセットを指定します。必要に応じて、そのサービスを優先的にホストするサーバーを指定したり、その優先サーバーで障害が発生した場合のバックアップ・サーバー候補を順序付けしたリストを指定したりできます。ただし、移行可能ターゲットを同時に複数のサーバーでホストすることはできません。
移行可能ターゲットを使用するように構成したサービスは、現時点でそれをホストしているサーバー・メンバーから独立した存在になります。たとえば、あるJMSサーバーにJMSキューがデプロイされているとします。このJMSキューは、移行可能ターゲットを使用するように構成することで、特定のサーバー・メンバーが使用できるかどうかに関係なく動作できるようになります。つまり、このキューは、その移行可能ターゲットがクラスタ内のいずれかのサーバーでホストされている限り常に使用できます。
管理者は、サーバー障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。クラスタ内に移行可能ターゲットを構成しない場合、移行可能サービスは、クラスタ内のどのWebLogic Serverインスタンスにでも移行できます。「JMS関連サービスの手動移行を構成する手順」を参照してください。
移行可能ターゲットでは、ヘルス・モニタリング・サブシステムを利用して、ホストしているサービスが異常なホスト・サーバーから正常なアクティブ・サーバーに手動で移行されるか(システムのデフォルト)、または自動で移行されるかを定義した移行ポリシーを提供しています。自動サービス移行ポリシーには、次の項で説明するように2つのタイプがあります。
移行可能ターゲットでmanualポリシー(システムのデフォルト)を使用している場合、管理者は、サーバーの障害へのレスポンスとして、あるいは定期的な保守の一環として、固定された移行可能サービスをクラスタ内のサーバー間で手動で移行できます。
「JMS関連サービスの手動移行を構成する手順」を参照してください。
このポリシーでは、候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバーで障害が発生するかサーバーが停止(正常停止または強制停止)されても、サービスはクラスタ内のどこかでアクティブになります。この値を使用すると、ターゲットのグループ化が生じることに注意してください。たとえば、Exactly-Onceの移行可能ターゲットが5つあるときに、クラスタ内の1つの管理対象サーバーのみを起動すると、5つのターゲットすべてがそのサーバー上でアクティブ化されます。
|
ヒント: ベスト・プラクティスとして、パス・サービスをホストする移行可能ターゲットは常に |
JMSサーバーでのサンプル・ユース・ケース:
ドメイン内に3つの管理対象サーバーから成るクラスタがあり、1つのJMSサーバーがクラスタ内の1つのメンバー・サーバーにデプロイされています。クラスタにデプロイされているアプリケーションはそのJMSサーバーにターゲット指定されているキューにメッセージを送信します。他のドメインのMDBは、JMSサーバーに関連付けられているキューを消費します。MDBは同一のキューの複数のインスタンスではなく、キューの一つのセットから消費します。つまり、この環境でクラスタリングを使用しているのは、アプリケーションのためにスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためで、JMSサーバーのためではありません。したがって、この環境では、JMSサーバーをExactly-Onceサービスとして使用可能なクラスタ・メンバーに自動移行するのが適しています。
「JMS関連サービスの自動移行を構成する手順」を参照してください。
このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者が手動でUPSを停止(正常停止または強制停止)した場合、failure-recoveryサービスは移行されません。ただし、UPSで内部エラーによる障害が発生した場合、failure-recoveryサービスは別の候補サーバーに移行されます。(手動停止または内部エラーにより)候補サーバーが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバーに移行されます。
JMSサーバーでのサンプル・ユース・ケース:
ドメイン内に3つの管理対象サーバーから成るクラスタがあります。各メンバー・サーバー上にJMSサーバーがあり、各JMSサーバー上には分散キュー・メンバーがあります。また、このクラスタには、ローカルのサーバー・メンバー上にある分散キュー・メンバーからメッセージを消費するMDBがターゲット指定されています。つまり、この環境では全体的なスケーラビリティ、ロード・バランシング、フェイルオーバーを実現するためにクラスタリングを使用しています。したがって、この環境では、JMSサーバーをfailure-recoveryサービスとしてUPSメンバーに自動移行するのが適しています。
|
警告: サーバー全体の自動移行フレームワークを使用するようにサーバーが構成されている場合、期限切れのリースが更新されない場合にサーバーが停止されます。そのとき、サーバー上で構成されている |
「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サービスで使用できるカスタム・ストア」を参照してください。
移行可能ターゲットを使用しない場合は、SAFエージェントをクラスタ全体にターゲット指定したり、クラスタ内のサーバー群のリストにターゲット指定したりできます。ただし、SAFエージェントおよびクラスタ内の各サーバーで、デフォルト永続ストアを使用しなければなりません。しかし、移行可能ターゲットにターゲット指定した場合は、SAFエージェントはその移行可能ターゲットにしかターゲット指定できません。また、JMSサーバーと同様、カスタム永続ストアを使用し、そのカスタム・ストアによって使用される同じ移行可能ターゲットにターゲット指定される必要があります。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の自動移行を有効化」チェック・ボックスを選択します。JTAのデフォルトの移行ポリシーは手動ですが、これを自動移行用に構成すると、JTAポリシーは内部的にfailure-recoveryに設定されます。これは、トランザクション・リカバリ・サービスが、ユーザー優先サーバー(UPS)の起動時にのみ開始されることを意味します。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。
一方、UPSが内部エラーによって停止した場合、このサービスは別の候補サーバーに移行されます。(手動停止または内部エラーにより)候補サーバーが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバーに移行されます。
WebLogic Serverの移行フレームワークでは、JMS関連サービスやJTAトランザクション・リカバリ・サービスの手動移行または自動移行を実行するためのインフラストラクチャと機能を提供しています。デフォルトでは、あるサーバー・インスタンスから別のサーバー・インスタンスにサービスを正常に移行するために、管理者はこのプロセスを手動で実行する必要があります。ただし、サーバーに障害が発生した場合に自動的に移行されるように、これらのサービスを簡単に構成することもできます。
管理者はWebLogic管理コンソールを使用して、移行プロセスを構成し実行できます。
詳細は、Oracle WebLogic Server管理コンソール・ヘルプにある次のトピックを参照してください。
サービス移行フレームワークは、次のコンポーネントを使用してサーバーのヘルス状態の問題をモニターし、必要に応じて固定サービスを正常なサーバーに自動的に移行します。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタ全体エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に1つしか存在しません。また、サーバーやクラスタの障害時には、リースをフェイルオーバーさせることができます。これにより、シングル・ポイント障害を回避できます。「リース」を参照してください。
自動移行オプションを使用する場合は、クラスタの「移行基盤」ポリシーを、次のように「データベース」または「コンセンサス」リースに設定する必要があります。
Oracle RACなどの高可用性データベースを使用してリース情報を管理する場合は、「高可用性データベース・リース」の手順に従って、サーバーの移行に使用するデータベースを構成します。
「移行基盤」を「データベース」リースに設定するには、有効なJDBCシステム・リソースに「自動移行に使用するデータ・ソース」オプションが設定されている必要があります。この設定は、管理対象サーバーでリースに使用する表が、そのリソース上に作成されていることを示します。JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCの構成と管理』のJDBCデータ・ソースの構成に関する項を参照してください。
「移行基盤」を「コンセンサス」リースに設定すると、メンバー・サーバーはリース情報をメモリー内に保持します。これにより、リースを使用するために高可用性データベースを用意する必要がなくなります。このリース方法では、ノード・マネージャを使用してクラスタ内のサーバーを管理する必要があります。また、移行可能な(または移行可能ターゲットをホストできる)すべてのサーバーにノード・マネージャを関連付ける必要もあります。ノード・マネージャが必要になるのは、関係するメンバー・サーバーのヘルス・モニター情報を取得するためです。「コンセンサス(非データベース)リース」を参照してください。
サービスの自動移行を使用する場合、ノード・マネージャは、次のように、メンバー・サーバーのヘルス・モニタリング情報を取得する必要があります。
コンセンサス・リース - クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。
データベース・リース - 移行前/移行後スクリプトが定義されている場合のみ、クラスタ内の管理対象サーバーをホストするすべてのマシンでノード・マネージャを実行する必要があります。移行前/移行後スクリプトを定義しない場合はノード・マネージャは必要ありません。
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。
サービス移行リクエストに対応するため、移行可能ターゲットでは、デプロイされているヘルス・モニタリング・インタフェースを実装する移行可能サービスの基本的なヘルス・モニタリングを実行します。移行可能ターゲットに状態モニターを実行させることの利点は、その実行がローカルに限定される点です。また、移行可能ターゲットはリース・システムと直接通信するためのチャネルを備えており、ヘルス状態の悪化が検出されたらリースを解放する(つまり移行をトリガーする)ことをリクエストできます。
JTAにおいて自動移行が有効になっている場合は、JTAサブシステムのヘルス状態が悪い(FAILED)ことが報告されると、デフォルトではサーバーが停止します。JTAのヘルス状態がFAILEDに変わるのは、たとえばTLOGへのアクセス時にIOエラーが発生した場合です。
プライマリ・サーバーで障害が発生すると、移行可能サービス・フレームワークがトランザクション・リカバリ・サービスを自動的にバックアップ・サーバーに移行します。サービス自動移行フレームワークでは、構成されている候補サーバーの中からバックアップ・サーバーが選択されます。トランザクション・リカバリ・アクションを完了する前にバックアップ・サーバーで障害が発生し、その後再起動された場合、トランザクション・リカバリ・サービスはクラスタ内の別のサーバーに移行されることになります(プライマリ・サーバーがその返還を要求するか、移行フレームワークがバックアップ・サーバーのリースの期限切れを通知します)。
移行が成功した後、バックアップ・サーバーが正常に停止して再起動されると、そのバックアップ・サーバー上でトランザクション・リカバリ・サービスが再度アクティブ化になります。この動作は、サービスの手動移行とまったく同じです。サービスの手動移行では、実行中のプライマリ・サーバーからトランザクション・リカバリ・サービスを移行することはできません。
JMS関連サービスの自動移行が有効になっている場合:
JMSサーバー - 実行時の自身のヘルス状態を保持して、ヘルス・モニタリング・サブシステムに登録および更新します。JMSサーバーが依存しているサービス(ターゲット指定された永続ストアなど)がFAILEDのヘルス状態を報告すると、移行フレームワークによって検出され、移行可能ターゲットで構成されている自動移行ポリシーに基づいて移行プロセスが発生します。通常、移行フレームワークは現在のユーザー優先サーバー上でJMSサーバーと移行可能ターゲットのその他のユーザーを非アクティブ化し、制約付き候補サーバー・リストにある正常で使用可能なサーバー上に移行します。
SAFサービス - 構成済のSAFエージェントからSAFサービスのヘルス状態が取得されます。SAFサービスが異常なヘルス状態を検出すると、SAFエージェント・インスタンス全体が異常であると報告されます。SAFエージェントにはJMSサーバーと同じモニター機能があります。通常、移行フレームワークは現在のユーザー優先サーバー上でSAFエージェントを非アクティブ化し、制約付き候補サーバー・リストにある正常で使用可能なサーバー上に移行します。
パス・サービス - パス・サービス自体は自身のヘルス状態を変更しませんが、そのかわりに、サーバーとそのカスタム・ストアに依存して移行をトリガーします。
永続ストア - 自身のヘルス状態をヘルス・モニタリング・サブシステムに登録します。永続ストアが読み書きを続行できず、再起動しないとデータの一貫性が保証されない場合に、I/Oレイヤーによってエラーが報告されると、ストアの状態は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ディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。
アプリケーションでJDBCベースの永続性(JDBCストア)を使用する場合は、すべての候補サーバーからそのデータベース・インスタンスのJDBC接続情報(データ・ソース、接続プールなど)を使用できるようにする必要があります。
MW_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリ(mydomainはドメイン固有のディレクトリでドメインと同じ名前)に格納されている移行前/移行後スクリプトを使用して、バックアップ・サーバー・ターゲットに移行済み。
|
注意: 移行前/移行後スクリプトを作成する基本的な手順については、このディレクトリ内の |
状況によっては、スクリプトで移行元のサーバーからディスクをアンマウントし、バックアップ・サーバーにマウントする必要があります。これらのスクリプトは、Oracle WebLogic Server MBeanリファレンスのMigratableTargetMBeanのPreScript()およびPostScript()メソッド、または管理コンソールを使用してノード・マネージャに構成されます。それ以外にも、スクリプトでカスタム・ファイル・ストア・ディレクトリをバックアップ・サーバーに(コピーではなく)移動しなければならない場合もあります。移行元に構成されていたファイル・ストア・ディレクトリは、移行可能ターゲットが次回その移行元サーバーによってホストされるときに残っていてはなりません。したがって、そのファイルを削除するか、別のディレクトリに移動する必要があります。
クラスタ内の障害が発生したサーバーから同じクラスタ内の別のサーバー(バックアップ・サーバー)にJTAトランザクション・リカバリ・サービスを移行するには、障害が発生したサーバーのトランザクション・ログ(TLOG)レコードにバックアップ・サーバーからアクセスできる必要があります。トランザクション・ログ・レコードは、サーバーのデフォルト永続ストアに格納されています。
障害が発生した場合にサービスを移行する予定がある場合は、障害が発生した移行可能サーバーからの移行先となり得るすべてのマシンからアクセスできる共有ストレージ・システムにレコードが格納されるよう、デフォルト永続ストアを構成する必要があります。高い信頼性を実現したい場合は、ストレージ・エリア・ネットワーク(SAN)やデュアル・ポート・ディスクなど、高可用性の備わっている共有ストレージ・ソリューションを使用してください。なお、同じデフォルト・ストアを共有できるのは、JTAを始めとする移行可能でないサービスのみです。
必要に応じて、移行前/移行後スクリプトを使用して、共有ストレージのアンマウントとマウントを実行できます。移行前/移行後スクリプトを作成する基本的な手順は、MW_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリ内のreadme.txtを参照してください。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。
自動移行の場合は、現在の(移行元の)サーバーで障害が発生すると、移行フレームワークがトランザクション・リカバリ・サービスをターゲット・バックアップ・サーバーに自動的に移行します。
手動移行の場合は、トランザクション・リカバリ・サービスを実行中のサーバーからバックアップ・サーバーに移行することはできません。トランザクション・リカバリ・サービスを移行する前に、サーバーを停止する必要があります。
表8-1に、実行状態に基づく移行のサポートを示します。
WebLogic JMSでは、管理者がJMSサーバーやSAFエージェントなどのJMS関連サービスの移行可能ターゲットを指定できるように、移行フレームワークを有効に活用できます。WebLogic管理者は、WebLogic Serverのヘルス・モニタリング機能に基づいて、障害が発生したサーバーから自動的に移行されるように移行可能サービスを構成することもできます。
|
注意: JMSサービスはJTAトランザクション・リカバリ・サービスとは関係なく移行できます。ただし、JTAトランザクション・リカバリ・サービスは他のサブシステム・サービスのトランザクション制御を提供するため、通常は他のサブシステム・サービスと共に移行されます。これによって、サブシステム・サービスの移行前後でトランザクションの整合性が維持されます。 |
クラスタ内の移行可能ターゲットでJMSサービスの自動移行を構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。特定の状況では、ノード・マネージャも実行中でなければなりません。また、サーバーの自動移行を許可するように構成されている必要があります。
これらのタスクを管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・ヘルプにある次のトピックを参照してください。
|
注意: 移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。一意の値が設定されていない場合、移行は失敗します。 |
|
注意: サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバーを制御し、すべての移行可能サーバーにノード・マネージャを関連付ける必要があります。データベース・リースを使用する場合は、移行前/移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前/移行後スクリプトを定義しない場合はノード・マネージャは必要ありません。 |
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。
「クラスタ」>「構成」>「移行」ページで、構成されているデータ永続性環境に応じて、データベース・リースまたはコンセンサス・リースを使用して、クラスタの「移行基盤」を構成します。「移行可能サービスのリース」を参照してください。
この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。
管理コンソールの「移行可能ターゲット」表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバーごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、自動移行用にターゲット指定および構成する必要があります。
新しい移行可能ターゲットを作成する際は、管理コンソールを使用して移行ポリシーを作成、ターゲット指定、および選択します。
管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバーを選択してターゲットを関連付けることができます。ユーザー優先サーバーとは、移行可能ターゲットをホストするサーバーとして最優先されるサーバーです。
|
注意: 自動的に移行されたサービスは指定されたユーザー優先サーバーにホストされない可能性もあります。移行されたサービスをホストしているサーバーを確認するには、管理コンソールを使用して、「移行可能ターゲット: 制御コンソール」ページの「現在のホスト・サーバー」の情報を参照してください。詳細は、Oracle WebLogic Server管理コンソール・ヘルプの「移行可能ターゲット: 制御」を参照してください。 |
移行可能ターゲットのデフォルトの移行ポリシーは「サービスの手動での移行のみ」であるため、次のいずれかの自動移行ポリシーを選択する必要があります。
Exactly-Onceのサービス自動移行 - 候補リスト内の1つ以上の管理対象サーバーが実行中である場合、サーバーで障害が発生するかサーバーが停止(正常停止または強制停止)しても、サービスはクラスタ内のどこかでアクティブになります。
|
注意: この値を使用するとターゲットのグループ化が生じる可能性があります。たとえば、 |
障害リカバリ・サービスの自動移行 - このポリシーでは、ユーザー優先サーバー(UPS)が起動されている場合にのみサービスが開始されます。管理者がUPSを正常停止または強制停止した場合、このサービスは移行されません。ただしUPSで内部エラーによる障害が発生した場合、サービスは別の候補サーバーに移行されます。(手動停止または内部エラーにより)候補サーバーが使用できない場合、移行フレームワークはまず、UPSサーバー上でサービスを再アクティブ化しようとします。UPSサーバーがその時点で使用できない場合、サービスは別の候補サーバーに移行されます。
「手動および自動のサービス移行ポリシー」を参照してください。
Exactly-Onceサービス移行ポリシーを使用する移行可能ターゲットを作成する場合は、JMSサーバーの移行先になる可能性のあるメンバー・サーバーを制限することもできます。推奨されるベスト・プラクティスは、各移行可能ターゲットの候補サーバー・セットを1番目、2番目または3番目のサーバーまでに制限することです。各サーバーが起動しているとき、移行可能ターゲットでは最初にオンラインになったサーバーが割り当てられるのではなく、その候補サーバーに制限されます。管理者はサービスを手動でアイドル状態のサーバーに移行できます。
一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバーをクラスタ全体にする必要があり、これがデフォルトの設定です。
移行可能ターゲットの「構成」>「移行」ページにある制約付き候補サーバーの「使用可能」ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。これらは、「選択済み」ボックスに移動すると有効な候補サーバーになります。
移行可能ターゲットを作成したら、必要に応じて共有カスタム・ファイル・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前/移行後スクリプトは、MW_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。利便性のために、このディレクトリには移行前/移行後スクリプトのサンプルが用意されています。
移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行する「インプレースでの再起動」オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください。
「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サービスは自動的には戻されないため手動で移行する必要があります。
管理コンソールを使用してJMS関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。
WLSTを使用してJMS関連サービスを手動で移行する手順は、『WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。
サーバーのデフォルトの移行可能ターゲットを利用すればほぼ問題ありません(サーバーごとに1つのデフォルトの移行可能ターゲットが存在する)。または、各サーバーに1つの移行可能ターゲットを構成することもできます。「ステップ3: 移行可能ターゲットを構成する」を参照してください。
移行可能ターゲットごとに1つのカスタム・ストアを構成し、そのカスタム・ストアを移行可能ターゲットにターゲット指定します。「ステップ4: カスタム・ストアを構成およびターゲット指定する」を参照してください。
各移行可能ターゲットにJMSサービス(JMSサーバーとSAFエージェント)を構成する際は、そのサービスが対応するカスタム・ストアを参照していることを確認します。その後、それらのサービスを各移行可能ターゲットにターゲット指定します。「ステップ5: JMSサービスをターゲット指定する」を参照してください。
デプロイメント・モジュールではなく、JMSシステム・モジュールを使用します。管理コンソールでは、システム・モジュールのみ構成できます。『Oracle WebLogic Server JMSの構成と管理』のJMSシステム・モジュールの構成に関する項を参照してください。
予想されるターゲット・セットごとにシステム・モジュールを1つ作成し、そのモジュールを1つのクラスタにターゲット指定します。たとえば、1つの宛先が1つのJMSサーバーにまたがり、別の宛先が6つのJMSサーバーにまたがるようにするには、2つのモジュールを作成し、それらを同じクラスタにターゲット指定します。
モジュールごとにサブデプロイメントを1つ構成し、そのサブデプロイメントに同種のJMSサーバーまたはJMS SAFエージェントのターゲット・セットを設定します。サブデプロイメントにはWebLogic Serverやクラスタの名前を含めないでください。
1つのクラスタで複数のアプリケーションが実行されている場合は、接続ファクトリをクラスタにターゲット指定し(デフォルトのターゲット指定を行い、モジュール・ターゲットを継承することができる)、クラスタから離れた場所でアプリケーションが実行されている場合には、そのアプリケーションで利用するため「高度なターゲット指定」で接続ファクトリをサブデプロイメントにターゲット指定します。
宛先など、他のJMSモジュール・リソースについては、サブデプロイメントを使用してターゲット指定します。デフォルトのターゲット指定は利用しないでください。サブデプロイメントのターゲット指定は、コンソールの「高度なターゲット指定」から実行できます。
JMSサーバーやSAFエージェントを追加/削除したら、モジュールのサブデプロイメントにも忘れずに追加/削除します。
移行できなくなるため、SAFエージェントはクラスタにターゲット指定しません。複数の独立したSAFエージェントを構成し、各SAFエージェントを移行可能ターゲットにターゲット指定します(サーバーごとに1つのデフォルトの移行可能ターゲットが存在します)。同様に、SAFエージェントごとに1つのカスタム・ストアを構成し、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関連サービスをクラスタ内の移行可能ターゲットに手動で移行できるように構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。
これらのタスクを管理コンソールで実行する手順は、Oracle WebLogic Server管理コンソール・ヘルプにある次のトピックを参照してください。
|
注意: 移行するJMSサーバーをホストすることになる管理対象サーバーのインスタンスには、一意のリスニング・アドレス値を設定する必要があります。一意の値が設定されていない場合、移行は失敗します。 |
この手順は、JMS関連サービスをターゲット指定したり、JTAトランザクション・リカバリ・サービスの移行を有効にしたりする前に実行する必要があります。
管理コンソールの「移行可能ターゲット」表には、サーバー名を持つ、システム生成による移行可能ターゲットが表示されます(移行可能)。これらの移行可能ターゲットは、クラスタ内の実行中のサーバーごとに自動的に生成されるものです。ただし、汎用的なテンプレートしか含まれていないため、移行用にターゲット指定および構成する必要があります。
新しい移行可能ターゲットを作成する際は、管理コンソールを使用して移行ポリシーを作成、ターゲット指定、および選択します。
管理コンソールを使用して新しい移行可能ターゲットを作成する場合は、最初にクラスタ内の優先サーバーを選択してターゲットを関連付けることができます。優先サーバーとは、移行可能ターゲットをホストするサーバーとして最優先されるサーバーです。
移行可能ターゲットを作成する際は、JMS関連サービスの移行先となり得るサーバーを、そのJMS関連サービスと同じ移行可能ターゲットにターゲット指定されたカスタム永続ストアにアクセスできるサーバーに限定したい場合もあります。
一方、クラスタのパス・サービスの場合は、移行可能ターゲットの候補サーバーをクラスタ全体にする必要があり、これがデフォルトの設定です。
移行可能ターゲットの「構成」>「移行」ページにある制約付き候補サーバーの「使用可能」ボックスには、移行可能ターゲットをサポートできるすべての管理対象サーバーの一覧が表示されます。これらは、「選択済み」ボックスに移動すると有効な候補サーバーになります。
移行可能ターゲットを作成したら、必要に応じて共有カスタム・ストアのアンマウントやマウントを実行する移行前/移行後スクリプトを指定することもできます。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前/移行後スクリプトは、MW_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。移行前/移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txtを参照してください。
移行可能ターゲットでは、サービスを移行する代わりに、障害が発生したサービスの非アクティブ化と再アクティブ化を試行する「インプレースでの再起動」オプションが提供されています。「障害が発生した移行可能サービスのインプレースでの再起動」を参照してください。
「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関連サービスを手動で移行する手順は、Oracle WebLogic Server管理コンソール・ヘルプのJMS関連サービスの手動移行に関する項を参照してください。
WLSTを使用してJMS関連サービスを手動で移行する手順は、『WebLogic Scripting Toolコマンド・リファレンス』を参照してください。
|
注意: 移行元のプライマリ・サーバーが復旧したら、JMSサービスをもう一度移行して元のサーバーに戻したい場合もあります。自動的にプライマリ・サーバーに移行されるJTAトランザクション・リカバリ・サービスとは異なり、JMSサービスは自動的には戻されないため手動で移行する必要があります。 |
JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに自動的に移行できます。これにより、障害が発生したサーバーのトランザクション処理をバックアップ・サーバーで完了できます。
トランザクション・リカバリ・サービスがクラスタ内の移行可能ターゲットに自動移行されるように構成するには、次のタスクを実行します。
管理対象サーバーをマシンに割り当てるなど、クラスタ内の管理対象サーバーを移行用に構成します。ノード・マネージャも実行中で、サーバーの自動移行ができるように構成されている必要があります。ノード・マネージャはサーバーに関するヘルス・ステータスの情報を取得する必要があります。
これらのタスクを管理コンソールで実行する詳しい手順については、管理コンソールオンライン・ヘルプの次のトピックを参照してください。
|
注意: プライマリ・サーバーとリカバリ・モードの別のバックアップ・サーバーが同時にTLOGにアクセスすることを防止するため、プライマリ・サーバーが管理対象サーバー独立モード(MSI)で起動しないように構成する方法は、『Oracle WebLogic Server JTAのプログラミング』の管理対象サーバーの独立性に関する項を参照してください。 |
|
注意: サービスの自動移行でコンセンサス・リースを使用する場合は、ノード・マネージャを使用してクラスタ内のサーバーを制御し、すべての移行可能サーバーにノード・マネージャを関連付ける必要があります。データベース・リースを使用する場合は、移行前/移行後スクリプトを定義する場合にのみノード・マネージャが必要です。移行前/移行後スクリプトを定義しない場合はノード・マネージャは必要ありません。 |
ノード・マネージャの構成の詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャの概要に関する項を参照してください。
「クラスタ」>「構成」>「移行」ページで、構成されているデータ永続性環境に応じて、データベース・リースまたはコンセンサス・リースを使用して、クラスタの「移行基盤」を構成します。「移行可能サービスのリース」を参照してください。
「サーバー」>「構成」>「移行」ページの「JTA移行の構成」セクションで、次のオプションを構成します。
トランザクション・リカバリ・サービスの移行先となり得るサーバーを、現在のサーバーのデフォルトWebLogicストアに格納されているトランザクション・ログ・ファイルにアクセスできるサーバーのみに制限することもできます。候補サーバーを選択しない場合は、クラスタ内のいずれかのサーバーが候補サーバーとして選択されます。
候補サーバーの「使用可能」ボックスから、JTAログ・ファイルにアクセスできる管理対象サーバーを選択します。これらは、「選択済み」ボックスに移動すると有効な候補サーバーになります。
|
注意: 必要に応じてトランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻せるように、「選択済み」リストに移行元のサーバーを含めておく必要があります。管理コンソールでは、この規則に従わなくてはなりません。 |
共有ストレージのアンマウントおよびマウントを実行する移行前/移行後スクリプトを使用するかどうかを指定します。
移行前スクリプトのパス - 移行可能ターゲットを実際にアクティブ化する前に実行する移行前スクリプトへのパスを指定します。
移行後スクリプトのパス - 移行可能ターゲットを完全に非アクティブ化にした後に実行する移行後スクリプトへのパスを指定します。
移行後スクリプトが失敗した場合に自動移行を取り消す - 移行後スクリプトの実行中に発生したエラーを、移行に対して致命的と判断するかどうかを指定します。
移行後スクリプトを別のマシンで実行できるようにする - 移行後スクリプトの実行を、別のマシンでも許可するかどうかを指定します。
移行前/移行後スクリプトは、MW_HOME/user_projects/domains/mydomain/bin/service_migrationディレクトリに配置する必要があります。mydomainはドメインに固有のディレクトリで、ドメインと同じ名前です。移行前/移行後スクリプトを作成する基本的な手順は、このディレクトリ内のreadme.txtを参照してください。
「JTAで使用できるデフォルト・ファイル・ストア」で説明したように、トランザクション・マネージャはデフォルト永続ストアを使用してトランザクション・ログ・ファイルを格納します。トランザクション・リカバリ・サービスの移行を有効化するには、移行元のサーバーで障害が発生した場合に、クラスタ内の別のサーバーから使用できる永続ストレージ・ソリューションにデータ・ファイルが格納されるよう、デフォルト永続ストアを構成する必要があります。
JTAトランザクション・リカバリ・サービスを自動移行用に構成したら、管理サーバーを再起動する必要があります。
また、移行ポリシーを変更した管理対象サーバーも再起動する必要があります。
バックアップ・サーバーは、障害が発生したサーバーのトランザクションのリカバリが完了すると、トランザクションリカバリ・サービスの所有権を解放します。そのため、元のサーバーは再起動時にその所有権の返還をリクエストできます。トランザクションのリカバリが完了する前にバックアップ・サーバーが停止(クラッシュ)した場合は、そのリースが期限切れになります。これにより、プライマリ・サーバーが起動時に所有権の返還をリクエストすることが可能になります。
トランザクション・リカバリ・サービスのプライマリ・サーバーへの自動フェイルバックには、次の2つのシナリオがあります。
リカバリが完了した後に自動フェイルバック:
プライマリ・サーバーが再起動する前にバックアップ・サーバーがTLOGトランザクションのリカバリを完了した場合は、トランザクション・リカバリ・サービスのプライマリ・サーバーへの移行が暗黙的に開始されます。
移行後スクリプトは、手動移行か自動移行かに関係なく自動的に実行されます。
リカバリが完了する前に自動フェイルバック:
プライマリ・サーバーが起動したときにTLOGトランザクションのリカバリが進行中だった場合は、プライマリ・サーバーの起動時にトランザクション・リカバリ・サービスを開始する間に、バックアップ・サーバーからのトランザクション・リカバリ・サービスの暗黙的な移行が開始されます。
JTAトランザクション・リカバリ・サービスは、クラッシュ後にトランザクションのリカバリを正常に行うために設計されたものです。サーバー・ヘルス・モニタリング・サービスを使用することで、トランザクション・リカバリ・サービスを異常のあるサーバー・インスタンスから正常なサーバー・インスタンスに手動で移行できます。これにより、障害が発生したサーバーのトランザクション処理をバックアップ・サーバーで完了できます。
また、移行先サーバーとして元のサーバーを選択すると、トランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻すことができます。ただし、バックアップ・サーバーが実行中である場合は、トランザクション・リカバリ・サービスを手動で移行して元のサーバーに戻すことはできません。
次に注意してください:
トランザクション・リカバリ・アクションが完了する前にバックアップ・サーバーで障害が発生した場合は、プライマリ・サーバーがトランザクション・リカバリ・サービスの所有権の返還をリクエストできないため、リカバリはサーバーの再起動時に再試行されません。したがって、この場合はトランザクション・リカバリ・サービスを別のバックアップ・サーバーに手動で移行しなおす必要があります。
バックアップ・サーバーによるトランザクションのリカバリ中に元のサーバーを再起動した場合は、バックアップ・サーバーが正常にトランザクション・リカバリ・サービスの所有権を解放します。バックアップ・サーバーを停止する必要はありません。詳細は、『Oracle WebLogic Server JTAのプログラミング』のクラスタ化サーバーで障害が発生した場合のトランザクションのリカバリに関する項を参照してください。
プライマリ・サーバーとリカバリ・モードの別のバックアップ・サーバーが同時にTLOGにアクセスすることを防止するため、プライマリ・サーバーが管理対象サーバー独立モード(MSI)で起動しないように構成する方法は、『Oracle WebLogic Server JTAのプログラミング』の管理対象サーバーの独立性に関する項を参照してください。
管理コンソールを使用してトランザクション・リカバリ・サービスを手動で移行する手順は、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内にスタンドアロン・サービスとしてデプロイします。
また、シングルトン・サービスの移行動作を構成できます。
次の項では、これらの詳細手順の概要を示します。
アプリケーション内にパッケージ化されるシングルトン・サービスでは、SingletonServiceインタフェースを実装するクラスが、デプロイメント用のJARファイル内のAPP-INF/libまたはAPP-INF/classesディレクトリまたはEAR-level内のlibディレクトリに格納される必要があります。
スタンドアロン・シングルトン・サービスのクラスは、WebLogic Serverシステムのクラスパスで使用できるようにする必要があります。
また、weblogic-application.xml記述子ファイルに次のエントリを追加します。
<weblogic-application>
...
<singleton-service>
<class-name>mypackage.MySingletonServiceImpl</class-name>
<name>Appscoped_Singleton_Service</name>
</singleton-service>
...
</weblogic-application>
|
注意:
|
アプリケーション・スコープのシングルトン・サービスのデプロイメントは、アプリケーション・デプロイメントの一環として自動的に行われます。アプリケーションがデプロイされるクラスタ・メンバーがシングルトン・サービスの候補サーバーとなります。
SingletonServiceインタフェースを使用するシングルトン・サービス・クラスを作成したら、そのクラスをWebLogic Server内でシングルトン・サービスとして定義する必要があります。このシングルトン・サービス・オブジェクトには次の情報が格納されます。
シングルトン・サービスとしてロードするクラスのパス
シングルトン・サービスの優先サーバーとその他の候補サーバー
次に示すconfig.xmlのクラスタ要素からの抜粋は、シングルトン・サービスをどのように定義するかを示しています。
<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) - MigratableTarget Management Beanを使用してサービスの自動移行を構成できます。『WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドおよび変数リファレンスに関する項を参照してください。
