寺田　佳央 – Yoshio Terada

WS(Memory)とAS(HADB)のSession Replicationの違いについて

1. はじめに
前回、「Sun Java System Web Server 7 Technology Preview」の紹介で
Session Replicationの方法がWebサーバとApplicationサーバで異なることを
簡単に説明しました。
本日はSJS WebサーバのSession ReplicationとSJS Applicationサーバの
Session Replicationについてもう少し詳しく説明したいと思います。
SJS Webサーバ：メモリ
SJS Applicationサーバ：HADB(High Availability Data Base)
この違いについて、下記に、詳しく説明したいと思います。
まず、今回、下記の図のように４台構成について検討したいと思います。
「User A」はLoad Balancer経由で4台のマシンに対して接続します。

2. SJS WebサーバのSession Replicationについて
Webサーバを構成する4台をそれぞれ、WS1 , WS2 , WS3 , WS4 とします。
SJS Webサーバの Session Replication では下図に示すように、
2台間でSession Replicationを実現しています。

さらに詳しく説明すると、下記の図のように、WS1に対するsessionの
バックアップはWS2のオンメモリ上にのみ保持されています。
WS3 , WS4 はWS1のセッションのバックアップを保持していません。
以降順に、WS2のバックアップはWS3へ、WS3のバックアップはWS4へ
WS4のバックアップはWS1へというようにリング状を形成しバックアップノードが
作成されます。

次に、実際にセッションが作成された後、マシン障害が発生した場合について
考えてみたいと思います。下記の図のように、「User A」がHTTPリクエストを
送信し、sessionを作成します。この時Load Balancerが WS1に対して「User A」の
リクエストを送信したとします。すると、WS1では「User A」に対するsessionが
生成されます。そして、WS2に対してRMI経由で「User A」のsession情報がコピー
されます。

この状態で、WS1のマシンに対して何らかの障害が発生したとします。
すると、Load Balancerは当然、WS1 に対して接続ができなくなりますので、
別の利用可能なWebサーバへ接続を試みます。この時、Load Balancerは
「User A」のセッション情報がどのWebサーバに存在するかはしりません。
そこで、任意のWebサーバに接続を割り振ります。下記の例ではWS4に対して
リクエストが割り振られています。ここで割り振られた、WS4 は「User A」の
sessionを保持していません。そこで「User A」に対するsessionを検索します。

次に、WS4 は WS2 が「User A」に対するsessionをバックアップとして
保持している事を見つけ出し、下記の図のように「User A」のsessionの情報を
取得し、WS4 がレスポンスを返します。

ここでさらに、下記の図のようにWS1 に加えて WS2 も同時にシステム障害が
発生した場合を想定します。この場合、「User A」のセッション情報は、WS1 , WS2
しか保持していませんでしたので、「User A」のセッション情報は存在しなくなって
います。このような状況が発生してしまった場合、「User A」は新たにsessionを
再度作成しなくてはならず、既存の情報は全て無くなってしまいます。

このように、SJS WebサーバのSession Replicationはメモリ上にのみsession情報を
保持し、かつセッション情報の複製を2台間でしか保持していません。
そこで、セッションを保持する2台同時に障害が発生した場合は、再度sessionを
再作成しなければなりません。このことからSJS WebサーバのSession Replicationを
Light Weight(軽量な) Session Replicationと呼んでいます。

3. SJS ApplicationサーバのSession Replication(HADB)について
High Availability Session Store(HADB)の概要を御参照下さい。

※ HADBは99.999% のサービスおよびデータの可用性をサポートするように設計されています
Webサーバ、Applicationサーバの選択においては、御使用の目的・用途、また
価格に応じて適切な製品を御検討頂ければと思います。

2006年6月25日 at 10:55 午後

SJS Web Server7.0サンプルWebアプリのデプロイと高可用性の検証

