フェイルオーバー

フェイルオーバー

Tomcatサーバにリクエストを転送したけれどもTomcatがダウンしていた場合、mod_jkはクラスタ内の次のサーバにリクエストを割り当て、クライアントに異常事態が発生したことを気づかせないような自然なフェイルオーバーを実現します。

一度ダウンと判定されたサーバに対してはその後リクエストを振らないようになりますが、mod_jkは一定周期でサーバの生死確認を行うので、その時に正常稼動を再度確認できれば、またロードバランスの対象とします。

スティッキーセッションを使うことで、セッションを利用するアプリケーションの場合でも同じサーバにアクセスし続けることでセッションを維持できて いたのですが、そのサーバがダウンしてしまったら、mod_jkは別のサーバにリクエストを割り振るしかありません。当然その新しく割り当てられたサーバ はセッション情報を持っていないため、処理を継続することができなくなり、新規セッションを新たに開始しなければなりません。

この時にユーザが多大な苦労をして入力してきた情報が失われたとしたら、大クレームにつながりかねません。

Tomcat 5.0からはこのような事態を避けるべく、セッション情報を含めたフェイルオーバーが実現されたのですが、そのためにはセッション情報をクラスタ内で共有しておく必要があることから、セッションレプリケーションの機能が標準搭載されることとなりました。

現在Tomcatのセッションレプリケーションには次の3種類の実装があります。

"PersistenceManager"を使用

複数のサーバでファイルシステムを共有し、セッション永続先として用いる。

"JDBCManager"を使用

複数のサーバでDataBaseを共有し、セッション永続先として用いる。

"catalina-cluster.jar"を使用

TCPソケットを使用したインメモリセッションレプリケーション。

本連載ではこの"catalina-cluster.jar"を使用を扱います。

Tomcatクラスタはマルチキャスト通信を通じて構成され、どちらかのサーバに届いたセッション情報はTCPソケット通信によりもう一方のサーバ にも伝えられます。情報を受信したサーバはそのセッション情報を保持しておき、万一どちらか一方のサーバがダウンすれば、もう一方のサーバがそのセッショ ンを引き継ぎます。

Tomcat 5.0ではセッションレプリケーションを含むクラスタ機能を実現するためのクラスが追加されており、クラスタ機能を有効にするためには、"server.xml"の「Cluster」要素を編集するだけで実装ができ、内部構造は図3のような構造になっています。

図3：Server - ... - Cluster - Membershipの要素の階層図

次に図3のクラスタの各要素について説明します。

Cluster

クラスタの各要素を統合します。実装クラスとしては"org.apache.catalina.cluster.tcp.SimpleTcpCluster"が用意されています。

SessionManager

セッションマネージャではセッションの管理方法を定義します。図3ではClusterの子要素として表現していますが、"server.xml"では「Cluster」要素の属性で定義します。セッションレプリケーションを行うには、実装クラスとし て"org.apache.catalina.cluster.session.DeltaManager"もしく は"org.apache.catalina.cluster.session.SimpleTcpReplicationManager"が選択できま す。

どちらもクラスタを構成する全サーバに対してインメモリのセッションレプリケーションを行いますが、"SimpleTcpReplicationManager"がセッション情報のすべてをレプリケーションするのに対し て"DeltaManager"はセッション情報の差分のみレプリケーションするため、後者のほうがパフォーマンスが向上しています。基本的には"DeltaManager"を使用すればよいでしょう。

「Cluster」要素の属性の"useDirtyFlag"がtrueの場合、"setAttribute"メソッドあるいは"removeAttribute"メソッドが呼ばれない限り、レプリケーションは行われません。

一方falseの場合はリクエストごとにレプリケーションが行われます。trueに設定し、変更したセッション情報に対して明示的にsetAttributeメソッドを呼ぶことによって、レプリケーションの回数を大きく減らすことができます。