クラスタ動作シーケンス

クラスタ動作シーケンス

Tomcatのクラスタは表1のような流れで動作します。今回は例として2台構成のクラスタを考え、サーバ名をtomcat1、tomcat2とし、クラスタの前段にはロードバランサが存在するとします。また本連載ではTomcat 5.0.28を使用します。

それでは各項目について、解説します。

tomcat1を起動

デプロイされるアプリケーションの"web.xml"に「distributable」要素が記述されていた場合に は、"StandartManager"のかわりに"DeltaManager"などのセッションマネージャを生成します。またクラスタのメンバーシップ サービス、レプリケーションサービスを開始します。

tomcat2を起動

tomcat1と同様に起動され、メンバーシップサービスによりtomcat1とtomcat2がお互いを認識します。tomcat2は後からクラスタに参加する形になるため、セッションレプリケーション情報をtomcat1から取得する必要があります。

tomcat2がtomcat1からセッションレプリケーション情報を得て、クラスタと同期が取れた時点でリクエストを受け付けられるようになります。tomcat1からレスポンスが得られなかった場合はタイムアウトして、その旨がログ出力されます。

tomcat1へのリクエスト

tomcat1がリクエストを受け、セッションを生成します。リクエストの処理が終了した後にセッションレプリケーションが行われます。セッションをレプリケーションすべきであると判定されれば、Senderの設定に基づきTCPを用いてtomcat2へセッションがレプリケーションされます。

tomcat1がダウン

tomcat1がクラッシュもしくはメンテナンスなどの理由でシャットダウンされた場合、tomcat2はメンバーシップサービスにより tomcat1のダウンを知ります。tomcat2はtomcat1をメンバーシップリストから削除し、今後tomcat1へのセッションレプリケーショ ンは行いません。

またロードバランサも独自にtomcat1のダウンを判別し、以降のアクセスはtomcat2へ割り振ります。tomcat2ではこれまでにレプリケーションされたセッション情報を保持していますので、継続したセッションの処理を行うことが可能です。

tomcat1が再起動

tomcat1が再起動されたときには、「2のtomcat2を起動」した場合と同様にクラスタへ参加し、セッションレプリケーション情報をtomcat2から取得してクラスタと同期を取ります。

この時点でtomcat1は再度リクエストを受け付けられる状態になります。しかしロードバランサがtomcat1の生存を確認し再度リクエストを割り振ることを決定するタイミングは、ロードバランサの設定によります。

セッションの無効化

セッションが明示的に無効化（invalidateメソッド）された、あるいはタイムアウトした場合は、セッションのレプリケーションを行うかわりにセッションの無効化を指示します。