SJS Web Server7.0サンプルWebアプリのデプロイと高可用性の検証
今回はSJS Web Server7.0のクラスタ環境にWebアプリケーションをデプロイ
したいと思います。
1. Webアプリケーションを追加
管理サーバにログインすると、下記の画面が表示されます。
ここで、「Web アプリケーションを追加」ボタンを押下します。


すると下記のウィンドウが別画面として表示されます。


ここで、「参照」ボタンを押下し、デプロイするWeb アプリケーションを指定します。
今回は、WSの付属としてインストールされている下記のサンプルアプリケーションを
デプロイします。
/sun/webserver7/samples/java/webapps/simple/webapps-simple.war
ファイルを選択した後、「了解」ボタンを押下すると下記の画面が表示されます。
ここでは、通常シングルサインオンの設定を行いますが、今回はシングルサインオンは
利用しないため、そのまま「配備」を行います。
画面右上に「▲ 配備保留中」が表示されていますので、
このリンクを押下します。
2007/09/21追記
Web アプリケーションをセッションリプリケーションできるようにする為に、
sun-web.xmlに対して下記のように、persistence-type=”replicated”を追記して下さい。

<?xml version=”1.0″ encoding=”UTF-8″?> <!– Copyright 2006 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. –> <!DOCTYPE sun-web-app PUBLIC “-//Sun Microsystems, Inc.//DTD Application Server 8.1 Servlet 2.4//EN” “http://www.sun.com/software/sunone/appserver/dtds/sun-web-app_2_4-1.dtd”&gt; <sun-web-app> <session-config> <session-manager persistence-type=”replicated”/> </session-config> <jsp-config/> </sun-web-app>

「▲ 配備保留中」のリンクを押下すると下記の画面が表示されます。
これは、現在、管理サーバのローカルでのみ設定が変更されており、全ての
インスタンス上では有効になっていない状態であることを示してます。
そこで、全てのインスタンス上で有効にするため、「配備」ボタンを押下します。


「配備」ボタンを押下すると、下記の画面が表示され、全てのインスタンスに
対してデプロイが開始されます。


正常に全てのインスタンスに対してデプロイが完了すると下記の画面が表示されます。


以上で、ウェブアプリケーションの配備（デプロイ）の処理は完了です。
如何でしょうか、まるで1台のマシンにデプロイしているのと同様の操作で、
かつ1回の操作だけで、複数台のマシンに対して同一アプリケーションを
デプロイ可能となっています。
このように、非常に管理が楽になっていることが御理解いただけるかと思います。
さて、デプロイが完了しましたので、
正常にWeb アプリケーションが動作しているかを確認します。
ブラウザ経由で下記のURLにアクセスし確認してください。
http://jse8-026:8080/simple/jsp
http://jse8-027:8080/simple/jsp
正常に動作している場合、下記の画面が表示されます。






2. Load Balancer設定
次に、ロードバランサの設定を行います。
ロードバランサとして稼動させるWebサーバを別途用意し下記のコマンドを実行します。
（今回は便宜上、jse8-026 上でロードバランサを設定していますが、別のマシン上で
　設定する場合も下記と同様の設定を行います。）

該当のマシンにTELNET等でログインし、wadmコマンドを実行します。 wadm> create-config –http-port=80 –server-name=lbserver lb CLI201 コマンド ‘create-config’ は正常に実行されました wadm> create-reverse-proxy –config=lb –vs=lb –uri-prefix=/ –server=”http://jse8-026:8080,http://jse8-027:8080″ CLI201 コマンド ‘create-reverse-proxy’ は正常に実行されました wadm> create-instance –config=lb jse8-026 ※ここで指定するホスト名はLoad Balancerを稼動させるホスト名です。 CLI201 コマンド ‘create-instance’ は正常に実行されました wadm> deploy-config lb CLI201 コマンド ‘deploy-config’ は正常に実行されました wadm> start-instance –config=lb CLI204 サーバーインスタンスは正常に起動しました。

