| Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方 11g リリース 1 (10.3.1) B55518-01 |
|
 戻る |
 次へ |
クラスタが高可用性を提供するためには、サービスの障害からの回復が可能でなければなりません。以下の節では、WebLogic Server でクラスタ内の障害が検出される仕組みについて説明し、フェイルオーバ方式の概要をオブジェクトのタイプ別に示します。
ここでは、アプリケーション レベルでのフェイルオーバとレプリケーションについて重点的に説明します。WebLogic Server では、障害発生後にサーバ インスタンスやサービスを自動的に移行することも可能です。詳細については、「サーバ全体の移行」を参照してください。
クラスタ内の WebLogic Server インスタンスは、以下のものをモニタすることで、自身のピア サーバ インスタンスの障害を検出します。
ピア サーバへのソケット接続
サーバの定期的なハートビート メッセージ
WebLogic Server インスタンスは、障害を直ちに検出するために、ピア サーバ インスタンス間で IP ソケットが使用されているかどうかをモニタします。サーバがクラスタ内のピアのいずれかに接続し、ソケットを使ってデータ転送を始めた場合、そのソケットが突然クローズされると、ピア サーバが「エラー」としてマークされ、その関連サービスが JNDI ネーミング ツリーから削除されます。
クラスタ化されたサーバ インスタンスがピア ツー ピア通信用にソケットをオープンしていない場合、障害が発生したサーバは WebLogic Server のハートビートによって検出できます。クラスタ内のすべてのサーバ インスタンスはマルチキャストまたはユニキャストを使用して、定期的なサーバ ハートビート メッセージを他のクラスタ メンバーにブロードキャストします。
|
注意 : 以前のバージョンの WebLogic Server との互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
個々のハートビート メッセージには、メッセージの送信元のサーバを一意に識別するデータが入っています。サーバは、自身のハートビート メッセージを 10 秒間隔で定期的にブロードキャストします。同時に、クラスタ内の各サーバはマルチキャスト アドレスまたはユニキャスト アドレスをモニタして、すべてのピア サーバのハートビート メッセージが送信されているかどうかを確認します。
|
注意 : 以前のバージョンの WebLogic Server との互換性を維持するため、クラスタ間の通信にマルチキャストを使用することも可能です。 |
マルチキャスト アドレスまたはユニキャスト アドレスをモニタ中のサーバにピア サーバからのハートビート メッセージが 3 回届かなかった場合 (つまり、モニタする側のサーバが他のサーバから 30 秒以上ハートビートを受信していない場合)、モニタする側のサーバはピア サーバを「エラー」としてマークします。次に、必要であればローカルの JNDI ツリーを更新して、障害が発生したサーバでホストされていたサービスを削除します。
このようにして、サーバは、ピア ツー ピア通信でソケットがオープンされていない場合でも、障害を検出できます。
|
注意 : WebLogic Server での IP ソケットとマルチキャスト通信 (またはユニキャスト通信) の使用について、詳しくは「クラスタでの WebLogic Server の通信」を参照してください。 |
クラスタ内でのサーブレットと 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 Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「セッションの永続性のコンフィグレーション」を参照してください。
JDBC ベースの永続性は、ワイド エリア ネットワーク (WAN) 内の HTTP セッション ステート レプリケーションにも使用されます。詳細については、「WAN での HTTP セッション ステートのレプリケーション」を参照してください。
|
注意 : 永続ストアのタイプがreplicated または replicated_if_clustered に設定されている Web アプリケーションは、クラスタまたはそのクラスタのすべてのノードに対象指定する必要があります。クラスタ内の一部のノードにしか対象指定されていない場合、その Web アプリケーションはデプロイされません。インメモリ レプリケーションでは、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 (プロキシ) プラグイン
プロキシ プラグインの設定方法については、「プロキシ プラグインをコンフィグレーションする」を参照してください。
プロキシ プラグインではなくロード バランシング ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなクッキーの永続性メカニズムと、SSL の永続性にハードウェアが対応している必要があります。これらの必要条件の詳細については、「ロード バランサのコンフィグレーション要件」を参照してください。ロード バランサの設定手順については、「パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする」を参照してください。
この節では、クラスタ環境にデプロイするサーブレットおよび JSP を対象とした、プログラミング上の重要な制限および考慮事項について説明します。
セッション データはシリアライズ可能でなければならない
HTTP セッション ステートのインメモリ レプリケーションを行うには、サーブレットと JSP のセッション データがすべてシリアライズ可能でなければなりません。
|
注意 : シリアライゼーションとは、複雑なデータ構造を変換するプロセスのことです。この例には、データの並列な配置 (多数のビットが並列チャネルを通じて同時に転送される) からシリアル形式 (1 ビットずつ順番に転送される) への変換などがあります。シリアル インタフェースでは、この変換によってデータ転送を可能にしています。 |
オブジェクトをシリアル化可能であると定義するための条件は、オブジェクトのすべてのフィールドがシリアル化可能または一時的であることです。サーブレットまたは JSP でシリアライズ可能なオブジェクトと不可能なオブジェクトが組み合わせて使用される場合、WebLogic Server ではシリアライズ不可能なオブジェクトのセッション ステートがレプリケートされません。
setAttribute を使用してセッション ステートを変更する
javax.servlet.http.HttpSession を実装する HTTP サーブレットでセッション オブジェクトの属性を変更するには、非推奨となった putValue に代わって HttpSession.setAttribute を使用します。setAttribute を使用してセッション オブジェクトの属性を設定する場合、オブジェクトとその属性はインメモリ レプリケーションを使用してクラスタにレプリケートされます。その他の set メソッドを使用してセッションの内部でオブジェクトを変更する場合、WebLogic Server ではその変更はレプリケートされません。セッション内にあるオブジェクトに対して変更が行われるたびに、setAttribute() を呼び出してクラスタ全体でそのオブジェクトを更新してください。
同様に、セッション オブジェクトから属性を削除するには、非推奨となった removeValue に代わって removeAttribute を使用します。
|
注意 : 非推奨のputValue メソッドおよび removeValue メソッドを使用しても、セッション属性はレプリケートされます。 |
シリアライゼーションのオーバーヘッドを考慮する
セッション データをシリアライズすると、セッション ステートのレプリケーションでオーバーヘッドが生じます。オーバーヘッドは、シリアライズされるオブジェクトのサイズに比例して大きくなります。セッション内で非常にサイズの大きいオブジェクトを作成するような設計では、サーブレットのパフォーマンスをテストして適切なレベルを確保してください。
フレームからのセッション データへのアクセスを制御する
複数のフレームを利用する Web アプリケーションを設計する場合は、指定したフレームセットのフレームが同時にリクエストを送らないようにすることを心がけてください。たとえば、論理的にはクライアントが 1 つのセッションを作成する場合でも、1 つのフレームセットの複数のフレームがクライアント アプリケーションに代わって複数のセッションを作成する可能性があります。
クラスタ環境では、フレーム リクエストを適切に調整しないとアプリケーションの予期しない動作が発生することがあります。プロキシ プラグインは各リクエストを他のリクエストに関係なく処理するので、複数のフレーム リクエストによって、アプリケーションとクラスタ化されたインスタンスとの関連付けが「リセット」される場合が考えられます。また、フレームセット内の複数のフレームを介して同じセッションの属性を変更することで、アプリケーションがセッション データを壊してしまう可能性もあります。
アプリケーションの予期しない動作を防ぐには、フレームからのセッション データへのアクセスを注意深く設計します。以下のいずれかの規則に従うと、よくある問題を防ぐことができます。
指定のフレームセットでは、1 つのフレームだけがセッション データを作成および変更するようにする。
必ず、アプリケーションで使用する最初のフレームセットのフレームでセッションを作成する (たとえば、最初に訪れる HTML ページでセッションを作成する)。セッションを作成した後は、最初のフレームセット以外のフレームセットでセッション データにアクセスします。
デフォルトでは、WebLogic Server はプライマリ セッション ステートが置かれるものとは別のマシン上にセッション ステートのレプリカを作成しようと試みます。それ以外にも、レプリケーション グループを使用することにより、セカンダリ ステートが置かれる場所を独自に制御することができます。レプリケーション グループは、セッション ステートのレプリカを格納するために使用されるクラスタ内のサーバの優先順リストです。
WebLogic Server Console を使用して、個別のサーバ インスタンスのホストとなるユニークなマシン名を定義できます。それらのマシン名を新しい 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 と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 書き換えを有効にする方法については、『Oracle Fusion Middleware Oracle 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 アドレスを使用してサーブレットを要求する場合は、次のようなプロセスが行われます。
ロード バランサはクライアントの接続リクエストを、コンフィグレーション済みのポリシーに従って WebLogic Server クラスタに転送します。クラスタはリクエストを WebLogic Server A に転送します。
WebLogic Server A は、クライアントのサーブレット セッション ステートのプライマリ ホストとして機能します。プライマリ ホストは、「レプリケーション グループの使用」で説明されているランキング システムを使用して、セッション ステートのレプリカのホストとなるサーバを選択します。上の例では、WebLogic Server B がレプリカのホストとして選択されています。
クライアントは、WebLogic Server インスタンス A と B の場所をローカルのクッキーに記録するように指示されます。クライアントでクッキーを利用できない場合、プライマリ サーバとセカンダリ サーバの場所は URL 書き換えを利用してクライアントに返される URL に記録できます。
|
注意 : クッキーを無効にしているクライアントに対応するには、「URL 書き換えを利用したセッション レプリカの追跡」で説明しているように、WebLogic Server の URL 書き換え機能を有効にする必要があります。 |
クライアントがクラスタに対してさらにリクエストを行う場合、ロード バランサはクライアント側のクッキーに記録された識別子を利用して、リクエストが引き続き、クラスタ内の別のサーバではなく WebLogic Server A に確実に転送されるようにします。このような処理によって、クライアントはセッションが終了するまでプライマリ セッション オブジェクトのホスト サーバと関係を維持することができます。
クライアントのセッションの途中でサーバ A に障害が発生すると、図 6-4 に示すように、そのクライアントによるサーバ A への次の接続リクエストは失敗します。
接続が失敗した場合は、次のようなプロセスが行われます。
ロード バランシング ハードウェアは、コンフィグレーションされているポリシーを使用して、クラスタ内の利用可能な WebLogic Server にリクエストを転送します。上の例では、WebLogic Server A で障害が起こった後、クライアントのリクエストは WebLogic Server C に転送されます。
クライアントが WebLogic Server C に接続すると、そのサーバはクライアントのクッキーにある情報 (URL 書き換えが使用される場合は HTTP リクエストの情報) を使用して WebLogic Server B にあるセッション ステートのレプリカを取得します。このフェイルオーバ プロセスは、クライアントではまったく意識されません。
WebLogic Server C はクライアントのプライマリ セッション ステートの新しいホストになり、WebLogic Server B は引き続きセッション ステートのレプリカを保持します。プライマリ ホストとセカンダリ ホストに関するこの新しい情報は、クライアントのクッキーまたは URL 書き換えで再び更新されます。
クラスタ内のサーバ間での HTTP セッション ステート レプリケーションに加えて、WebLogic Server には、複数のクラスタ間で HTTP セッション ステートをレプリケートする機能が用意されています。これにより、複数の地理的領域、電力供給網、インターネット サービス プロバイダに渡ってクラスタを分散できるようになるため、高可用性とフォールト トレランスが向上します。この節では、WebLogic Server でサポートされている、クラスタ間レプリケーションの 2 種類のメカニズムについて説明します。
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 Fusion Middleware Oracle WebLogic Server ドメインのコンフィグレーションについて』の「WebLogic Server ドメインについて」
『Oracle Fusion Middleware コンフィグレーション ウィザードを使用したドメインの作成』の「環境のカスタマイズ」
以下は、クラスタ間レプリケーションをサポートするようにドメインをコンフィグレーションする場合の一般的な考慮事項です。
各ドメインに対して、同じ設定およびコンフィグレーションを行うこと。ドメイン、クラスタ、およびサーバのコンフィグレーションを同じにするだけでなく、サーバやクラスタの数なども同じにする必要があります。
各ドメインのアプリケーション デプロイメントを同じにすること。
ドメインの設定時に、両ドメイン間の信頼を有効にすること。ドメイン間の信頼の有効化に関する詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic Server ドメイン間の信頼関係の有効化」を参照してください。
WAN 環境でクラスタ間レプリケーションを使用する場合は、セッション ステートの保持に使用するデータ ソースを作成する必要があります。詳細については、「WAN でのセッション ステート レプリケーション用のデータベースのコンフィグレーション」を参照してください。
ドメイン、サーバ、およびクラスタの作成とコンフィグレーションが終わったら、クラスタ間レプリケーションに固有のコンフィグレーション要素が正しくコンフィグレーションされていることを確認する必要があります。以下のパラメータのコンフィグレーションは、両方のドメインで同じでなければなりません。
表 6-2 に、クラスタ間レプリケーションのコンフィグレーションに使用される config.xml の Cluster 要素の下位要素を示します。
表 6-2 config.xml の Cluster 要素
| 要素 | 説明 |
|---|---|
|
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 |
クラスタが待機する時間 (ミリ秒単位)。 |
サードパーティのレプリケーション製品を使用してクラスタ間でステートをレプリケートするか、または WebLogic Server を使用してクラスタ間でセッション ステートをレプリケートすることができます。使用する方法に応じて、以下のコンフィグレーション上の考慮事項に注意する必要があります。
サードパーティ製品を使用する場合は、jdbc-pool の値が指定されていることと、backup-cluster-address が空白になっていることを確認する。
WebLogic Server を使用してセッション ステート レプリケーションを処理する場合は、jdbc-pool と backup-cluster-address の両方をコンフィグレーションする必要がある。
backup-cluster-address が null になっていると、WebLogic Server ではレプリケーションの処理にサードパーティ製品が使用されると見なされます。この場合、セッション データはリモート データベースに保持されません (ローカルに保持されます)。
レプリケーション チャネルは、クラスタ間のトラフィックのレプリケーション専用として使用する普通のネットワーク チャネルです。ネットワーク チャネルのコンフィグレーションの概要については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「JDBC データ ソースのコンフィグレーション」を参照してください。
このデータ ソースは、JDBC マルチ データ ソースとしてコンフィグレーションすることもできます。マルチ データ ソースのコンフィグレーションの詳細については、『Oracle Fusion Middleware 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 Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server RMI プログラマーズ ガイド』の「WebLogic RMI の機能」を参照してください。
WebLogic Server クラスタで使用する EJB をプログラムする場合は、この節の解説を参照して、クラスタ内での各種の EJB の機能について理解します。EJB のデプロイメント記述子でクラスタ化を有効にします。クラスタ化に関する XML デプロイメント要素については、『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
EJB またはカスタム RMI オブジェクトを開発する場合は、『Oracle Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照して、クラスタ化されたオブジェクトを JNDI ツリーにバインドする実装について理解してください。
JDBC は、クライアントと DBMS 間の高度にステートフルなプロトコルです。JDBC では、DBMS 接続とトランザクションのステートが、DBMS プロセスとクライアント (ドライバ) の間のソケットに直接関連付けられます。このため、接続のフェイルオーバはサポートされません。WebLogic Server インスタンスが消滅すると、そのインスタンスで管理していた JDBC 接続も消滅し、DBMS は処理中のトランザクションをロールバックします。関連するアプリケーションは、現在のトランザクションを最初から始める必要があります。切断された接続に関連付けられているすべての JDBC 接続も切断されます。クラスタ化された JDBC では、簡単に再接続できます。外部クライアント アプリケーションの WebLogic データ ソースはクラスタ対応なので、接続をホストしていたサーバ インスタンスで障害が発生した場合でも、クライアントは他の接続を要求できます。
データベース インスタンスをすでにレプリケートし、同期させている場合には、JDBC マルチ データ ソースを使用してデータベースのフェイルオーバをサポートできます。その場合、データ ソースが存在しないか、またはデータ ソースからのデータベース接続がダウンしたために、クライアントがマルチ データ ソース内のあるデータ ソースから接続を取得できない場合でも、WebLogic Server は、データ ソースのリストの次のデータ ソースから接続を取得しようとします。
JDBC オブジェクトのクラスタ化の手順については、「クラスタ化された JDBC をコンフィグレーションする」を参照してください。
|
注意 : 予約時に接続をテストするように、マルチ データ ソースに割り当てられたデータ ソースをコンフィグレーションする必要があります。これは、データ ソースの接続が良好かどうかを確認し、マルチ データ ソースがリスト内の次のデータ ソースにフェイルオーバするタイミングを認識する唯一の方法です。 |
