| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 12cリリース1(12.1.1) B65915-02 |
|
 前 |
 次 |
この章では、WebLogic Serverでクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバー方式の概要をオブジェクトのタイプ別に示します。
この章の内容は以下のとおりです。
ここでは、アプリケーション・レベルでのフェイルオーバーとレプリケーションについて重点的に説明します。WebLogic Serverでは、障害発生後にサーバー・インスタンスやサービスを自動的に移行することも可能です。詳細は、第7章「サーバー全体の移行」を参照してください。
クラスタ内のWebLogic Serverインスタンスは、次のものをモニターすることで、自身のピア・サーバー・インスタンスの障害を検出します。
ピア・サーバーへのソケット接続
サーバーの定期的なハートビート・メッセージ
WebLogic Serverインスタンスは、障害を直ちに検出するために、ピア・サーバー・インスタンス間でIPソケットが使用されているかどうかをモニターします。サーバーがクラスタ内のピアのいずれかに接続し、ソケットを使ってデータ転送を始めた場合、そのソケットが突然クローズされると、ピア・サーバーが「エラー」としてマークされ、その関連サービスがJNDIネーミング・ツリーから削除されます。
クラスタ化サーバー・インスタンスがピア・ツー・ピア通信用にソケットをオープンしていない場合、障害が発生したサーバーはWebLogic Serverのハートビートによって検出できます。クラスタ内のすべてのサーバー・インスタンスはマルチキャストまたはユニキャストを使用して、定期的なサーバー・ハートビート・メッセージを他のクラスタ・メンバーにブロードキャストします。
|
注意: 以前のバージョンのWebLogic Serverとの互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
個々のハートビート・メッセージには、メッセージの送信元のサーバーを一意に識別するデータが入っています。サーバーは、自身のハートビート・メッセージを10秒間隔で定期的にブロードキャストします。同時に、クラスタ内の各サーバーはマルチキャスト・アドレスまたはユニキャスト・アドレスをモニターして、すべてのピア・サーバーのハートビート・メッセージが送信されているかどうかを確認します。
|
注意: 以前のバージョンのWebLogic Serverとの互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
マルチキャスト・アドレスまたはユニキャスト・アドレスをモニター中のサーバーにピア・サーバーからのハートビート・メッセージが3回届かなかった場合(たとえば、モニターする側のサーバーが他のサーバーから30秒以上ハートビートを受信していない場合)、モニターする側のサーバーはピア・サーバーを「エラー」としてマークします。次に、必要であればローカルのJNDIツリーを更新して、障害が発生したサーバーでホストされていたサービスを削除します。
このようにして、サーバーは、ピア・ツー・ピア通信でソケットがオープンされていない場合でも、障害を検出できます。
クラスタ内でのサーブレットとJSPの自動レプリケーションとフェイルオーバーをサポートするために、WebLogic ServerではHTTPセッション状態を保持する次の2種類のメカニズムがサポートされています。
ハードウェア・ロード・バランサ
サポート対象のハードウェア・ロード・バランシング・ソリューションを使用しているクラスタの場合、ロード・バランシング・ハードウェアは、WebLogic Serverクラスタ内で使用可能な任意のサーバーにクライアントのリクエストを単純にリダイレクトします。クラスタ自身は、クライアントのHTTPセッション状態のレプリカをクラスタ内のセカンダリ・サーバーから取得します。
プロキシ・プラグイン
WebLogicプロキシ・プラグインと組み合わせてWebサーバーを利用しているクラスタでは、クライアントから意識されない形でプロキシ・プラグインがフェイルオーバーを処理します。サーバーで障害が発生した場合、プラグインはセカンダリ・サーバー上にレプリケートされているHTTPセッション状態を探し、その結果に従ってクライアントからのリクエストをリダイレクトします。
この項では、次のトピックを取り上げます。
WebLogic Serverでは、複数のクラスタ間でHTTPセッション状態をレプリケートするために次の2つの方法が使用されます。
インメモリー・レプリケーション
WebLogic Serverは、インメモリー・レプリケーションを使用してセッション状態をサーバー・インスタンス間でコピーします。プライマリ・サーバーはクライアントが最初に接続するサーバー上にプライマリ・セッション状態を作成し、クラスタ内の別のWebLogic Serverインスタンス上に予備のレプリカを作成します。サーブレットのホストとなっているサーバーで障害が起きた場合に使用できるように、レプリカは最新の状態に保たれます。
JDBCベースの永続性
JDBCベースの永続性では、WebLogic Serverはファイル・ベースまたはJDBCベースの永続性メカニズムを使用して、サーブレットまたはJSPのHTTPセッション状態を保持します。それぞれの永続性メカニズムの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッションの永続性の構成に関する項を参照してください。
JDBCベースの永続性は、ワイド・エリア・ネットワーク(WAN)内のHTTPセッション状態レプリケーションにも使用されます。詳細は、「WANでのHTTPセッション状態のレプリケーション」を参照してください。
|
注意: 永続ストアのタイプが |
Coherence*Web
セッション・レプリケーションのためにCoherence*Webを使用することができます。Coherence*Webは、WebLogic ServerのインメモリーHTTP状態レプリケーション・サービスの代替ではありません。しかし、アプリケーションに多くのHTTPセッション状態オブジェクトがある場合、大量のセッション・オブジェクト・データがあってメモリー制約になる場合、または既存のCoherenceクラスタにHTTPセッション状態をオフロードする場合は、Coherence*Webを使用することをお薦めします。
詳細は、『Oracle Coherence*Webユーザーズ・ガイド』を参照してください。
次の項では、インメモリー・レプリケーションを使用するセッション状態レプリケーションについて説明します。
HTTPセッション状態のインメモリー・レプリケーションを利用するためには、WebLogicプロキシ・プラグインの構成が同一であるWebサーバーの集合、またはロード・バランシング・ハードウェアのどちらかを使用してWebLogic Serverクラスタにアクセスする必要があります。
WebLogicプロキシ・プラグインは、クラスタ化されたサーブレットまたはJSPのホストであるWebLogic Serverインスタンスのリストを保持し、ラウンドロビン方式を使用してHTTPリクエストをそれらのインスタンスに転送します。このプラグインは、WebLogic Serverインスタンスで障害が発生した場合に、クライアントのHTTPセッション状態のレプリカを見つけるために必要なロジックも備えています。
HTTPセッション状態のインメモリー・レプリケーションは、次のWebサーバーおよびプロキシ・ソフトウェアでサポートされています。
WebLogic ServerとHttpClusterServlet
ApacheとApache Server (プロキシ)プラグイン
Microsoft Internet Information ServerとMicrosoft-IIS (プロキシ)プラグイン
プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」を参照してください。
プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなCookieの永続性メカニズムと、SSLの永続性にハードウェアが対応している必要があります。これらの必要条件の詳細は、「ロード・バランサの構成要件」を参照してください。ロード・バランサの設定手順については、「パッシブなCookieの永続性をサポートするロード・バランサを構成する」を参照してください。
次の項では、クラスタ環境にデプロイするサーブレットおよびJSPを対象とした、プログラミング上の重要な制限および考慮事項について説明します。
セッション・データはシリアライズ可能でなければならない
HTTPセッション状態のインメモリー・レプリケーションを行うには、サーブレットとJSPのセッション・データがすべてシリアライズ可能でなければなりません。
|
注意: シリアライゼーションとは、複雑なデータ構造を変換するプロセスのことです。この例には、データの並列な配置(多数のビットが並列チャネルを通じて同時に転送される)からシリアル形式(1ビットずつ順番に転送される)への変換などがあります。シリアル・インタフェースでは、この変換によってデータ転送を可能にしています。 |
オブジェクトをシリアライズ可能であると定義するための条件は、オブジェクトのすべてのフィールドがシリアライズ可能または一時的であることです。サーブレットまたはJSPでシリアライズ可能なオブジェクトと不可能なオブジェクトが組み合わせて使用される場合、WebLogic Serverではシリアライズ不可能なオブジェクトのセッション状態がレプリケートされません。
setAttributeを使用してセッション状態を変更する
javax.servlet.http.HttpSessionを実装するHTTPサーブレットでセッション・オブジェクトの属性を変更するには、非推奨となったputValueに代わってHttpSession.setAttributeを使用します。setAttributeを使用してセッション・オブジェクトの属性を設定する場合、オブジェクトとその属性はインメモリー・レプリケーションを使用してクラスタにレプリケートされます。その他のsetメソッドを使用してセッションの内部でオブジェクトを変更する場合、WebLogic Serverではその変更はレプリケートされません。セッション内にあるオブジェクトに対して変更が行われるたびに、setAttribute()を呼び出してクラスタ全体でそのオブジェクトを更新してください。
同様に、セッション・オブジェクトから属性を削除するには、非推奨となったremoveValueに代わってremoveAttributeを使用します。
|
注意: 非推奨の |
シリアライゼーションのオーバーヘッドを考慮する
セッション・データをシリアライズすると、セッション状態のレプリケーションでオーバーヘッドが生じます。オーバーヘッドは、シリアライズされるオブジェクトのサイズに比例して大きくなります。セッション内で非常にサイズの大きいオブジェクトを作成するような設計では、サーブレットのパフォーマンスをテストして適切なレベルを確保してください。
フレームからのセッション・データへのアクセスを制御する
複数のフレームを利用するWebアプリケーションを設計する場合は、指定したフレーム・セットのフレームが同時にリクエストを送らないようにすることを心がけてください。たとえば、論理的にはクライアントが1つのセッションを作成する場合でも、1つのフレーム・セットの複数のフレームがクライアント・アプリケーションに代わって複数のセッションを作成する可能性があります。
クラスタ環境では、フレーム・リクエストを適切に調整しないとアプリケーションの予期しない動作が発生することがあります。プロキシ・プラグインは各リクエストを他のリクエストに関係なく処理するので、複数のフレーム・リクエストによって、アプリケーションとクラスタ化されたインスタンスとの関連付けが「リセット」される場合が考えられます。また、フレーム・セット内の複数のフレームを介して同じセッションの属性を変更することで、アプリケーションがセッション・データを壊してしまう可能性もあります。
アプリケーションの予期しない動作を防ぐには、フレームからのセッション・データへのアクセスを注意深く設計します。次のいずれかの規則に従うと、よくある問題を防ぐことができます。
指定のフレーム・セットでは、1つのフレームだけがセッション・データを作成および変更するようにします。
必ず、アプリケーションで使用する最初のフレーム・セットのフレームでセッションを作成します(たとえば、最初に訪れるHTMLページでセッションを作成します)。セッションを作成した後は、最初のフレーム・セット以外のフレーム・セットでセッション・データにアクセスします。
デフォルトでは、WebLogic Serverはプライマリ・セッション状態が置かれるものとは別のマシン上にセッション状態のレプリカを作成しようと試みます。それ以外にも、レプリケーション・グループを使用することにより、セカンダリ状態が置かれる場所を独自に制御することができます。レプリケーション・グループは、セッション状態のレプリカを格納するために使用されるクラスタ内のサーバーの優先順リストです。
WebLogic Server管理コンソールを使用して、個別のサーバー・インスタンスのホストとなる固有のマシン名を定義できます。これらのマシン名を新しいWebLogic Serverインスタンスに関連付けると、システムでのサーバーの場所を識別できます。
マシン名は一般に、同じマシン上で動作するサーバーを表すために使用します。たとえば、同じマシンまたはサーバー・ハードウェア上で動作するすべてのサーバー・インスタンスに同じマシン名を割り当てます。
1台のマシン上で複数のWebLogic Serverインスタンスを実行しない場合、WebLogic Serverマシン名を指定する必要はありません。マシン名のないサーバーは、それぞれ別個のマシン上にあるものとして扱われます。マシン名を設定する手順の詳細は、「マシン名を構成する」を参照してください。
クラスタ化されるサーバー・インスタンスを構成するとき、サーバーをレプリケーション・グループと優先セカンダリ・レプリケーション・グループに割り当てることができます。後者のグループは、そのサーバーに対して作成されるプライマリHTTPセッション状態のレプリカの保存先となります。
クライアントがクラスタ内のサーバーに接続されて、プライマリ・セッション状態が作成されると、そのプライマリ状態のホスト・サーバーではセカンダリのホスト・サーバーを決定するためにクラスタ内の他のサーバーがランク付けされます。サーバーのランクは、そのサーバーがプライマリ・サーバーと同じマシン上にあるかどうか、およびプライマリ・サーバーの優先レプリケーション・グループに属しているかどうか、という2つの情報を組み合わせて判断されます。表6-1は、クラスタ内のサーバーの相対的なランキングを示しています。
表6-1 セッション・レプリケーションのためのサーバー・インスタンスのランキング
| サーバーのランク | 別のマシンにある | 優先レプリケーション・グループのメンバーである |
|---|---|---|
|
1 |
はい |
はい |
|
2 |
いいえ |
はい |
|
3 |
はい |
いいえ |
|
4 |
いいえ |
いいえ |
プライマリWebLogic Serverは、このルールに従ってクラスタ内のその他のサーバーをランク付けし、最もランクの高いサーバーをセカンダリ・セッション状態のホストとして選択します。たとえば、図6-1は地理的な分類に基づいて構成されたレプリケーション・グループを示しています。
この例では、サーバーA、B、およびCは「Headquarters」というレプリケーション・グループのメンバーであり、「Crosstown」という優先的なセカンダリ・レプリケーション・グループを使用します。逆に、サーバーX、Y、およびZは「Crosstown」というグループのメンバーであり、「Headquarters」という優先的なセカンダリ・レプリケーション・グループを使用します。サーバーA、B、およびXは、「sardina」という同じマシン上にあります。
クライアントがサーバーAに接続し、HTTPセッション状態を作成する場合、
サーバーYおよびZは別のマシン上にあり、サーバーAの優先セカンダリ・グループのメンバーであるため、これらのサーバーが最も高い確率でこの状態のレプリカのホストとなります。
サーバーXは、次に高いランクに位置しています。プライマリと同じマシン上ではありますが、サーバーXも優先レプリケーション・グループのメンバーであるためです。
サーバーCは、マシンは別ですが、優先的なセカンダリ・グループのメンバーではないためランクは3番目になります。
サーバーBは最低のランクです。サーバーAと同じマシン上にあり(したがってハードウェアに障害があるとAと一緒にダウンする可能性があります)、かつ優先的なセカンダリ・グループのメンバーではないためです。
レプリケーション・グループ内のサーバーのメンバーシップを構成する手順、あるいはサーバーの優先セカンダリ・レプリケーション・グループを割り当てる手順については、「レプリケーション・グループを構成する」を参照してください。
次の項では、クラスタ化されたサーブレットおよびJSPにプロキシ経由で送られてくるリクエストを対象とした、接続およびフェイルオーバーのプロセスについて説明します。プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」を参照してください。
図6-2は、クラスタでホストされるサーブレットにクライアントがアクセスする状況を表しています。この例では、静的なHTTPリクエストのみを処理する1つのWebLogic Serverインスタンスを使用します。すべてのサーブレット・リクエストは、HttpClusterServlet経由でWebLogic Serverクラスタに転送されます。
|
注意: 次の説明は、WebLogic Serverと |
HTTPクライアントがサーブレットをリクエストすると、HttpClusterServletがプロキシとして機能し、WebLogic Serverクラスタにそのリクエストを転送します。HttpClusterServletは、クラスタ内の全サーバーのリストと、クラスタへのアクセス時に使用するロード・バランシング・ロジックを管理します。上の例では、HttpClusterServletはクライアントのリクエストをWebLogic Server Aにあるサーブレットに転送します。WebLogic Server Aは、クライアントのサーブレット・セッションをホストするプライマリ・サーバーになります。
サーブレットのフェイルオーバー・サービスを提供するために、プライマリ・サーバーではクライアントのサーブレット・セッション状態がクラスタ内のセカンダリWebLogic Serverにレプリケートされます。このような処理により、たとえばネットワークの障害によってプライマリ・サーバーがダウンしても、セッション状態のレプリカを利用することができます。上の例では、サーバーBがセカンダリとして選択されています。
サーブレット・ページはHttpClusterServletを通じてクライアントに返され、クライアント・ブラウザはサーブレット・セッション状態のプライマリとセカンダリの場所を示すCookieを記述するように指示されます。クライアント・ブラウザでCookieがサポートされていない場合、WebLogic Serverでは代わりにURL書換えを利用できます。
デフォルト構成のWebLogic Serverでは、クライアント側のCookieを使用して、クライアントのサーブレット・セッション状態のホストであるプライマリ・サーバーとセカンダリ・サーバーが追跡されます。クライアント・ブラウザでCookieが無効になっている場合、WebLogic ServerではURL書換えを利用してもプライマリ・サーバーとセカンダリ・サーバーを追跡できます。URL書換えを利用する場合は、クライアント・セッション状態の両方の場所が、クライアントとプロキシ・サーバーの間で渡されるURLに挿入されます。この機能をサポートするには、WebLogic ServerクラスタでURL書換えを有効にする必要があります。URL書換えを有効にする方法は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のCookieにかわるURL書換えの使用に関する項を参照してください。
プライマリ・サーバーで障害が発生すると、HttpClusterServletはクライアントのCookie情報を利用して、セッション・ステートのレプリカのホストであるセカンダリWebLogic Serverの場所を確認します。HttpClusterServletは、クライアントの次のHTTPリクエストを自動的にセカンダリ・サーバーにリダイレクトします。フェイルオーバーは、クライアントには意識されません。
障害の発生後は、WebLogic Server Bがサーブレット・セッション状態のプライマリ・サーバーになり、新しいセカンダリ・サーバーが作成されます(前の例ではサーバーC)。HTTPレスポンスでは、今後のフェイルオーバーに備えて、新しいプライマリ・サーバーとセカンダリ・サーバーを反映するためにプロキシによってクライアントのCookieが更新されます。
|
注意: 現在、WebLogicプロキシ・プラグインはフェイルオーバー後にランダムにセカンダリ・サーバーを選択します。 |
2つのサーバーで構成されるクラスタでは、クライアントはセカンダリ・セッション状態のホスト・サーバーに透過的にフェイルオーバーされます。ただし、もう1つのWebLogic Serverがクラスタで利用可能にならない限り、クライアントのセッション状態のレプリケーションは継続されません。たとえば、元のプライマリ・サーバーが再起動されるか、ネットワークに再び接続されると、そのサーバーはセカンダリ・セッション状態のホストとして使用されます。
ロード・バランシング・ハードウェアを経由したクライアントの直接アクセスを可能にするために、WebLogic Serverのレプリケーション・システムでは、クライアントがフェイルオーバー先のサーバーとは無関係にセカンダリ・セッション・ステートを使用できます。WebLogic Serverは、プライマリ・サーバーとセカンダリ・サーバーの場所を記録する手段としてクライアント側のCookieまたはURL書換えを使用します。ただし、この情報はサーブレット・セッション・ステートの場所の履歴としてのみ使用されます。ロード・バランシング・ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバーを能動的に見つける手段としてはCookie情報を使用しません。
次の項では、HTTPセッション状態のレプリケーションをロード・バランシング・ハードウェアと組み合わせて使用する場合の、接続およびフェイルオーバーのプロセスについて説明します。
図6-3は、ロード・バランサを通じてクラスタにアクセスしているクライアントの接続手順を示しています。
WebアプリケーションのクライアントがパブリックなIPアドレスを使用してサーブレットをリクエストする場合:
ロード・バランサはクライアントの接続リクエストを、構成済みのポリシーに従ってWebLogic Serverクラスタに転送します。クラスタはリクエストをWebLogic Server Aに転送します。
WebLogic Server Aは、クライアントのサーブレット・セッション状態のプライマリ・ホストとして機能します。プライマリ・ホストは、「レプリケーション・グループの使用」で説明されているランキング・システムを使用して、セッション状態のレプリカのホストとなるサーバーを選択します。上の例では、WebLogic Server Bがレプリカのホストとして選択されています。
クライアントは、WebLogic ServerインスタンスAとBの場所をローカルのCookieに記録するように指示されます。クライアントでCookieを利用できない場合、プライマリ・サーバーとセカンダリ・サーバーの場所はURL書換えを利用してクライアントに返されるURLに記録できます。
|
注意: Cookieを無効にしているクライアントに対応するには、「URL書換えを利用したセッション・レプリカの追跡」で説明しているように、WebLogic ServerのURL書換え機能を有効にする必要があります。 |
クライアントがクラスタに対してさらにリクエストを行う場合、ロード・バランサはクライアント側のCookieに記録された識別子を利用して、リクエストが引き続き、クラスタ内の別のサーバーではなくWebLogic Server Aに確実に転送されるようにします。このような処理によって、クライアントはセッションが終了するまでプライマリ・セッション・オブジェクトのホスト・サーバーと関係を維持することができます。
クライアントのセッションの途中でサーバーAに障害が発生すると、図6-4に示すように、そのクライアントによるサーバーAへの次の接続リクエストは失敗します。
接続の失敗へのレスポンスとして:
ロード・バランシング・ハードウェアは、構成されているポリシーを使用して、クラスタ内の利用可能なWebLogic Serverにリクエストを転送します。上の例では、WebLogic Server Aで障害が起こった後、クライアントのリクエストはWebLogic Server Cに転送されます。
クライアントがWebLogic Server Cに接続すると、そのサーバーはクライアントのCookieにある情報(URL書換えが使用される場合はHTTPリクエストの情報)を使用してWebLogic Server Bにあるセッション状態のレプリカを取得します。このフェイルオーバー・プロセスは、クライアントではまったく意識されません。
WebLogic Server Cはクライアントのプライマリ・セッション状態の新しいホストになり、WebLogic Server Bは引続きセッション状態のレプリカを保持します。プライマリ・ホストとセカンダリ・ホストに関するこの新しい情報は、クライアントのCookieまたはURL書換えで再び更新されます。
クラスタ内のサーバー間でのHTTPセッション状態レプリケーションに加えて、WebLogic Serverでは、複数のクラスタ間でHTTPセッション状態をレプリケートする機能が提供されます。これにより、複数の地理的領域、電力網、インターネット・サービス・プロバイダに渡ってクラスタを分散できるようになるため、高可用性とフォルト・トレランスが向上します。この項では、WebLogic Serverでサポートされるクラスタ間のレプリケーションのメカニズムを説明します。
HTTPセッション状態レプリケーションの概要については、「HTTPセッション状態のレプリケーション」を参照してください。ハードウェア・ロード・バランサの使用方法の詳細は、「クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス」を参照してください。
WebLogic Serverでクラスタ間のレプリケーションを実行するには、使用しているネットワークにグローバル・ハードウェア・ロード・バランサとローカル・ハードウェア・ロード・バランサが含まれている必要があります。図6-5に、クラスタ間のレプリケーションをサポートするマルチ・クラスタ環境で両方のタイプのロード・バランサが対話する仕組みを示します。WebLogic Server環境でのロード・バランサの使用に関する全般的な情報については、「ロード・バランシング・ハードウェアを利用した接続」を参照してください。
次の項では、このネットワーク構成の各コンポーネントについて説明します。
クラスタ間のレプリケーションをサポートするネットワーク構成では、グローバル・ロード・バランサがクラスタ間のHTTPリクエストのバランシングを行います。リクエストが受信されると、グローバル・ロード・バランサは、各クラスタによって現在処理されているリクエスト数に基づいてそのリクエストの送信先となるクラスタを決定します。その後、リクエストは選択されたクラスタのローカル・ロード・バランサに渡されます。
ローカル・ロード・バランサは、グローバル・ロード・バランサからHTTPリクエストを受信します。ローカル・ロード・バランサは、クラスタ内にあるサーバー間のHTTPリクエストのバランシングを行います。
クラスタ間でセッション・データをレプリケートするには、プライマリ・クラスタからセカンダリ・クラスタにセッション状態情報を送信するように、レプリケーション・チャネルが構成されている必要があります。セッション情報のレプリケーションに使用される特定の方法は、実装しているクラスタ間レプリケーションのタイプによって異なります。詳細は、「MANでのHTTPセッション状態のレプリケーション」または「WANでのHTTPセッション状態のレプリケーション」を参照してください。
次の手順は、クラスタ間レプリケーションを構成するために必要なステップの概要を示しています。
ネットワーク構成および要件に従って、WebLogic Serverをインストールします。この手順には、WebLogic Serverインスタンスのホストとなる物理的な各マシンへのWebLogic Serverインスタンスのインストールも含まれます。
ハードウェア・ロード・バランサをインストールし、構成します。ロード・バランサの要件の詳細は、「クラスタ間レプリケーションのネットワーク要件」を参照してください。ロード・バランサのインストールおよび構成の詳細は、使用するロード・バランサのドキュメントを参照してください。
次は、クラスタ間レプリケーションをサポートするようにハードウェア・ロード・バランサを構成する場合の一般的な考慮事項です。
セッションIDを保持するようにロード・バランサを構成する必要があります。ロード・バランサがセッションIDを保持しない場合、後続のリクエストは常に新しいサーバーに送信されます。詳細は、「ロード・バランシング・ハードウェアを利用した接続」を参照してください。
クラスタのフェイルオーバーのタイムアウト値が大きい値を設定しないように注意します。この値は、およそ3 - 5秒に設定する必要があります。ハードウェア・ロード・バランサによっては、デフォルト値がそれよりかなり大きいものもあります。
プライマリ・クラスタまたはサーバーで障害が発生した場合に使用するバックアップ・クラスタを識別するようにロード・バランサを構成する必要があります。
クラスタの要件に従って、ドメインを作成し、構成します。
|
注意: クラスタ間レプリケーションでは、各クラスタが別々のドメインに割り当てられている必要があります。 |
ドメインの作成と構成だけでなく、クラスタおよび管理対象サーバーも作成し、構成する必要があります。ドメイン、クラスタ、および管理対象サーバーの作成と構成については、次のトピックを参照してください。
『Oracle WebLogic Serverドメイン構成の理解』のOracle WebLogic Serverドメインに関する項
『構成ウィザードによるドメインの作成』のオプションの構成の選択に関する項
次は、クラスタ間レプリケーションをサポートするようにドメインを構成する場合の一般的な考慮事項です。
各ドメインに対して、同じ設定および構成を行う必要があります。ドメイン、クラスタ、およびサーバーの構成を同じにするだけでなく、サーバーやクラスタの数なども同じにする必要があります。
各ドメインのアプリケーション・デプロイメントを同じにする必要があります。
ドメインを設定するときは、両方のドメイン間の信頼関係を有効にする必要があります。ドメイン間の信頼関係の有効化の詳細は、『Oracle WebLogic Serverの保護』のWebLogic Serverドメイン間の信頼関係の有効化に関する項を参照してください
WAN環境でクラスタ間のレプリケーションを使用する場合、セッション状態の保持に使用するデータ・ソースを作成する必要があります。詳細は、「WANでのセッション状態レプリケーション用のデータベースの構成」を参照してください。
ドメイン、サーバー、およびクラスタの作成と構成が終わったら、クラスタ間レプリケーションに固有の構成要素が正しく構成されていることを確認する必要があります。次のパラメータの構成は、両方のドメインで同じでなければなりません。
表6-2に、クラスタ間レプリケーションの構成に使用されるconfig.xmlのクラスタ要素の下位要素を示します。
表6-2 config.xmlのクラスタ要素
| 要素 | 説明 |
|---|---|
|
cluster-type |
この設定は、使用するレプリケーションのタイプと一致し、両方のクラスタ間で同じでなければなりません。 有効な値は、 |
|
remote-cluster-address |
もう一方のクラスタとのレプリケーション情報の通信に使用されるアドレスです。クラスタ間の通信はロード・バランサを通じて行われるように構成する必要があります。 |
|
replication-channel |
もう一方のクラスタとのレプリケーション情報の通信に使用されるネットワーク・チャネルです。 注意: 名前付きのチャネルが、クラスタのすべてのメンバーに存在し、同じプロトコルを使用するように構成されている必要があります。選択したチャネルは、セキュア・プロトコルを使用するように構成できます。 |
|
data-source-for-session-persistence |
JDBCベースのセッション永続性の使用時に、セッション情報の格納に使用されるデータ・ソースです。 セッション状態レプリケーションのこの方法は、WAN内のクラスタ間レプリケーションの実行に使用されます。詳細は、「WANでのセッション状態レプリケーション用のデータベースの構成」を参照してください。 |
|
session-flush-interval |
クラスタがHTTPセッションをバックアップ・クラスタにフラッシュする間隔(秒単位)です。 |
|
session-flush-threshold |
HTTPセッションの数がsession-flush-thresholdの値に達すると、セッションはバックアップ・クラスタにフラッシュされます。これにより、負荷が大きい場合でもセッションを高速にフラッシュできます。 |
|
inter-cluster-comm-link-health-check-interval |
2つのクラスタ間のリンクが復元されているかどうかを判断する連続チェック間の時間(ミリ秒単位)です。 |
サード・パーティのレプリケーション製品を使用してクラスタ間で状態をレプリケートするか、またはWebLogic Serverを使用してクラスタ間でセッション状態をレプリケートすることができます。使用する方法に応じて、次の構成上の考慮事項に注意する必要があります。
サード・パーティ製品を使用する場合は、jdbc-poolの値が指定されていることと、backup-cluster-addressが空白になっていることを確認します。
WebLogic Serverを使用してセッション状態レプリケーションを処理する場合は、jdbc-poolとbackup-cluster-addressの両方を構成する必要があります。
backup-cluster-addressがnullになっていると、WebLogic Serverではレプリケーションの処理にサード・パーティ製品が使用されると見なされます。この場合、セッション・データはリモート・データベースに保持されません(ローカルに保持されます)。
レプリケーション・チャネルは、クラスタ間のレプリケーション・トラフィック専用のネットワーク・チャネルです。ネットワーク・チャネルの構成の詳細は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。
クラスタ間のレプリケーション・チャネルとして使用するネットワーク・チャネルを作成する場合は、次の点を考慮に入れてください。
レプリケーション・チャネルは、すべてのクラスタ・メンバー上に同じ名前で作成されている必要があります。
このチャネルは、レプリケーション専用として使用する必要があります。他の種類のネットワーク・トラフィックは、別のネットワーク・チャネルに転送する必要があります。
メトロポリタン・エリア・ネットワーク(MAN)内のリソースは、多くの場合物理的に異なる場所にありますが、ネットワーク待機時間が問題になるほど地理的には離れていません。MANにおけるネットワーク通信では通常、低レイテンシで高速な相互接続が提供されます。MAN内のクラスタは物理的に異なる場所にインストールできるため、可用性が向上します。
MAN内でフェイルオーバーを提供するために、WebLogic Serverには2つのクラスタ間で機能するインメモリー・メカニズムが用意されています。ネットワーク待機時間が数ミリ秒であれば、この機能によりセッション状態はクラスタ間で同期的にレプリケートされます。同期的な方法を使用する利点は、インメモリー・レプリケーションの信頼性が保証されることです。
|
注意: 同期的な状態レプリケーションのパフォーマンスは、クラスタ間のネットワーク待機時間で決まります。この方法は、クラスタ間のネットワーク待機時間が許容可能な場合にのみ使用するようにしてください。 |
次の項では、MAN内の複数のクラスタ間で想定されるフェイルオーバーのシナリオについて説明します。図6-6に、MAN内における一般的なマルチ・クラスタ環境を示します。
この図には、HTTPセッション状態の次のシナリオが示されています。
クライアントが、グローバル・ロード・バランサを通じてリクエストを送信します。
グローバル・ロード・バランサが、現在のシステム負荷に基づいてリクエストをローカル・ロード・バランサに渡します。この場合、セッション・リクエストはローカル・ロード・バランサ1に渡されます。
ローカル・ロード・バランサが、システム負荷に基づいてリクエストをクラスタ内のサーバー(この場合はS1)に渡します。リクエストがS1に到達すると、この管理対象サーバーはこのHTTPセッションのプライマリ・サーバーになります。障害が発生しないかぎり、後続のリクエストはこのサーバーによって処理されます。
セッション状態情報は、プライマリ・クラスタのデータベースに格納されます。
サーバーによってHTTPセッションが確立されると、現在のセッション状態が指定されたセカンダリ・サーバーにレプリケートされます。
次の項では、図6-6のMAN構成に基づいて、フェイルオーバーの様々なシナリオについて説明します。
フェイルオーバーのシナリオ1
クラスタ1内のすべてのサーバーで障害が発生した場合、グローバル・ロード・バランサは以降のセッション・リクエストをすべてクラスタ2に自動的にフェイルオーバーします。クラスタ2にレプリケートされたすべてのセッションが回復され、クライアントはデータ損失を回避できます。
フェイルオーバーのシナリオ2
プライマリ・サーバーS1はクラスタ1でホストされ、セカンダリ・サーバーS6はクラスタ2でホストされているとします。S1がクラッシュした場合、クラスタ1内の他のサーバー(S2またはS3)がリクエストを受信し、サーバーS6からセッション・データを取得します。S6は引き続き、バックアップ・サーバーとして機能します。
フェイルオーバーのシナリオ3
プライマリ・サーバーS1はクラスタ1でホストされ、セカンダリ・サーバーS6はクラスタ2でホストされているとします。セカンダリ・サーバーS6で障害が発生した場合、プライマリ・サーバーS1はクラスタ2から新しいセカンダリ・サーバーを自動的に選択します。クライアント・リクエストを受信すると、セッション情報は新しいセカンダリ・サーバーにバックアップされます。
フェイルオーバーのシナリオ4
2つのクラスタ間の通信で障害が発生した場合、プライマリ・サーバーはローカル・クラスタ内の新しいセカンダリ・サーバーにセッション状態を自動的にレプリケートします。2つのクラスタ間の通信が回復すると、以降のクライアント・リクエストはすべてリモート・クラスタにレプリケートされます。
MANでのレプリケーションでは、クラスタ・アフィニティを管理するグローバル・ロード・バランサとサーバー・アフィニティを管理するローカル・ロード・バランサが使用されます。クラスタ内のあるサーバーで障害が発生した場合、ローカル・ロード・バランサはセッション状態がそのクラスタ内の別のサーバーにレプリケートされることを保証します。クラスタ内のすべてのサーバーで障害が発生した場合や、クラスタ内のすべてのサーバーが使用できなくなっている場合は、グローバル・ロード・バランサがセッション状態をもう一方のクラスタにレプリケートします。これにより、クラスタ全体で障害が発生しない限り、もう一方のクラスタへのフェイルオーバーは発生しないようになります。
クライアントは、ロード・バランサを通じてクラスタへの接続を確立したら、そのクラスタが正常な状態である限り、そのクラスタへの接続を保持する必要があります。
ワイド・エリア・ネットワーク(WAN)内のリソースは、多くの場合異なる地理的領域に渡って分散されています。ネットワーク・トラフィックが長い距離を進む必要があるだけでなく、これらのリソースは通常、複数のルーターなどのネットワーク・ボトルネックによっても分離されています。WANにおけるネットワーク通信は通常、待機時間が比較的長く、相互接続の速度も遅くなります。
WANではネットワークのパフォーマンスが低いため、MANで使用されるような同期的なレプリケーション・メカニズムを使用することは困難です。WebLogic Serverは、非同期的なデータ・レプリケーション方式使用することで、WANにおけるクラスタ間のフェイルオーバーを提供します。
次の項では、WAN内の複数のクラスタ間で想定されるフェイルオーバーのシナリオについて説明します。図6-7に、WANにおける一般的なマルチ・クラスタ環境を示します。
この図には、HTTPセッション状態の次のシナリオが示されています。
クライアントが、グローバル・ロード・バランサを通じてリクエストを送信します。
グローバル・ロード・バランサが、現在のシステム負荷に基づいてリクエストをローカル・ロード・バランサに渡します。この場合、セッション・リクエストはローカル・ロード・バランサ1に渡されます。
ローカル・ロード・バランサが、システム負荷に基づいてリクエストをクラスタ内のサーバー(この場合はS1)に渡します。リクエストがS1に到達すると、この管理対象サーバーはこのHTTPセッションのプライマリ・サーバーになります。障害が発生しないかぎり、後続のリクエストはこのサーバーによって処理されます。
セッション状態情報は、プライマリ・クラスタのデータベースに格納されます。
サーバーによってHTTPセッションが確立されると、現在のセッション状態が指定されたセカンダリ・サーバーにレプリケートされます。
次の項では、WAN環境でのフェイルオーバーのシナリオについて説明します。
フェイルオーバーのシナリオ
クラスタ1内のすべてのサーバーで障害が発生した場合、グローバル・ロード・バランサは以降のセッション・リクエストをすべてクラスタ2に自動的にフェイルオーバーします。すべてのセッションは、認識されている最新のデータベースへのフラッシュに従ってバックアップされます。
次の項では、WANでのクラスタ間セッション状態レプリケーション用のデータ・ソースの構成要件について説明します。クラスタ間レプリケーションの設定の概要については、「クラスタ間レプリケーションの構成要件」を参照してください。
WAN環境でのクラスタ間レプリケーションを有効にするには、セッション状態情報が格納されるデータベースを指定するJDBCデータ・ソースを作成する必要があります。次の手順を実行して、データベースを設定し構成します。
ベンダーのドキュメントに従って、データベース・サーバー・ソフトウェアをインストールし、構成します。
このデータベースを参照するJDBCデータ・ソースを作成します。JDBCデータ・ソースの作成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のJDBCデータ・ソースの構成に関する項を参照してください。
このデータ・ソースは、JDBCマルチ・データ・ソースとして構成することもできます。マルチ・データ・ソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のJDBCマルチ・データ・ソースの構成に関する項を参照してください。
このデータ・ソースを指定するように、プライマリ・クラスタとセカンダリ・クラスタの両方のDataSourceForSessionPersistenceを設定します。
次のスキーマに従って、データベースにWLS_WAN_PERSISTENCEという表を作成します。
CREATE TABLE WLS_WAN_PERSISTENCE_TABLE ( WL_ID VARCHAR2(100) NOT NULL, WL_CONTEXT_PATH VARCHAR2(50) NOT NULL, WL_CREATE_TIME NUMBER(20), WL_ACCESS_TIME NUMBER(20), WL_MAX_INACTIVE_INTERVAL NUMBER(38), WL_VERSION NUMBER(20) NOT NULL, WL_INTERNAL_ATTRIBUTE NUMBER(38), WL_SESSION_ATTRIBUTE_KEY VARCHAR2(100), WL_SESSION_ATTRIBUTE_VALUE LONG RAW, PRIMARY KEY(WL_ID, WL_CONTEXT_PATH, WL_VERSION, WL_SESSION_ATTRIBUTE_KEY));
表6-3では、この表の各行が格納する内容について説明します。
表6-3 レプリケーション表の内容
| データベースの行 | 説明 |
|---|---|
|
wl_id |
HTTPセッションIDを格納します。 |
|
wl_context_path |
セッションを作成したWebアプリケーションのコンテキスト・パスを格納します。 |
|
wl_create_time |
セッション状態が作成された時刻を格納します。 |
|
wl_session_values |
セッションの属性を格納します。 |
|
wl_access_time |
セッション状態の最終の更新時刻を格納します。 |
|
wl_max_inactive_interval |
セッション状態の |
|
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のコマンドライン・オプションを使用して、明示的にレプリカ対応スタブを生成します。詳細は、『Oracle WebLogic Server 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段階でロード・バランシングとフェイルオーバーのメリットを実現できることになります。
クライアントがEJBHomeスタブを使用してEJBオブジェクトをルックアップするとき
クライアントがEJBObjectスタブを使用してEJBに対するメソッド呼出しを行うとき
次の項では、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スタブをクライアントに戻します。
図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が検索または作成される場合は、レプリカ対応スタブが返されます。このスタブでは、すべての呼出しでロード・バランシングが行われますが、回復可能な呼出しエラーが発生したときに自動的にフェイルオーバーは行われません。読取り専用Beanは、データベース読込みを防止するためにすべてのサーバーでキャッシュされます。
エンティティBeanとEJBハンドルのフェイルオーバーは、クラスタ・アドレスの指定方法に依存します。「クラスタ・アドレス」で説明しているように、クラスタ・アドレスは明示的に定義することも、WebLogic Serverによって自動的に生成することもできます。クラスタ・アドレスを明示的に定義する場合は、クラスタ内のすべてのサーバー・インスタンスにマップされ、かつクラスタ内のサーバー・インスタンスのみにマップされるDNS名として指定する必要があります。クラスタのDNS名は、クラスタに属していないサーバー・インスタンスに対応しないようにします。
WebLogic RMIには、クラスタ化されたリモート・オブジェクト作成専用の拡張機能があります。これらの拡張機能を使用して、EJBの項で説明されているレプリカ対応スタブをビルドします。クラスタでのRMIの使用の詳細は、『Oracle WebLogic Server RMIのプログラミング』のWebLogic RMI機能に関する項を参照してください。
WebLogic Serverクラスタで使用するEJBをプログラミングする場合は、この項の説明を参照して、クラスタ内の各種のEJBの機能について理解してください。そして確実にEJBのデプロイメント記述子でクラスタリングできるようにします。クラスタ化に関するXMLデプロイメント要素の詳細は、『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1のプログラミング』のweblogic-ejb-jar.xmlデプロイメント記述子のリファレンスに関する項を参照してください。
EJBまたはカスタムRMIオブジェクトを開発する場合は、『Oracle WebLogic Server JNDIのプログラミング』のクラスタ環境でのWebLogic JNDIの使い方に関する項を参照して、クラスタ化オブジェクトをJNDIツリーにバインドすることの影響を理解してください。
