|
|
|
|
|
|
| | | |
HTTP セッション ステートのレプリケーションについて
以下の節では、HTTP セッション ステートのレプリケーションについて説明します。
概要
サーブレットと JSP の HTTP セッション ステートで自動フェイルオーバをサポートするために、WebLogic Server ではメモリ内のセッション ステート オブジェクトがレプリケートされます。このプロセスでは、クライアントが最初に接続する WebLogic Server でプライマリ セッション ステートが作成され、クラスタ内の別の WebLogic Server インスタンスでそのセッション ステートのセカンダリ レプリカが作成されます。レプリカは常に最新の状態に保たれるので、サーブレットのホスト サーバで障害が起きた場合に使用することができます。インスタンス間でステートをコピーするプロセスは、インメモリ レプリケーションと呼ばれます。インメモリ レプリケーションをセットアップする方法については、 インメモリ HTTP レプリケーションをコンフィグレーションするを参照してください。
注意: WebLogic Server では、ファイルベースまたは JDBC ベースの永続性を利用して、サーブレットまたは JSP の HTTP セッション ステートを維持することもできます。それらの永続性の詳細については、『WebLogic HTTP サーブレット プログラマーズ ガイド』の「セッションの永続化」を参照してください。
HTTP セッション ステートのレプリケーションに関する必要条件
HTTP セッション ステートのインメモリ レプリケーションを利用するには、以下のいずれかを使用して WebLogic Server クラスタにアクセスする必要があります。
プロキシの必要条件
WebLogic プロキシ プラグインでは、クラスタ化されたサーブレットまたは JSP のホストである WebLogic Server インスタンスのリストが維持され、単純なラウンドロビン方式を使用して HTTP リクエストがそれらのインスタンスに転送されます。プロキシでは、WebLogic Server のインスタンスで障害が起きた場合にクライアントの HTTP セッション ステートのレプリカを見つけるためのロジックも提供されます。
以下の Web サーバとプロキシ ソフトウェアの組み合わせがサポートされています。
HttpClusterServlet
ロード バランサの必要条件
プロキシ プラグインではなくロード バランシング ハードウェアを使用する場合は、以下の機能をサポートするハードウェアを使用する必要があります。
パッシブなクッキーの永続性では、ロード バランサを介して WebLogic Server がクライアントにクッキー（レプリケートされた HTTP セッション ステートの位置情報を格納する）を書き込むことができます。ロード バランサでは、クライアントのクッキーにある識別子文字列を読み取って、クライアントとプライマリ WebLogic Server（HTTP セッション ステートのホスト）の関係を維持します。
ロード バランサが WebLogic Server クッキーを変更しないのであれば、特定のアクティブなクッキーの永続性メカニズムを WebLogic Server クラスタで使用することもできます。
SSL 永続性を使用する場合、クライアントと WebLogic Server クラスタ間のデータの暗号化および復号化は、すべてロード バランシング製品が行います。そして、ロード バランサは、WebLogic Server がクライアントに挿入したプレーン テキストのクッキーを使用して、クライアントとクラスタ内の特定サーバ間の関係を維持します。
WebLogic Server でサポートされているロード バランシング ソリューションの設定については、「 ロード バランシング ハードウェアをコンフィグレーションする（省略可能）」を参照してください。Alteon ロード バランシング製品の永続性メカニズムをコンフィグレーションする方法については、「 クラスタに関する Alteon ハードウェアのコンフィグレーション」を参照してください。BIG-IP ロード バランサをコンフィグレーションする方法については、「 クラスタに関する BIG-IP ハードウェアのコンフィグレーション」を参照してください。
クラスタ環境でデプロイするサーブレットまたは JSP を開発するときには、以下の事項に注意してください。
セッション データはシリアライズ可能でなければならない
HTTP セッション ステートのインメモリ レプリケーションをサポートするには、すべてのサーブレットと JSP のセッション データがシリアライズ可能でなければなりません。サーブレットまたは JSP でシリアライズ可能なオブジェクトと不可能なオブジェクトが組み合わせて使用される場合、WebLogic Server ではシリアライズ不可能なオブジェクトのセッション ステートがレプリケートされません。
setAttribute でセッション ステートを変更する
javax.servlet.http.HttpSession を実装する HTTP サーブレットでは、HttpSession.setAttribute（廃止された putValue に代わるもの）を使用して、セッション オブジェクトの属性を変更する必要があります。setAttribute でセッション オブジェクトの属性を設定すると、そのオブジェクトと属性は、インメモリ レプリケーションを使ってクラスタ内で複製されます。他の設定メソッドを使ってセッション内のオブジェクトを変更した場合は、WebLogic Server によってその変更が複製されることはありません。
同様に、セッション オブジェクトから属性を削除するには、removeAttribute（廃止された removeValue に代わるもの）を使用する必要があります。
注意: 非推奨の putValue メソッドおよび removeValue メソッドの使用も、セッション属性の複製を招きます。
セッション オブジェクトのシリアライゼーション オーバーヘッドに注意する
セッション データをシリアライズすると、セッション ステートのレプリケートでオーバーヘッドが生じます。オーバーヘッドは、シリアライズされるオブジェクトのサイズに比例して大きくなります。セッションで非常に大きなオブジェクトを作成する予定の場合は、あらかじめサーブレットをテストして、パフォーマンスが適切なレベルになるようにください。
フレームを使用するアプリケーションではセッションのアクセスを調整しなければならない
複数のフレームを利用する Web アプリケーションを設計する場合は、指定したフレームセットのフレームが同時にリクエストを送らないようにすることを心がけてください。たとえば、論理的にはクライアントが 1 つのセッションを作成する場合でも、1 つのフレームセットの複数のフレームがクライアント アプリケーションに代わって複数のセッションを作成する可能性があります。
クラスタ環境では、フレーム リクエストを適切に調整しないとアプリケーションの予期しない動作が発生することがあります。プロキシ プラグインは各リクエストを他のリクエストに関係なく処理するので、複数のフレーム リクエストによって、アプリケーションとクラスタ化されたインスタンスとの関連付けが「リセット」される場合が考えられます。また、フレームセット内の複数のフレームを介して同じセッションの属性を変更することで、アプリケーションがセッション データを壊してしまう可能性もあります。
アプリケーションの予期しない動作を防ぐには、フレームを使用してセッション データにアクセスする場合のプランニングに十分な注意を払います。以下のいずれかの規則に従うと、よくある問題を防ぐことができます。
レプリケーション グループの使用
デフォルトの WebLogic Server では、プライマリ セッション ステートのホスト マシンとは別のマシンにセッション ステートのレプリカが作成されます。WebLogic Server では、レプリケーション グループを使用してセカンダリ ステートの配置場所をもっと詳しく指定できます。レプリケーション グループは、セッション ステートのレプリカを格納するために優先的に使用されるクラスタ化されたインスタンスのリストです。
WebLogic Server Administration Console では、個々のサーバ インスタンスのホストとなるユニークなマシン名を定義できます。それらのマシン名を新しい WebLogic Server インスタンスに関連付けると、そのサーバがシステムのどこにあるのかを識別できます。通常、マシン名はマルチホーム マシン上のサーバを表すために使用します。たとえば、同じマルチホーム マシン上、または同じサーバ ハードウェア上で動作するすべてのサーバ インスタンスに同じマシン名を割り当てます。
マルチホームのマシンを使用しない場合、または単一のハードウェア上で複数の WebLogic Server を実行しない場合は、WebLogic Server のマシン名を指定する必要はありません。マシン名が関連付けられていないサーバは、自動的に、物理的に異なるハードウェア上にあるものとして扱われます。マシン名の設定の詳細については、「 マシン名を定義する（省略可能）」を参照してください。
クラスタ化されたサーバ インスタンスをコンフィグレーションするときには、そのサーバで作成されたプライマリ HTTP セッション ステートのレプリカのホストとして検討される優先的なセカンダリ レプリケーション グループだけでなく、レプリケーション グループでのメンバシップも割り当てることができます。
クライアントがクラスタ内のサーバに接続されて、プライマリ セッション ステートが作成されると、そのプライマリ ステートのホスト サーバではセカンダリのホスト サーバを決めるためにクラスタ内の他のサーバがランク付けされます。サーバのランクは、そのサーバがプライマリ サーバと同じマシン上にあるかどうか、およびプライマリ サーバの優先レプリケーション グループに属しているかどうか、という 2 つの情報を組み合わせて判断されます。次の表は、クラスタ内のサーバの相対的なランキングを示しています。
|
サーバのランク |
別のマシンにあるのか |
優先レプリケーション グループのメンバーか |
|---|---|---|
|
1 |
はい |
はい |
|
2 |
いいえ |
はい |
|
3 |
はい |
いいえ |
|
4 |
いいえ |
いいえ |
プライマリ WebLogic Server では、前述のランキング ルールを使用してクラスタの他のメンバーがランク付けされ、セカンダリ セッション ステートのホストとなる最高ランクのサーバが選択されます。たとえば、次の図は地理的な区別に基づいてコンフィグレーションされたレプリケーション グループを示しています。
この例では、サーバ 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 と一緒にダウンする可能性がある）、かつ優先的なセカンダリ グループのメンバーではないからです。
クラスタ化された WebLogic Server インスタンスのマシン名を定義する手順については、「 マシン名を定義する（省略可能）」を参照してください。レプリケーション グループでのサーバのメンバシップをコンフィグレーションする手順、あるいはサーバの優先的なセカンダリ レプリケーション グループを割り当てる手順については、「 レプリケーション グループをコンフィグレーションする（省略可能）」を参照してください。
クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス
この節では、WebLogic プロキシ プラグインを含むコンフィグレーションにおいて、クラスタ化されたサーブレットおよび JSP に WebLogic Server がどのようにしてアクセスするかについて説明します。
WebLogic プロキシ プラグインは、クラスタ化されたサーブレットまたは JSP のホストである WebLogic Server インスタンスのリストを管理し、ラウンドロビン方式を使用してそれらのインスタンスに HTTP リクエストを転送します。プラグインはまた、WebLogic Server インスタンスで障害が発生した場合に、クライアントの HTTP セッション ステートのレプリカの位置を特定するために必要なロジックも備えています。
WebLogic Server では、Web サーバとプロキシ プラグインの以下の組み合わせがサポートされています。
プロキシのセットアップ手順については、『管理者ガイド』を参照してください。
次の図は、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 書き換えを利用できます。
URL 書き換えを利用したセッション レプリカの追跡
デフォルト コンフィグレーションの WebLogic Server では、クライアントサイドのクッキーを使用して、クライアントのサーブレット セッション ステートのホストであるプライマリ サーバとセカンダリ サーバが追跡されます。クライアント ブラウザでクッキーが無効になっている場合、WebLogic Server では URL 書き換えを利用してもプライマリ サーバとセカンダリ サーバを追跡できます。URL 書き換えを利用する場合は、クライアント セッション ステートの両方の位置が、クライアントとプロキシ サーバの間で渡される URL に挿入されます。この機能をサポートするには、WebLogic Server クラスタで URL 書き換えを有効にする必要があります。詳細については、「セッション クッキーのコンフィグレーション」を参照してください。
プロキシ フェイルオーバのプロセス
プライマリ サーバで障害が起きると、HttpClusterServlet ではクライアントのクッキー情報を利用してセッション ステートのレプリカのホストであるセカンダリ WebLogic Server の位置が確認されます。HttpClusterServlet では、クライアントの次の HTTP リクエストが自動的にセカンダリ サーバにリダイレクトされます。フェイルオーバは、クライアントには意識されません。
障害の後は、WebLogic Server B がサーブレット セッション ステートのプライマリ サーバになり、新しいセカンダリが作成されます（上の例ではサーバ C）。HTTP 応答では、今後のフェイルオーバに備えて、新しいプライマリ サーバとセカンダリ サーバを反映するためにプロキシによってクライアントのクッキーが更新されます。
2 つのサーバで構成されるクラスタでは、クライアントはセカンダリ セッション ステートのホスト サーバに透過的にフェイルオーバされます。ただし、もう 1 つの WebLogic Server がクラスタで利用可能にならない限り、クライアントのセッション ステートのレプリケーションは継続されません。たとえば、元のプライマリ サーバが再起動されるか、ネットワークに再び接続されると、そのサーバはセカンダリ セッション ステートのホストとして使用されます。
クラスタ化されたサーブレットと JSP へのロード バランシング ハードウェアを利用したアクセス
この節では、ロード バランシング ハードウェアを含むコンフィグレーションにおいて、クラスタ化されたサーブレットおよび JSP に WebLogic Server がどのようにしてアクセスするかについて説明します。外部ロード バランサのセットアップ手順については、 ロード バランシング ハードウェアをコンフィグレーションする（省略可能）を参照してください。
ロード バランシング ハードウェアを通じたダイレクトなクライアント アクセスをサポートするために、WebLogic Server のレプリケーション システムでは、クライアントがフェイルオーバ先のサーバとは無関係にセカンダリ セッション ステートを使用できます。WebLogic Server バージョン 6.1 でも、プライマリ サーバとセカンダリ サーバの位置を記録する手段としてクライアントサイド クッキーまたは URL 書き換えが継続して使用されます。ただし、この情報はサーブレット セッション ステートの位置の履歴としてのみ使用されます。ロード バランシング ハードウェアを通じてクラスタにアクセスする場合、クライアントは障害発生後にサーバを能動的に見つける手段としてはクッキー情報を使用しません。以下の手順は、HTTP セッション ステートのレプリケーションをロード バランシング ハードウェアと共に使用する場合の接続とフェイルオーバのプロセスを示しています。
Web アプリケーションのクライアントがパブリックな IP アドレスを使用してサーブレットを要求する場合は、次のようなプロセスが行われます。
注意: クッキーが無効のクライアントをサポートするには、WebLogic Server の URL 書き換え機能を有効にする必要があります。詳細については、「URL 書き換えの使用」を参照してください。
ロード バランシング ハードウェアを利用したフェイルオーバ
クライアントのセッションの途中でサーバ A に障害が起きると、そのクライアントによるサーバ A への次の接続要求は失敗します。
接続が失敗した場合は、次のようなプロセスが行われます。
障害後の遅延レプリケーション
プロキシとロード バランシングの例はどちらも、WebLogic Server のセッション ステート レプリケーションの重要な性質を示しています。セッション ステートのホストであるサーバで障害が発生した後、そのサーバのセッション ステートのレプリケーションは、クラスタ内の別のサーバ上にあるセッション ステートへのアクセスをクライアントが試みるのに呼応して遅延方式で実行されます。
たとえば、 ロード バランシング ハードウェアを利用したフェイルオーバで説明したシナリオでは、サーバ A で障害が発生しても、クラスタで直ちにサーバ C 上にセッション ステートの新しいコピーが生成されるわけではありません。実際には、クライアントがサーバ C に接続してセッション ステートの使用を試みた時点ではじめて、セッション ステートがサーバ C にコピーされます（クライアントがサーバ C ではなくサーバ B に再接続した場合、クラスタはやはりセッション ステートをサーバ C にコピーして、アクティブなセッション ステートのコピーがクラスタ内に少なくとも 1 つは存在することを保証します）。
障害後の遅延レプリケーションには、2 つの重要な利点があります。
遅延レプリケーション動作には、クラスタに WebLogic Server インスタンスが 2 つしかない特殊な状況でレプリケーションが失敗するわずかなリスクが伴います。次のシナリオは、サーバ A とサーバ B の 2 つのノードで構成されるクラスタで起こりうるレプリケーション失敗の例を示します。
この時点の状態では、サーバ B に障害が発生するとクライアントはセッション ステートを失います。
このような状況でセッション ステートが失われる危険性を回避するためには、3 つ以上の WebLogic Server インスタンスを使用してクラスタを構成するようにします。
|
|
|