※create-reverse-proxy コマンドで、Webサーバが稼動しているホスト名と
Webサーバのインスタンスが稼動しているポート番号を指定します。
（今回の例では、2つのWebサーバインスタンスを作成していますので、
　それぞれ、jse8-026:8080,jse8-027:8080を指定しています。）
以上でLoad Balancerの設定が完了です。
正常に設定が完了しているか下記のURLにアクセスし確認してください。
(LB-HOSTNAME: Load Balancerが稼動するホスト名)
http://LB-HOSTNAME/simple/jsp
正常に設定が完了している場合、下記の画面が表示されます。






3. Session Replication（高可用性）の動作確認
最後に、Session Replicationの動作確認を行います。
Session Replicationの動作確認を行うため、下記のURLにアクセスしてください。
http://LB-HOSTNAME/simple/jsp
アクセスすると下記の画面が表示されます。


今回、Session Replicationの動作確認のために「Carts」(ショッピングカート)の
サンプルアプリケーションを使用します。
「Carts」のリンクを押下すると下記の画面が表示されます。


現在、Load Balancer経由でアクセスしているため、実際には、
どのWebサーバのインスタンス上のアプリケーションを実行しているかわかりません。
　　（jse8-026:8080 もしくは jse8-027:8080）
そこで、全インスタンスのアクセスログファイルを確認します。
全マシン(jse8-026,jse8-027)にTELNET等でアクセスし
Webサーバインスタンスのアクセスログをそれぞれ確認します。
　　/sun/webserver7/https-cluster1/logs/access
ここで、「add」、「remove」ボタンを押下しないで、ブラウザの
再読み込みボタンを押下してください。
するとラウンドロビンにて交互にアクセスが振り分けられていることが
確認できます。
次に、「add」ボタンを押下してください。
すると特定のWebインスタンスにのみアクセスするようになります。
たとえば、「Carts」のWeb アプリケーションで「Item」を「add」してください。
すると特定のインスタンスへアクセスするようになります。


その際のアクセスログを下記に示します。下記の例ではjse8-027のインスタンスに
対してアクセスされるようになりました。

jse8-027> tail -f /sun/webserver7/https-cluster1/logs/access 10.14.8.26 – – [22/Jun/2006:18:48:20 +0900] “GET /simple/jsp/sessions/carts.jsp?item=JSP+Book&submit=add HTTP/1.1” 200 915 10.14.8.26 – – [22/Jun/2006:18:48:26 +0900] “GET /simple/jsp/sessions/carts.jsp?item=Concert+tickets&submit=add HTTP/1.1” 200 938 10.14.8.26 – – [22/Jun/2006:18:48:30 +0900] “GET /simple/jsp/sessions/carts.jsp?item=Love+life&submit=add HTTP/1.1” 200 955 10.14.8.26 – – [22/Jun/2006:18:48:36 +0900] “GET /simple/jsp/sessions/carts.jsp?item=Concert+tickets&submit=add HTTP/1.1” 200 978

アクセスログを確認した所、現在、jse8-027 にアクセスされていました。
そこで、jse8-027のインスタンスを停止してみたいと思います。
インスタンスを停止した場合の想定動作：
　　jse8-027のインスタンスを停止した場合も、画面を再読み込みして
　　同一画面が表示される。

それでは、実際に、jse8-027のインスタンスを停止してみます。
管理サーバのトップページより「インスタンスの起動/停止」ボタンを押下してください。


「インスタンスの起動/停止」ボタンを押下すると、下記の画面が表示されます。
ここで、「jse8-027」のノードにチェックを付け、「停止」ボタンを押下します。

「停止」ボタンを押下すると下記の画面が表示され、jse8-027のノードの「状態」が
「停止中」に切り替わり停止状態となります。


この状態で、再度同一のURLにアクセス（再読み込み）してください。
http://LB-HOSTNAME/simple/jsp
すると、下記の画面が表示されます。


