 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| クラスタ動作シーケンス | ||||||||||||
|
Tomcatのクラスタは表1のような流れで動作します。今回は例として2台構成のクラスタを考え、サーバ名をtomcat1、tomcat2とし、クラスタの前段にはロードバランサが存在するとします。また本連載ではTomcat 5.0.28を使用します。
表1：クラスタの動作の流れ それでは各項目について、解説します。 |
||||||||||||
| 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メソッド）された、あるいはタイムアウトした場合は、セッションのレプリケーションを行うかわりにセッションの無効化を指示します。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
