 |
|
| Javaアプリケーションサーバのクラスタリング機能比較
|
第２回：Tomcatのクラスタ設定
著者：サンモアテック 津田 新吾 2005/10/31
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| クラスタ動作シーケンス
|
Tomcatのクラスタは表1のような流れで動作します。今回は例として2台構成のクラスタを考え、サーバ名をtomcat1、tomcat2とし、クラスタの前段にはロードバランサが存在するとします。また本連載ではTomcat 5.0.28を使用します。
- tomcat1を起動
- tomcat2を起動
- tomcat1へのリクエスト
- tomcat1がダウン
- tomcat1が再起動
- セッションの無効化
表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 次のページ
|
|
|
|
|
著者プロフィール
株式会社サンモアテック 津田 新吾
技術開発事業部。
某電線メーカーでカーナビの経路案内・経路計算などの組込みソフトウェア開発を10年近く経験。その後現在の(株)サンモアテックに入社。以来、携帯Javaでの業務支援システムやオープンソースのエンタープライズ適用、Webサービスなど主にサントリーグループ向けの新技術開発に従事している。
|
|
|
|
|
|
