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の設定方法について
紹介します。
SJS Application Server with HADB 2台目インストール
さて、今日はもう１台のマシン(appserver02:192.168.0.2)に対して
SJS Application Server 9.1 with HADBをインストールしましょう。
先日紹介したインストール方法と異なる点は、DASのコンポーネントはインストールせず、
管理コマンドと、ノードエージェントを追加するだけとなっています。
※ ドメイン管理サーバ(DAS: Domain Administration Server)はappserver01(192.168.0.1)
に既に導入されています。
1. インストーラの起動
SJS Application Server 9.1をインストールする為、下記のコマンドを実行して下さい。
> ./sjsas_ee-9_1-solaris-sparc.bin |
2. インストール Wizard画面の表示
インストーラを起動した後下記の画面が表示されます。
インストールを続行する場合、「Next」ボタンを押下して下さい。
3. ライセンスの同意確認画面
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、ライセンス条項に同意する場合「Yes」のチェックボックスに
チェックを付け「Next」ボタンを押下して下さい。
4. インストール場所の指定
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、Application Serverのインストール場所を指定します。
デフォルトではインストール先として [/opt/SUNWappserver] が
記載されています。インストールする環境に応じて適切な場所を
指定して「Next」ボタンを押下して下さい。
仮に指定したディレクトリ名が存在しない場合、下記の画面が表示されます。
[Create Directory] ボタンを押下してディレクトリを作成して下さい。
5. インストールするコンポーネントの選択
「Next」ボタンもしくは [Create Directory] ボタンを押下すると下記の画面が表示されます。
ここで、SJS Application Server 9.1のインストールするコンポーネントを選択します。
DASの管理コンポーネントは別のマシン(appserver01)にインストールされていますので、
「Command Line Administration Tool Only」を選択します。
また、「Sample Applications」のチェックも外しておきます。
6. Java 2 SDKの指定
「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」ボタンを押下して下さい。
7. SJS Application Server 9.1の管理設定
ここで、SJS Application Server 9.1のDASに接続するために、
必要な情報である、DASのサーバ名（もしくはDASのIPアドレス）
管理者のユーザ名・パスワード・マスターパスワード・
そしてノードエージェント名を設定します。
設定項目入力後、「Next」ボタンを押下して下さい。
8. インストールオプションの選択
「Next」ボタンを押下すると下記の画面が表示されます。
ここでは、インストールを行う際に選択可能なオプションが指定できます。
[※] Register Application Server
ここで、Application Serverの登録チェックボックスにチェックをつけ
「Next」ボタンを押下して下さい。
9. インストール前の事前確認
「Next」ボタンを押下すると下記の画面が表示され、必要なディスク容量が存在するか否かを
チェックします。
10. インストール前の最終確認
十分なディスク容量が存在する場合、下記の画面が表示されます。
内容を確認し、「Install Now」ボタンを押下して下さい。
11. インストールの実行
「Install Now」 ボタンを押下すると、インストールが開始し下記の画面が
表示されます。
12. インストール完了
インストールが正常に終了すると下記の画面が表示されます。
ここには、Application Serverの参考情報へのURL等が記載されていますので
内容を確認し「Finish」ボタンを押下します。
13. ノードエージェントの起動
それぞれのマシン上で下記のコマンドを実行し、ノードエージェントの
プロセスを起動して下さい。
appserver01側のノードエージェントの起動
appserver1 > ./asadmin start-node-agent –user=admin appserver01 Please enter the admin password> [********] Please enter the master password [Enter to accept the default]:>[********] Redirecting output to /sun/SUNWappserver91/nodeagents/appserver01/agent/logs/server.log Command start-node-agent executed successfully. |
appserver02側のノードエージェントの起動
appserver2 > ./asadmin start-node-agent –user=admin appserver02 Please enter the admin password> [********] Please enter the master password [Enter to accept the default]:>[********] Redirecting output to /sun/SUNWappserver91/nodeagents/appserver02/agent/logs/server.log Command start-node-agent executed successfully. |
14. ノードエージェントの起動確認とクラスタ環境の構築
ノードエージェントを起動した後、ブラウザでSJS Application Server 9.1の
管理サーバに接続して下さい。
左側の管理コンポーネントのツリーの「Node Agents」を展開すると、
それぞれ、「appserver01」、「appserver02」のノードが追加されている事が
確認できます。
クラスタ環境の構築
この状態で、管理コンポーネントのツリーより「Cluster」を押下します。
すると上記の画面が表示されます。
ここで、クラスタ名として「app-cluster1」を入力します。
次に、クラスタ内に属するインスタンスを「New」ボタンを(2度)押下し指定します。
「New」ボタンを押下すると「インスタンス名」と「ノードエージェント」を
指定するフィールドが表示されます。
また、「Weight(重み付け)」の箇所は負荷分散を行う際の重み付けを指定しますが、
例えば、均等にアクセスを分散させる場合は、「50」、「50」と入力します。
補足：1/4のリクエストを「appserver01-instance1」に3/4のリケエスとを
「appserver02-instance1」に振り分けたい場合は、それぞれの
Weight(重み付け)欄に「25」、「75」と入力するか、もしくは
「1」、「3」と記入して下さい。
各項目を入力した後、「OK」ボタンを押下して下さい。
ボタンを押下すると下記の画面が表示されます。
15. クラスタ環境に対するアプリケーションのデプロイ
次に、構築したクラスタ環境に対してサンプルアプリケーションのデプロイを行います。
管理コンポーネントより、「Cluster」を選択し、「app-cluster1」を押下して下さい。
すると下記の画面が表示されます。ここで、右側の画面より「Applications」タブを押下します。
「Applications」タブを押下すると下記の画面が表示されます。
ここで、「Deploy…」ボタンを押下して下さい。
「Deploy…」ボタンを押下すると下記の画面が表示されます。
「Local packaged file or directory that is accessible from the Application Server 」の
ラジオボタンを選択し、「Browse Files…」ボタンを押下して下さい。
「Browse Files…」ボタンを押下すると下記の画面が表示されます。
SJS Application Server 9.1に付属する「clusterjsp」というサンプルアプリケーションを
選択し、「Choose File」ボタンを押下します。
「Choose File」ボタンを押下すると下記の画面に戻ります。
ここで、「Available Targets:」よりインストールする対象のクラスタ「app-cluster1」を
選択し、「Add >」ボタンを押下し「Selected Targets:」に追加します。
最後に、「OK」ボタンを押下しアプリケーションのデプロイを完了します。
アプリケーションのデプロイが正常に完了すると下記の画面が表示されます。
それでは、実際にインスタンスに対してアクセスし、サンプルアプリケーションが
動作しているかを確認してみましょう。
ブラウザを使用して、アプリケーションのインスタンスに接続して下さい。
デフォルトの設定の場合、それぞれ下記のポート番号になっています。
http://appserver01:38080/clusterjsp
http://appserver02:38080/clusterjsp
如何でしょう？
たった、１度の操作でアプリケーションを２台のマシンに配備できました。
次回は、Web Server 7で負荷分散（ロードバランサ）の設定を行います。
クラスタ環境構築の準備
先日は、SJS Application Server 9.1 EEを１台のマシンにインストールし、
ドメイン管理サーバ（Domain Administration Server）上に存在する
インスタンスに対してアプリケーションをデプロイし動作確認を行いました。
参考：SJS Application Server 9.1 EE Betaのインストール
さて今回より、負荷分散・高可用性を実現する為クラスタ環境を構築し、
セッション情報を複数台のマシン上で共有できるようなシステムの構築を
行います。
まず、システムを構築する前に、事前に理解して置かなければならない内容について
説明します。
キーワードは下記の４つです。
●ドメイン
●ドメイン管理サーバ(DAS: Domain Administration Server)
●ノードエージェント(Node Agent)
●インスタンス(Instance)
●クラスタ
絵を使ってもう少し詳しく説明しましょう。
「ユーザの観点」からと「サーバ管理者」の観点からそれぞれ確認します。
まず「サーバ管理者」はSJS Application Serverの管理を
行うために必ず１つ以上のドメイン（Application Serverの構成単位）を
作成します。
そして、ドメインを管理する為にドメイン内に必ず１つの
ドメイン管理サーバ(DAS)を用意します。
インストール時には下記の項目で「ドメイン管理サーバ」として
インストールを行う設定をします。
ドメイン内に所属する全てのマシン（物理的なH/W）上に
それぞれのマシンを管理する為の軽量エージェントプロセス（ノードエージェント）
を導入する必要があります。ノードエージェントはDAS上から管理を行い、
実際にサービスを提供するインスタンス(Server Instance)の
起動・停止・作成・削除等の操作を行う事ができます。
また、Web アプリケーションやEJBモジュール等はインスタンスに
配備し、ユーザはこのインスタンスに対してアクセスする事で
サービスを受ける事ができるようになります。
次にクラスタについて説明します。
アプリケーションに対する負荷を複数台のマシンで分散させる為(Scalability)、
単一システムの障害によるサービス停止を防ぐ高可用性(High Availability)を
実現する為に管理者は複数台のマシンでサービスを提供したいと考えます。
この際、同一のアプリケーションを複数台のマシンに配備する必要が
ありますが、サーバインスタンスを個別に作成し、個別にアプリケーションを
配備するのは非常に管理コストのかかる作業になります。
また、マシンの数が多くなればなる程、管理者による操作ミスが発生して
しまう可能性があります。
これらを防ぐために、SJS Application Serverでは「クラスタ」という
概念が存在します。
クラスタはアプリケーション・リソース(JNDI等)・設定情報をクラスタに
属するインスタンスで共有する事が可能となります。つまり管理者は
クラスタに対する1回の操作を行うだけで全てのインスタンスに対して
同一の操作をしたのと同じ事が実現できます。これにより管理者の
管理コストは軽減し、さらには管理者による単純ミスを防ぐ事ができるように
なります。
今回構築するシステムは下記の図の構成とします。
前段にWeb Serverを配置し、後段にApplication Server を2台のマシンに
それぞれ配置します。
インストールコンポーネント
今回、appserver01(192.168.0.1),appserver2(192.168.0.2)それぞれに対して
SJS Application Server 9.1 EE(with HADB)をインストールします。
それぞれにインストールするコンポーネントを下記の表に示します。
インストールコンポーネント/ホスト名 | appserver01 | appserver02 | |
|---|---|---|---|
| アプリケーションサーバ | ドメイン管理サーバ | ● | × |
ノードエージェント | ● | ● | |
コマンド行管理ツール | ● | ● | |
| ロードバランスプラグイン | × | × | |
JavaDBデータベース | ● | ● | |
OpenESB | ● | ● | |
| サンプルアプリケーション | ● | × | |
Sun Java System Message Queue | ● | ● | |
| High Availability Session Store (HADB) | ● | ● | |
SJS Application Server 9.1 EE Betaのインストール
Sun Java System Application Server 9.1 のリリースが
まじかとなって参りました。
そこで、本日よりSJS Application Server 9.1 with HADBのベータ版を使用して
機能検証を行いたいと思います。本検証は英語を使用しています。
(マルチリンガル版を入手し次第画面ダンプを置き換え予定)
また本ブログ中でダンプした画像と正式リリース後の表示画面は
異なる場合がありますので、御了承ください。
それでは早速インストールを行ってみたいと思います。
SJS Application Server 9.1 Enterprise Editionのインストール
1. インストールバイナリの入手
現時点ではSJS Application Server 9.1 with HADBバージョンを
入手する事はできません。SJS Application Server 9.1の
正式リリース後に弊社サイトより入手可能となる予定です。
2. インストーラの起動
インストーラを入手した後、ファイルを保存したディレクトリ下で
下記のコマンドを実行して下さい。
> ./sjsas_ee-9_1-solaris-sparc.bin |
3. インストール Wizard画面の表示
インストーラを起動した後下記の画面が表示されます。
インストールを続行する場合、「Next」ボタンを押下してください。
4. ライセンスの同意確認画面
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、ライセンス条項に同意する場合「Yes」のチェックボックスに
チェックを付け「Next」ボタンを押下して下さい。
5. インストール場所の指定
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、Application Serverのインストール場所を指定します。
デフォルトではインストール先として [/opt/SUNWappserver] が
記載されています。インストールする環境に応じて適切な場所を
指定して「Next」ボタンを押下して下さい。
仮に指定したディレクトリ名が存在しない場合、下記の画面が表示されます。
[Create Directory] ボタンを押下してディレクトリを作成して下さい。
6. インストールするコンポーネントの選択
「Next」ボタンもしくは [Create Directory] ボタンを押下すると下記の画面が表示されます。
ここで、SJS Application Server 9.1のインストールするコンポーネントを選択します。
Serverに関するコンポーネント：
Node Agent :
High Availability Database Servver(以降 HADB) :
Load Balancing Plugin :
管理に関するコンポーネント
Domain Administration Server and Administration Tool ;
Command Line Administration Tool Only :
No Administration Tools :
追加コンポーネント
Sample Applications
本マシンにはドメインを管理する為のDomain Administration Serverとして
設定する為、[Node Agent] , [HADB] , [Domain Administration Server and Administration Tools]
[Sample Applications] のチェックボックスにチェックを付けインストールを行う事にします。
チェックを付けた後、「Next」ボタンを押下して下さい。
7. Java 2 SDKの指定
「Next」ボタンを押下すると下記の画面が表示されます。
ここで、SJS Application Server 9.1を稼働させる為に使用する
Java 2 SDKを指定します。
インストールを行うシステム上にJava 2 SDKが導入されていない場合は
[Install Java 2 SDK (5.0)] にチェックを付け、付属のJava 2 SDKを
インストールして下さい。
既に Java 2 SDK が導入されている場合は、[Reuse existing Java 2 SDK]
にチェックを付け、[Browse]ボタンより既存のJava 2 SDKを指定して下さい。
チェックを付けた後、「Next」ボタンを押下して下さい。
8. SJS Application Server 9.1の管理設定
ここで、SJS Application Server 9.1の管理を行うために、
管理者のユーザ名・パスワード・マスターパスワード・
管理用GUIへアクセスする為のポート番号を設定します。
設定項目入力後、「Next」ボタンを押下して下さい。
9. インストールオプションの選択
「Next」ボタンを押下すると下記の画面が表示されます。
ここでは、インストールを行う際に選択可能なオプションが指定できます。
[＊] Register Application Server(アプリケーションの導入後、登録を行う場合)
[ ] Upgrade from Previous Version (前バージョンからの設定を引き継いでアップグレードインストールを行う場合)
[＊] Enable Updatecenter Client (アップデートセンターのクライアントを有効にする場合)
必要なオプションにチェックを付け「Next」ボタンを押下して下さい。
10. インストール前の事前確認
「Next」ボタンを押下すると下記の画面が表示され、必要なディスク容量が存在するか否かを
チェックします。
11. インストール前の最終確認
十分なディスク容量が存在する場合、下記の画面が表示されます。
内容を確認し、「Install Now」ボタンを押下して下さい。
12. インストールの実行
「Install Now」 ボタンを押下すると、インストールが開始し下記の画面が
表示されます。
13. インストール完了
インストールが正常に終了すると下記の画面が表示されます。
ここには、アプリケーションサーバの起動方法、管理コンソールへの接続方法
また、動作確認を行うためのサンプルアプリケーションのパスが記載されていますので、
内容を確認し「Finish」ボタンを押下します。
14. SJS Application Server 9.1 の起動
インストールが完了したので、実際にアプリケーションサーバを起動します。
「13. インストール完了」のインストール完了時に表示される画面の内容に
従い、コマンドを実行します。
appserver1 > ./asadmin start-domain –user=admin domain1 Starting Domain domain1, please wait. Log redirected to /sun/SUNWappserver91/domains/domain1/logs/server.log. Please enter the master password> [********] Redirecting output to /sun/SUNWappserver91/domains/domain1/logs/server.log Domain domain1 started. Domain [domain1] is running [Sun Java System Application Server 9.1 (build local)] with its configuration and logs at: [/sun/SUNWappserver91/domains]. Admin Console is available at [https://localhost:4848]. Use the same port [4848] for “asadmin” commands. User web applications are available at these URLs: [http://localhost:8080 https://localhost:8181 ]. Following web-contexts are available: [/web1 /__wstx-services ]. Standard JMX Clients (like JConsole) can connect to JMXServiceURL: [service:jmx:rmi:///jndi/rmi://appserver01:8686/jmxrmi] for domain management purposes. Domain listens on at least following ports for connections: [8080 8181 4848 3700 3820 3920 8686 ]. Domain supports application server clusters and other standalone instances. |
15. SJS Application Server 9.1 の管理コンソールへの接続
アプリケーションサーバが起動した後、Web Browserより管理コンソールの
URLへアクセスして下さい。
※管理コンソールはJSFアプリケーションで作成されている為、起動後
最初にアクセスする際には、内部でコンパイルが行われているため
表示までに時間を要します。
ログイン画面にて管理者のユーザ名、パスワードを入力後「Login」ボタンを押下して
下さい。
「Login」ボタンを押下すると下記の画面が表示されます。
16. SJS Application Server 9.1 へサンプルアプリケーションのデプロイ
次に、サンプルアプリケーションのデプロイと動作確認を行います。
管理コンソールの左に表示されるTreeより「Enterprise Applications」を選択して下さい。
その後、右画面に表示される配備用の画面より「Deploy…」ボタンを押下して下さい。
「Deploy…」ボタンを押下すると下記の画面が表示されます。ここで「Location」として
「Local packaged file or directory that is accessible from the Application Server」に
チェックを付け「Browse Files…」ボタンを押下します。
「Browse Files…」ボタンを押下すると、下記のサブウィンドウが表示されます。
この機能は、SJS Application Server 8.2 までは存在しておりませんでしたが、
Application Server 9.1がインストールされているファイルシステムのディレクトリ構造や
ファイルの内容を確認できるアプリケーションとなっています。
ディレクトリを辿って下記のディレクトリ中に存在する「clusterjsp.ear」ファイルを指定します。
[/sun/SUNWappserver91/samples/ee-samples/highavailability/apps/clusterjsp]
※この機能は非常に便利な反面、管理コンソールに対して外部からアクセスできる環境の場合
システムのディレクトリ構造を初め、どのようなファイルが存在しているのかが外部に
漏れる可能性があるため、本番環境においては管理コンソールは特定のシステムからしか
アクセスできないようにして下さい。ファイルを選択後、「OK」ボタンを押下して下さい。
「Choose File」ボタンを押下すると下記の画面が表示されます。
下記の２画面の設定内容を確認し、「OK」ボタンを押下して下さい。
最後に、デプロイしたアプリケーションの動作確認を行います。
ブラウザより、[http://APP-SERVER:8080/clusterjsp/] に接続してください。
如何でしょうか。アプリケーションサーバの動作確認はできましたか？
次回は、他のマシンにもアプリケーションサーバを導入し２台でクラスタ環境を
構築したいと思います。
セキュアプログラミング
さて、今日は少しセキュリティについて触れてみたいと思います。
Web アプリケーションの開発者は色々とセキュリティについて考慮して
プログラムを行わなければなりません。
古くは、CGI 等でフォームを使用する場合、 「<」 を「<」に
置き換える文字列置換等を行ってきました。
こういった事を怠った場合、運用するシステムに致命的な欠陥を
もたらし、場合によっては情報漏洩等も発生し影響は非常に
大きな物となってしまいます。
古くからWeb アプリケーションの開発を行ってきた人は、
こういった情報を収集する必要性を感じ個々で知識を蓄えて
来たものと思います。
しかし、開発初心者の方はこういった点を見落とす、
もしくは重要性を認知していない、もしくは重要性は
認知していてもどのように対応すればよいのかがわからない
といった事があるかと思います。
また、運用管理者の方もWeb アプリケーションの
セキュリティは興味はあるが、具体的にどのような点が
問題となるのかがわからない、どのようにして問題を
発見すればいいのかがわからないといった事もあるかと
思います。
そこで、そのような開発初心者、運用管理者にとって
有用な情報を紹介したいと思います。
Web アプリケーションのセキュリティについて
IPAで資料をまとめられてましたので是非御一読いただければと思います。
独立行政法人 情報処理推進機構 セキュリティセンター
情報セキュリティ技術ラボラトリー
[IPA セキュア・プログラミング講座
]
PS.
これ以外にも有用な情報はたくさんあるのですが、個人のページであったりするため、
直接のリンクはさし控えたいと思います。google等で「セキュリティチェックリスト」をキーワードに
検索してみてください。
新年度 (FY08) 開始にあたって
さて、今日より新年度 (FY08) が開始になります。
日本企業と異なり会計年度の始まりが7月1日になるため、
日本企業で働く方にはこの時期に新年度といわれると
若干違和感があるかと思いますがUSが本社の会社なので
外資系の会社にいるとそんな事にもなれてきます。
ただ、新年度開始といっても初詣にいったり、祈願を
したりするわけでもないので新年を迎えたぁ！！
という実感もまだまだ少なく、今はまだ去年
（先週からの引き続き）の仕事をしています。
さて、昨年は、Javaエバンジェリストグループの一員になった他、
それ以外でも色々とたくさんの面白い事をやってきました。
今年もいろいろと挑戦して行きたいと思います。
2007年7月2日 FY08の初出社＠用賀オフィス
Web Server 7.0 から Web Server 7.0 Update1へのアップデート方法
今日は、SJS Web Server 7.0からSJS Web Server 7.0 Update 1へのアップデート方法
について説明します。
SJS Web Server 7.0から7.0 Update 1へのアップデート方法は非常に簡単です。
7.0 Update 1を御入手いただいた後、Update 1のsetupを実行してください。
そしてインストール先として既存のWeb Server 7.0のディレクトリを指定してください。
ディレクトリを指定後、「次へ」ボタンを押下すると、下記のような画面が表示されます。
ここでは、インストーラが自動的に既存の情報を入手し必要なライブラリのみ
アップデートインストールしてくれます。
実際にこの手法でアップデートした後、アップデートされたファイルを確認してみました。
Web Server 7.0 Upadte 1をアップデートした日付を6月27日とします。
そして、ファイルの更新日付が6月27日の内容だけを確認してみます。
その結果、管理サーバを初めとし既存のインスタンスの内容には一切変更は施されていない事がわかります。つまり、アップデートする為に再度Web Serverのインスタンスを設定をしなおさなくてもそのまま設定が反影される事がわかります。既存の設定が壊れる事はありませんので容易にアップデートが可能です。
※ ただし、アップデートの際は管理サーバやインスタンスは停止してアップデートしてください。
# ls -lt 合計 28 drwx------ 2 root root 512 6月 27日 20:29 setup drwxr-xr-x 3 root root 512 6月 27日 20:28 bin drwxr-xr-x 13 root root 3072 6月 27日 20:28 lib -rw-r--r-- 1 root root 726 6月 27日 20:27 README.txt drwxr-xr-x 2 root root 512 6月 27日 20:27 Legal drwxr-xr-x 8 root root 512 6月 27日 20:27 include drwxr-xr-x 11 root root 512 6月 13日 23:10 https-test.Japan.Sun.COM drwxr-xr-x 9 root other 512 6月 13日 18:57 jdk drwxr-xr-x 2 root root 512 5月 31日 22:10 etc drwxr-xr-x 9 root root 512 5月 28日 21:12 admin-server drwxr-xr-x 6 root root 512 5月 28日 10:34 plugins drwxr-xr-x 7 root root 512 5月 28日 10:34 samples |
# pwd /sun/webserver7/bin # ls -lt 合計 252 -rwxr-xr-x 1 root root 29332 6月 27日 20:28 uninstall -rwxr-xr-x 1 root root 66184 6月 27日 20:27 flexanlg -rwxr-xr-x 1 root root 17068 6月 27日 20:27 htpasswd lrwxrwxrwx 1 root root 7 5月 28日 10:35 64 -> sparcv9 -rwxr-xr-x 1 root root 1062 5月 28日 10:35 schemagen -rwxr-xr-x 1 root root 1015 5月 28日 10:35 xjc -rwxr-xr-x 1 root root 426 5月 28日 10:35 wsimport -rwxr-xr-x 1 root root 421 5月 28日 10:35 wsgen drwxr-xr-x 2 root root 512 5月 28日 10:35 sparcv9 -rwxr-xr-x 1 root root 540 5月 28日 10:35 jspc -rwxr-xr-x 1 root root 941 5月 28日 10:35 modutil -rwxr-xr-x 1 root root 942 5月 28日 10:35 certutil -rwxr-xr-x 1 root root 942 5月 28日 10:35 pk12util -rwxr-xr-x 1 root root 1308 5月 28日 10:35 wdeploy -rwxr-xr-x 1 root root 1439 5月 28日 10:35 wadm # |
# pwd /sun/webserver7/lib # ls -lt 合計 114546 -rw-r--r-- 1 root root 7747324 6月 27日 20:28 webserv-jwsdp.jar -rw-r--r-- 1 root root 44623 6月 27日 20:28 activation.jar -rw-r--r-- 1 root root 270394 6月 27日 20:28 mail.jar -rw-r--r-- 1 root root 698579 6月 27日 20:28 jss4.jar -rw-r--r-- 1 root root 263556 6月 27日 20:28 ldapjdk.jar -rw-r--r-- 1 root root 497796 6月 27日 20:28 ktsearch.jar -rw-r--r-- 1 root root 1034049 6月 27日 20:28 ant.jar -rw-r--r-- 1 root root 476 6月 27日 20:28 libfreebl_32int64_3.chk -rw-r--r-- 1 root root 476 6月 27日 20:28 libfreebl_32int_3.chk -rw-r--r-- 1 root root 476 6月 27日 20:28 libfreebl_32fpu_3.chk -rw-r--r-- 1 root root 476 6月 27日 20:28 libsoftokn3.chk -rw-r--r-- 1 root root 9902188 6月 27日 20:28 libicudata.so.3 -rw-r--r-- 1 root root 1170776 6月 27日 20:28 libicuuc.so.3 -rw-r--r-- 1 root root 1437600 6月 27日 20:28 libicui18n.so.3 -rwxr-xr-x 1 root root 66452 6月 27日 20:28 libz.so -rwxr-xr-x 1 root root 482360 6月 27日 20:28 libfreebl_32int64_3.so -rwxr-xr-x 1 root root 430888 6月 27日 20:28 libfreebl_32int_3.so -rwxr-xr-x 1 root root 599128 6月 27日 20:28 libfreebl_32fpu_3.so -rwxr-xr-x 1 root root 588448 6月 27日 20:28 libsoftokn3.so -rwxr-xr-x 1 root root 304172 6月 27日 20:28 libjss4.so -rwxr-xr-x 1 root root 414472 6月 27日 20:28 libnssckbi.so -rwxr-xr-x 1 root root 162780 6月 27日 20:28 libsasl.so -rwxr-xr-x 1 root root 51488 6月 27日 20:28 libssldap60.so -rwxr-xr-x 1 root root 34344 6月 27日 20:28 libprldap60.so -rwxr-xr-x 1 root root 422884 6月 27日 20:28 libldap60.so -rwxr-xr-x 1 root root 434288 6月 27日 20:28 libnspr4.so -rwxr-xr-x 1 root root 17228 6月 27日 20:28 libplds4.so -rwxr-xr-x 1 root root 43780 6月 27日 20:28 libplc4.so -rwxr-xr-x 1 root root 885804 6月 27日 20:28 libnss3.so -rwxr-xr-x 1 root root 284568 6月 27日 20:28 libsmime3.so -rwxr-xr-x 1 root root 283620 6月 27日 20:28 libssl3.so -rwxr-xr-x 1 root root 137100 6月 27日 20:28 pk12util -rwxr-xr-x 1 root root 309728 6月 27日 20:28 modutil -rwxr-xr-x 1 root root 203376 6月 27日 20:28 certutil drwxr-xr-x 2 root root 4608 6月 27日 20:28 htmlconvert drwxr-xr-x 4 root root 512 6月 27日 20:28 snmp drwxr-xr-x 2 root root 512 6月 27日 20:28 tlds -rwxr-xr-x 1 root root 23871 6月 27日 20:28 migrateServer.pl drwxr-xr-x 2 root root 1536 6月 27日 20:28 messages drwxr-xr-x 3 root root 1024 6月 27日 20:28 perl drwxr-xr-x 3 root root 512 6月 27日 20:28 install drwxr-xr-x 2 root root 512 6月 27日 20:28 icons drwxr-xr-x 2 root root 512 6月 27日 20:28 dtds -rw-r--r-- 1 root root 55028 6月 27日 20:28 s1as-jsr160-server.jar -rw-r--r-- 1 root root 36050 6月 27日 20:28 container-auth.jar -rw-r--r-- 1 root root 22342 6月 27日 20:28 deployment-api.jar -rw-r--r-- 1 root root 36600 6月 27日 20:28 sun-ws-jsr88-dm.jar -rw-r--r-- 1 root root 1965940 6月 27日 20:28 webserv-rt.jar -rw-r--r-- 1 root root 383236 6月 27日 20:28 webserv-jstl.jar -rw-r--r-- 1 root root 531457 6月 27日 20:28 webserv-admin.jar -rw-r--r-- 1 root root 2786266 6月 27日 20:28 pwc.jar -rw-r--r-- 1 root root 323012 6月 27日 20:28 jsf-api.jar -rw-r--r-- 1 root root 1210046 6月 27日 20:28 jsf-impl.jar -rwxr-xr-x 1 root root 17744 6月 27日 20:28 libadminsecurity.so -rwxr-xr-x 1 root root 136004 6月 27日 20:28 libwssecurity.so -rwxr-xr-x 1 root root 37132 6月 27日 20:28 libwsserverctrl.so -rwxr-xr-x 1 root root 15904 6月 27日 20:28 libwslifecycle.so -rwxr-xr-x 1 root root 18840 6月 27日 20:28 libwsconfigurator.so -rwxr-xr-x 1 root root 145176 6月 27日 20:28 libwsconfig.so -rwxr-xr-x 1 root root 72304 6月 27日 20:28 libmonitorjni.so -rwxr-xr-x 1 root root 28836 6月 27日 20:28 libadminjni.so -rwxr-xr-x 1 root root 15184 6月 27日 20:28 libadminutil.so -rwxr-xr-x 1 root root 5113892 6月 27日 20:28 libxerces-c.so.26 -rwxr-xr-x 1 root root 36960 6月 27日 20:28 libxalanMsg.so.19 -rwxr-xr-x 1 root root 6241880 6月 27日 20:28 libxalan-c.so.19 -rwxr-xr-x 1 root root 67472 6月 27日 20:28 libpcre.so.0 -rwxr-xr-x 1 root root 52240 6月 27日 20:28 libxsd2cpp.so -rwxr-xr-x 1 root root 188128 6月 27日 20:28 libwebdav.so -rwxr-xr-x 1 root root 93184 6月 27日 20:28 libsupport.so -rwxr-xr-x 1 root root 13132 6月 27日 20:28 libCld.so -rwxr-xr-x 1 root root 7524 6月 27日 20:28 libShtml.so -rwxr-xr-x 1 root root 13208 6月 27日 20:28 libnstp.so -rwxr-xr-x 1 root root 25224 6月 27日 20:28 libnstime.so -rwxr-xr-x 1 root root 73288 6月 27日 20:28 libnsprwrap.so -rwxr-xr-x 1 root root 50136 6月 27日 20:28 libnsfc.so -rwxr-xr-x 1 root root 4193796 6月 27日 20:28 libns-httpd40.so -rwxr-xr-x 1 root root 203088 6月 27日 20:27 liblibsi18n.so -rwxr-xr-x 1 root root 69420 6月 27日 20:27 liblibdbm.so -rwxr-xr-x 1 root root 260184 6月 27日 20:27 libj2eeplugin.so -rwxr-xr-x 1 root root 7584 6月 27日 20:27 libgetprop.so -rwxr-xr-x 1 root root 294244 6月 27日 20:27 libdavplugin.so -rwxr-xr-x 1 root root 31936 6月 27日 20:27 libares3.so -rwxr-xr-x 1 root root 11976 6月 27日 20:27 runmagt -rwxr-xr-x 1 root root 336484 6月 27日 20:27 httpagt -rwxr-xr-x 1 root root 74344 6月 27日 20:27 CertificateMgrUtil -rwxr-xr-x 1 root root 12068 6月 27日 20:27 svrctl -rwxr-xr-x 1 root root 18156 6月 27日 20:27 parsexml -rwxr-xr-x 1 root root 65904 6月 27日 20:27 dpstats -rwxr-xr-x 1 root root 38696 6月 27日 20:27 dblink -rwxr-xr-x 1 root root 32272 6月 27日 20:27 Cgistub -rwxr-xr-x 1 root root 11128 6月 27日 20:27 webservd -rwxr-xr-x 1 root root 72168 6月 27日 20:27 webservd-wdog -rw-r--r-- 1 root root 206352 6月 27日 20:27 jmxremote_optional.jar -rw-r--r-- 1 root root 168112 6月 27日 20:27 libcliutil.so -rw-r--r-- 1 root root 130194 6月 27日 20:27 webserv-admin-shared.jar -rw-r--r-- 1 root root 1319503 6月 27日 20:27 wadmcli.jar -rw-r--r-- 1 root root 220775 6月 27日 20:27 tcljava.jar -rw-r--r-- 1 root root 62270 6月 27日 20:27 s1as-jsr160-client.jar -rw-r--r-- 1 root root 56936 6月 27日 20:27 jline.jar -rw-r--r-- 1 root root 719297 6月 27日 20:27 jacl.jar -rw-r--r-- 1 root root 81895 6月 27日 20:27 cli-framework.jar -rw-r--r-- 1 root root 20988 6月 27日 20:27 webserv-rt-l10n.jar -rw-r--r-- 1 root root 220685 6月 27日 20:27 webserv-admin-shared-l10n.jar -rw-r--r-- 1 root root 38924 6月 27日 20:27 wadmcli-l10n.jar -rw-r--r-- 1 root root 2576 6月 27日 20:27 cli-framework_zh_TW.jar -rw-r--r-- 1 root root 2572 6月 27日 20:27 cli-framework_zh_CN.jar -rw-r--r-- 1 root root 2695 6月 27日 20:27 cli-framework_ko.jar -rw-r--r-- 1 root root 2723 6月 27日 20:27 cli-framework_ja.jar -rw-r--r-- 1 root root 2505 6月 27日 20:27 cli-framework_fr.jar -rw-r--r-- 1 root root 2493 6月 27日 20:27 cli-framework_es.jar -rw-r--r-- 1 root root 2511 6月 27日 20:27 cli-framework_de.jar drwxr-xr-x 2 root root 1536 6月 27日 20:27 sparcv9 lrwxrwxrwx 1 root root 7 5月 28日 10:35 64 -> sparcv9 -rwxr-xr-x 1 root root 1348 5月 28日 10:35 searchadmin -rwxr-xr-x 1 root root 371 5月 28日 10:35 migrateServer -rwxr-xr-x 1 root root 317 5月 28日 10:35 wsenv drwxr-xr-x 3 root root 512 5月 28日 10:35 cpu drwxr-xr-x 6 root root 512 5月 28日 10:35 webapps |
# pwd /sun/webserver7/include # ls -lt 合計 292 drwxr-xr-x 2 root root 512 6月 27日 20:28 ldapsdk50 drwxr-xr-x 4 root root 3072 6月 27日 20:28 nspr drwxr-xr-x 2 root root 512 6月 27日 20:27 shtml -rw-r--r-- 1 root root 121806 6月 27日 20:27 nsapi.h drwxr-xr-x 2 root root 512 6月 27日 20:27 nsacl -rw-r--r-- 1 root root 350 6月 27日 20:27 netsite.h drwxr-xr-x 2 root root 512 6月 27日 20:27 frame -rw-r--r-- 1 root root 9001 6月 27日 20:27 drnsapi.h drwxr-xr-x 2 root root 512 6月 27日 20:27 base # |
※ nspr , shtml , nsacl , frame , baseディレクトリの中身は全て
アップデートされていました。
高パフォーマンスで信頼できるWeb Proxyソリューション
弊社のSun Fire T1000, T2000等は非常に優れたパフォーマンスを
発揮するサーバ製品として良く知られています。特にWeb Serverや
Application Server等に対する用途として非常にマッチする事も
知られています。
今回、Web ServerやApplication Server以外にProxy Server
(実はHTTPのハンドリング等の部分はWeb Serverのコードを使用)
でも非常に優れたパフォーマンスを発揮する点をレポートに
まとめた資料がリリースされましたので報告します。
この資料の中には、Proxy Serverのベンチマークテストで良く使用されている、
Web Polygraphでの結果も記載されていますので、参考になるかと思います。
是非、一度御確認いただければと思います。
Sun’s High-Performance and Reliable Web Proxy Solution
上記資料によると、PolygraphというProxy Serverのベンチマークツールを
使用し、Sun Fire T2000でProxy １インスタンスあたり、8000 req/secまで
スケールしています。（その際のコンテンツサイズは13Kbです。）
ただし、Sun Fire T2000で8000 req/secが最大なのかというとそうではありません。
その際のCPU使用率は20〜30%しか使用しておらず、
Proxy Serverに対する要求を8000 req/secまでいくとNIC(1GB)の限界に達し
(Network Utilizationが100%)、それ以上を処理できないというのが本当の所です。
Sun Fire T2000にはデフォルトでGigabit Ethernetのポートが4つ付いていますので、
T2000を効率的に使用する為には、Solaris 10の仮想化技術（zone）を使用し
zone毎にProxyをインストールする事でSun Fire T2000上では8000req/sec以上の
処理ができるという事が言えます。
Polygraphによるベンチマーク結果
ドキュメントの日本語化
Sun Java System Web Server 7.0のドキュメントが一部
日本語化されました。
今回は要望が一部とおりパフォーマンスチューニングガイドも
翻訳されました。その中には、Sun Fire T2000上でのチューニングパラメータの設定例
等も記載されておりますので、是非一度御確認いただければと思います。
Sun Java System Web Server 7.0 – Japanese
Sun Java System Web Server 7.0 管理ガイド
Sun Java System Web Server 7.0 パフォーマンスのチューニング、サイジング、およびスケーリング
Sun Java System Web Server 7.0 リリースノート (UNIX 版)
Sun Java System Web Server 7.0 リリースノート (Windows 版)
※ リンク先に一部誤りがありました。（2006/06/26リンク先を修正しました。）
寺田 佳央 - Yoshio Terada 