如何でしょうか。アクセスされていた方(jse8-027)のインスタンスを停止しても、
同一の画面が表示されたでしょうか。
ここで念のため、本当に切り替わったかを確認するため、全インスタンス
(jse8-026,jse8-027)のアクセスログを確認してください。
正常に切り替わっている場合、他方（jse8-026側）のアクセスログに
ログが出力されるようになることが確認できます。

jse8-026> tail -f /sun/webserver7/https-cluster1/logs/access 10.14.8.26 – – [22/Jun/2006:18:58:11 +0900] “GET /simple/jsp/sessions/carts.jsp?item=JSP+Book&submit=remove HTTP/1.1” 200 1041 10.14.8.26 – – [22/Jun/2006:18:58:15 +0900] “GET /simple/jsp/sessions/carts.jsp?item=JSP+Book&submit=remove HTTP/1.1” 200 1025 10.14.8.26 – – [22/Jun/2006:18:58:28 +0900] “GET /simple/jsp/sessions/carts.jsp?item=NIN+CD&submit=add HTTP/1.1” 200 1039 10.14.8.26 – – [22/Jun/2006:18:58:40 +0900] “GET /simple/jsp/sessions/carts.jsp?item=NIN+CD&submit=add HTTP/1.1” 200 1053

以上でWeb Server 7.0のSession Replicationの動作確認ができましたが、
如何でしょうか？
これで、仮に単一のマシンに何らかの障害が発生しても引き続きサービスを提供できる
事が確認できたかと思います。
次回は、Application Server付属のHADBとWeb ServerのSession Replicationについて
もう少し詳しく説明したいと思います。

2006年6月23日 at 12:50 午前

SJS Web Server7.0クラスタ環境の構築

今回はSJS Web Server7.0のクラスタ環境を構築したいと思います。
1. 管理サーバと管理エージェントについて
前回、インストール時にも説明しましたが、インストール時の構成タイプの選択で、、
「管理サーバ」と「管理エージェント」と呼ばれる、構成タイプが存在することを
説明しました。
これによりWS7.0からは単一の「管理サーバ」から複数の「管理エージェント」を
管理できるようになっております。

さてそれでは、実際に単一の「管理サーバ」から「管理エージェント」を管理するため
にはどのような手順が必要でしょうか。次より手順を紹介したいと思います。
2. 管理サーバ上にクラスタ用の設定を作成
まず、今回作成するクラスタの構成について説明します。
今回、下記図に示すように、管理サーバとして jse8-026 というマシンを、
管理エージェントとして jse8-027 というマシンを割り当てて環境を構築したいと思います。

さて、それでは実際に管理サーバ上に設定を追加する方法を下記に記述します。
まず、管理サーバである jse8-026 にTELNET等でログインし下記を実行します。

jse8-026> cd /sun/webserver7/bin jse8-026> ./wadm –user=admin admin-user-password を入力してください> adminadmin Sun Java System Web Server 7.0 B06/18/2006 10:03 wadm> create-config –http-port=8080 –server-name=cluster cluster1 CLI201 コマンド ‘create-config’ は正常に実行されました

3. クラスタ用の設定にSession Replicationの設定項目を追加
次に、作成したクラスタ用の設定に「Session Replication」の設定を行います。

wadm> set-session-replication-prop –config=cluster1 enabled=true CLI201 コマンド ‘set-session-replication-prop’ は正常に実行されました

4. クラスタ用の設定情報に対してWebサーバのインスタンスを追加
最後に、作成したクラスタの設定に対して、Webサーバのインスタンスを追加します。
ここでは、クラスタに属するノードのホストを指定します。

wadm> create-instance –config=cluster1 jse8-026 jse8-027 CLI201 コマンド ‘create-instance’ は正常に実行されました wadm>

5. 管理サーバへのログイン
さて、それではクラスタの設定が完了しましたので、管理サーバへログインします。
ブラウザより管理サーバのURLを入力しアクセスします。
　　https://jse8-026:8989

6. ログイン完了画面
正常にログインが完了すると下記の画面が表示されます。

