セッションレプリケーションとは、あるセッション内に格納されたデータを異なるインスタンス間でレプリケートするために使用される機構のことです。ただし、レプリケート対象インスタンスは、同じクラスタの一部になっている必要があります。クラスタ環境でセッションレプリケーションが有効になると、セッションデータの全体がレプリケート対象インスタンスにコピーされます。ただし、セッションレプリケーションの処理では、セッション内の直列化可能でない属性やインスタンスに固有のあらゆるデータはコピーされません。
セッションレプリケーションと負荷分散を組み合わせると、Web アプリケーションのフェイルオーバー機能を効率的に実現できます。
この節では、セッションレプリケーションの動作について詳しく説明します。
Web Server は Web 要求の終了時に、サーバー構成ファイル server.xml 内に格納されたセッションレプリケーション構成に基づいてセッションデータをコピーする必要があるかどうかを判定します。
ここで、4 つのインスタンスが 1 つのクラスタを形成しており、管理サーバー上でセッションレプリケーションが有効になっている、というユースケースを考えます。
4 つのインスタンス (A、B、C、および D) が 4 つのノード上で稼働している Web Server クラスタにおけるセッションレプリケーションの手順は、次のとおりです。
インスタンス A は D のバックアップであり、B は A のバックアップであり、C は B のバックアップであり、D は C のバックアップです。これで完全なバックアップリングが形成されます。
クラスタ内の各インスタンスは、クラスタ内のすべてのインスタンスの静的リストと、アクティブなバックアップインスタンスを追跡します。
構成によっては、各要求の終了時に、セッションデータがバックアップインスタンスに同期的に送信されます。
Web Server クラスタ環境におけるフェイルオーバーの手順は、次のとおりです。
インスタンス A で障害が発生すると、ロードバランサによってインスタンス A 宛のすべての受信 Web 要求がクラスタ内の残りのインスタンスへリダイレクトされるとともに、バックアップリングが次のように構成し直されます。
D は、自身のバックアップである A が停止したことを検出し、順序付きリスト上で A の次にあるインスタンスを、自身の新しいバックアップインスタンスとして選択します。
この場合は B が選択され、D は、B とのバックアップ接続を新たに確立します。B はこの時点で、2 つのバックアップを保持しています。A の読み取り専用バックアップと、D のアクティブなバックアップです。
これでバックアップリングが完結し、B が C にバックアップされ、C が D にバックアップされ、D が B にバックアップされるようになります。
障害の発生したインスタンス A が再度利用可能になると、A は、自身の指定されたバックアップインスタンスである B に再結合メッセージを送信することでバックアップリングに再度参加し、B とのバックアップ接続を確立します。
D が、A から正常な ping リターンを受信するか A から何らかのメッセージを受信することによって、A がオンラインになったことを検出すると、
D は、A とのバックアップ接続を確立し、B とのバックアップ接続を終了します。
Web Server 7.0 のセッションレプリケーションでサポートされていない機能は、次のとおりです。
2 つ以上のインスタンスで同時に発生した障害を復旧すること。
2 つの障害間の間隔が、復活したインスタンスが完全に復旧するのに必要な時間よりも長くなければいけません。
複数のインスタンスへのセッションのバックアップ。通常の動作では、どのセッションのコピーも 2 つしか存在しません。主要セッションとバックアップセッションです。
セッションの持続性: セッションは、フェイルオーバーの目的で別のインスタンスのメモリー内にバックアップされるだけです
Web Server がセッションレプリケーションをサポートするのは、Java Web アプリケーションに対してだけです。CGI や PHP など、Java 以外のアプリケーションを使用する場合には、セッションデータをレプリケートできません。
クラスタのセッションレプリケーションの有効化は、管理コンソール、CLI のいずれかを使って行えます。セッションレプリケーションを有効化する前に、ブラウザの Cookie が有効になっていることを確認してください。
server.xml ファイルには、セッションレプリケーションに関する情報が含まれています。セッションレプリケーションが有効化されたサンプル server.xml ファイルを、次に示します。
<cluster> <local-host>hostA</local-host> <instance> <host>hostB</host> </instance> <instance> <host>hostC</host> </instance> <instance> <host>hostD</host> </instance> <instance> <host>hostA</host> <session-replication/> </cluster>
次の各要素のデフォルト値を使用する場合、それらの要素のエントリは server.xml 構成ファイル内に含まれません。
Port number (デフォルトは 1099) |
Protocol (デフォルトは jrmp) |
Encrypted (デフォルトは false) |
Getattribute Triggers Replication (デフォルトは true) |
Replica Discovery MaxHopss (デフォルトは –1) |
Startup Discovery Timeout (デフォルトは ? |
) |
Cookie Name (デフォルトは CLUSTERSESSIONLOCATOR) |
これらのセッションレプリケーションプロパティーの詳細については、『Sun Java System Web Server 7.0 Administrator’s Configuration File Reference』を参照してください。
サーバーがセッションをレプリケートできるようにするには、Web アプリケーションでもセッションレプリケーションを有効にする必要があります。
Web アプリケーションのセッションレプリケーションを有効にするには、<web-application>/WEB-INF ディレクトリに格納された sun-web.xml 構成ファイルを変更します。
sun-web.xml で次の変更を行う必要があります。
要素 <session-manager/> を <session-manager persistence-type="replicated"> に変更します。
セッションレプリケーションが有効化されたサンプル sun-web.xml ファイルを、次に示します。
<sun-web-app> <session-config> <session-manager persistence-type="replicated"> </session-manager> </session-config> </sun-web-app>
sun-web.xml ファイルを変更したあと、Web アプリケーションをビルドし直すかアプリケーションの JAR ファイルを作成し直すことで、Web アプリケーションアーカイブ (WAR ファイル) を作成します。
すべてのインスタンスを再起動することで、その Web アプリケーションがすべてのインスタンスで利用可能になるようにします。
Web アプリケーションには、クラスタ内のすべてのインスタンスからアクセスできます。Web アプリケーションにアクセスするには、ブラウザで次のように入力します。
http://webserver-name/webapplication-name/
すべてのノードからアクセス可能なディレクトリが、配備用のアプリケーションを格納するための最良の方法です。ただし、このディレクトリには、管理サーバーからアクセスできる必要はありません。Web アプリケーションのサイズが 1M バイトを超える場合には、ディレクトリベースの配備を行うことをお勧めします。
検索コレクションを作成する場合、すべてのノードからアクセス可能な共通ディレクトリ内に検索コレクションが存在していることを確認してください。