Archive for 2007年9月4日
High Availability Session Store(HADB)の概要
さて、先日まででロードバランサ（負荷分散）の設定が完了しました。
ロードバランサの設定を行っただけでは、単一ノードの障害（H/W or S/W）が
発生した場合、Webアプリケーションを利用するエンドユーザは再度
ログインからしなければなりません。
そこで、今日は単一ノードの障害が発生した場合でも継続してWebアプリケーションを
利用できるように、セッション情報を共有し高可用性を実現できる環境を
構築しましょう。
SJS Application Server 9.1では高可用性を実現する為の手段として
下記の２通り存在します。
1. インメモリセッションリプリケーション
2. High Availability Session Store (HADB:高可用性データベース)
インメモリセッションリプリケーションの概要については、以前
GlassFish v2のインメモリセッションリプリケーションの概要で紹介していますので、
今日はインメモリセッションリプリケーションに比べ、さらに高い高可用性(99.999%)を実現する
High Availability Session Store (HADB:高可用性データベース)について説明します。
HADBとはそもそも何なんだ？何故エンタープライズ用にHADBが
組み込まれているんだ？そんな疑問に答えるためにHADBについて
下記にまとめてみたいと思います。
はじめに
SJS Application Server は、HADB(高可用性データベース)を使用して、HTTPセッションデータ
およびステートフルセッションビーン (SFSB) のセッションデータを格納します。
HADBの特徴
● 99.999%の高可用性
ー１年間で５分以下のダウンタイムを実現可能
● メンテナンス性が高い
ーハードウェア・ソフトウェア・OS・HADBのメインテナンス
バージョンアップ等にサービス停止を行わないで済む
● 高パフォーマンス
ーHADBのデータベースノードを追加すればするだけ
線形的にパフォーマンスが向上（スケール）する
ー並列処理を行う高パフォーマンスなデータベース
99.999%の高可用性
HADBはデータベースのデータにアクセスする際に、99.999%の
非常に高い可用性を実現します。そしてそれは年間のダウンタイムとして
計算するならば、１年間に５分以下しか停止しない事を意味しています。
これは、高い高可用性を実現する為に、特別に開発した、並行データベースで
現在提供されている一般的なH/Wシステム、ネットワーク回線で実現可能です。
参考:
IEEEに提出された99.999%の高可用性の証明論文
99.999%のWhite Paper
メンテナンス性
システム管理者は、H/W機器の増強(メモリ・CPU等)、ソフトウェアの追加、
OSの保守（パッチ適用等）、HADB自身のバージョンアップ等、様々な
作業を行う必要があります。このような作業を行う際もHADBでは
サービスを停止する事なく作業を行う事ができます。
パフォーマンス
HADBはリアルタイムの応答を返します。現行のハードウェア環境にHADBを
構築した環境で、HADB内の4つのレコードに対する更新(update)処理を
行った場合、95%の処理が 1ms 以下で終了します。
また、単一のレコードを読み込むトランザクションを実行した場合、
0.3 ms 以下で処理が終了します。
実際にUSでベンチマークテストを行った結果、読み込みテストに関しては
単一レコードの読み込みに秒間 30,000以上のトランザクションを完了し、
更新処理に関しても秒間 10,000以上のトランザクションを完了しました。
（※ 40CPUを使用した場合、primary keyに対する操作を実行）
また、スケーラビリティに関して、HADBを構成するノードを追加する毎に
線形的にパフォーマンスが向上します。つまり１度構成を組んだ後、
パフォーマンスの改善が必要と考えられる場合、システム管理者はノードを
追加する事でパフォーマンスを改善する事ができるようになります。
※ 最大で28ノードの構成が可能（内：アクティブノード:24、スペアノード:4)
※ HADBを使用する場合、セッションサイズがパフォーマンスに
大きく影響します。プログラムのセッションサイズを小さくするように
プログラムを作って下さい。
※ 上記パフォーマンスデータは過去にUSで行われた検証結果に基づき報告しています。
HADBの概要紹介はこの位にしておいて、実際にどのような動きをする
データベースなのか、より詳細に説明してみたいと思います。
HADBの詳細：
HADBは、データのフラグメント（断片化）とレプリケーション（複製）を
通してデータの高可用性を実現します。
下記の図のようにデータベース内に存在するすべてのテーブルは
分割され、フラグメント（断片化）と呼ばれる、ほぼ同サイズの
レプリカ（複製）が作成されます。
断片化は、ハッシュ関数に基づいて行われ、HADBの各ノード間に
データを均等に分散させる為に行われます。
HADBノードは、互いをミラー化する2つのData Redundancy Unit
(DRU:データ冗長ユニット) から構成されます。
上記で説明した各フラグメントは、それぞれ異なるDRU中に存在するノードに対して
2回保存されます。
一つは、「プライマリ」として使用され、そしてもう一つは
「ホットスタンバイ」として使用されます。
下記の図にでは、「プライマリ」用のフラグメントレプリカが白色で、
「ホットスタンバイ」用のフラグメントレプリカが赤色で示されています。
※ F1R0はフラグメント番号：１、レプリカ番号：０を表しDRU0に所属します。
※ F1R1はフラグメント番号：１、レプリカ番号：１を表しDRU1に所属します。
このように、データベース中に存在するデータの完全なコピーを
それぞれのDRUが保持し、単一ノードHADBノード障害に対する耐障害性や、
データの早急な復旧が保証されています。
仮に、プライマリのフラグメントレプリカ(F1R0)に対して内容が更新された場合は、
データベースのトランザクション処理の一部として更新ログが
ホットスタンバイフラグメントレプリカ(F1R1)に対して送られ、ホットスタンバイ
フラグメントレプリカ上でも更新されるようになります。
HADBに対する接続について
HADBに接続するクライアント（SJS Application Server 9.1との連携の為
ここでいうクライアントはApplication Serverになります）は下記の図に示す
ようにHADB中に含まれるどのノードに対しても接続が可能です。
言い換えれば、クライアントはHADBのノードAかノードBか、さらには
HADB中に含まれるどのノードに接続するかを気にする必要はありません。
また、どのDRU中に存在するかも気にしなくてよいのです。
これは、HADBが場所の透過性(location transparency)を提供しているためで、
クライアントは実際にデータがどのノードに保存されているのかを
知る必要はなく、データベースが自動的に保存されている
場所を検索してくれます。
そこで、クライアント(SJS Application Server)が複数存在する場合は、
クライアント毎に接続先のHADBノードを変更する事でワークロードが
より均等になり推奨されます。
耐障害性について
各HADBノードは必ず１つのミラーノードを持っています。フラグメントを説明した箇所で
示した図によると、「Node 0とNode 1」、「Node 2とNode 3」、「Node 4とNode5」
の組み合わせになっています。これらのHADBノードが何らかの理由により障害発生した場合、
ケースに応じて異なる動作を行います。その動作の違いについて下記に説明します。
障害発生ケース１（ノードの自己復旧成功の場合）：
DRU 1上に存在するノード(Node 1)に障害が発生した場合、まず初めに下記の図のように、
データベースの操作を引き続き行えるように、DRU 0上のミラーノード(Node 0)が
サービスを提供するようになります。
(参照：A. Mirror node takeover
※ DRU 0の一番上のノードのフラグメントレプリカが両方とも白色になっています。)
次に障害が発生したノード(Node 1)ではノードの自己復旧を試みるため、メモリもしくは
ハードディスクから再起動を試みます。(参照：B. Node Recovery attempt)
障害発生ノードの自己復旧が成功した場合、DRU 0上のノード(Node 0)に対して更新された
データが存在する為、DRU 1上のノード(Node 1)で保持している障害発生時の
データと一致していない可能性があります。そこで、自己復旧完了後、DRU 1上の
ノード(Node 1)はDRU 0上のノード(Node 0)から更新ログを受け取りデータの同期を試みます。
（参照：C. Copy log records）
仮に更新ログの内容がデータの同期を行うために十分な情報を持っていない場合、
ノードの復旧処理は失敗します。そのような場合、次はノード修理という操作が行われます。
復旧に失敗した場合、プライマリノード(Node 0)が保持するデータや更新ログのコピーを
全て取得しノード(Node 1)の再構築を行います。
● ミラーノードから障害ノードに対して全てのフラグメントレプリカのコピーの実施
● ミラーノードから障害ノードに対して全ての更新ログのコピーの実施
上記の操作は、ノード間のデータが同期されるまで行われます。
最後に、全てのデータが同期された後、障害発生前の状態に戻します。
(参照：D. Takeback: Normal operation resumes)
障害発生ケース２（ノードの自己復旧失敗の場合）：
上記のケースと異なり、自己復旧やノードの修理ができないような場合は、
（例：物理的なH/Wシステム障害等）異なる動作を行います。
HADBはスペアノード(Node 7)を代わりに使用して
障害発生したノード(Node 1)が持つ役割を全て引き継ぐようになります。
下記の図において、「Node 1」の自己復旧に失敗した場合、スペアノード(Node 7)が
起動し、「Node 0」より全てのフラグメントレプリカのコピーと更新ログを
取得しノード(Node 7)を構築し初めます。そして全てのデータの同期が完了した後、
「Node 0」のミラーノードとして「Node 7」が設定されます。
そして、それ以外のノード(Node 2,3,4,5,6)に対してノードのペアが変更された事を通知します。
手順
AではスペアノードのTake Overが実施され２つのプライマリフラグメントレプリカを
保持しています。
Bでは「Node 1」が自己復旧を試みますが、失敗します。
Cではレプリカデータとログが「Node 0」から、他のDRU(DRU 1)に存在するスペアノード
の「Node 7」に対してコピーされます。
Dでは「Node 0」と「Node 7」の組み合わせで通常のサービスが提供されています。
また、「Node 1」が復旧した場合は、DRU 1におけるスペアノードとして稼働します。
以上でHADBの全体的な動作概要を説明しました。
まだ、説明がたりない点もありますが、HADBの動作について理解
いただけましたか？
上記のように、HADBは提供するDBサービスをH/W障害等が発生した場合でも
継続して提供できるように、自己回復機能やスペアノードを利用する等して実現しています。
結果として、HADBを複数台のノードから構成する事で99.999%の高可用性を実現できる
ようになっています。
インメモリリプリケーションではHADBに比べ高可用性率は若干低下します。
そこで、ミッションクリティカルのシステムでは是非HADBの御使用を御検討ください。
ロードバランサプラグインのインストールと設定
さて今日はWeb Server(SJS Web Server 7.0)にロードバランサ（負荷分散）の
設定を行いたいと思います。
構築する環境は、下記の図に示す通りで、SJS Web Server 7.0 u1を
webserver:192.168.0.3にインストールします。そしてWeb Serverの
インストール後、ロードバランサプラグインを導入・設定します。
それではまず、Sun Java System Web Server 7.0 u1を入手して
下記のインストール手順（ステップ１〜ステップ１５まで）に従いインストールを
行ってください。
SJS Web Server 7.0のインストール手順
1. SJS Web Server 7.0の構成のクリーンアップ
インストール完了後、まずはじめに既存のWeb Serverの構成を
クリーンアップ（削除）します。下記の手順にて既存の構成を
削除して下さい。
> ./wadm –user=admin admin-user-password を入力してください> [********] localhost:8989 に接続されました Sun Java System Web Server 7.0U1 B06/12/2007 22:48 wadm> list-configs https-webserver //<—この構成を削除 wadm> delete-config https-webserver wadm> list-configs |
2. ロードバランサ用の構成を作成
構成のクリーンアップを行った状態で、SJS Web Server 7.0 u1の
管理画面に(http://webserver:8989/)ブラウザでアクセスして下さい。
すると下記の画面が表示されます。
ここで「新規構成」ボタンを押下して下さい。
すると下記の画面が表示されます。
ここで今回、ロードバランサ用のインスタンスを構成する構成名として
「lb-config」を入力します。
またWeb Server名として「webserver」を入力して下さい。
各項目を入力した後「次へ」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
ここで、Web Server上でロードバランサのサービスを提供するポート番号を
「80」とする場合「80」を入力します。
またIPアドレス欄にはサービスを受け付けるIPアドレスを入力します。
「＊」を指定した場合、システム内に複数の論理IPアドレスが
設定されているシステムにおいて、どのIPアドレスでアクセスされても
ポート番号：80に対するアクセスがあった場合、HTTPの処理が
施されます。
各項目を入力した後「次へ」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
ここでは、Web Server上でJava,CGIおよびSHTMLの有効・無効化の設定を行います。
各項目を設定した後「次へ」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
ここでは、インスタンスを動作させるノードを選択します。
Web Server 7.0よりApplication Serverと同様にクラスタ構成を組む事が
可能となっており、単一の管理サーバから複数のノードを管理できるように
なっています。仮に複数のノードを管理している場合、ノード選択欄に
選択可能なノードが表示されます。
※ 今回は、Webサーバをインストールするマシン（ノード）として
「appserver02:192.168.0.3」を使用します。
ノードを選択後「次へ」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
ここで、Web Serverの構成を行う前の最終確認を行います。
設定内容を確認後「完了」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
正常にWeb Server の構成が完了すると下記の画面が表示されます。
「閉じる」ボタンを押下して下さい。
3. Web Serverインスタンスの起動
構成が正常に完了した後、ブラウザで再度Web Serverbの管理画面に
アクセスして下さい。そして「構成」タブを選択して下さい。
すると下記の画面が表示されます。
ここで、先ほど作成した構成のチェックボックスにチェックを付け、
「起動…」ボタンを押下して下さい。
「起動…」ボタンを押下すると下記の画面が表示されます。
Web Serverのインスタンスが正常に起動された場合下記の画面が表示
されます。「閉じる」ボタンを押下して下さい。
4. ロードバランサプラグインのインストール
SJS Web Server 7のインストールと設定が完了した後、
SJS Application Server 9.1 with HADBのインストーラを
Web Server 7のシステムにFTP等でコピーします。
Web Server 7が稼働するシステム上でApplication Server 9.1の
インストーラを起動して下さい。
> ./sjsas_ee-9_1-solaris-sparc.bin |
インストーラを起動した後下記の画面が表示されます。
インストールを続行する場合、「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、ライセンス条項に同意する場合「Yes」のチェックボックスに
チェックを付け「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、Application Serverのインストール場所を指定します。
インストールする環境に応じて適切な場所を指定して
「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、SJS Application Server 9.1のインストールコンポーネントを選択します。
今回は、ロードバランサプラグインのみをインストールしますので、
「Load Balancing Plugin」のチェックボックスにチェックを付け「Next」ボタンを
押下してください。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、SJS Application Server 9.1を稼働させる為に使用する
Java 2 SDKを指定します。
インストールを行うシステム上にJava 2 SDKが導入されていない場合は
[Install Java 2 SDK (5.0)] にチェックを付け、SJS Application Server 9.1に付属の
Java 2 SDKをインストールして下さい。
Java 2 SDK が導入されている場合は、[Reuse existing Java 2 SDK]
にチェックを付け、[Browse]ボタンより既存のJava 2 SDKを指定して下さい。
チェックを付けた後、「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、既存のWeb Serverの場所を指定します。
Web Server 7.0 u1のインストール場所と構成ディレクトリは
下記の場所にインストールされています。
> pwd /sun/webserver7 > ls Legal admin-server https-lb-config jdk plugins setup README.txt bin include lib samples |
そこで、「Browse…」ボタンを押下しWeb Server 7.0の構成ディレクトリ
「/sun/webserver7/https-lb-config」を指定します。
ディレクトリを指定した後、「Next」ボタンを押下してください。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、Web Server 7.0の管理ポートに接続する為の
設定を行います。
Web Serverの管理者のユーザ名・パスワード・Web Serverのホスト名
（もしくはIPアドレス）・ポート番号をそれぞれ入力した後、
「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、Application Serverの登録チェックボックスにチェックをつけ
「Next」ボタンを押下して下さい。
「Next」ボタンを押下すると下記の画面が表示され、必要なディスク容量が存在するか否かを
チェックします。
十分なディスク容量が存在する場合、下記の画面が表示されます。
内容を確認し、「Install Now」ボタンを押下して下さい。
インストールが完了すると下記の画面が表示されます。
5. インストール内容の確認
Web Server 7.0にロードバランサプラグインのインストールが完了した後、
変更内容について確認します。下記のディレクトリに移動しWeb Server 7.0の
設定変更箇所を確認します。
> cd /sun/webserver7/https-lb-config/config > ls -lt 合計 388 -rw——- 1 webservd webservd 2050 9月 3日 18:22 obj.conf -rw-r–r– 1 root root 1436 9月 3日 18:22 obj.conf.orig -rw——- 1 webservd webservd 527 9月 3日 18:22 magnus.conf -rw-r–r– 1 root root 177 9月 3日 18:22 magnus.conf.orig -rw-r–r– 1 root root 7745 9月 3日 18:22 sun-loadbalancer_1_2.dtd -rw-r–r– 1 root root 7530 9月 3日 18:22 sun-loadbalancer_1_1.dtd -rw-r–r– 1 root root 5292 9月 3日 18:22 sun-loadbalancer_1_0.dtd -rw-r–r– 1 root root 1284 9月 3日 18:22 loadbalancer.xml.example -rw——- 1 webservd webservd 2154 9月 3日 17:55 server.xml -rw——- 1 webservd webservd 2887 9月 3日 17:55 server.policy -rw——- 1 webservd webservd 9153 9月 3日 17:55 mime.types -rw——- 1 webservd webservd 466 9月 3日 17:55 login.conf -rw——- 1 webservd webservd 160 9月 3日 17:55 keyfile -rw——- 1 webservd webservd 400 9月 3日 17:55 default.acl -rw——- 1 webservd webservd 14732 9月 3日 17:55 default-web.xml -rw——- 1 webservd webservd 1527 9月 3日 17:55 certmap.conf -rw——- 1 webservd webservd 32768 9月 3日 17:55 key3.db -rw——- 1 webservd webservd 65536 9月 3日 17:55 cert8.db -rw——- 1 webservd webservd 32768 9月 3日 17:55 secmod.db |
上記より、変更・追加されたファイルは下記の６ファイルである事が確認できます。
●obj.conf
●magnus.conf
●sun-loadbalancer_1_2.dtd
●sun-loadbalancer_1_1.dtd
●sun-loadbalancer_1_0.dtd
●loadbalancer.xml.example
ここで、さらに設定ファイルの変更箇所を確認して見ましょう。
ファイルの内容をdiffコマンドで確認した所、下記の項目が追加・変更
されている事が確認できます。
obj.confに対する追加項目
NameTrans fn=”name-trans-passthrough” name=”lbplugin” config-file=”/sun/webserver7/https-lb-config/config/loadbalancer.xml” <Object name=”lbplugin”> ObjectType fn=”force-type” type=”magnus-internal/lbplugin” PathCheck fn=”deny-existence” path=”*/WEB-INF/*” Service type=”magnus-internal/lbplugin” fn=”service-passthrough” Error reason=”Bad Gateway” fn=”send-error” uri=”$docroot/badgateway.html” </Object> <Object ppath=”*lbconfigupdate*”> PathCheck fn=”get-client-cert” dorequest=”1″ require=”1″ </Object> <Object ppath=”*lbgetmonitordata*”> PathCheck fn=”get-client-cert” dorequest=”1″ require=”1″ </Object> |
magnus.confに対する追加項目
##BEGIN EE LB Plugin Parameters Init fn=”load-modules” shlib=”/sun/webserver7/plugins/lbplugin/bin/libpassthrough.so” funcs=”init-passthrough,service-passthrough,name-trans-passthrough” Thread=”no” Init fn=”init-passthrough” ##END EE LB Plugin Parameters 変更前： Init fn=”load-modules” shlib=”libj2eeplugin.so” shlib_flags=”(global|now)” 変更後： Init fn=”load-modules” shlib=”/sun/webserver7/lib/libj2eeplugin.so” shlib_flags=”(global|now)” |
ロードバランサプラグインのインストール場所
プラグインの実体は下記のディレクトリにインストールされます。
> pwd /sun/webserver7/plugins > ls -lt 合計 10 drwxr-xr-x 5 root root 512 9月 3日 18:22 lbplugin drwxr-xr-x 3 root root 512 9月 3日 17:45 fastcgi drwxr-xr-x 3 root root 512 9月 3日 17:45 loadbal drwxr-xr-x 3 root root 512 9月 3日 17:45 htaccess drwxr-xr-x 3 root root 512 9月 3日 17:45 digest > cd lbplugin/ > ls bin errorpages resource > ls -lR .: 合計 6 drwxr-xr-x 2 root root 512 9月 3日 18:22 bin drwxr-xr-x 2 root root 512 9月 3日 18:22 errorpages drwxr-xr-x 2 root root 512 9月 3日 18:22 resource ./bin: 合計 1520 -rwxr–r– 1 root root 762284 9月 3日 18:22 libpassthrough.so ./errorpages: 合計 4 -rw-r–r– 1 root root 715 9月 3日 18:22 default-error.html -rw-r–r– 1 root root 715 9月 3日 18:22 sun-http-lberror.html ./resource: 合計 112 -rw-r–r– 1 root root 22272 9月 3日 18:22 LBPluginDefault_root.res -rw-r–r– 1 root root 34060 9月 3日 18:22 LBPlugin_root.res |
以上で、Web Serverに対するロードバランサプラグインのインストールが完了しました。
6. SJS Application Server 9.1の設定のエキスポート
上記で、Web Server 7.0上でロードバランサ（負荷分散）を行うための
コンポーネントのインストールは完了していますが、まだ実際には
負荷分散を行う事はできません。そこでSJS Application Server 9.1に
デプロイしたアプリケーションに対して負荷分散ができるように設定を
行ってみたいと思います。
設定手順と設定内容のエクスポート
下記の手順に従い、ロードバランサの設定を行ってください。
A.ロードバランサの設定の作成
appserver1 > ./asadmin list-clusters app-cluster1 running Command list-clusters executed successfully. appserver1 > ./asadmin create-http-lb-config –user admin –target app-cluster1 lb-config Command create-http-lb-config executed successfully. |
B. ロードバランサの有効化
appserver1 > ./asadmin enable-http-lb-server –user admin app-cluster1 Command enable-http-lb-server executed successfully. |
C.ロードバランサ上でアプリケーションの有効化
appserver1 > ./asadmin enable-http-lb-application –user admin –name clusterjsp app-cluster1 Application [clusterjsp] is already enabled for cluster [app-cluster1]. CLI137 Command enable-http-lb-application failed. |
※ 今回は既にアプリケーションが有効になっていますので
既に有効になっているメッセージが出力されていますが、
アプリケーションが有効になっていない場合は上記コマンドで
有効にして下さい。
D.ヘルスチェックの有効化
appserver1 > ./asadmin create-http-health-checker –user admin –interval 10 –config lb-config app-cluster1 Command create-http-health-checker executed successfully. |
E.設定ファイルのエキスポート
appserver1 > ./asadmin export-http-lb-config –user admin –config lb-config /tmp/loadbalancer.xml Generated file location: /tmp/loadbalancer.xml Command export-http-lb-config executed successfully. |
エクスポートで生成されたloadbalancer.xmlの内容
<?xml version=”1.0″ encoding=”UTF-8″?> <!DOCTYPE loadbalancer PUBLIC “-//Sun Microsystems Inc.//DTD Sun Java System Application Server 9.1//EN” “sun-loadbalancer_1_2.dtd”> <loadbalancer> <cluster name=”app-cluster1″ policy=”round-robin”> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://appserver01:38080 https://appserver01:38181″ name=”appserver01-instance1″ weight=”50″/> <instance disable-timeout-in-minutes=”30″ enabled=”true” listeners=”http://appserver02:38080 https://appserver02:38181″ name=”appserver02-instance1″ weight=”50″/> <web-module context-root=”/clusterjsp” disable-timeout-in-minutes=”30″ enabled=”true”/> <health-checker interval-in-seconds=”10″ timeout-in-seconds=”10″ url=”/”/> </cluster> <property name=”response-timeout-in-seconds” value=”60″/> <property name=”reload-poll-interval-in-seconds” value=”60″/> <property name=”https-routing” value=”false”/> <property name=”require-monitor-data” value=”false”/> <property name=”active-healthcheck-enabled” value=”false”/> <property name=”number-healthcheck-retries” value=”3″/> <property name=”rewrite-location” value=”true”/> </loadbalancer> <!– This file was generated on: [Tue Sep 04 15:56:34 JST 2007]. Debugging Tips: By default, instances and web-modules are not enabled. Please enable them manually if you have not done that using asadmin. –> |
7. SJS Web Server 7.0 u1への設定の反映
Application Server 上でロードバランサの設定を行った後、
Web Server 7.0でエキスポートされたファイルを取得し
動的再構成を行います。FTPを使用しファイルを取得して下さい。
webserver > pwd /sun/webserver7/https-lb-config/config webserver > ls cert8.db keyfile mime.types server.xml certmap.conf loadbalancer.xml.example obj.conf sun-loadbalancer_1_0.dtd default-web.xml login.conf obj.conf.orig sun-loadbalancer_1_1.dtd default.acl magnus.conf secmod.db sun-loadbalancer_1_2.dtd key3.db magnus.conf.orig server.policy webserver > ftp 192.168.0.1 Connected to 192.168.0.1. 220 appserver01 FTP server ready. Name (192.168.0.1:root): 331 Password required for root. Password: [********] 230 User root logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> ascii 200 Type set to A. ftp> cd /tmp 250 CWD command successful. ftp> get loadbalancer.xml 200 PORT command successful. 150 Opening ASCII mode data connection for loadbalancer.xml (1384 bytes). 226 Transfer complete. local: loadbalancer.xml remote: loadbalancer.xml 1405 bytes received in 0.023 seconds (60.25 Kbytes/s) ftp> quit 221-You have transferred 1405 bytes in 1 files. 221-Total traffic for this session was 1871 bytes in 1 transfers. 221-Thank you for using the FTP service on appserver01. 221 Goodbye. |
次に、Web Server 7.0上で設定の反映を行います。
webserver > cd/sun/webserver7/https-lb-config/bin webserver > ./reconfig webserver > ./startserv Sun Java System Web Server 7.0U1 B06/12/2007 22:48 info: reports: Initializing lbplugin BuildId: A701212-164111 info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] config: trying to GET /, name-trans-passthrough reports: init-passthrough has not been called config: trying to GET /WEB-INF/web.xml, name-trans-passthrough reports: init-passthrough has not been called config: trying to GET /, name-trans-passthrough reports: init-passthrough has not been called warning: reports: lb.runtime: RNTM2019: Daemon http://appserver01:38080 has been intialized. warning: reports: lb.runtime: RNTM2019: Daemon https://appserver01:38181 has been intialized. warning: reports: lb.runtime: RNTM2019: Daemon http://appserver02:38080 has been intialized. warning: reports: lb.runtime: RNTM2019: Daemon https://appserver02:38181 has been intialized. info: HTTP3072: http-listener-1: http://webserver:80 ready to accept requests info: CORE3274: successful server startup |
8. ロードバランサ（負荷分散）の動作確認
上記でロードバランサ（負荷分散）を行うための全ての設定が完了しました。
それでは、最後にブラウザを使用しSJS Web Server 7.0のサービスを
提供しているURLに接続してみましょう。
ブラウザで下記のURLにアクセスしてみます。
http://webserver(192.168.0.3)/clusterjsp
すると下記の画面が表示されます。
ここで、「Executed From Server：」の項目に注目しておいて下さい。
これは、どのサーバ上で実行されているかを示しています。
下記の例では、「appserver02」で実行されている事がわかります。
そして、ブラウザを一度終了し、再起動した後、再度同一URLに
アクセスしてみて下さい。すると下記の画面が表示されます。
下記の例では、同一のURLにアクセスしたにも関わらず、
「appserver01」で実行されている事が確認できます。
今は重み付けの設定を50:50に設定しておりますので、
負荷は均等に割り振られていますが、重み付けを変更する事で
負荷の割合を変更する事もできるようになります。
如何でしょうか。少し長くなりましたが、以上でロードバランサの
設定は終了です。
次回は、99.999%の高可用性を実現する為のHADBの設定方法について
紹介します。
寺田 佳央 - Yoshio Terada 