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