|
| |
| Sun Java System Application Server Enterprise Edition 7 2004Q2 入門ガイド | |
第 4 章
クラスタ JSP サンプルアプリケーションのチュートリアルこの章では、ロードバランサプラグインを使用した単純な HTTP フェイルオーバーについて記載しています。HTTP ロードバランサプラグインがサポートする機能をすべて記述しているわけではありません。ロードバランサプラグインが備える他の機能の詳細については、『Sun Java System Application Server Administration Guide』を参照してください。
この章には次の節があります。
クラスタ JSP サンプルアプリケーションのチュートリアルを使用する準備このチュートリアルを使用するためには、次の準備が必要になります。
- 第 3 章「エンタープライズ機能の設定のチュートリアル」のすべてのチュートリアル手順が正常に完了していること
- 必要に応じて、サンプルアプリケーションのコピーを作成すること
アプリケーションサーバーのインストールをほかのユーザーと共有しているか、システムユーザー ID にアプリケーションサーバーがインストールされている場所への書き込み権がない場合は、サンプルのコピーを作成する必要があります。
サンプルをコピーするには、install_dir/samples ディレクトリを、ユーザー ID に書き込み権がある場所にコピーします。
次に例を示します。
cp -r install_dir/samples user_sample_directory
samples ディレクトリには、このマニュアルで使用するサンプルが含まれているサブディレクトリ ee-samples があります。
このマニュアルの手順に従ってサンプルのコピーを使用する場合、install_dir/samples/ と表記されるディレクトリは、サンプルアプリケーションの専用コピーが保存されているディレクトリを指します。
クラスタ JSP のサンプルアプリケーションのクラスタへの配備クラスタ JSP のサンプルアプリケーションは、JSP に対する要求をクラスタ内のアプリケーションサーバー間でロードバランスを行う方法を示します。アプリケーションサーバーが停止した場合でも、HTTP セッション情報を持続させる方法を示すショッピングカートがあります。
このサンプルアプリケーションには、そのままの状態で Web アプリケーションの配備に使用できる WAR ファイルが付属しています。このため、配備にあたっては、必ずしもコンパイルやアセンブルは必要ではありません。
サンプルアプリケーションをクラスタに配備するには、最初にクラスタ内のすべてのインスタンスに配備する必要があります。
cladmin コマンドを使って、アプリケーションをクラスタ内のすべてのインスタンスに、同時に配備します。cladmin コマンドにより、クラスタ内のすべてのインスタンスで同時に asadmin コマンドが実行されます。cladmin コマンドは install_dir/bin にあります。
この節には次の項目があります。
cladmin コマンドの入力ファイル
cladmin コマンドは、clinstance.conf と clpassword.conf という、2 つの入力ファイルを使います。
これらのファイルは install_config_dir にあります。これらのファイルは以前に clsetup を実行するために使用したので、環境に適した値が含まれているはずです。
cladmin deploy を実行するために指定する必要がある値の多くはこれらのファイルに含まれているため、deploy コマンドは、最低限のオプションを付けるだけで実行できます。
cladmin コマンドの構文
cladmin コマンドの構文は次のとおりです。
cladmin [--help] [--instancefile instance_file_location] [--passwordfile password_file_location] asadmin_command
各変数の意味は次のとおりです。
入力ファイルがデフォルトの場所である /etc/opt/SUNWappserver7 にある場合は、instancefile オプションと passwordfile オプションを省略して、コマンドを次のように実行できます。
cladmin asadmin_command
cladmin deploy の実行
アプリケーションをクラスタ内のすべてのインスタンスに配備するには、次のように入力します。
cladmin deploy filepath
サンプルに付属の WAR ファイルを使って、サンプルを Web アプリケーションとして配備できます。filepath は、WAR ファイルへのパスです。
たとえば、クラスタ JSP アプリケーションがデフォルトの場所にある場合は、次のように入力します。
cladmin deploy¥
/opt/SUNWappserver7/samples/ee-samples/clusterjsp/clusterjsp.warPATH 変数が設定されている場合は、WAR ファイルが置かれているディレクトリに移動して、そこからアプリケーションを配備することもできます。次に例を示します。
cd install_dir/samples/ee-samples/clusterjsp
cladmin deploy clusterjsp.war
cladmin deploy コマンドを実行すると、アプリケーションがクラスタ内の各インスタンスに配備されるときにメッセージが表示されます。
エラーが発生した場合は、/var/tmp/cladmin.log にあるログファイルで詳細を確認してください。
注
ルートとして実行しているときに、ルートの PATH 変数が設定されていない場合は、任意のディレクトリから cladmin を実行することができない場合があります。install_dir/bin ディレクトリに変更してから、コマンドプロンプトに ./cladmin asadmin_command と入力します。
cladmin コマンドでサポートされている asadmin コマンド
cladmin コマンドを使って、クラスタ内の各アプリケーションサーバーインスタンスに対して、次の asadmin コマンドを同時に実行できます。ただし、configure-session-persistence は除きます。
cladmin コマンドの詳細については、『Sun Java System Application Server Administration Guide』を参照してください。
要件と制限事項
cladmin コマンドには、次のような要件と制限があります。
- クラスタに組み込まれたすべてのインスタンスには、管理者用の同じパスワードが必要になります。ユーザー名は、clinstance.conf ファイルの user プロパティ名で指定できます。
- このコマンドの起動に先立ち、クラスタに含まれるすべてのアプリケーションサーバーインスタンスで、対応する管理サーバーを起動しておくことが必要です。
- このコマンドの入力ファイルに指定した値は、クラスタ内のすべてのインスタンスに対し、一律に設定されます。cladmin コマンドは、各インスタンスを別の値で設定するようには設計されていません。たとえば、このコマンドでは、インスタンスごとに設定が異なる JDBC 接続プールは作成できません。
cladmin を使ったアプリケーションサーバーインスタンスの起動サンプルアプリケーションを配備したら、サーバーインスタンスが稼働していることを確認します。
アプリケーション配備の確認アプリケーションが配備されたら、それを Sun Java System Application Server インスタンスで実行して、配備をテストできます。サンプルアプリケーションを実行する手順は、次のとおりです。
- ブラウザから次の URL にアクセスします。
http://host:application_server_instance_port/clusterjsp
次に例を示します。
http://test.sun.com:81/clusterjsp
- このサンプルアプリケーションのページが表示されます。
図 4-1 クラスタ JSP のサンプルアプリケーションページ
エラーが発生した場合は、「アプリケーションサーバーインスタンスへの配備に対するトラブルシューティング」を参照してください。
- セッション属性フィールドに情報を入力して、「ADD SESSION DATA (セッションデータを追加)」をクリックします。
データが表示されます。
- 2 番目のインスタンスに対する配備を確認するには、URL にその他のインスタンスのポートとホスト名を入力します。
http://host:application_server_instance_port/clusterjsp
次に例を示します。
http://test.sun.com:82/clusterjsp
これらの URL で、アプリケーションがアプリケーションサーバーインスタンスに配備されたことを確認します。アプリケーションは loadbalancer.xml 内のクラスタにまだ追加されていないため、まだ Web サーバーからは確認できません。
アプリケーションサーバーのサンプルの監視
アプリケーションサーバーインスタンスのイベントログファイルを調べることで、サンプルアプリケーションを監視できます。アプリケーションサーバーインスタンスごとにイベントログがあります。
この節には次の項目があります。
管理インタフェースによるログの表示
管理インタフェースを使ってサーバーインスタンスのログファイルを表示するには、次のようにします。
25 項目より多くのログを表示するには、「表示するイベント数」に表示する項目数を入力し、「了解」をクリックして表示を更新します。
管理インタフェースを使ってアプリケーションサーバーインスタンスの HTTP アクセスログを表示するには、次のようにします。
サーバーインスタンスの HTTP アクセスログには、サーバーインスタンスに対するサンプルアプリケーションへのアクセスが表示されます。
アクセスログの名前は access です。デフォルトの設定では、アクセスログファイルはサーバーイベントログと同じディレクトリに保存されます。
domain_config_dir/domain1/server1/logs/
tail コマンドによるログの表示
ログファイルを監視するために tail -f コマンドを使うと、ログが記録されるときに自動的にメッセージが表示されるようにできます。管理インタフェースではボタンをクリックして、ページ上の新しい情報を反映する必要があります。
tail -f コマンドを使用するには、次の手順に従います。
イベントログに記録されるアプリケーション生成メッセージ
アプリケーションが stdout または stderr、あるいはその両方に情報を書き込むと、同じ情報が INFO レベルのメッセージとしてサーバーインスタンスのイベントログファイルにも記録されます。このメッセージの ID は、それぞれ CORE3282 (stdout) および CORE3283 (stderr) になります。クラスタ JSP のサンプルの実行中は、アプリケーションから多数のメッセージが生成され、サーバーのイベントログに記録されます。次に、出力されるメッセージの一部を引用します。
[13/Aug/2003:17:32:28] INFO ( 9657): CORE3282: stdout:No parameter entered for this request
[13/Aug/2003:17:32:34] INFO ( 9657): CORE3282: stdout:Add to session:name1 = 1
[13/Aug/2003:17:32:45] INFO ( 9657): CORE3282: stdout:Add to session:name2 = 2
[13/Aug/2003:17:32:52] INFO ( 9657): CORE3282: stdout:Add to session:name3 = 3
これらのメッセージには、データがアプリケーションのユーザーインタフェースに入力されるときの値の変更が示されます。
アクセスログに記録されるアプリケーション生成メッセージ
クラスタ JSP のサンプルを実行すると、アクセスログメッセージが、要求を処理したアプリケーションサーバーインスタンスに記録されます。
192.18.151.14 - - [12/Aug/2003:15:34:52 -0700] "GET /clusterjsp/ HTTP/1.0" 302 1086
192.18.151.14 - - [12/Aug/2003:15:34:52 -0700] "GET /clusterjsp/HaJsp.jsp HTTP/1.0" 200 1578
アプリケーションサーバーインスタンスへの配備に対するトラブルシューティング
サンプルアプリケーションの実行に関する一般的な問題を、次の表にまとめます。左側の列には状態、中央の列には問題の考えられる原因、右側の列には解決策を示します。
表 4-2 アプリケーションサーバーインスタンスへの配備に対するトラブルシューティング
状態
考えられる原因
解決法
最初のページにアクセスできない
アプリケーションサーバーが稼動していない
URL に別のポート番号を指定している
アプリケーションサーバーが稼動していることを確認する
HTTP サーバーの正しいポート番号を指定する
詳細は、「サーバーの起動」を参照
メインページの表示時の 404 エラー
アプリケーションが配備されていない
問題を解決したら、必ずアプリケーションサーバーのログファイルを確認してください。また、HTTP アクセスログファイルの内容を確認すれば、HTTP 要求が正しくアプリケーションサーバーに送られているかどうかを確認できます。
クラスタへのサンプルアプリケーションの追加サンプルアプリケーションをクラスタ内の 2 つのサーバーインスタンスに配備したら、アプリケーションを loadbalancer.xml で作成したクラスタに追加する必要があります。
- Web サーバーの config ディレクトリに移動し、loadbalancer.xml をテキストエディタで開きます。
- サンプルの loadbalancer.xml ファイルには、次の行があります。
<web-module context-root="/abc" enabled="true" disable-timeout-in-minutes="60" enabled="true" />
clusterjsp サンプルアプリケーションを反映するように、この行を変更します。
<web-module context-root="clusterjsp" enabled="true" disable-timeout-in-minutes="60"/>
この行により clusterjsp アプリケーションがクラスタに追加され、有効になります。
コンテキストルートは、Sun Java System Application Server インスタンスの server.xml ファイルのアプリケーションに設定されているものと同じ値です。
disable-timeout-in-minutes 属性は 60 に設定されています。アプリケーションが無効になっている場合は、アプリケーションに対する未処理の要求を処理するために、サーバーは 60 分間アプリケーションを休止状態にしておくことができます。インスタンスレベルの disable-timeout-in-minutes は、すでに設定しています。これは、サーバーインスタンスの休止時間を制御します。
- 変更を保存します。
この時点で、loadbalancer.xml ファイルは次のようになっているはずです。
コード例 4-1 サンプルアプリケーションが設定されている loadbalancer.xml ファイル
<!DOCTYPE loadbalancer PUBLIC "-//Sun Microsystems Inc.//DTD Sun Java System Application Server 7.0//EN" "sun-loadbalancer_1_0.dtd">
<loadbalancer>
<cluster name="cluster1">
<instance name="server1" enabled="true" disable-timeout-in-minutes="5" listeners="http://test.sun.com:81"/>
<instance name="server2" enabled="true" disable-timeout-in-minutes="5" listeners="http://test.sun.com:82"/>
<web-module context-root="clusterjsp" enabled="true" disable-timeout-in-minutes="60"/>
<health-checker url="/" interval-in-seconds="10" timeout-in-seconds="30" />
</cluster>
<property name="reload-poll-interval-in-seconds" value="60"/>
<property name="response-timeout-in-seconds" value="30"/>
<property name="https-routing" value="true"/>
<property name="require-monitor-data" value="true"/>
</loadbalancer>
設定の変更の適用と Web サーバーの再起動loadbalancer.xml を編集したら、Web サーバーを再起動する必要があります。Web サーバーがすでに稼働している場合は、設定の変更を適用して、Web サーバーを再起動する必要があります。
Web サーバーを起動するには、次のようにします。
web_server_install_dir/https-admin-serv にある Web サーバーの管理サーバーも起動する必要があります。
稼働している Web サーバーに変更を適用して再起動するには、次のようにします。
- Web ブラウザに適切な URL を入力して、Web サーバーの Server Manager にアクセスします。
http://web_server:web_server_admin_port
次に例を示します。
http://test.sun.com:8888
- Server Manager からサーバーを選択して、「Manage (管理)」をクリックします。
Web サーバーインスタンスの Server Manager が表示されます。
- 設定ファイルに手動で変更が加えられたため、変更を適用する必要があるという警告メッセージが表示されます。
- ページの右上にある「Apply (適用)」リンクをクリックします。
- 「Apply Changes (変更の適用)」をクリックして変更を適用し、サーバーを再起動します。
それ以降の loadbalancer.xml の変更には、変更を適用してサーバーを再起動する必要はありません。再読み込みのポーリング間隔が設定されているため、それ以降のすべての変更は自動的に読み込まれます。詳細は、「再読み込みのポーリング間隔を使った動的再設定」を参照してください。
アプリケーションの実行アプリケーションをすべてのインスタンスに配備して、loadbalancer.xml ファイルを更新したら、Web サーバー上のアプリケーションをテストして、機能することを確認します。
- ブラウザから次の URL にアクセスします。
http://host:web_server_port/clusterjsp
次に例を示します。
http://test.sun.com:80/clusterjsp
このサンプルアプリケーションのページが表示されます。
図 4-2 クラスタ JSP のサンプルアプリケーションページ
サーバー情報は、一意なセッション ID とともにページの上部に表示されます。アプリケーションサーバーインスタンス上で直接このアプリケーションにアクセスしている場合は、ページの上部に表示されるポート情報がアプリケーションサーバー情報です。クラスタ化されたアプリケーションに Web サーバーからアクセスしている場合、ポート情報が Web サーバー情報です。
- セッション属性の名前と値を入力して、「Add Session Data (セッションデータを追加)」をクリックします。
セッションデータが表示されます。
図 4-3 クラスタ JSP に表示されたセッションデータ
ページ上部のセッション ID に注意してください。セッションがタイムアウトになる前にセッション属性を入力して「ADD SESSION DATA (セッションデータを追加)」をクリックした場合、ページの上部のセッション ID は最初にアクセスしたときと同じものになります。
上の例では、セッション ID である d8bf64b4dd0146c7ff47b943cf52 はどちらの場合でも同じです。
セッションがタイムアウトになった場合、セッション ID は異なります。
- 新しいセッション属性の名前と値を入力します。セッションがタイムアウトになっていない場合は、すべての属性が「Data Retrieved from HttpSession (HttpSession から受信されたデータ)」領域に表示されます。
たとえば、セッションがタイムアウトになる前にセッション属性データを 2 回以上入力した場合、次のようなページが表示されます。
図 4-4 複数の HTTP セッション属性を含むクラスタ JSP のサンプルアプリケーション
- セッションがタイムアウトするまで (1800 秒) 待機してから新しいセッション属性データを入力した場合は、ページの上部に、最後に入力したデータと新しいセッション ID のみが表示されます。
「CLEAR SESSION (セッションをクリア)」をクリックして、タイムアウトをシミュレートすることもできます。これにより、セッションデータがクリアされ、新しいセッション ID が指定されます。
図 4-5 新しい HTTP セッション情報を持つクラスタ JSP
ページの上部には新しいセッション ID (この例では d8ca7921435686ffffffff996dc3bbf9c5489) が表示され、最後に入力した情報 (この例では test4=4) は、「Data Retrieved from HttpSession (HttpSession から受信されたデータ)」領域に表示されています。
HTTP ロードバランスの確認これで、サンプルアプリケーションの実行が完了し、セッション情報がどのように表示されるかがわかりました。これでロードバランサがどのように動作するかを見ることができます。または、ロードバランサの問題を解決できます。
この節には次の項目があります。
ロードバランスの確認手順
次の手順に従って、ロードバランサの動作を見ることができます。
- 2 つの別々のブラウザを開き、http://web_server_name:web_server_port/clusterjsp と入力して、アプリケーションを Web サーバーから実行します。次に例を示します。
http://test.sun.com:80/clusterjsp
ロードバランサを使用するときはセッションデータがスティッキーであるため、ブラウザウィンドウを開いてアプリケーションにアクセスする場合、そのブラウザからの再読み込みなどのすべての操作は同じセッションにあるとみなされ、単一の Sun Java System Application Server インスタンスによって処理されます。
アプリケーションに対してロードバランスが機能することを確認するために、2 番目のブラウザを開いてアプリケーションにアクセスします。セッションデータは Cookie に格納されているため、別のマシンにある 2 番目のブラウザを開くか、同じマシンにある別のブラウザソフトウェアを使用する必要があります。セッション ID をチェックして、両方のブラウザウィンドウに個別のセッションデータがあることを確認してください。
- 2 つの異なるセッションウィンドウでアプリケーションにアクセスしたら、もう 1 つのブラウザウィンドウを開いて、Web サーバーのエラーログを確認します。
- その中の RequestExit を含むエントリを探します。
目で見て調べるか、「Only show entries with (表示するエントリタイプ)」フィールドに「RequestExit」と入力することができます。
- RequestExit を含むエントリは、Sun Java System Application Server の両方のインスタンスの HTTP リスナー ID を示すため、両方のアプリケーションサーバーインスタンスが要求を処理していることを確認できます。
- Sun Java System Application Server インスタンスが要求を処理したことを確認するには、それぞれのアプリケーションサーバーインスタンスの HTTP アクセスログをチェックします。
clusterjsp アプリケーションに対する要求が表示されます。アクセスログのチェックの詳細については、「管理インタフェースによるログの表示」を参照してください。
注
RequestExit メッセージを表示するためには、Web サーバーの詳細ログが有効になっている必要があります。手順については、「ロードバランサの監視の有効化」を参照してください。
ロードバランサを動作させるときにトラブルが発生する場合は、次項「ロードバランサプラグインのトラブルシューティング」を参照してください。
ロードバランサプラグインのトラブルシューティング
次の表は、ロードバランスのトラブルシューティングに役立ちます。左側の列には状態、中央の列には考えられる原因、右側の列には解決策が示されています。
表 4-3 ロードバランスに対するトラブルシューティング
状態
考えられる原因
解決法
アプリケーションにアクセスできない
Web サーバーが起動していない
URL に別のポート番号を指定している
Web サーバーが稼動していることを確認する
Web サーバーの正しいポート番号を指定する
詳細は、Web サーバーのマニュアルを参照
アプリケーションへのアクセス時の 404 エラー
アプリケーションが配備されていない
loadbalancer.xml ファイル内のエラー
「クラスタ JSP のサンプルアプリケーションのクラスタへの配備」を参照
loadbalancer.xml ファイル内のエラーは Web サーバーのエラーログに書き込まれる。詳細は、「loadbalancer.xml ファイル内のエラーの検出」を参照
アプリケーションへのアクセス時のエラーページ
クラスタ内の 1 つまたは複数のサーバーが応答していない
クラスタ内のサーバーインスタンスが稼働していることを確認する
エラーログをチェックして、ヘルスチェッカーによりダウンしているインスタンスが見つかったかどうかを確認する。詳細は、「ヘルスチェッカーの使用」を参照
loadbalancer.xml ファイル内のエラーの検出
Web サーバーの URL からサンプルアプリケーションにアクセスできない場合は、ロードバランサに問題がある可能性があります。個々の Application Server からアプリケーションにアクセスできる場合は、Application Server インスタンスには問題がないと判断できます。
ロードバランサプラグインは、Web サーバーのログファイルにメッセージを記録するので、さらに詳細な情報については、Web サーバーのエラーログから確認してください。
Sun Java System Web Server のエラーログは、Server Manager から表示できます。
ロードバランサで問題が発生した場合は、「Failed to initialize load balancing subsystem (ロードバランスのサブシステムの初期化に失敗しました)」に示されているメッセージを確認します。
loadbalancer.xml ファイルにエラーがあるという問題の場合は、loadbalancer.xml ファイル内のエラーがある行を示すパーサーエラーが表示されることがあります。たとえば、次のように表示されます。
[17/Jun/2003:09:57:44] catastrophe (5643):LBConfigParser.cpp@434:reports:lb.configurator:CNFG1000:Pars ing of file :/usr/iplanet/servers/https-test.sun.com/config/loadbalancer.xml
Failed at line :7 and column :3.The error message is :No character data is allowed by content model
このメッセージは、loadbalancer.xml ファイル内のエラーがある行を示しています。
loadbalancer.xml ファイル内の問題を修正し、変更を適用して Web サーバーを再起動します。その後、再試行します。
ヘルスチェッカーの使用
ロードバランサが正常に稼働していて、Web サーバーの LogVerbose が on に設定されている場合は、Web サーバーのログファイルに動作しているヘルスチェッカーが表示されます。
[09/Apr/2003:13:36:02] verbose (7576):HealthChecker.cpp@153:reports:lb.monitor:HLCK1006:UnhealthyI nstances cluster1 1049920562631 NoUnhealthyInstances
詳細ログを有効にする手順については、「ロードバランサの監視の有効化」を参照してください。
詳細ログを使用するかどうかとは関係なく、インスタンスの 1 つがダウンすると、ロードバランサは、アクセスの試行が失敗したときにダウンしたというフラグを付けます。ダウンしたままになっている場合、ヘルスチェッカーはそれに、ダウンしているとして再度フラグを付けます。
次に例を示します。
[17/Jun/2003:10:37:27] warning (5700):reports:lb.runtime:RNTM2024:Daemon http://test.sun.com:81 is unhealthy.
[17/Jun/2003:10:37:27] warning (5700):reports:lb.healthchecker:HLCK3003:Listener:http://test.sun.c om:81 is detected to be still unHealthy in cluster:cluster1
ヘルスチェッカーはダウンしているインスタンスの監視を続け、稼働中になると、稼働しているというフラグを付けます。
HTTP セッションの持続性の確認ロードバランスの機能が、正常に動作していることを確認したなら、次に、HTTP セッションの持続性の機能を確認することができます。セッション持続性では、何らかの理由により 1 つの Sun Java System Application Server インスタンスが失敗すると、2 番目のインスタンスがセッションをピックアップして要求を処理します。
HTTP セッションの持続性が機能していることを確認するには、次のようにします。
- ブラウザウィンドウを開きます。
- Web サーバーからアプリケーションにアクセスします。次に例を示します。
http://test.sun.com:80/clusterjsp
- Web サーバーのエラーログを表示して、要求を処理したサーバーを確認します (ここでも、RequestExit エントリを検索します)。
- ページを処理している Sun Java System Application Server インスタンスをシャットダウンします。
管理インタフェースを使ってシャットダウンすることができます。
- クラスタ JSP のサンプルアプリケーションページを再度読み込みます。
セッション ID とセッション属性のデータは保持されています。
- Web サーバーのエラーログをチェックします。この時点ではほかの Application Server インスタンスが要求を処理していることに注意してください。
セッション情報は、サーバーがオフラインになったあとで保存されます。障害発生時にセッションデータが失われる可能性があるのは、アプリケーションによるデータの転送中に障害が発生した場合のみです。この場合、少し古いセッションデータが表示されることがあります。
サーバーインスタンスの休止実際には、既存のセッションを完了させようとしないかぎり、サーバーがシャットダウンすることはありません。代わりに、休止というプロセスで、サーバーを段階的にシャットダウンします。
アプリケーションサーバーインスタンスを休止させるには、次の手順で行います。
- ブラウザウィンドウを開いて、クラスタ JSP アプリケーションに Web サーバーポートからアクセスします。このウィンドウは開いたままにします。
- 要求を処理するアプリケーションサーバーインスタンスを決定します。
2 番目のブラウザウィンドウを開き、管理インタフェースで server1 アプリケーションサーバーインスタンスの HTTP アクセスログにアクセスします。要求が送信された時点でのクラスタ JSP アプリケーションのアクセスのログを確認します。server1 ログにあるアクセスが表示された場合、server1 アプリケーションサーバーインスタンスは要求を処理しています。アクセスログのこのようなエントリが表示されない場合は、server2 アプリケーションサーバーインスタンスのアクセスログを確認してください。アクセスログウィンドウは開いたままにします。
- 要求を処理しているアプリケーションサーバーインスタンスを確認したら、loadbalancer.xml ファイルにあるそのサーバーインスタンスを無効にします。
正しいサーバーインスタンスに対して、enabled="true" を enabled="false" に変更します。次に例を示します。
<instance name="server1" enabled="false" disable-timeout-in-minutes="5" listeners="http://test.sun.com:81"/>
- loadbalancer.xml の変更を保存します。
- 新しい設定が読み込まれるように、再読み込みポーリング間隔の経過を待ちます。
このチュートリアルでは、再読み込みポーリング間隔は 60 秒に設定されているため、1 分だけ待機する必要があります。
- 再読み込みポーリング間隔が経過して、新しい設定が読み込まれると、ロードバランサプラグインは、既存のセッションがない要求をそのサーバーインスタンスに送信しなくなります。ただし、既存のセッションがある要求は、休止時間中も引き続きサーバーインスタンスに転送されます。
この状態を確認するには、開いているクラスタ JSP ウィンドウで名前と属性の情報を入力して、「ADD SESSION DATA (セッションデータを追加)」をクリックします。
- 最初の要求を処理したサーバーの HTTP アクセスログを表示する、ブラウザウィンドウに移動します。「OK (了解)」をクリックして情報を更新します。
サーバーは、loadbalancer.xml で無効になっていても、この要求を処理することに注意してください。
- 終了までの休止時間として 5 分間待機してから、クラスタ JSP アプリケーションウィンドウを開いて追加の名前属性情報を入力して、「ADD SESSION DATA (セッションデータを追加)」をクリックします。
休止時間は、サーバーインスタンスの無効タイムアウトによって制御されます。このチュートリアルの前の手順で、この値を 5 分に設定しています。
- 休止時間が経過したため、要求は別のアプリケーションサーバーインスタンスに送信されます。
この結果を表示するには、サーバーインスタンスの HTTP アクセスログを更新します。新しい要求は表示されません。
- 3 番目のブラウザウィンドウを開いて、ほかのサーバーインスタンスの HTTP アクセスログを表示します。2 番目のサーバーインスタンスによって処理されているクラスタ JSP の要求が表示されます。
そのあと、アプリケーションサーバーインスタンスを安全にシャットダウンすることができます。
アプリケーションを休止して、安全にオフラインにすることもできます。アプリケーションサーバーインスタンスとアプリケーションの休止の詳細については、『Sun Java System Application Sever Administration Guide』を参照してください。