7. クラスタのインスタンスの起動
管理画面上の「設定」タブを押下します。
すると下記の画面が表示されます。
現在インスタンスを作成した状態ですのでWebサーバのインスタンスは
起動されていません。これは「インスタンスの状態」の項目に
「２　停止中」が表示されている事から確認できます。

全インスタンスを起動するために、「cluster1」のチェックボックスに
チェックを付け、「インスタンスを起動」ボタンを押下します。
すると下記の画面に切り替わり、「インスタンスの状態」の項目が
「２　稼動中」に変わっている事が確認できます。

上記のように、ひとつづつのインスタンスをそれぞれ起動しなくても、
一度に全てのインスタンスの起動・停止・再起動などの操作ができるようになり
非常に操作が簡単になっています。
次回は、サンプルWeb アプリケーションのデプロイを行い、
実際に高可用性が実現できるかを確認します。

2006年6月21日 at 11:30 午後

Sun Java System Web Server 7 TP Install

今回は、SJS Web Server 7.0のインストールを行いたいと思います。
1. プロダクトの入手
まずは、下記よりSJS Web Server 7.0 Technology Preview 1を入手してください。
SJS Web Server 7.0
Technology Preview 1版の入手
上記より入手可能なファイルは下記になります。
sjsws-7.0_2006Q1-b44.2-solaris-sparc.tar.gz
今回、私は本ドキュメントを記述するため、上記より若干新しいバイナリ(2006Q1-b46.1)
を入手し検証を実施しています。
2. ファイルの展開とsetupの実行
ファイルを入手した後、下記を実行してください。

# gzip -dc sjsws-7.0_2006Q1-b44.2-solaris-sparc.tar.gz | tar xvf – ….. ….. # ls -F 3RD-PARTY-LICENSE.txt LICENSE.txt README.txt WebServer/ setup* # ./setup

3. setupの実行画面
setupを実行すると下記の画面が表示され「次へ」ボタンを押下します。

4. ソフトウェアライセンス使用許諾契約画面
ソフトウェアライセンス使用許諾契約画面で、ライセンス契約書の条項に同意し、
「はい」ボタンを押下します。

5. インストールディレクトリの選択画面
インストールディレクトリの選択画面で、インストールディレクトリを指定し
（デフォルトで/sun/webserver7）「次へ」ボタンを押下します。

インストール先のディレクトリが存在しない場合、ディレクトリを作成します。

6. インストールのタイプ選択画面
インストールのタイプ選択画面にて、インストール方法を選択します。
今回は、クラスタ構成を組むため「カスタム」を選択し「次へ」ボタンを
押下します。

7. コンポーネントの選択画面
次に、インストールするコンポーネントを選択します。デフォルトでは
「サンプルアプリケーション」は選択されていませんが、今回は「すべて選択」ボタンを
押下し、すべてのコンポーネントをインストールします。

8. Java設定画面
次に、Java設定画面にてJava 2 SDK ,Standard Editionをインストール・設定します。
今回は、Web ServerにバンドルされているSDKをインストールします。

9. 構成のタイプの設定画面
次に構成タイプを選択します。
ここで、構成について説明します。
Web Server 6.1までは、同一の設定情報を持つWebサーバを構築するために、
それぞれのWebサーバ管理画面にて、同じ設定を各サーバ毎に設定しなければ
なりませんでした。
しかしWeb Server 7.0からは「管理サーバ」と「管理エージェント」という
構成タイプに分かれ、複数の管理エージェントを単一の管理サーバから設定可能に
なりました。管理サーバから設定を行うとJMX経由で管理エージェントに対して
設定が施されるようになっています。
例えば、あるWeb Applicationをデプロイしたい場合、WS 6.1まではそれぞれの
管理画面よりデプロイの処理を実施しなければなりませんでしたが、WS 7.0からは
単一の管理画面よりすべての管理エージェントに対して同一のアプリをデプロイ可能
になっています。

