|
|
以下の節では、WebLogic Server でサポートされているさまざまな移行メカニズムについて説明します。
これらの節では、障害が発生したサーバ インスタンスやサービスの移行について重点的に説明します。WebLogic Server では、アプリケーションレベルでのレプリケーションやフェイルオーバもサポートされています。詳細については、「クラスタのフェイルオーバとレプリケーション」を参照してください。
| 注意 : | サーバの移行は、どのプラットフォームでもサポートされていません。詳細については、『WebLogic Platform 9.2 でサポート対象のコンフィグレーション』の「サーバの移行のサポート」を参照してください。 |
WebLogic Server クラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバ インスタンスに均一にデプロイされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS や JTA トランザクション回復システムなどの「固定サービス」はクラスタ内の個々のサーバ インスタンスを対象にします。こうしたサービスのために、WebLogic Server では、フェイルオーバではなく移行を使用する障害からの回復がサポートされています。
WebLogic Server での「移行」とは、クラスタ化された WebLogic Server インスタンスやクラスタ化されたインスタンスで実行されているコンポーネントを、障害が発生したときに別の場所に移動するプロセスです。サーバの移行の場合は、障害が発生すると、サーバ インスタンスが物理的に別のマシンに移行されます。サービスレベルの移行の場合は、サービスをクラスタ内の別のサーバ インスタンスに移動します。
WebLogic Server には、JMS や JTA トランザクション システムの可用性を高めるための機能 (「移行可能なサーバ」) が用意されています。移行可能なサーバは、サービスレベルではなく、サーバレベルで自動または手動で移行できます。
| 注意 : | サーバレベルの移行は、サービスレベルの移行に取って代わるものです。サービスレベルの移行とサーバレベルの移行は、組み合わせて使用することを目的としたものではありません。クラスタ内で個々のサービスを移行する場合は、サーバ インスタンス全体を移行しないようにしてください。 |
| 注意 : | サーバの移行は、SSH バージョンのノード マネージャを使用する場合にのみサポートされます。サーバの移行は Windows ではサポートされていません。 |
移行可能なサーバが何らかの理由 (ハング、ネットワーク接続の消失、ホスト マシンの障害など) で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバ インスタンスの移行を開始することもできます。
ノード マネージャの基本的な情報と、ノード マネージャが WebLogic Server 環境に組み込まれる仕組みについては、『サーバの起動と停止の管理』の「ノード マネージャを使用したサーバの制御」を参照してください。
リースは、クラスタの複数のメンバーで同時に実行することができないサービスを管理するために使用するプロセスです。リースによって、クラスタワイド エンティティの排他的な所有権を確保できます。リースのオーナーは、クラスタ内に 1 つしか存在しません。また、サーバやクラスタの障害時には、リースをフェイルオーバさせることができます。これにより、シングル ポイント障害を回避できます。
リースは、以下の WebLogic サーバ機能で使用します。
リースを使用することで、クラスタ マスターが常に実行されており、しかもクラスタ内のいずれか 1 つのサーバでのみ実行されていることが保証されます。クラスタ マスターの詳細については、「サーバの移行におけるクラスタ マスターの役割」を参照してください。
| 注意 : | ジョブ スケジューラには非データベース リースを使用できますが、その場合はフェイルオーバやレプリケーションの情報を保持するための外部データベースが必要になります。 |
| 注意 : | 基本的なコンフィグレーションだけでなく、リース機能のほとんどは WebLogic Server 内部で処理されます。 |
WebLogic Server では、2 種類のリース機能を実装できます。どちらを使用するかは、そのときどきの要件や環境によって決まります。
| 注意 : | 1 つの WebLogic Server インストールでは、1 種類のリースしか使用できません。1 つの環境において、リースを使用する複数の機能を実装することは可能ですが、各機能には同じ種類のリースを使用する必要があります。 |
このタイプのリースでは、リース情報を可用性の高いテーブル内に保持します。リース情報を常に利用できるようにするため、可用性の高いデータベースが必要になります。リース情報にアクセスするため、クラスタの各メンバーからデータベースに接続できなければなりません。
このリース方法は、クラスタ化された環境にすでに高可用性データベースが存在する場合に便利です。この方法を使用すると、ノード マネージャを使用して環境内のサーバを管理していなくてもリース機能を利用できます。
| 注意 : | クラスタ内でジョブ スケジューラをコンフィグレーションしている場合、データベースがリース用にコンフィグレーションされていないと、ジョブ スケジューラは機能しません。 |
以下では、リース用のデータベースをコンフィグレーションするために必要な手順の概略を示します。
データベースは信頼性のあるものでなければなりません。サーバ インスタンスの信頼性は、このデータベースの信頼性で決まります。実験的な目的で使用する場合は、通常のデータベースで十分です。プロダクション環境で使用する場合は、高可用性データベースしかお勧めできません。データベースが停止すると、すべての移行可能なサーバが停止します。
データベース内にリース テーブルを作成します。このテーブルは、サーバの移行を可能にするためのマシンとサーバの関連付けの格納に使用されます。このテーブルのスキーマは、次の場所にあります。
<WEBLOGIC_HOME>/server/db/<dbname>/leasing.ddl
| 注意 : | リース テーブルは高可用性データベースに格納する必要があります。移行可能なサーバの信頼性は、リース テーブルの格納に使用されるデータベースの信頼性で決まります。 |
| 注意 : | サーバの移行では、XA データ ソースはサポートされていません。 |
JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
非データベース リースでは、リース情報がメモリ内に保持されます。そのため、リースを必要とする機能を使用するだけのために、高可用性データベースを用意する必要はありません。
クラスタのいずれか 1 つのメンバーをクラスタ リーダーとし、このメンバーにリース情報を保持する役割を付与します。クラスタ リーダーは、起動後の経過時間の長さに基づいて選択されます。クラスタ内の管理対象サーバのうち、起動後の経過時間が最も長いものがクラスタ リーダーとなります。その他のクラスタ メンバーは、クラスタ リーダーと通信してリース情報を識別します。フェイルオーバを可能にするため、リース テーブルはクラスタの他のノードにレプリケートされます。
| 注意 : | このリース方法では、ノード マネージャを使用してクラスタ内のサーバを管理する必要があります。ノード マネージャは、クラスタ内の管理対象サーバをホストするすべてのマシンで実行する必要があります。詳細については、「ノード マネージャを使用したサーバの制御」を参照してください。 |
| 注意 : | サーバの移行は、どのプラットフォームでもサポートされていません。詳細については、『WebLogic Platform 9.2 でサポート対象のコンフィグレーション』の「サーバの移行のサポート」を参照してください。 |
この節では、サーバの移行をコンフィグレーションする手順の概略を示し、WebLogic Server 環境内でサーバ移行機能をどのように使用するかについて説明します。
サーバの移行をコンフィグレーションする前に、以下の要件について確認します。
ifconfig に対して同じ機能がサポートされている必要がある。wlscontrol.sh のローカル バージョンをコンフィグレーションします。
wlsconstol.sh の詳細については、「ノード マネージャを使用したサーバの制御」を参照してください。
domain_dir/bin の内容が各マシンにコピーされていることを確認する必要があります。
サーバの移行をコンフィグレーションする前に、お使いの環境が「サーバの自動移行の準備」で説明されている要件を満たしていることを確認してください。
クラスタ内の管理対象サーバに対してサーバの移行をコンフィグレーションするには、以下のタスクを行います。
移行可能なサーバには、それぞれ浮動 IP アドレスを割り当てる必要があります。この IP アドレスは、物理的なマシンが変わってもサーバを追跡します。浮動 IP アドレスが割り当てられるすべてのサーバで、AutoMigrationEnabled を true に設定する必要もあります。
| 注意 : | 移行可能な IP アドレスは、移行可能なサーバが起動されるまではどの候補マシンのインタフェースでも提示されないようにします。 |
| 注意 : | サーバの移行は、SSH バージョンのノード マネージャを使用する場合にのみサポートされます。 |
サーバの移行でのノード マネージャの使用に関する全般的な情報については、「サーバの移行におけるノード マネージャの役割」を参照してください。ノード マネージャのコンフィグレーションに関する全般的な情報については、「ノード マネージャを使用したサーバの制御」を参照してください。
リースの全般的な情報については、「リース」を参照してください。
各クラスタのコンフィグレーションで、DataSourceForAutomaticMigration をこのデータ ソースに設定してください。
| 注意 : | サーバの移行では、XA データ ソースはサポートされていません。 |
JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
ifconfig が適切なパーミッションを持つように wlsifconfig.sh スクリプトがコンフィグレーションされていることを確認してください。
このスクリプトは、移行時にマシン間での IP アドレスの転送に使用され、ifconfig を実行可能である必要があります。sudo を使用してこのスクリプトを呼び出している場合、スクリプトを手動で編集する必要はありません。
このスクリプトは、$BEA_HOME/weblogic92/common/bin ディレクトリにあります。
wlsifconfig.sh、wlscontrol.sh、および nodemanager.domains が、使用するマシンの PATH に含まれていることを確認してください。.sh ファイルは $BEA_HOME/weblogic92/common/bin にあり、nodemanager.domains は $BEA_HOME/weblogic92/common/nodemanager にあります。
これらのスクリプトの最初の行は、使用するデフォルトのシェルに応じて編集する必要があります。
ssh/rsh machine_A」を使用して (同様にマシン A から「ssh/rsh machine_B」を使用して) シェル プロンプトにアクセスできる必要があります。また、各マシンは SSH を使用して同じ方法で自身に接続できなければなりません。| 注意 : | シェルが対話型である場合は、ログイン スクリプト (.cshrc、.profile、.login など) がシェル プロファイルからのメッセージのみをエコーすることを確認してください。WebLogic Server は、ssh コマンドを使用してログインし、server.state ファイルの内容をエコーします。この出力の最初の行だけがサーバの状態の判別に使用されます。 |
wlscontrol.sh を編集し、Interface 変数に、使用しているネットワーク インタフェースの名前を設定します。
サーバの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられたステート情報は移行されません。
高可用性を確保するには、こうした情報を移行後にサーバ インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能なサーバによって保持されるステート情報 (トランザクション ログに格納されるデータなど) は、移行可能なサーバで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ システムに格納する必要があります。高い信頼性を実現するために、ストレージ エリア ネットワーク (SAN) などの、高可用性の備わっている共有ストレージ ソリューションを使用してください。
さらに、データベースを使用してリース情報を格納する場合は、移行可能なサーバの状態とそれらが使用可能かどうかの追跡に使用されるリース テーブル (以下の節を参照) も高可用性データベースに格納する必要があります。詳細については、「リース」を参照してください。
以下の節では、移行可能なサーバを含むクラスタにおける主要なプロセスについて説明します。
図 7-1 に、移行可能なサーバを含むクラスタの起動時に発生するプロセスと通信を示します。
例のクラスタには 2 つの管理対象サーバが含まれており、それらは両方とも移行可能です。管理サーバと 2 つの管理対象サーバは、それぞれ別々のマシンで実行されています。4 つ目のマシンは、いずれかの移行可能なサーバで障害が発生した場合にバックアップとして使用できます。バックアップ マシンと移行可能なサーバが実行されている各マシンでは、ノード マネージャが実行されています。
以下は、図 7-1 に示されている、クラスタの起動時に発生する主要な手順です。
図 7-2 に、管理対象サーバ 2 をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。
| 注意 : | サーバのハングが原因で管理対象サーバ 2 のリースが期限切れになっていて、マシン C にはアクセスできる場合、クラスタ マスターはノード マネージャを使用してマシン C 上の管理対象サーバ 2 を再起動します。 |
移行する管理対象サーバのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。Solaris および Linux オペレーティング システムでは、ifconfig コマンドを使用して再接続を行うことができます。移行されたサーバのクライアントは、サーバの移行先の特定のマシンを認識する必要はありません。
移行されたサーバ インスタンスを移行前にホストしていたマシンが再び使用可能になった場合、移行プロセスの逆戻し (サーバ インスタンスを元のホスト マシンに移行して戻すこと) を行うことができます。これを、フェイルバックと呼びます。WebLogic Server ではフェイルバックのプロセスは自動化されていません。管理者は、サーバ インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。
サーバを元のホストに復元するおおまかな手順は次のとおりです。
細かな手順は、サーバおよびネットワーク環境によって異なります。
図 7-3 に、管理者が移行可能なサーバを手動で移行するときに発生するプロセスと通信を示します。
以下に、移行可能なサーバを含むクラスタでの管理サーバの動作を示します。
さらに管理サーバには、管理者によって発行されたコンフィグレーションの更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能なサーバも含めた通常のドメイン管理機能があります。
移行可能なサーバとは、移行可能としてコンフィグレーションされている、クラスタ化された管理対象サーバのことです。以下に、移行可能なサーバの主要な動作を示します。
リースの詳細については、「リース」を参照してください。
デフォルトでは、移行可能なサーバは 30,000 ミリ秒ごとにリースを更新します。このデフォルト値は、以下の 2 つのコンフィグレーション可能な ServerMBean プロパティ値を掛け合わせた値です。
System.exit を使用して、自身をできるだけ迅速に終了する。この場合、リース テーブルにはそのサーバ インスタンスの行が引き続き格納されます。この動作と自動移行の関連については、「サーバの移行におけるクラスタ マスターの役割」を参照してください。
ノード マネージャの使用は、サーバの移行に不可欠です。ホストとなる (またはホストとなる予定の) 各マシン上で実行されなければなりません。
ノード マネージャは、以下のようにサーバの移行を支援します。
Administration Console から管理対象サーバの起動を開始すると、管理サーバがノード マネージャを使用してそのサーバ インスタンスを起動します。ノード マネージャを呼び出して、スタンドアロンのノード マネージャ クライアントを使用してサーバ インスタンスを起動することもできます。ただし、起動する管理対象サーバが自身のコンフィグレーションを取得するために管理サーバが使用可能になっていなければなりません。
| 注意 : | 最初にノード マネージャによって起動されていないサーバ インスタンスの移行は失敗します。 |
ノード マネージャは、サーバの起動、再起動、停止、IP アドレスの移行、およびディスクのマウントとアンマウントを行う、WebLogic Server に付属のカスタマイズ可能なシェル スクリプトを実行することでサーバの移行プロセスの手順を実行します。これらのスクリプトは、Solaris および Linux で使用できます。
移行可能なサーバを含むクラスタでは、1 つのサーバ インスタンスがクラスタ マスターとして機能します。クラスタ マスターは、サーバの移行プロセスを調整する役割を担います。クラスタ内のどのサーバ インスタンスもクラスタ マスターになることができます。移行可能なサーバを含むクラスタの起動時に、クラスタに参加した最初のサーバがクラスタ マスターになり、クラスタ マネージャ サービスを起動します。クラスタに移行可能なサーバが 1 つも含まれない場合はクラスタ マスターは不要です。クラスタ マスター サービスは起動されません。クラスタ マスターが存在しなくても、移行可能なサーバは動作を継続できますが、サーバの移行はできません。以下に、クラスタ マスターの主要な機能を示します。
ClusterMBean の FencingGracePeriodMillis で指定された期間、待機する。その後、リースが期限切れになっている移行可能なサーバをホストするマシン上でノード マネージャ プロセスを呼び出してその移行可能なサーバを再起動しようとします。
WebLogic Server では、JMS サーバおよび JTA トランザクション回復サービスのサービスレベルの移行がサポートされています。これらのサービスは、クラスタ内のあるサーバから別のサーバに移すことができるため「移行可能サービス」と呼ばれます。
| 注意 : | JMS については、単一の分散送り先セットの一部として複数の物理送り先 (キューとトピック) をコンフィグレーションできるため、単独の WebLogic Server で障害が発生した場合のサービスの継続可能性も改善されています。 |
WebLogic Server では、サーバレベルの移行、つまり、サーバ インスタンスのそのまま全部の移行もサポートされています。また、サーバ インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。この機能については、「サーバおよびサービスの移行について」を参照してください。
| 注意 : | データベースを使用してリース情報を保持する場合は、リース テーブルを高可用性データベースに格納する必要があります。移行可能なサーバの信頼性は、リース テーブルの格納に使用されるデータベースの信頼性で決まります。詳細については、「リース」を参照してください。 |
WebLogic Server クラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバ インスタンスに均一にデプロイされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS や JTA トランザクション回復システムなどのシングルトン サービスは常にクラスタ内の 1 つのサーバのみで実行されます。
WebLogic Server では、管理者はシングルトン サービスをクラスタ内のサーバ間で移行できます。これは、サーバの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバで障害が発生した場合に冗長サーバ上でサービスを速やかに再開できるため、クラスタ内のシングルトン サービスの可用性が向上します。
クライアントは、移行対応の RMI スタブを使用してクラスタ内の移行可能サービスにアクセスします。RMI スタブは、各時点でどのサーバが固定サービスのホストとなっているかを追跡し、それに従ってクライアントからのリクエストを転送します。たとえば、クライアントが最初に固定サービスにアクセスしたとき、スタブはクライアントのリクエストを、その時点でサービスのホストとなっているクラスタ内のサーバ インスタンスに転送します。クライアントからの次のリクエストまでにサービスが別の WebLogic Server に移動している場合、スタブはそのリクエストを最新のホスト サーバに透過的にリダイレクトします。
JMS サーバや JTA トランザクション回復サービスがクラスタ内に存在し、コンフィグレーションで移行が有効にされているとき、WebLogic Server はそれらのサービスに対する移行対応の RMI スタブを実装します。
クラッシュした、または管理サーバからアクセスできないサーバ インスタンスからサービスを移行する場合は、特別な考慮事項があります。移行を行う時点で以前にアクティブだったサービスのホストに管理サーバからアクセスできない場合、その管理対象サーバのローカル コンフィグレーション情報は、それがサービスのアクティブなホストでなくなっていることを反映して更新されることはありません。この場合は、アクセス不能な管理対象サーバのローカル コンフィグレーション キャッシュを再起動前にパージする必要があります。そうすれば、以前にアクティブだったホストが、別の管理対象サーバに移行しているサービスを起動時に再びアクティブにしてしまうことがなくなります。
デフォルトでは、WebLogic Server は JTA トランザクション回復サービスまたは JMS サーバを、クラスタ内のほかのどのサーバにでも移行できます。また必要に応じて、固定サービスのホストとなることのできるクラスタ内のサーバのリストを手動で編集できます。このサーバ リストは移行可能対象と呼ばれ、サービスを移行することのできるサーバを管理します。JMS の場合、移行可能対象は JMS サーバをデプロイ可能なサーバのリストも定義します。
たとえば、次の図では 4 つのサーバで構成されるクラスタを示しています。クラスタ内で、サーバ A および B は JMS サーバの移行可能対象としてコンフィグレーションされます。
上の図では、移行可能対象の設定に従って、管理者は固定サービスである JMS サーバをサーバ A からサーバ B に、またはサーバ B からサーバ A にのみ移行できます。同様に、JMS サーバをクラスタにデプロイするとき、管理者はデプロイメント先としてサーバ A または B のどちらかを選択して、サービスの移行を有効にします (管理者が移行可能対象を使用しない場合、JMS サーバはクラスタ内で使用可能などのサーバにもデプロイまたは移行できます)。
WebLogic Server では、JTA トランザクション回復サービスと JMS サーバに対して個別の移行可能対象を作成できます。これにより、必要に応じて、クラスタ内の別々のサーバ上で常に各サービスを動作させ続けることが可能になっています。また逆に、JTA と JMS の両方に共通する移行可能対象として同じサーバ群を選択し、両方のサービスが確実にクラスタ内の同じサーバ上に配置されるようにすることもできます。
シングルトン サービスの自動的な移行機能によって、シングルトン サービスの自動的な状態モニタと移行が可能になります。シングルトン サービスとは、クラスタ内の複数のサーバで同時に実行できないサービスです。移行可能サービスが何らかの理由 (たとえば、サービス コード内のバグ、サーバの障害、ネットワークの障害など) で失敗したり使用できなくなった場合、そのサービスは現在の場所で非アクティブ化されて、新しいサーバ上でアクティブ化されます。これらのサービスを別のサーバに移行するプロセスは、移行マスターによって処理されます。「移行マスター」を参照してください。
WebLogic Server では、ユーザ定義のシングルトン サービスを自動的に移行できます。
| 注意 : | JMS や 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-"
/>
サービスの自動移行の動作は、以下を使用してコンフィグレーションできます。
  
|
