WebLogic Server クラスタ ユーザーズ ガイド
|
 |
 |
|
クラスタが高可用性を提供するためには、サービスの障害からの回復が可能でなければなりません。この章の以下の節では、WebLogic Server でクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバ方式の概要をオブジェクトのタイプ別に示します。
クラスタ内の WebLogic Server インスタンスは、以下のものをモニタすることで、自身のピア サーバ インスタンスの障害を検出します。
WebLogic Server インスタンスは、障害を直ちに検出するために、ピア サーバ インスタンス間で IP ソケットが使用されているかどうかをモニタします。サーバがクラスタ内のピアのいずれかに接続し、ソケットを使ってデータ転送を始めた場合、そのソケットが突然クローズされると、ピア サーバが「エラー」としてマークされ、その関連サービスが JNDI ネーミング ツリーから削除されます。
クラスタ化されたサーバ インスタンスがピア ツー ピア通信用にソケットをオープンしていない場合、障害が発生したサーバは WebLogic Server のハートビートによって検出できます。クラスタ内のすべてのサーバ インスタンスはマルチキャストを使用して、定期的なサーバ ハートビート メッセージを他のクラスタ メンバーにブロードキャストします。個々のハートビート メッセージには、メッセージの送信元のサーバを一意に識別するデータが入っています。サーバは、自身のハートビート メッセージを 10 秒間隔で定期的にブロードキャストします。同時に、クラスタ内の各サーバはマルチキャスト アドレスをモニタして、すべてのピア サーバのハートビート メッセージが送信されているかどうかを確認します。
マルチキャスト アドレスをモニタ中のサーバにピア サーバからのハートビート メッセージが 3 回届かなかった場合 (つまり、モニタする側のサーバが他のサーバから 30 秒以上ハートビートを受信していない場合)、モニタする側のサーバはピア サーバを「エラー」としてマークします。次に、必要であればローカルの JNDI ツリーを更新して、障害が発生したサーバでホストされていたサービスを削除します。
このようにして、サーバは、ピア ツー ピア通信でソケットがオープンされていない場合でも、障害を検出できます。
注意 : WebLogic Server での IP ソケットとマルチキャスト通信の使用について、詳しくは「クラスタでの WebLogic Server の通信」を参照してください。
WebLogic プロキシ プラグインと組み合わせて Web サーバを利用しているクラスタでは、クライアントから意識されない形でプロキシ プラグインがフェイルオーバを処理します。サーバに障害が発生した場合、プラグインはセカンダリ サーバ上にレプリケートされている HTTP セッション ステートを探し、その結果に従ってクライアントからのリクエストをリダイレクトします。
サポート対象のハードウェア ロード バランシング ソリューションを使用しているクラスタの場合、ロード バランシング ハードウェアは、WebLogic Server クラスタ内で使用可能な任意のサーバにクライアントのリクエストを単純にリダイレクトします。クラスタ自身は、クライアントの HTTP セッション ステートのレプリカをクラスタ内のセカンダリ サーバから取得します。
WebLogic Server では、サーブレットと JSP の HTTP セッション ステートの自動フェイルオーバを、セッション ステートをメモリ内にレプリケートすることによって実現しています。WebLogic Server はクライアントが最初に接続するサーバ上にプライマリ セッション ステートを作成し、クラスタ内の別の WebLogic Server インスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。サーバ インスタンス間でセッション ステートをコピーするプロセスは、インメモリ レプリケーションと呼ばれます。
注意 : WebLogic Server では、ファイルベースまたは JDBC ベースの永続性メカニズムを利用して、サーブレットまたは JSP の HTTP セッション ステートを維持することもできます。それぞれの永続性メカニズムの詳細については、『WebLogic Server Web アプリケーションの開発』の「セッションの永続性のコンフィグレーション」を参照してください。
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 つの情報を組み合わせて判断されます。次の表は、クラスタ内のサーバの相対的なランキングを示しています。
表 5-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 クラスタに転送されます。
図 5-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 アプリケーションの開発』の「クッキーに代わる URL 書き換えの使用」を参照してください。
プライマリ サーバで障害が発生すると、HttpClusterServlet はクライアントのクッキー情報を利用して、セッション ステートのレプリカのホストであるセカンダリ WebLogic Server の場所を確認します。HttpClusterServlet は、クライアントの次の HTTP リクエストを自動的にセカンダリ サーバにリダイレクトします。フェイルオーバは、クライアントには意識されません。
障害の発生後は、WebLogic Server B がサーブレット セッション ステートのプライマリ サーバになり、新しいセカンダリ サーバが作成されます (前の例ではサーバ C)。HTTP 応答では、今後のフェイルオーバに備えて、新しいプライマリ サーバとセカンダリ サーバを反映するためにプロキシによってクライアントのクッキーが更新されます。
2 つのサーバで構成されるクラスタでは、クライアントはセカンダリ セッション ステートのホスト サーバに透過的にフェイルオーバされます。ただし、もう 1 つの WebLogic Server がクラスタで利用可能にならない限り、クライアントのセッション ステートのレプリケーションは継続されません。たとえば、元のプライマリ サーバが再起動されるか、ネットワークに再び接続されると、そのサーバはセカンダリ セッション ステートのホストとして使用されます。
ロード バランシング ハードウェアを経由したクライアントの直接アクセスを可能にするために、WebLogic Server のレプリケーション システムでは、クライアントがフェイルオーバ先のサーバとは無関係にセカンダリ セッション ステートを使用できます。WebLogic Server は、プライマリ サーバとセカンダリ サーバの位置を記録する手段としてクライアント側のクッキーまたは URL 書き換えを使用します。ただし、この情報はサーブレット セッション ステートの位置の履歴としてのみ使用されます。ロード バランシング ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバを能動的に見つける手段としてはクッキー情報を使用しません。
以下の節では、HTTP セッション ステートのレプリケーションをロード バランシング ハードウェアと組み合わせて使用する場合の、接続およびフェイルオーバのプロセスについて説明します。
次の図は、ロード バランサを通じてクラスタにアクセスしているクライアントの接続手順を示しています。
図 5-3 ロード バランシング ハードウェアを利用した接続
Web アプリケーションのクライアントがパブリックな IP アドレスを使用してサーブレットを要求する場合は、次のようなプロセスが行われます。
注意 : クッキーを無効にしているクライアントに対応するには、「URL 書き換えを利用したセッション レプリカの追跡」で説明しているように、WebLogic Server の URL 書き換え機能を有効にする必要があります。
クライアントのセッションの途中でサーバ A に障害が発生すると、次の図に示すように、そのクライアントによるサーバ A への次の接続リクエストは失敗します。
図 5-4 ロード バランシング ハードウェアを利用したフェイルオーバ
WebLogic Server C はクライアントのプライマリ セッション ステートの新しいホストになり、WebLogic Server B は引き続きセッション ステートのレプリカを保持します。プライマリ ホストとセカンダリ ホストに関するこの新しい情報は、クライアントのクッキーまたは URL 書き換えで再び更新されます。
クラスタ化される EJB と RMI のフェイルオーバは、オブジェクトのレプリカ対応スタブを使用して実現されます。クライアントがレプリカ対応スタブを通じて障害が発生したサービスに対して呼び出しを行うと、スタブはその障害を検出し、別のレプリカに対してその呼び出しを再試行します。
クラスタ化されたオブジェクトについては、オブジェクトが多重呼び出し不変の場合にだけ自動的なフェイルオーバが行われます。ただし、非多重呼び出し不変メソッドに対してフェイルオーバが行われることもあります。
メソッドを何回呼び出しても 1 回呼び出したときと効果に違いがなければ、オブジェクトは多重呼び出し不変となります。このことは、恒久的な副作用を持たないメソッドに関して常に当てはまります。副作用のあるメソッドは、多重呼び出し不変性に留意して作成する必要があります。
ここでショッピング カートに商品を追加するショッピング カード サービス呼び出し addItem() を考えてみます。クライアント C がこの呼び出しをサーバ S1 上のレプリカで行うものとします。S1 が呼び出しを受け取った後、呼び出しを C に返す前に、S1 がクラッシュしたとします。この時点では、商品がショッピング カートに追加されていますが、レプリカ対応スタブは例外を受け取っています。スタブがサーバ S2 でこのメソッドを再試行すれば、商品がショッピングカートに 2 回追加されることになります。この理由から、レプリカ対応スタブは、デフォルトでは、リクエストが送られた後、そのリクエストが返ってくるまでは、メソッドの再試行は行いません。この動作は、サービスを多重呼び出し不変としてマークすることで、オーバーライドできます。
WebLogic Server で非多重呼び出し不変メソッドに対するフェイルオーバが許可されるのは、基底の JVM によって以下の例外のいずれかが送出される場合のみです。
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 8.1 は、EJB ホーム インタフェースのサーバ アフィニティを提供する新しいロード バランシング アルゴリズムをサポートします。サーバ アフィニティ、およびロード バランシングとフェイルオーバに対するその影響については、「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」を参照してください。
EJBObject スタブは、クラスタ内の EJB の使用可能なレプリカを追跡します。
ホームでステートレス Bean が作成されると、Bean のデプロイ先となる、クラスタ内のすべてのサーバのリストを示す EJBObject スタブが返されます。ステートレス Bean ではステートが保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できます。スタブでは障害が起きたときに自動的にフェイルオーバを実行できます。スタブでは、Bean は自動的には多重呼び出し不変として扱われないので、あらゆる障害から自動的に回復することはありません。Bean が多重呼び出し不変メソッドを利用して記述されている場合は、そのことをデプロイメント記述子で示すことができ、そうすればあらゆる場合で自動フェイルオーバが有効になります。
注意 : WebLogic Server 8.1 では、新しいロード バランシング オプションでステートレス EJB リモート インタフェースのサーバ アフィニティが提供されます。サーバ アフィニティ、およびロード バランシングとフェイルオーバに対するその影響については、「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」を参照してください。
ステートフル サービスに対するメソッドレベルのフェイルオーバには、ステートのレプリケーションが必要です。WebLogic Server では、HTTP セッション ステートで使用されるものと同様のレプリケーション方式を使用して、プライマリ Bean インスタンスのステートをセカンダリ サーバ インスタンスにレプリケートすることで、この要件を満たします。
ホーム インタフェースはステートレス セッション Bean インスタンスを作成するときに、「レプリケーション グループの使用」で定義した同じルールを使用して、レプリケートされたステートをホストするためのセカンダリ インスタンスを選択します。ホーム インタフェースは、プライマリ Bean インスタンスの場所とレプリケートされた Bean ステートの場所のリストを示す EJBObject スタブをクライアントに返します。
次の図は、クラスタ化されたステートフル セッション EJB にクライアントがアクセスする状況を示しています。
図 5-5 ステートフル セッション EJB にアクセスするクライアント
クライアントによって EJB のステートが変更されると、ステートの変更部分がセカンダリ サーバのインスタンスにレプリケートされます。トランザクションに関係している EJB の場合、レプリケーションはトランザクションのコミットの直後に行われます。トランザクションに関係していない EJB の場合、レプリケーションは各メソッド呼び出しの後に行われます。
両方の場合で、EJB のステートの実際の変更部分だけがセカンダリ サーバにレプリケートされます。このため、レプリケーション プロセスに伴うオーバーヘッドが最小限に抑えられます。
注意 : EJB 仕様で説明されているように、ステートフル EJB の実際のステートはトランザクション非対応です。可能性は低いですが、EJB の現在のステートが失われることもあり得ます。たとえば、EJB の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた EJB のステートにフェイルオーバされます。どのような障害が起きても EJB のステートを維持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用してください。
プライマリ サーバで障害が起きると、以降のリクエストはクライアントの EJB スタブによって自動的にセカンダリ WebLogic Server インスタンスにリダイレクトされます。この時点で、レプリケートされたステート データを使用してセカンダリ サーバで新しい EJB インスタンスが作成され、セカンダリ サーバで処理が継続されます。
フェイルオーバの後、WebLogic Server では EJB セッション ステートをレプリケートする新しいセカンダリ サーバが選択されます (クラスタ内に利用可能な別のサーバがある場合)。新しいプライマリとセカンダリのサーバ インスタンスの位置は、次に示すように、次のメソッド呼び出しのときにクライアントのレプリカ対応スタブで自動的に更新されます。
図 5-6 フェイルオーバ後にレプリカ対応スタブが更新される
エンティティ Bean には、読み書き対応エンティティ Bean と読み込み専用エンティティ Bean の 2 種類があります。
ホームで読み書き対応エンティティ Bean が検索または作成される場合は、ローカル サーバでインスタンスが取得され、そのサーバに固定されたスタブが返されます。ロード バランシングとフェイルオーバはホームのレベルでのみ行われます。クラスタにはエンティティ Bean の複数のインスタンスが存在する可能性があるため、各インスタンスは各トランザクションの前にデータベースから読み込まれ、各コミットで書き込まれなければなりません。
エンティティ Bean と EJB ハンドルのフェイルオーバでは、クラスタ アドレスに対して、クラスタ内のすべてのサーバ インスタンスだけにマップされる DNS 名を指定する必要があります。クラスタの DNS 名は、クラスタに属していないサーバ インスタンスに対応しないようにします。
WebLogic RMI には、クラスタ化されたリモート オブジェクトをビルドするための特殊な拡張機能があります。それらの拡張機能は、EJB のセクションで説明されているレプリカ対応スタブをビルドするために使用します。クラスタでの RMI の使用に関する詳細については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI の機能とガイドライン」を参照してください。
WebLogic Server クラスタで使用する EJB をプログラムする場合は、この節の解説を参照して、クラスタ内での各種の EJB の機能について理解します。EJB のデプロイメント記述子でクラスタ化を有効にします。クラスタ化用の XML デプロイメント要素については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」で説明しています。
EJB またはカスタム RMI オブジェクトを開発する場合は、『WebLogic JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照して、クラスタ化されたオブジェクトを JNDI ツリーにバインドする実装について理解してください。
クラスタ化されたオブジェクトが多重呼び出し不変でない場合でも、WebLogic Server は、ConnectException または MarshalException が発生したときに自動フェイルオーバを実行します。いずれの例外もオブジェクトが変更されないことを示しているため、別のインスタンスにフェイルオーバすることでデータの矛盾が起こる危険性はありません。
HTTP セッション ステートと EJB については、WebLogic Server クラスタはオブジェクトまたはサービスをクラスタ内の冗長サーバ上に複製することによって、高可用性とフェイルオーバを実現します。一方、JMS サーバや JTA トランザクション回復サービスなどの一部のサービスは、クラスタ内で動作しているサービスのアクティブなインスタンスが常に 1 つだけ存在するという前提のもとで設計されています。これらのタイプのサービスは、同時に 1 つのサーバ インスタンス上でのみアクティブな状態を保つため、「固定」サービスと呼ばれます。
WebLogic Server では、あるサーバ インスタンスからクラスタ内の別のインスタンスに管理者の手で固定サービスを移行することができます。これは、サーバ インスタンスの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバで障害が発生した場合に冗長サーバ上でサービスを速やかに再開できるため、クラスタ内の固定サービスの可用性が向上します。
このリリースでは、JMS サーバと JTA トランザクション回復サービスの移行だけが可能です。これらのサービスはクラスタの内部であるサーバから別にサーバに移すことができるため、このマニュアルではこれらのサービスを「移行可能サービス」と呼びます。
警告 : グローバル トランザクションに単独で参加している JMS サービスを、保留中のトランザクションが残らないように移行するには、JMS サービスと JTA サービスの両方を移行する必要があります。その場合、JMS サービスを移行してから JTA サービスを移行しなければなりません。
このリリースの JMS では、分散送り先も使用できます。それにより、単一の分散送り先セットの一部として複数のスタンドアロンの送り先 (キューとトピック) をコンフィグレーションできるため、単独の WebLogic Server で障害が発生した場合のサービスの継続可能性が改善されています。分散送り先の詳細については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
ただし、このリリースの 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 をコンフィグレーションする」を参照してください。
注意 : すべての接続が使用中であるプールに対してクライアントが接続を要求した場合は、例外が生成され、WebLogic Server は他のプールから接続を取得しようとしなくなります。接続プール内の接続数を増やすと、この問題に対処できます。
予約時に接続をテストするように、マルチプールに割り当てられた接続プールをコンフィグレーションする必要があります。これは、プールが接続が良好かどうかを確認し、マルチプールがリスト内の次のプールにフェイルオーバするタイミングを認識する唯一の方法です。
|
|
|
