WebLogic Server クラスタ ユーザーズ ガイド
![]() |
![]() |
![]() |
![]() |
クラスタが高可用性を提供するためには、サービスの障害からの回復が可能でなければなりません。この章の以下の節では、WebLogic Server でクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバ方式の概要をオブジェクトのタイプ別に示します。
クラスタ内の WebLogic Server インスタンスは、以下のものをモニタすることで、自身のピア サーバ インスタンスの障害を検出します。
WebLogic Server インスタンスは、障害を直ちに検出するために、ピア サーバ インスタンス間で IP ソケットが使用されているかどうかをモニタします。サーバがクラスタ内のピアのいずれかに接続し、ソケットを使ってデータ転送を始めた場合、そのソケットが突然クローズされると、ピア サーバが「エラー」としてマークされ、その関連サービスが JNDI ネーミング ツリーから削除されます。
クラスタ化されたサーバ インスタンスがピア ツー ピア通信用にソケットをオープンしていない場合、障害が発生したサーバは WebLogic Server のハートビートによって検出できます。クラスタ内のすべてのサーバ インスタンスはマルチキャストを使用して、定期的なサーバ ハートビート メッセージを他のクラスタ メンバーにブロードキャストします。個々のハートビート メッセージには、メッセージの送信元のサーバを一意に識別するデータが入っています。サーバは、自身のハートビート メッセージを 10 秒間隔で定期的にブロードキャストします。同時に、クラスタ内の各サーバはマルチキャスト アドレスをモニタして、すべてのピア サーバのハートビート メッセージが送信されているかどうかを確認します。
マルチキャスト アドレスをモニタ中のサーバにピア サーバからのハートビート メッセージが 3 回届かなかった場合 (つまり、モニタする側のサーバが他のサーバから 30 秒以上ハートビートを受信していない場合)、モニタする側のサーバはピア サーバを「エラー」としてマークします。次に、必要であればローカルの JNDI ツリーを更新して、障害が発生したサーバでホストされていたサービスを削除します。
このようにして、サーバは、ピア ツー ピア通信でソケットがオープンされていない場合でも、障害を検出できます。
注意 : WebLogic Server での IP ソケットとマルチキャスト通信の使用について、詳しくは「クラスタでの WebLogic Server の通信」を参照してください。
クラスタ内でのサーブレットと JSP の自動レプリケーションとフェイルオーバを支援するために、WebLogic Server では HTTP セッション ステートを保持する以下の 2 種類のメカニズムがサポートされています。
サポート対象のハードウェア ロード バランシング ソリューションを使用しているクラスタの場合、ロード バランシング ハードウェアは、WebLogic Server クラスタ内で使用可能な任意のサーバにクライアントのリクエストを単純にリダイレクトします。クラスタ自身は、クライアントの HTTP セッション ステートのレプリカをクラスタ内のセカンダリ サーバから取得します。
WebLogic Server では、複数のクラスタに渡って HTTP セッション ステートをレプリケートするために以下の 2 種類の方法が使用されます。
WebLogic Server は、インメモリ レプリケーションを使用してセッション ステートをサーバ インスタンス間でコピーします。プライマリ サーバはクライアントが最初に接続するサーバ上にプライマリ セッション ステートを作成し、クラスタ内の別の WebLogic Server インスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。
JDBC ベースの永続性では、WebLogic Server はファイルベースまたは JDBC ベースの永続性メカニズムを使用して、サーブレットまたは JSP の HTTP セッション ステートを保持します。それぞれの永続性メカニズムの詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「セッションの永続性のコンフィグレーション」を参照してください。
JDBC ベースの永続性は、ワイド エリア ネットワーク (WAN) 内の HTTP セッション ステート レプリケーションにも使用されます。詳細については、「WAN での HTTP セッション ステートのレプリケーション」を参照してください。
以下の節では、インメモリ レプリケーションを使用するセッション ステート レプリケーションについて説明します。
HTTP セッション ステートのインメモリ レプリケーションを利用するためには、WebLogic プロキシ プラグインのコンフィグレーションが一致した Web サーバの集合、またはロード バランシング ハードウェアのどちらかを使用して WebLogic Server クラスタにアクセスする必要があります。
WebLogic プロキシ プラグインは、クラスタ化されたサーブレットまたは JSP のホストである WebLogic Server インスタンスのリストを保持し、ラウンドロビン方式を使用して HTTP リクエストをそれらのインスタンスに転送します。このプラグインは、WebLogic Server インスタンスで障害が発生した場合に、クライアントの HTTP セッション ステートのレプリカを見つけるために必要なロジックも備えています。
HTTP セッション ステートのインメモリ レプリケーションは、以下の Web サーバおよびプロキシ ソフトウェアでサポートされています。
HttpClusterServlet
プロキシ プラグインの設定方法については、「プロキシ プラグインをコンフィグレーションする」を参照してください。
プロキシ プラグインではなくロード バランシング ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなクッキーの永続性メカニズムと、SSL の永続性にハードウェアが対応している必要があります。これらの必要条件の詳細については、「ロード バランサのコンフィグレーション要件」を参照してください。ロード バランサの設定手順については、「パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする」を参照してください。
この節では、クラスタ環境にデプロイするサーブレットおよび JSP を対象とした、プログラミング上の重要な制限および考慮事項について説明します。
注意 : シリアライゼーションとは、複雑なデータ構造を変換するプロセスのことです。この例には、データの並列な配置 (多数のビットが並列チャネルを通じて同時に転送される) からシリアル形式 (1 ビットずつ順番に転送される) への変換などがあります。シリアル インタフェースでは、この変換によってデータ転送を可能にしています。
javax.servlet.http.HttpSession
を実装する HTTP サーブレットでセッション オブジェクトの属性を変更するには、非推奨となった putValue
に代わって HttpSession.setAttribute
を使用します。setAttribute
を使用してセッション オブジェクトの属性を設定する場合、オブジェクトとその属性はインメモリ レプリケーションを使用してクラスタにレプリケートされます。その他の set メソッドを使用してセッションの内部でオブジェクトを変更する場合、WebLogic Server ではその変更はレプリケートされません。セッション内にあるオブジェクトに対して変更が行われるたびに、setAttribute()
を呼び出してクラスタ全体でそのオブジェクトを更新してください。
同様に、セッション オブジェクトから属性を削除するには、非推奨となった removeValue
に代わって removeAttribute
を使用します。
注意 : 非推奨の putValue
メソッドおよび removeValue
メソッドを使用しても、セッション属性はレプリケートされます。
セッション データをシリアライズすると、セッション ステートのレプリケーションでオーバーヘッドが生じます。オーバーヘッドは、シリアライズされるオブジェクトのサイズに比例して大きくなります。セッション内で非常にサイズの大きいオブジェクトを作成するような設計では、サーブレットのパフォーマンスをテストして適切なレベルを確保してください。
複数のフレームを利用する Web アプリケーションを設計する場合は、指定したフレームセットのフレームが同時にリクエストを送らないようにすることを心がけてください。たとえば、論理的にはクライアントが 1 つのセッションを作成する場合でも、1 つのフレームセットの複数のフレームがクライアント アプリケーションに代わって複数のセッションを作成する可能性があります。
クラスタ環境では、フレーム リクエストを適切に調整しないとアプリケーションの予期しない動作が発生することがあります。プロキシ プラグインは各リクエストを他のリクエストに関係なく処理するので、複数のフレーム リクエストによって、アプリケーションとクラスタ化されたインスタンスとの関連付けが「リセット」される場合が考えられます。また、フレームセット内の複数のフレームを介して同じセッションの属性を変更することで、アプリケーションがセッション データを壊してしまう可能性もあります。
アプリケーションの予期しない動作を防ぐには、フレームからのセッション データへのアクセスを注意深く設計します。以下のいずれかの規則に従うと、よくある問題を防ぐことができます。
デフォルトでは、WebLogic Server はプライマリ セッション ステートが置かれるものとは別のマシン上にセッション ステートのレプリカを作成しようと試みます。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカを格納するために使用されるクラスタ内のサーバの優先順リストです。
WebLogic Server Console を使用して、個別のサーバ インスタンスのホストとなるユニークなマシン名を定義できます。それらのマシン名を新しい WebLogic Server インスタンスに関連付けると、そのサーバがシステムのどこにあるのかを識別できます。
マシン名は一般に、同じマシン上で動作するサーバを表すために使用します。たとえば、同じマシンまたはサーバ ハードウェア上で動作するすべてのサーバ インスタンスに同じマシン名を割り当てます。
1 台のマシン上で複数の WebLogic Server インスタンスを実行しない場合、WebLogic Server マシン名を指定する必要はありません。マシン名のないサーバは、それぞれ別個のマシン上にあるものとして扱われます。マシン名を設定する手順の詳細については、「マシン名をコンフィグレーションする」を参照してください。
クラスタ化されるサーバ インスタンスをコンフィグレーションするとき、サーバをレプリケーション グループと優先セカンダリ レプリケーション グループに割り当てることができます。後者のグループは、そのサーバに対して作成されるプライマリ HTTP セッション ステートのレプリカの保存先となります。
クライアントがクラスタ内のサーバに接続されて、プライマリ セッション ステートが作成されると、そのプライマリ ステートのホスト サーバではセカンダリのホスト サーバを決定するためにクラスタ内の他のサーバがランク付けされます。サーバのランクは、そのサーバがプライマリ サーバと同じマシン上にあるかどうか、およびプライマリ サーバの優先レプリケーション グループに属しているかどうか、という 2 つの情報を組み合わせて判断されます。次の表は、クラスタ内のサーバの相対的なランキングを示しています。
表 6-1 セッション レプリケーションのためのサーバ インスタンスのランキング
プライマリ WebLogic Server は、このルールに従ってクラスタ内のその他のサーバをランク付けし、最もランクの高いサーバをセカンダリ セッション ステートのホストとして選択します。たとえば、次の図は地理的な分類に基づいてコンフィグレーションされたレプリケーション グループを示しています。
この例では、サーバ A、B、および C は「Headquarters」というレプリケーション グループのメンバーであり、「Crosstown」という優先的なセカンダリ レプリケーション グループを使用します。逆に、サーバ X、Y、および Z は「Crosstown」というグループのメンバーであり、「Headquarters」という優先的なセカンダリ レプリケーション グループを使用します。サーバ A、B、および X は、「sardina」という同じマシン上にあります。
クライアントがサーバ A に接続し、HTTP セッション ステートを作成する場合の動作は次のようになります。
レプリケーション グループ内のサーバのメンバシップをコンフィグレーションする手順、あるいはサーバの優先セカンダリ レプリケーション グループを割り当てる手順については、「レプリケーション グループをコンフィグレーションする」を参照してください。
この節では、クラスタ化されたサーブレットおよび JSP にプロキシ経由で送られてくるリクエストを対象とした、接続およびフェイルオーバのプロセスについて説明します。プロキシ プラグインの設定方法については、「プロキシ プラグインをコンフィグレーションする」を参照してください。
次の図は、クラスタでホストされるサーブレットにクライアントがアクセスする状況を表しています。この例では、静的な HTTP リクエストのみを処理する 1 つの WebLogic Server を使用します。すべてのサーブレット リクエストは、HttpClusterServlet
を通じて WebLogic Server クラスタに転送されます。
図 6-2 サーブレットと JSP へのプロキシ経由のアクセス
注意 : 以下の説明は、WebLogic Server と HttpClusterServlet
ではなくサード パーティの Web サーバと WebLogic プロキシ プラグインを使用する場合にも有効です。
HTTP クライアントがサーブレットを要求すると、HttpClusterServlet
がプロキシとして機能し、WebLogic Server クラスタにそのリクエストを転送します。HttpClusterServlet
は、クラスタ内の全サーバのリストと、クラスタへのアクセス時に使用するロード バランシング ロジックを管理します。上の例では、HttpClusterServlet
はクライアントのリクエストを WebLogic Server A にあるサーブレットに転送します。WebLogic Server A は、クライアントのサーブレット セッションをホストするプライマリ サーバになります。
サーブレットのフェイルオーバ サービスを提供するために、プライマリ サーバではクライアントのサーブレット セッション ステートがクラスタ内のセカンダリ WebLogic Server にレプリケートされます。このような処理により、たとえばネットワークの障害によってプライマリ サーバがダウンしても、セッション ステートのレプリカを利用することができます。上の例では、サーバ B がセカンダリとして選択されています。
サーブレット ページは HttpClusterServlet
を通じてクライアントに返され、クライアント ブラウザはサーブレット セッション ステートのプライマリとセカンダリの場所を示すクッキーを記述するように指示されます。クライアント ブラウザでクッキーがサポートされていない場合、WebLogic Server では代わりに URL 書き換えを利用できます。
デフォルト コンフィグレーションの WebLogic Server では、クライアントサイドのクッキーを使用して、クライアントのサーブレット セッション ステートのホストであるプライマリ サーバとセカンダリ サーバが追跡されます。クライアント ブラウザでクッキーが無効になっている場合、WebLogic Server では URL 書き換えを利用してもプライマリ サーバとセカンダリ サーバを追跡できます。URL 書き換えを利用する場合は、クライアント セッション ステートの両方の場所が、クライアントとプロキシ サーバの間で渡される URL に挿入されます。この機能をサポートするには、WebLogic Server クラスタで URL 書き換えを有効にする必要があります。URL 書き換えを有効にする方法については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「クッキーに代わる URL 書き換えの使用」を参照してください。
プライマリ サーバで障害が発生すると、HttpClusterServlet
はクライアントのクッキー情報を利用して、セッション ステートのレプリカのホストであるセカンダリ WebLogic Server の場所を確認します。HttpClusterServlet
は、クライアントの次の HTTP リクエストを自動的にセカンダリ サーバにリダイレクトします。フェイルオーバは、クライアントには意識されません。
障害の発生後は、WebLogic Server B がサーブレット セッション ステートのプライマリ サーバになり、新しいセカンダリ サーバが作成されます (前の例ではサーバ C)。HTTP 応答では、今後のフェイルオーバに備えて、新しいプライマリ サーバとセカンダリ サーバを反映するためにプロキシによってクライアントのクッキーが更新されます。
2 つのサーバで構成されるクラスタでは、クライアントはセカンダリ セッション ステートのホスト サーバに透過的にフェイルオーバされます。ただし、もう 1 つの WebLogic Server がクラスタで利用可能にならない限り、クライアントのセッション ステートのレプリケーションは継続されません。たとえば、元のプライマリ サーバが再起動されるか、ネットワークに再び接続されると、そのサーバはセカンダリ セッション ステートのホストとして使用されます。
ロード バランシング ハードウェアを経由したクライアントの直接アクセスを可能にするために、WebLogic Server のレプリケーション システムでは、クライアントがフェイルオーバ先のサーバとは無関係にセカンダリ セッション ステートを使用できます。WebLogic Server は、プライマリ サーバとセカンダリ サーバの場所を記録する手段としてクライアント側のクッキーまたは URL 書き換えを使用します。ただし、この情報はサーブレット セッション ステートの場所の履歴としてのみ使用されます。ロード バランシング ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバを能動的に見つける手段としてはクッキー情報を使用しません。
以下の節では、HTTP セッション ステートのレプリケーションをロード バランシング ハードウェアと組み合わせて使用する場合の、接続およびフェイルオーバのプロセスについて説明します。
次の図は、ロード バランサを通じてクラスタにアクセスしているクライアントの接続手順を示しています。
図 6-3 ロード バランシング ハードウェアを利用した接続
Web アプリケーションのクライアントがパブリックな IP アドレスを使用してサーブレットを要求する場合は、次のようなプロセスが行われます。
注意 : クッキーを無効にしているクライアントに対応するには、「URL 書き換えを利用したセッション レプリカの追跡」で説明しているように、WebLogic Server の URL 書き換え機能を有効にする必要があります。
クライアントのセッションの途中でサーバ A に障害が発生すると、次の図に示すように、そのクライアントによるサーバ A への次の接続リクエストは失敗します。
図 6-4 ロード バランシング ハードウェアを利用したフェイルオーバ
WebLogic Server C はクライアントのプライマリ セッション ステートの新しいホストになり、WebLogic Server B は引き続きセッション ステートのレプリカを保持します。プライマリ ホストとセカンダリ ホストに関するこの新しい情報は、クライアントのクッキーまたは URL 書き換えで再び更新されます。
クラスタ内のサーバ間での HTTP セッション ステート レプリケーションに加えて、WebLogic Server には、複数のクラスタ間で HTTP セッション ステートをレプリケートする機能が用意されています。これにより、複数の地理的領域、電力供給網、インターネット サービス プロバイダに渡ってクラスタを分散できるようになるため、高可用性とフォールト トレランスが向上します。この節では、WebLogic Server でサポートされている、クラスタ間レプリケーションの 2 種類のメカニズムについて説明します。
HTTP セッション ステート レプリケーションに関する一般的な情報については、「HTTP セッション ステートのレプリケーション」を参照してください。ハードウェア ロード バランサの使用方法の詳細については、「クラスタ化されたサーブレットと JSP へのロード バランシング ハードウェアを利用したアクセス」を参照してください。
WebLogic Server でクラスタ間のレプリケーションを実行するには、使用しているネットワークにグローバル ハードウェア ロード バランサとローカル ハードウェア ロード バランサが含まれている必要があります。図 6-5 に、クラスタ間のレプリケーションをサポートするマルチ クラスタ環境で両方のタイプのロード バランサが対話する仕組みを示します。WebLogic Server 環境でのロード バランサの使用に関する一般的な情報については、「ロード バランシング ハードウェアを利用した接続」を参照してください。
図 6-5 クラスタ間レプリケーションのロード バランサの要件
以下の節では、このネットワーク コンフィグレーションの各コンポーネントについて説明します。
クラスタ間のレプリケーションをサポートするネットワーク コンフィグレーションでは、グローバル ロード バランサがクラスタ間の HTTP リクエストのバランシングを行います。リクエストが受信されると、グローバル ロード バランサは、各クラスタによって現在処理されているリクエスト数に基づいてそのリクエストの送信先となるクラスタを決定します。その後、リクエストは選択されたクラスタのローカル ロード バランサに渡されます。
ローカル ロード バランサは、グローバル ロード バランサから HTTP リクエストを受信します。ローカル ロード バランサは、クラスタ内にあるサーバ間の HTTP リクエストのバランシングを行います。
クラスタ間でセッション データをレプリケートするには、プライマリ クラスタからセカンダリ クラスタにセッション ステート情報を送信するように、レプリケーション チャネルがコンフィグレーションされていなければなりません。セッション情報のレプリケーションに使用される特定の方法は、実装しているクラスタ間レプリケーションのタイプによって異なります。詳細については、「MAN での HTTP セッション ステートのレプリケーション」または「WAN での HTTP セッション ステートのレプリケーション」を参照してください。
クラスタ内のあるサーバで障害が発生した場合、ローカル ロード バランサは、リクエストをクラスタ内のその他のサーバに転送します。クラスタ全体で障害が発生した場合は、ローカル ロード バランサは、HTTP リクエストをグローバル ロード バランサに戻します。その後、グローバル ロード バランサはそのリクエストをもう一方のローカル ロード バランサにリダイレクトします。
以下では、クラスタ間レプリケーションをコンフィグレーションするために必要な手順について概説します。
注意 : クラスタ間レプリケーションでは、各クラスタが別々のドメインに割り当てられている必要があります。
ドメインの作成とコンフィグレーションだけでなく、クラスタおよび管理対象サーバも作成し、コンフィグレーションする必要があります。ドメインの作成とコンフィグレーションについては、『ドメインのコンフィグレーションについて』の「Using WebLogic Tools to Configure a Domain」を参照してください。
次の表に、クラスタ間レプリケーションのコンフィグレーションに使用される config.xml の Cluster 要素の下位要素を示します。
|
|
|
|
|
|
メトロポリタン エリア ネットワーク (MAN) 内のリソースは、多くの場合物理的に異なる場所にありますが、ネットワーク レイテンシが問題になるほど地理的には離れていません。MAN におけるネットワーク通信では通常、低レイテンシで高速な相互接続が提供されます。MAN 内のクラスタは物理的に異なる場所にインストールできるため、可用性が向上します。
MAN 内でフェイルオーバを提供するために、WebLogic Server には 2 つのクラスタ間で機能するインメモリ メカニズムが用意されています。ネットワーク レイテンシが数ミリ秒であれば、この機能によりセッション ステートはクラスタ間で同期的にレプリケートされます。同期的な方法を使用する利点は、インメモリ レプリケーションの信頼性が保証されることです。
注意 : 同期的なステート レプリケーションのパフォーマンスは、クラスタ間のネットワーク レイテンシで決まります。この方法は、クラスタ間のネットワーク レイテンシが許容可能な場合にのみ使用するようにしてください。
この節では、MAN 内の複数のクラスタ間で想定されるフェイルオーバのシナリオについて説明します。図 6-6 に、MAN における一般的なマルチ クラスタ環境を示します。
この図には、HTTP セッション ステートの次のシナリオが示されています。
以下の節では、図 6-6 の MAN コンフィグレーションに基づいた、さまざまなフェイルオーバのシナリオについて説明します。
クラスタ 1 内のすべてのサーバで障害が発生した場合、グローバル ロード バランサは以降のセッション リクエストをすべてクラスタ 2 に自動的にフェイルオーバします。クラスタ 2 にレプリケートされたすべてのセッションが回復され、クライアントはデータの消失を回避できます。
プライマリ サーバ S1 はクラスタ 1 でホストされ、セカンダリ サーバ S6 はクラスタ 2 でホストされているとします。S1 がクラッシュした場合、クラスタ 1 内の他のサーバ (S2 または S3) がリクエストを受信し、サーバ S6 からセッション データを取得します。S6 は引き続き、バックアップ サーバとして機能します。
プライマリ サーバ S1 はクラスタ 1 でホストされ、セカンダリ サーバ S6 はクラスタ 2 でホストされているとします。セカンダリ サーバ S6 で障害が発生した場合、プライマリ サーバ S1 はクラスタ 2 から新しいセカンダリ サーバを自動的に選択します。クライアント リクエストを受信すると、セッション情報は新しいセカンダリ サーバにバックアップされます。
MAN でのレプリケーションでは、クラスタ アフィニティを管理するグローバル ロード バランサとサーバ アフィニティを管理するローカル ロード バランサが使用されます。クラスタ内のあるサーバで障害が発生した場合、ローカル ロード バランサはセッション ステートがそのクラスタ内の別のサーバにレプリケートされることを保証します。クラスタ内のすべてのサーバで障害が発生した場合や、クラスタ内のすべてのサーバが使用できなくなっている場合は、グローバル ロード バランサがセッション ステートをもう一方のクラスタにレプリケートします。これにより、クラスタ全体で障害が発生しない限り、もう一方のクラスタへのフェイルオーバは発生しないようになります。
クライアントは、ロード バランサを通じてクラスタへの接続を確立したら、そのクラスタが正常な状態である限り、そのクラスタへの接続を保持する必要があります。
ワイド エリア ネットワーク (WAN) 内のリソースは、多くの場合異なる地理的領域に渡って分散されています。ネットワーク トラフィックが長い距離を進む必要があるだけでなく、これらのリソースは通常、複数のルータなどのネットワーク ボトルネックによっても分離されています。WAN におけるネットワーク通信は通常、レイテンシが比較的長く、相互接続の速度も遅くなります。
WAN ではネットワークのパフォーマンスが低いため、MAN で使用されるような同期的なレプリケーション メカニズムを使用することは困難です。WebLogic Server は、非同期的なデータ レプリケーション方式使用することで、WAN におけるクラスタ間のフェイルオーバを提供します。
この節では、WAN 内の複数のクラスタ間で想定されるフェイルオーバのシナリオについて説明します。図 6-7 に、WAN における一般的なマルチ クラスタ環境を示します。
この図には、HTTP セッション ステートの次のシナリオが示されています。
この節では、WAN 環境で想定されるフェイルオーバのシナリオについて説明します。
クラスタ 1 内のすべてのサーバで障害が発生した場合、グローバル ロード バランサは以降のセッション リクエストをすべてクラスタ 2 に自動的にフェイルオーバします。すべてのセッションは、認識されている最新のデータベースへのフラッシュに従ってバックアップされます。
この節では、WAN でのクラスタ間セッション ステート レプリケーション用のデータ ソースのコンフィグレーション要件について説明します。クラスタ間レプリケーションの設定に関する一般的な情報については、「クラスタ間レプリケーションのコンフィグレーション要件」を参照してください。
WAN 環境でのクラスタ間レプリケーションを有効にするには、セッション ステート情報が格納されるデータベースを指定する JDBC データ ソースを作成する必要があります。次の手順を実行して、データベースを設定しコンフィグレーションします。
このデータ ソースは、JDBC マルチ データ ソースとしてコンフィグレーションすることもできます。マルチ データ ソースのコンフィグレーションの詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC マルチ データ ソースのコンフィグレーション」を参照してください。
CREATE TABLE WLS_WAN_PERSISTENCE_TABLE (WL_ID VARCHAR2(100) NOT NULL,
WL_CONTEXT_PATH VARCHAR(50) NOT NULL,
WL_CREATE_TIME NUMBER(20),
WL_SESSION_VALUES LONG RAW,
WL_ACCESS_TIME NUMBER(20),
WL_MAX_INACTIVE_INTERVAL INTEGER,
WL_VERSION INTEGER,
PRIMARY KEY(WL_ID, WL_CONTEXT_PATH,
WL_VERSION));
クラスタ化される EJB と RMI のフェイルオーバは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼び出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼び出しを再試行します。
クラスタ化されたオブジェクトについては、オブジェクトが多重呼び出し不変の場合にだけ自動的なフェイルオーバが行われます。メソッドを何回呼び出しても 1 回呼び出したときと効果に違いがなければ、オブジェクトは多重呼び出し不変となります。このことは、恒久的な副作用を持たないメソッドに関して常に当てはまります。副作用のあるメソッドは、多重呼び出し不変性に留意して作成する必要があります。
ここでショッピング カートに商品を追加するショッピング カード サービス呼び出し addItem()
を考えてみます。クライアント C がこの呼び出しをサーバ S1 上のレプリカで行うものとします。S1 が呼び出しを受け取った後、呼び出しを C に返す前に、S1 がクラッシュしたとします。この時点では、商品がショッピング カートに追加されていますが、レプリカ対応スタブは例外を受け取っています。スタブがサーバ S2 でこのメソッドを再試行すれば、商品がショッピングカートに 2 回追加されることになります。この理由から、レプリカ対応スタブは、デフォルトでは、リクエストが送られた後、そのリクエストが返ってくるまでは、メソッドの再試行は行いません。この動作は、サービスを多重呼び出し不変としてマークすることで、オーバーライドできます。
EJB または RMI オブジェクトをクラスタ化すると、オブジェクトのインスタンスがクラスタ内のすべての WebLogic Server にデプロイされます。クライアントでは、オブジェクトのどのインスタンスを呼び出すのかを選択できます。オブジェクトの各インスタンスはレプリカと呼ばれます。
WebLogic Server では、レプリカ対応スタブという技術を土台としてオブジェクトのクラスタ化を実現しています。クラスタ化をサポート (デプロイメント記述子で定義) する EJB をコンパイルすると、appc
によって EJB のインタフェースが rmic
コンパイラに渡されてその Bean のレプリカ対応スタブが生成されます。RMI オブジェクトの場合は、rmic
に渡されるコマンドライン オプションを使用して明示的にレプリカ対応スタブを生成します。詳細については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI コンパイラの使い方」を参照してください。
レプリカ対応スタブは、呼び出し側では通常の RMI スタブとして認識されます。しかしながら、スタブは 1 つのオブジェクトではなく複数のレプリカを表します。レプリカ対応スタブは、オブジェクトがデプロイされるすべての WebLogic Server インスタンスで EJB クラスまたは RMI クラスを見つけるためのロジックを備えています。クラスタ対応の EJB オブジェクトまたは RMI オブジェクトをデプロイすると、その実装は JNDI ツリーにバインドされます。「クラスタワイドの JNDI ネーミング サービス」で説明されているように、クラスタ化された WebLogic Server インスタンスではそのオブジェクトを利用できるすべてのサーバ インスタンスをリストするために JNDI ツリーを更新することができます。クライアントがクラスタ化されたオブジェクトにアクセスすると、その実装はクライアントに送信されるレプリカ対応スタブで置き換えられます。
スタブは、オブジェクトに対するメソッド呼び出しを負荷分散するためのロード バランシング アルゴリズム (呼び出しルーティング クラス) を備えています。呼び出しが行われるたびに、スタブではそのロード アルゴリズムを利用して呼び出すレプリカを選択できます。この機能により、呼び出し側からは意識されない方法でクラスタ全体でのロード バランシングが実現されます。RMI オブジェクトおよび EJB で利用可能なロード バランシング アルゴリズムを理解するには、「EJB と RMI オブジェクトのロード バランシング」を参照してください。呼び出しの途中でエラーが起きると、スタブによってその例外が横取りされ、別のレプリカで呼び出しが再試行されます。この機能により、同じように呼び出し側からは意識されないフェイルオーバが実現されます。
EJB は、2 つの異なったレプリカ対応スタブを生成できる点が通常の RMI オブジェクトと異なります。1 つは EJBHome
インタフェースに対して、もう 1 つは EJBObject
インタフェースに対して生成されます。つまり、EJB では以下の 2 段階でロード バランシングとフェイルオーバのメリットを実現できることになります。
以下の節では、EJB のタイプ別のクラスタ化サポートについて説明します。
すべての Bean のホーム インタフェース (Bean インスタンスの検索や作成に使用される) は、weblogic-ejb-jar.xml
の home-is-clusterable 要素で指定することで、クラスタ化できます。
注意 : ステートレス セッション Bean、ステートフル セッション Bean、およびエンティティ Bean にはホーム インタフェースがあります。メッセージ駆動型 Bean にはありません。
Bean をクラスタにデプロイするときに、各サーバは Bean のホーム インタフェースを同じ名前でクラスタ JNDI ツリーにバインドします。クライアントがクラスタにある Bean のホーム インタフェースを要求すると、ルックアップを行うサーバ インスタンスは、各サーバ上のホームへの参照を持つ EJBHome
スタブを返します。
クライアントが create()
または find()
呼び出しを発行すると、スタブはロード バランシング アルゴリズムに従ってレプリカ リストからサーバを選択し、そのサーバ上のホーム インタフェースに呼び出しをルーティングします。選択されたホーム インタフェースは呼び出しを受け取り、そのサーバ インスタンス上に Bean インスタンスを作成して、呼び出しを実行します。
注意 : WebLogic Server では、EJB ホーム インタフェースのサーバ アフィニティを提供するロード バランシング アルゴリズムがサポートされています。サーバ アフィニティ、およびロード バランシングとフェイルオーバに対するその影響については、「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」を参照してください。
EJBObject
スタブは、クラスタ内の EJB の使用可能なレプリカを追跡します。
ホームでステートレス Bean が作成されると、Bean のデプロイ先となる、クラスタ内のすべてのサーバのリストを示す EJBObject
スタブが返されます。ステートレス Bean ではステートが保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できます。スタブでは障害が起きたときに自動的にフェイルオーバを実行できます。スタブでは、Bean は自動的には多重呼び出し不変として扱われないので、あらゆる障害から自動的に回復することはありません。Bean が多重呼び出し不変メソッドを利用して記述されている場合は、そのことをデプロイメント記述子で示すことができ、そうすればあらゆる場合で自動フェイルオーバが有効になります。
注意 : WebLogic Server では、ステートレス EJB リモート インタフェースのサーバ アフィニティを提供するロード バランシング オプションがサポートされています。サーバ アフィニティ、およびロード バランシングとフェイルオーバに対するその影響については、「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」を参照してください。
ステートフル サービスに対するメソッドレベルのフェイルオーバには、ステートのレプリケーションが必要です。WebLogic Server では、HTTP セッション ステートで使用されるものと同様のレプリケーション方式を使用して、プライマリ Bean インスタンスのステートをセカンダリ サーバ インスタンスにレプリケートすることで、この要件を満たします。
ホーム インタフェースはステートレス セッション Bean インスタンスを作成するときに、「レプリケーション グループの使用」で定義した同じルールを使用して、レプリケートされたステートをホストするためのセカンダリ インスタンスを選択します。ホーム インタフェースは、プライマリ Bean インスタンスの場所とレプリケートされた Bean ステートの場所のリストを示す EJBObject
スタブをクライアントに返します。
次の図に、クラスタ化されたステートフル セッション EJB にクライアントがアクセスする状況を示します。
図 6-8 ステートフル セッション EJB にアクセスするクライアント
クライアントによって EJB のステートが変更されると、ステートの変更部分がセカンダリ サーバのインスタンスにレプリケートされます。トランザクションに関係している EJB の場合、レプリケーションはトランザクションのコミットの直後に行われます。トランザクションに関係していない EJB の場合、レプリケーションは各メソッド呼び出しの後に行われます。
両方の場合で、EJB のステートの実際の変更部分だけがセカンダリ サーバにレプリケートされます。このため、レプリケーション プロセスに伴うオーバーヘッドが最小限に抑えられます。
注意 : EJB 仕様で説明されているように、ステートフル EJB の実際のステートはトランザクション非対応です。可能性は低いですが、EJB の現在のステートが失われることもあり得ます。たとえば、EJB の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた EJB のステートにフェイルオーバされます。どのような障害が起きても EJB のステートを保持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用してください。
プライマリ サーバで障害が起きると、以降のリクエストはクライアントの EJB スタブによって自動的にセカンダリ WebLogic Server インスタンスにリダイレクトされます。この時点で、レプリケートされたステート データを使用してセカンダリ サーバで新しい EJB インスタンスが作成され、セカンダリ サーバで処理が継続されます。
フェイルオーバの後、WebLogic Server では EJB セッション ステートをレプリケートする新しいセカンダリ サーバが選択されます (クラスタ内に利用可能な別のサーバがある場合)。新しいプライマリとセカンダリのサーバ インスタンスの場所は、次に示すように、次のメソッド呼び出しのときにクライアントのレプリカ対応スタブで自動的に更新されます。
図 6-9 フェイルオーバ後にレプリカ対応スタブが更新される
エンティティ Bean には、読み書き対応エンティティ Bean と読み込み専用エンティティ Bean の 2 種類があります。
ホームで読み書き対応エンティティ Bean が検索または作成される場合は、ローカル サーバでインスタンスが取得され、そのサーバに固定されたスタブが返されます。ロード バランシングとフェイルオーバはホームのレベルでのみ行われます。クラスタにはエンティティ Bean の複数のインスタンスが存在する可能性があるため、各インスタンスは各トランザクションの前にデータベースから読み込まれ、各コミットで書き込まれなければなりません。
エンティティ Bean と EJB ハンドルのフェイルオーバは、クラスタ アドレスの指定方法に依存します。「クラスタ アドレス」で説明しているように、クラスタ アドレスは明示的に定義することも、WebLogic Server によって自動的に生成することもできます。クラスタ アドレスを明示的に定義する場合は、クラスタ内のすべてのサーバ インスタンスだけにマップされる DNS 名として指定する必要があります。クラスタの DNS 名は、クラスタに属していないサーバ インスタンスに対応しないようにします。
WebLogic RMI には、クラスタ化されたリモート オブジェクトをビルドするための特殊な拡張機能があります。それらの拡張機能は、EJB のセクションで説明されているレプリカ対応スタブをビルドするために使用します。クラスタでの RMI の使用に関する詳細については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI Features」を参照してください。
WebLogic Server クラスタで使用する EJB をプログラムする場合は、この節の解説を参照して、クラスタ内での各種の EJB の機能について理解します。EJB のデプロイメント記述子でクラスタ化を有効にします。クラスタ化用の XML デプロイメント要素については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」で説明しています。
EJB またはカスタム RMI オブジェクトを開発する場合は、『WebLogic JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照して、クラスタ化されたオブジェクトを JNDI ツリーにバインドする実装について理解してください。
クラスタ化されたオブジェクトが多重呼び出し不変でない場合でも、WebLogic Server は、ConnectException
または MarshalException
が発生したときに自動フェイルオーバを実行します。いずれの例外もオブジェクトが変更されないことを示しているため、別のインスタンスにフェイルオーバすることでデータの矛盾が起こる危険性はありません。
WebLogic Server クラスタでは、ほとんどのサービスがクラスタ内のすべてのサーバ インスタンスに均一にデプロイされます。これにより、サーバ間の透過的なフェイルオーバが可能になります。対照的に、JMS や JTA トランザクション回復システムなどの「固定サービス」はクラスタ内の個々のサーバ インスタンスを対象にします。こうしたサービスのために、WebLogic Server では、フェイルオーバではなく移行を使用する障害からの回復がサポートされています。
以前のリリースの WebLogic Server では、JMS サーバや JTA トランザクション回復システムは、ホストとなるサーバ インスタンスで障害が発生した場合に手動で移行できました。この機能は引き続きサポートされています。「サービスの移行」を参照してください。
WebLogic Server 9.0 には、JMS や JTA トランザクション システムの可用性を高めるための新しい機能 (「移行可能なサーバ」) が用意されています。移行可能なサーバは、サービスレベルではなく、サーバレベルで自動または手動で移行できます。
注意 : サーバレベルの移行は、サービスレベルの移行に取って代わるものです。サービスレベルの移行とサーバレベルの移行は、組み合わせて使用することを目的としたものではありません。クラスタ内で個々のサービスを移行する場合は、サーバ インスタンス全体を移行しないでください。
移行可能なサーバとは、それがホストするすべてのサービスとともにそのまま全部移行する、クラスタ化されたサーバ インスタンスのことです。移行可能なサーバは、JMS サーバや JTA トランザクション回復サーバなどの固定サービスをホストすることを目的としたものですが、クラスタ化可能なサービスもホストできます。移行可能なサーバ上で実行されるすべてのサービスには高可用性が備わっています。
移行可能なサーバが何らかの理由 (ハング、ネットワーク接続の消失、ホスト マシンの障害など) で使用できなくなると、自動的に移行が行われます。障害が発生した場合、移行可能なサーバは、可能であれば同じマシン上で自動的に再起動されます。障害が発生した同じマシン上で再起動できないときは、別のマシンに移行されます。また、管理者は手動でサーバ インスタンスの移行を開始することもできます。
クラスタ内の管理対象サーバに対してサーバの移行をコンフィグレーションするには、以下のタスクを行います。
移行可能なサーバには、それぞれ浮動 IP アドレスを割り当てる必要があります。この IP アドレスは、物理的なマシンが変わってもサーバを追跡します。浮動 IP アドレスが割り当てられるすべてのサーバで、AutoMigrationEnabled
を true に設定する必要もあります。
注意 : サーバの移行は、SSH バージョンのノード マネージャを使用する場合にのみサポートされます。
サーバの移行でのノード マネージャの使用に関する一般的な情報については、「サーバの移行におけるノード マネージャの役割」を参照してください。
データベースは信頼性のあるものでなければなりません。サーバ インスタンスの信頼性は、このデータベースの信頼性で決まります。実験的な目的で使用する場合は、通常のデータベースで十分です。プロダクション環境で使用する場合は、高可用性データベースしかお勧めできません。データベースが停止すると、すべての移行可能なサーバが自身を停止します。
次のデータベース スキーマを使用して、データベースにリース テーブルを作成します。
CREATE TABLE ACTIVE (
SERVER VARCHAR2(50) NOT NULL,
INSTANCE VARCHAR2(100) NOT NULL,
DOMAINNAME VARCHAR2(50) NOT NULL,
CLUSTERNAME VARCHAR2(50) NOT NULL,
TIMEOUT DATE,
PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME));
CREATE TABLE ACTIVE_MT (
SERVER VARCHAR2(50) NOT NULL,
HOSTMACHINE VARCHAR2(200) NOT NULL,
DOMAINNAME VARCHAR2(50) NOT NULL,
CLUSTERNAME VARCHAR2(50) NOT NULL,
PRIMARY KEY (SERVER, DOMAINNAME, CLUSTERNAME));
DataSourceForAutomaticMigration
をこのデータ ソースに設定してください。注意 : サーバの移行では、XA データ ソースはサポートされていません。
JDBC データ ソースの作成の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
wlsifconfig.sh
、wlscontrol.sh
、および nodemanager.domains
が、使用するマシンの PATH に含まれていることを確認してください。.sh
ファイルは $BEA_HOME/weblogic90b/common/bin
にあり、nodemanager.domains
は $BEA_HOME/weblogic90b/common/nodemanager
にあります。ssh/rsh machine_A
」を使用して (同様にマシン A から「ssh/rsh machine_B」を使用して) シェル プロンプトにアクセスできる必要があります。注意 : シェルが対話型である場合は、ログイン スクリプト (.cshrc、.profile、.login など) がシェル プロファイルからのメッセージのみをエコーすることを確認してください。WebLogic Server は、ssh コマンドを使用してログインし、server.state ファイルの内容をエコーします。この出力の最初の行だけがサーバの状態の判別に使用されます。
サーバの移行プロセスでは、サービスは移行されますが、障害の発生時に進行中だった作業に関連付けられたステート情報は移行されません。
高可用性を確保するには、こうした情報を移行後にサーバ インスタンスやそれがホストするサービスで使用できるようにすることが重要です。そうしないと、障害の発生時に進行中だった作業に関するデータが失われてしまうおそれがあります。移行可能なサーバによって保持されるステート情報 (トランザクション ログに格納されるデータなど) は、移行可能なサーバで障害が発生した場合にその移行先となる可能性のあるすべてのマシンからアクセスできる共有ストレージ システムに格納する必要があります。高い信頼性を実現するために、ストレージ エリア ネットワーク (SAN) などの、高可用性の備わっている共有ストレージ ソリューションを使用してください。
さらに、移行可能なサーバの状態とそれらが使用可能かどうかの追跡に使用されるリース テーブル (以下の節を参照) も高可用性データベースに格納する必要があります。
サーバの移行プロセスには、以下の WebLogic Server サービスおよびリソースが必要になります。
ノード マネージャの基本的な情報とノード マネージャが WebLogic Server 環境に組み込まれる仕組みについては、『サーバの起動と停止の管理』の「ノード マネージャを使用したサーバの制御」を参照してください。
以下の節では、移行可能なサーバを含むクラスタにおける主要なプロセスについて説明します。
図 6-10 移行可能なサーバのあるクラスタの起動に、移行可能なサーバを含むクラスタの起動時に発生するプロセスと通信を示します。
例のクラスタには 2 つの管理対象サーバが含まれており、それらは両方とも移行可能です。管理サーバと 2 つの管理対象サーバは、それぞれ別々のマシンで実行されています。4 つ目のマシンは、いずれかの移行可能なサーバで障害が発生した場合にバックアップとして使用できます。バックアップ マシンと移行可能なサーバが実行されている各マシンでは、ノード マネージャが実行されています。
以下は、図 6-10 に示されている、クラスタの起動時に発生する主要な手順です。
図 6-11 障害が発生したサーバの自動移行に、管理対象サーバ 2 をホストしているマシンで障害が発生した後の自動移行のプロセスを示します。
注意 : サーバのハングが原因で管理対象サーバ 2 のリースが期限切れになっていて、マシン C にはアクセスできる場合、クラスタ マスターはノード マネージャを使用してマシン C 上の管理対象サーバ 2 を再起動します。
移行する管理対象サーバのクライアントでは、移行中にサービスの短い中断が発生するおそれがあります。その場合、再接続が必要になることもあります。Solaris および Linux オペレーティング システムでは、ifconfig
コマンドを使用して再接続を行うことができます。移行されたサーバのクライアントは、サーバの移行先の特定のマシンを認識する必要はありません。
サーバの移行元だったマシンが再び使用可能になった場合に行う、移行プロセスの逆戻し (サーバ インスタンスを元のホスト マシンに移行して戻すこと) は、フェイルバックと呼ばれます。WebLogic Server ではフェイルバックのプロセスは自動化されていません。管理者は、サーバ インスタンスを元のホストに手動で戻すことでフェイルバックを実行できます。
図 6-12 手動によるサーバの移行に、管理者が移行可能なサーバを手動で移行するときに発生するプロセスと通信を示します。
以下に、移行可能なサーバを含むクラスタでの管理サーバの動作を示します。
さらに管理サーバには、管理者によって発行されたコンフィグレーションの更新の保持、ドメインの実行時情報の表示などの、ドメイン内の移行可能なサーバも含めた通常のドメイン管理機能があります。
移行可能なサーバとは、移行可能としてコンフィグレーションされている、クラスタ化された管理対象サーバのことです。以下に、移行可能なサーバの主要な動作を示します。
デフォルトでは、移行可能なサーバは 30,000 ミリ秒ごとにリースを更新します。このデフォルト値は、以下の 2 つのコンフィグレーション可能な ServerMBean
プロパティ値を掛け合わせた値です。
System.exit
を使用して、自身をできるだけ迅速に終了する。この場合、リース テーブルにはそのサーバ インスタンスの行が引き続き格納されます。この動作と自動移行の関連については、「サーバの移行におけるクラスタ マスターの役割」を参照してください。ノード マネージャの使用は、サーバの移行に不可欠です。ホストとなる (またはホストとなる予定の) 各マシン上で実行されなければなりません。
ノード マネージャは、以下のようにサーバの移行を支援します。
Administration Console から管理対象サーバの起動を開始すると、管理サーバがノード マネージャを使用してそのサーバ インスタンスを起動します。ノード マネージャを呼び出して、スタンドアロンのノード マネージャ クライアントを使用してサーバ インスタンスを起動することもできます。ただし、起動する管理対象サーバが自身のコンフィグレーションを取得するために管理サーバが使用可能になっていなければなりません。
移行可能なサーバを含むクラスタでは、1 つのサーバ インスタンスがクラスタ マスターとして機能します。その役割はサーバの移行プロセスを調整することです。クラスタ内のどのサーバ インスタンスもクラスタ マスターになることができます。移行可能なサーバを含むクラスタの起動時に、クラスタに参加した最初のサーバがクラスタ マスターになり、クラスタ マネージャ サービスを起動します。クラスタに移行可能なサーバが 1 つも含まれない場合はクラスタ マネージャは不要です。クラスタ マスター サービスは起動されません。クラスタ マスターが存在しなくてもサーバの移行は可能ですが、移行可能なサーバは動作を継続できません。以下に、クラスタ マスターの主要な機能を示します。
ClusterMBean
の FencingGracePeriodMillis
で指定された期間、待機する。その後、リースが期限切れになっている移行可能なサーバをホストするマシン上でノード マネージャ プロセスを呼び出してその移行可能なサーバを再起動しようとします。移行可能なサーバをホストできるマシンのリストは、2 つのレベル (クラスタ全体用と個々の移行可能なサーバ用) でコンフィグレーションできます。両方のレベルのマシン リストを定義できます。少なくとも一方のレベルのマシン リストを定義する必要があります。
WebLogic Server では、JMS サーバおよび JTA トランザクション回復サービスのサービスレベルの移行がサポートされています。これらのサービスはクラスタの内部であるサーバから別にサーバに移すことができるため、このマニュアルではこれらのサービスを「移行可能サービス」と呼びます。JMS については、単一の分散送り先セットの一部として複数の物理送り先 (キューとトピック) をコンフィグレーションできるため、単独の WebLogic Server で障害が発生した場合のサービスの継続可能性も改善されています。
注意 : WebLogic Server 9.0 では、サーバレベルの移行、つまり、サーバ インスタンスのそのまま全部の移行もサポートされています。サーバ インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。この機能については、「サーバの移行」を参照してください。
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 の両方に共通する移行可能対象として同じサーバ群を選択し、両方のサービスが確実にクラスタ内の同じサーバ上に配置されるようにすることもできます。
JDBC は、クライアントと DBMS 間の高度にステートフルなプロトコルです。JDBC では、DBMS 接続とトランザクションのステートが、DBMS プロセスとクライアント (ドライバ) の間のソケットに直接関連付けられます。このため、接続のフェイルオーバはサポートされません。WebLogic Server インスタンスが消滅すると、そのインスタンスで管理していた JDBC 接続も消滅し、DBMS は処理中のトランザクションをロールバックします。関連するアプリケーションは、現在のトランザクションを最初から始める必要があります。切断された接続に関連付けられているすべての JDBC 接続も切断されます。クラスタ化された JDBC では、簡単に再接続できます。外部クライアント アプリケーションの WebLogic データ ソースはクラスタ対応なので、接続をホストしていたサーバ インスタンスで障害が発生した場合でも、クライアントは他の接続を要求できます。
データベース インスタンスをすでにレプリケートし、同期させている場合には、JDBC マルチ データ ソースを使用してデータベースのフェイルオーバをサポートできます。その場合、データ ソースが存在しないか、またはデータ ソースからのデータベース接続がダウンしたために、クライアントがマルチ データ ソース内のあるデータ ソースから接続を取得できない場合でも、WebLogic Server は、データ ソースのリストの次のデータ ソースから接続を取得しようとします。
JDBC オブジェクトのクラスタ化の手順については、「クラスタ化された JDBC をコンフィグレーションする」を参照してください。
注意 : 予約時に接続をテストするように、マルチ データ ソースに割り当てられたデータ ソースをコンフィグレーションする必要があります。これは、データ ソースの接続が良好かどうかを確認し、マルチ データ ソースがリスト内の次のデータ ソースにフェイルオーバするタイミングを認識する唯一の方法です。
![]() ![]() |
![]() |
![]() |