| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Server クラスタ ユーザーズ ガイド > クラスタのフェイルオーバとレプリケーション |
|
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 セッション ステートを維持することもできます。それぞれの永続性メカニズムの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「セッション永続性のコンフィグレーション」を参照してください。
HTTP セッション ステートのレプリケーションに関する必要条件
HTTP セッション ステートのインメモリ レプリケーションを利用するためには、WebLogic プロキシ プラグインのコンフィグレーションが一致した Web サーバの集合、またはロード バランシング ハードウェアのどちらかを使用して WebLogic Server クラスタにアクセスする必要があります。
WebLogic プロキシ プラグインは、クラスタ化されたサーブレットまたは JSP のホストである WebLogic Server インスタンスのリストを維持し、単純なラウンドロビン方式を使用して HTTP リクエストをそれらのインスタンスに転送します。このプラグインは、WebLogic Server インスタンスで障害が発生した場合に、クライアントの HTTP セッション ステートのレプリカを見つけるために必要なロジックも備えています。
HTTP セッション ステートのインメモリ レプリケーションは、以下の Web サーバおよびプロキシ ソフトウェアでサポートされています。
プロキシ プラグインの設定方法については、プロキシ プラグインをコンフィグレーションするを参照してください。
プロキシ プラグインではなくロード バランシング ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなクッキーの永続性メカニズムと、SSL の永続性にハードウェアが対応している必要があります。これらの必要条件の詳細については、ロード バランサのコンフィグレーション要件を参照してください。ロード バランサの設定手順については、パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションするを参照してください。
クラスタ化されるサーブレットおよび JSP のプログラミング上の考慮事項
この節では、クラスタ環境にデプロイするサーブレットおよび 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 つの情報を組み合わせて判断されます。次の表は、クラスタ内のサーバの相対的なランキングを示しています。
プライマリ WebLogic Server は、このルールに従ってクラスタ内のその他のサーバをランク付けし、最もランクの高いサーバをセカンダリ セッション ステートのホストとして選択します。たとえば、次の図は地理的な分類に基づいてコンフィグレーションされたレプリケーション グループを示しています。
この例では、サーバ A、B、および C は「Headquarters」というレプリケーション グループのメンバーであり、「Crosstown」という優先的なセカンダリ レプリケーション グループを使用します。逆に、サーバ X、Y、および Z は「Crosstown」というグループのメンバーであり、「Headquarters」という優先的なセカンダリ レプリケーション グループを使用します。サーバ A、B、および X は、「sardina」という同じマシン上にあります。
クライアントがサーバ A に接続し、HTTP セッション ステートを作成する場合の動作は次のようになります。
レプリケーション グループ内のサーバのメンバーシップをコンフィグレーションする手順、あるいはサーバの優先セカンダリ レプリケーション グループを割り当てる手順については、レプリケーション グループをコンフィグレーションするを参照してください。
クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス
この節では、クラスタ化されたサーブレットおよび 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 書き換えを有効にする方法については、『Web アプリケーションのアセンブルとコンフィグレーション』の「URL 書き換えの使い方」を参照してください。
プライマリ サーバで障害が発生すると、HttpClusterServlet はクライアントのクッキー情報を利用して、セッション ステートのレプリカのホストであるセカンダリ WebLogic Server の位置を確認します。HttpClusterServlet は、クライアントの次の HTTP リクエストを自動的にセカンダリ サーバにリダイレクトします。 フェイルオーバは、クライアントには意識されません。
障害の発生後は、WebLogic Server B がサーブレット セッション ステートのプライマリ サーバになり、新しいセカンダリ サーバが作成されます (前の例ではサーバ C)。HTTP 応答では、今後のフェイルオーバに備えて、新しいプライマリ サーバとセカンダリ サーバを反映するためにプロキシによってクライアントのクッキーが更新されます。
2 つのサーバで構成されるクラスタでは、クライアントはセカンダリ セッション ステートのホスト サーバに透過的にフェイルオーバされます。ただし、もう 1 つの WebLogic Server がクラスタで利用可能にならない限り、クライアントのセッション ステートのレプリケーションは継続されません。たとえば、元のプライマリ サーバが再起動されるか、ネットワークに再び接続されると、そのサーバはセカンダリ セッション ステートのホストとして使用されます。
クラスタ化されたサーブレットと JSP へのロード バランシング ハードウェアを利用したアクセス
ロード バランシング ハードウェアを経由したクライアントの直接アクセスを可能にするために、WebLogic Server のレプリケーション システムでは、クライアントがフェイルオーバ先のサーバとは無関係にセカンダリ セッション ステートを使用できます。WebLogic Server は、プライマリ サーバとセカンダリ サーバの位置を記録する手段としてクライアント側のクッキーまたは URL 書き換えを使用します。ただし、この情報はサーブレット セッション ステートの位置の履歴としてのみ使用されます。ロード バランシング ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバを能動的に見つける手段としてはクッキー情報を使用しません。
以下の節では、HTTP セッション ステートのレプリケーションをロード バランシング ハードウェアと組み合わせて使用する場合の、接続およびフェイルオーバのプロセスについて説明します。
次の図は、ロード バランサを通じてクラスタにアクセスしているクライアントの接続手順を示しています。
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 エンタープライズ JavaBeans プログラマーズ ガイド』の「クラスタ内のセッション EJB」を参照してください。
EJB または RMI オブジェクトをクラスタ化すると、オブジェクトのインスタンスがクラスタ内のすべての WebLogic Server にデプロイされます。クライアントでは、オブジェクトのどのインスタンスを呼び出すのかを選択できます。オブジェクトの各インスタンスはレプリカと呼ばれます。
WebLogic Server では、レプリカ対応スタブという技術を土台としてオブジェクトのクラスタ化を実現しています。クラスタ化をサポート (デプロイメント記述子で定義) する EJB をコンパイルすると、ejbc によって EJB のインタフェースが rmic コンパイラに渡されてその Bean のレプリカ対応スタブが生成されます。RMI オブジェクトの場合は、rmic に渡されるコマンドライン オプションを使用して明示的にレプリカ対応スタブを生成します。 詳細については、『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI コンパイラ」を参照してください。
レプリカ対応スタブは、呼び出し側では通常の RMI スタブとして認識されます。しかしながら、スタブは 1 つのオブジェクトではなく複数のレプリカを表します。レプリカ対応スタブは、オブジェクトがデプロイされるすべての WebLogic Server インスタンスで EJB クラスまたは RMI クラスを見つけるためのロジックを備えています。クラスタ対応の EJB オブジェクトまたは RMI オブジェクトをデプロイすると、その実装は JNDI ツリーにバインドされます。クラスタワイドの JNDI ネーミング サービスで説明されているように、クラスタ化された WebLogic Server インスタンスではそのオブジェクトを利用できるすべてのサーバをリストするために JNDI ツリーを更新することができます。クライアントがクラスタ化されたオブジェクトにアクセスすると、その実装はクライアントに送信されるレプリカ対応スタブで置き換えられます。
スタブは、オブジェクトに対するメソッド呼び出しを負荷分散するためのロード バランシング アルゴリズム (呼び出しルーティング クラス) を備えています。呼び出しが行われるたびに、スタブではそのロード アルゴリズムを利用して呼び出すレプリカを選択できます。この機能により、呼び出し側からは意識されない方法でクラスタ全体でのロード バランシングが実現されます。呼び出しの途中でエラーが起きると、スタブによってその例外が横取りされ、別のレプリカで呼び出しが再試行されます。この機能により、同じように呼び出し側からは意識されないフェイルオーバが実現されます。
EJB は、2 つの異なったレプリカ対応スタブを生成できる点が通常の RMI オブジェクトと異なります。1 つは EJBHome インタフェースに対して、もう 1 つは EJBObject インタフェースに対して生成されます。つまり、EJB では以下の 2 段階でロード バランシングとフェイルオーバのメリットを実現できるのです。
以降の節では、EJB のタイプ別のクラスタ化サポートについて説明します。各タイプの EJB に対するクラスタ化の動作について、詳しくは『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「WebLogic Server クラスタにおける EJB」を参照してください。
すべての Bean ホームはクラスタ化可能です。Bean がサーバにデプロイされると、そのホームはクラスタワイドのネーミング サービスにバインドされます。ホームはクラスタ化可能なので、各サーバではそのホームのインスタンスを同じ名前でバインドできます。クライアントがこのホームをルックアップすると、そのクライアントでは Bean がデプロイされた各サーバ上のホームへの参照を持つレプリカ対応スタブが取得されます。create() または find() が呼び出されると、その呼び出しはレプリカ対応スタブによってレプリカの 1 つに転送されます。ホームのレプリカは、find() の結果を受信するか、またはそのサーバで Bean のインスタンスを作成します。
ホームでステートレス Bean が作成されると、Bean がデプロイされたどのサーバにでも呼び出しを転送できるレプリカ対応 EJBObject スタブが返されます。ステートレス Bean ではステートが保持されないので、スタブでは Bean のホストであるどのサーバにでも呼び出しを転送できます。また、Bean はクラスタ化されるので、スタブでは障害が起きたときに自動的にフェイルオーバを実行できます。スタブでは、Bean は自動的には多重呼び出し不変として扱われないので、あらゆる障害から自動的に回復することはありません。Bean が多重呼び出し不変メソッドを利用して記述されている場合は、そのことをデプロイメント記述子で示すことができ、そうすればあらゆる場合で自動フェイルオーバが有効になります。
あらゆる EJB の場合と同じように、クラスタ化されたステートフル セッション EJB でもレプリカ対応 EJBHome スタブが利用されます。ステートフル セッション EJB のレプリケーションを使用する場合、EJB ではそのプライマリ ステートとセカンダリ ステートの位置を保持するレプリカ対応 EJBObject スタブも利用されます。EJB のステートは、HTTP セッション ステートの場合と同様のレプリケーション方式で維持されます。ステートフル セッション EJB でのレプリケーションについては、次の節で説明します。
ステートフル セッション EJB に対して WebLogic Server で使用されるステート レプリケーションの方式は、HTTP セッション ステートのレプリケーションに使用されるものと似ています。クライアントで EJBObject スタブが作成されると、接続先の WebLogic Server インスタンスでは EJB のレプリケートされたステートのホストとなるセカンダリ サーバ インスタンスが自動的に選択されます。セカンダリ サーバ インスタンスは、レプリケーション グループを使用するで定義されているものと同じルールに従って選択されます。たとえば、レプリケートするステートフル セッション EJB データのホストとなるレプリケーション グループとして動作するように、WebLogic Server インスタンスの集合を定義できます。
クライアントでは、EJB のステートをホストするクラスタ内のプライマリ サーバとセカンダリ サーバの位置が記録されたレプリカ対応スタブが受信されます。次の図は、クラスタ化されたステートフル セッション EJB にクライアントがアクセスする状況を示しています。
図5-5 ステートフル セッション EJB にアクセスするクライアント
プライマリ サーバは、クライアントが対話する EJB の実際のインスタンスのホストとして機能します。セカンダリ サーバは、EJB のレプリケートされたステートのみを保持します。ステートのみなので、少しのメモリしか消費されません。セカンダリ サーバでは、フェイルオーバのとき以外は EJB の実際のインスタンスは作成されません。このため、セカンダリ サーバではリソースの使用が最小限に抑えられます。EJB ステートのレプリケートに備えて追加の EJB リソースをコンフィグレーションする必要はありません。
クライアントによって EJB のステートが変更されると、ステートの変更部分がセカンダリ サーバのインスタンスにレプリケートされます。トランザクションに関係している EJB の場合、レプリケーションはトランザクションのコミットの直後に行われます。トランザクションに関係していない EJB の場合、レプリケーションは各メソッド呼び出しの後に行われます。
両方の場合で、EJB のステートの実際の変更部分だけがセカンダリ サーバにレプリケートされます。このため、レプリケーション プロセスに伴うオーバーヘッドが最小限に抑えられます。
注意: EJB 仕様で説明されているように、ステートフル EJB の実際のステートはトランザクション非対応です。可能性は低いですが、EJB の現在のステートが失われることもあり得ます。たとえば、EJB の関与しているトランザクションがクライアントによってコミットされ、ステートの変更がレプリケートされる前にプライマリ サーバで障害が起きると、クライアントは以前に格納されていた EJB のステートにフェイルオーバされます。どのような障害が起きても EJB のステートを維持する必要がある場合は、ステートフル セッション EJB ではなくエンティティ EJB を使用してください。
プライマリ サーバで障害が起きると、以降のリクエストはクライアントの EJB スタブによって自動的にセカンダリ WebLogic Server インスタンスにリダイレクトされます。この時点で、レプリケートされたステート データを使用してセカンダリ サーバで新しい EJB インスタンスが作成され、セカンダリ サーバで処理が継続されます。
フェイルオーバの後、WebLogic Server では EJB セッション ステートをレプリケートする新しいセカンダリ サーバが選択されます (クラスタ内に利用可能な別のサーバがある場合)。新しいプライマリとセカンダリのサーバ インスタンスの位置は、次に示すように、次のメソッド呼び出しのときにクライアントのレプリカ対応スタブで自動的に更新されます。
エンティティ Bean には、読み書き対応エンティティと読み込み専用エンティティの 2 種類があります。
クラスタでの EJB の使用方法について、詳しくは『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「WebLogic Server EJB コンテナとサポートされるサービス」を参照してください。
エンティティ Bean および EJB ハンドルのフェイルオーバ
エンティティ Bean および EJB ハンドルのフェイルオーバでは、クラスタ内のすべてのサーバ インスタンスだけにマップされる DNS 名としてクラスタ アドレスを指定する必要があります。クラスタの DNS 名は、クラスタのメンバー以外のサーバ インスタンスにマップされません。
WebLogic RMI には、クラスタ化されたリモート オブジェクトをビルドするための特殊な拡張機能があります。それらの拡張機能は、EJB のセクションで説明されているレプリカ対応スタブをビルドするために使用します。クラスタでの RMI の使用方法について、詳しくは『WebLogic RMI プログラマーズ ガイド』の「WebLogic RMI の機能とガイドライン」を参照してください。
WebLogic Server クラスタで使用する EJB をプログラムする場合は、この節の解説と『WebLogic Server エンタープライズ JavaBeans プログラマーズ ガイド』の「WebLogic Server EJB コンテナとサポートされるサービス」を参照して、クラスタ内での各種の EJB の機能について理解します。EJB のデプロイメント記述子でクラスタ化を有効にします。クラスタ化用の XML デプロイメント要素については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「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 7.0 では、あるサーバ インスタンスからクラスタ内の別のインスタンスに管理者の手で固定サービスを移行することができます。 これは、サーバ インスタンスの障害への対応として、あるいは定期的な保守の一環として行います。この機能により、ホストのサーバで障害が発生した場合に冗長サーバ上でサービスを速やかに再開できるため、クラスタ内の固定サービスの可用性が向上します。
このリリースでは、JMS サーバと JTA トランザクション回復サービスの移行だけが可能です。これらのサービスはクラスタの内部であるサーバから別にサーバに移すことができるため、このマニュアルではこれらのサービスを移行可能サービスと呼びます。JMS については、単一の分散送り先セットの一部として複数の物理送り先 (キューとトピック) をコンフィグレーションできるため、単独の WebLogic Server で障害が発生した場合のサービスの継続可能性も改善されています。
注意: このリリースの WebLogic Server では、固定サービスの自動移行 (フェイルオーバ) を行うことはできません。固定サービスを手動で移行する方法については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic Server の障害からの回復」を参照してください。
クライアントは、移行対応の RMI スタブを使用してクラスタ内の移行可能サービスにアクセスします。RMI スタブは、各時点でどのサーバが固定サービスのホストとなっているかを追跡し、それに従ってクライアントからのリクエストを転送します。たとえば、クライアントが最初に固定サービスにアクセスしたとき、スタブはクライアントのリクエストを、その時点でサービスのホストとなっているクラスタ内のサーバ インスタンスに転送します。クライアントからの次のリクエストまでにサービスが別の WebLogic Server に移動している場合、スタブはそのリクエストを最新のホスト サーバに透過的にリダイレクトします。
JMS サーバや JTA トランザクション回復サービスがクラスタ内に位置し、コンフィグレーションで移行が有効にされているとき、WebLogic Server 7.0 はそれらのサービスに対する移行対応の 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 は他のプールから接続を取得しようとしなくなります。接続プール内の接続数を増やすと、この問題に対処できます。
予約時に接続をテストするように、マルチプールに割り当てられた接続プールをコンフィグレーションする必要があります。これは、プールが接続が良好かどうかを確認し、マルチプールがリスト内の次のプールにフェイルオーバするタイミングを認識する唯一の方法です
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
