セッションレプリケーションとフェイルオーバーの動作

この節では、セッションレプリケーションの動作について詳しく説明します。

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 以外のアプリケーションを使用する場合には、セッションデータをレプリケートできません。