ここでは、構成のタイプの設定画面にて、「管理サーバ」を選択し「次へ」ボタンを
押下します。

10. 管理サーバ設定画面
管理サーバ設定画面にて下記を入力し、「次へ」ボタン
を押下します。

11. Web Serverインスタンス設定画面
Web Serverインスタンス設定画面にて、デフォルトで作成されるインスタンスの
設定を行います。「次へ」ボタンを押下します。
（ここで作成するインスタンスは後で削除するため、デフォルトの
　設定のままで設定を行います。）

12. インストール準備画面
以上で、インストールの準備が完了いたしました。「今すぐインストール」ボタンを
押下し、インストールを行います。

13. インストール画面
インストール中は下記の画面が表示されます。

14. インストール完了画面
インストールが正常に完了すると下記の画面が表示されます。

15. 管理サーバの起動
ここで管理サーバを起動します。下記のメッセージが出力された後、
ブラウザより「https://jse8-026:8989」にアクセスし、
正常に管理サーバが起動されていることを確認します。

jse8-026> /sun/webserver7/admin-server/bin/startserv Sun Java System Web Server 7.0 B06/18/2006 10:03 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java Hotspot(TM) Server VM, Version 1.5.0_06] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [admin-server] at [/admingui] info: WEB0100: Loading web module in virtual server [admin-server] at [/jmxconnector] info: HTTP3072: admin-ssl-port: https://jse8-026:8989 ready to accept requests info: CORE3274: successful server startup jse8-026>

正常に管理サーバが起動されている場合、下記のログイン画面が表示されます。

16. 管理エージェントのインストール
次に、もう一台のマシン(jse8-027)に管理エージェントとしてWS 7.0をインストールします。管理エージェントのインストールは、管理サーバのインストール手順の
「1. プロダクトの入手」～「7. Java設定画面」までは同様の手順にて実施します。
「7. Java設定画面」の設定が完了すると、「構成のタイプの設定画面」にて
「管理インスタンスを管理エージェントとして設定する」を選択し「次へ」ボタンを
押下します。

17. Administration Agent Settings画面
管理エージェントの設定画面にて下記を入力し、「次へ」ボタンを押下します。

18. インストール準備完了画面
以上で、インストールの準備が完了いたしました。「今すぐインストール」ボタンを
押下し、インストールを行います。

19. 管理エージェントの起動
インストールが正常に完了した後、管理エージェントのプロセスを起動します。

jse8-027> /sun/webserver7/admin-server/bin/startserv Sun Java System Web Server 7.0 B06/18/2006 10:03 warning: CORE1251: On HTTP listener admin-ssl-port, server name jse8-027 does not match subject “jse8-026” of certificate Admin-Server-Cert. warning: CORE1250: In secure virtual server admin-server, host jse8-027 does not match subject jse8-026 of certificate Admin-Server-Cert. info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_06] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [admin-server] at [/jmxconnector] info: HTTP3072: admin-ssl-port: https://jse8-027:8989 ready to accept requests info: CORE3274: successful server startup jse8-027>

20. 管理サーバのデフォルトのインスタンスの削除
最後に、管理サーバにインストール時にデフォルトで作成される
インスタンスを削除します。下記のコマンドを実行して下さい。

jse8-026> ./wadm –user=admin admin-user-password を入力してください> adminadmin(←実際は非表示) Sun Java System Web Server 7.0 B06/18/2006 10:03 wadm> delete-instance –config=jse8-026 jse8-026 CLI201 コマンド ‘delete-instance’ は正常に実行されました wadm> delete-config jse8-026 CLI201 コマンド ‘delete-config’ は正常に実行されました

以上で、管理サーバ、管理エージェントのインストールが完了いたしました。
現時点では、管理サーバ・管理エージェントが存在するだけで、インスタンスが
存在しません。
そこで次回は、クラスタ環境の構築、クラスタ環境の検証用のアプリを使用した
高可用性の検証を行います。

2006年6月21日 at 8:30 午前

Sun Java System Web Server 7 Technology Preview

本日から数回に分けて、次期 Web Serverである、
Sun Java System Web Server 7の新機能について
まとめてみたいと思います。
Sun Java System Web Server 7は現在、テクノロジー
プレビュー版として下記のURLより入手が可能です。
機能検証等を目的として御自由に御試し頂ければと思います。

SJS Web Server 7 Technology Preview版 入手先
今回、SJS Web Server 7では非常に多くの新機能が盛り込まれています。
下記に、新機能の一覧を示します。

• JMX Based Management Infrastructure
  
• Redesigned Administration Server Interface
  
• Command-Line Interface Support
  
• N1 Grid Container (Service Provisioning Support)
  
• Consolidated Configuration Files
  
• Java Servlet 2.4 and Java Server Pages (JSP) 2.0 Support
  
• JavaServer Pages Standard Tag Library (JSTL) 1.1 and Java Server Faces 1.1 Support
  
• JNDI Support
  
• Java Database Connectivity and Connection Pooling Support
  
• Java SE 5.0 Support
  
• JavaWeb Services Developer Pack 2.0
  
• Session Replication Support
  
• Extensive Real-Time Monitoring Support
  
• Integrated Reverse Proxy Plug-in and FastCGI Plug-in Support
  
• Enhanced Security
  
• Elliptic Curve Cryptography
  
• NetBeans 5.0 Support
  
• Sun Java Studio Enterprise Support
  

このように、非常に多くの機能が盛り込まれていますが、
Web Server 6.1から7にかけて、特に大きな変更は、
Session Replicationの機能がサポートされたことです。
今までは、Session Replicationの機能がなかったため、
Webサーバだけで高可用性を実現することはできませんでした。
そこで、EJBコンテナを利用しないWebアプリケーションでも
高可用性を実現するためだけにApplication Serverを
導入された方も多いかと思います。
今後、EJBを使用しないWebアプリケーションで高可用性を
実現したい場合、Webサーバで可能になります。
下記に、WebサーバとApplication Serverの比較を記述いたします。

	Web Server 6.1	Web Server 7.0	Application Server 8.x EE
高可用性	無	有(On Memory)	有(HADB)
Servlet,JSP	Servlet 2.3,JSP 1.2	Servlet 2.4,JSP 2.0	Servlet 2.4, JSP 2.0
EJB Container	無	無	EJB 2.1
実行環境	32bit/64bit	32bit/64bit	32bit

※ WebサーバとApplication Serverで高可用性を
実現する方法が異なります。共有するセッション情報の保存先として
Application Serverでは外部 Data Base(High Availability Data Base[HADB])を
使用しますが、Webサーバではメモリを使用します。
HADBによるセッション保持
SJS Application Serverでは高可用性を実現するために、HADBを使用します。
HADBはApplication Serverのプロセスとは独自にDB用のプロセスが存在します。
そこで、Application Serverの再起動等が発生してもセッション情報がHADBに
格納されているため、Application Serverの再起動後にそのまま同一セッション
を利用可能です。そのため高可用性を実現するためにはHADBの方がより優れています。
メモリによるセッション保持
WS 7.0では高可用性を実現するために、メモリを使用します。
そこで、すべてのWSが再起動された場合、保持していたセッション情報がすべて
クリアされ再度セッションを確立しなければなりません。
多くのWeb Applicationの場合、高可用性を実現するために、メモリ上に
保持しておくだけで十分です。またセッション情報をDBに格納(ディスクアクセス)する
よりメモリ上で格納する方がより軽量ですみます。
しかし、エンタープライズ向けのミッションクリティカルなWeb Applicationの場合、
あらゆる障害や管理面を想定しHADBを御利用頂ければと思います。
次回から、Web Server 7のインストール方法、
Session Replicateの設定方法を説明します。

2006年6月20日 at 11:50 午後