Archive for 9月, 2007
SJS Application Server 9.1 Release in US
さて、9/17（日本では同日深夜）にGlassFish v2と
Sun Java System Application Server 9.1がUSで正式にリリースされました。
日本語版のリリース次期についてはまだ正式な日程を申し上げる事はできませんが、
来月あたりのリリースを予定しております。
製品についてですが、本バージョンより、
Platform Edition(PE) , Standard Edition(SE),
Enterprise Edition(EE)という製品種別はなくなり、
Sun Java System Application Server 9.1もしくは、
Sun Java System Application Server 9.1 with HADBの
何れかを選択する事ができるようになっています。
英語版であれば、既に下記のURLよりダウンロード可能になっていますので、
日本語版が出る前に少し触ってみたいという方がいらっしゃいましたら、
どうぞ下記より入手して試してみてください。
Sun Java System Application Server 9.1ダウンロード
Sun Java System Application Server 9.1 with HADBダウンロード
御参考：アーカイブ(インストール／設定手順等)
HADBの両ノード障害発生時の復旧方法
HADBの両ノード障害発生時の復旧方法
前回、HADBノードの再起動と状態確認方法で説明しましたが、
HADBを構成するノードの再起動が必要な場合は、片ノードづつ
リブートをして頂くか、“hadbm stop HADB_NAME”を実行した後、
再起移動してください。
仮に、HADBを構成するノードがお互いに通信できなくなった場合、
もしくは、両ノードが同時に停止してしまったような場合
データベースの整合性が取れなくなりHADBサービスを提供できなくなります。
そのような場合、データベースを再構築しなくてはなりません。
今回は、両ノードが同時に停止してしまった場合、もしくはステータスが
不正な状態になった場合のHADBの復旧方法について説明します。
復旧手順は下記の２ステップを実行してください。
手順１: HADBを初期化(“hadbm clear”)する。
手順２: “asadmin configure-ha-cluster”を実行する。
両ノード障害の発生（疑似）
DBの不整合が発生する状態を作成する為、HADBが稼働している状態で、
両ノードを同時にリブートして下さい。
appserver1 > sync appserver1 > reboot appserver2 > sync appserver2 > reboot |
不正な状態に陥っている事の確認
次に、両ノードをリブートした後、それぞれのシステム上でHADBの
管理エージェント(ma)を起動して下さい。
その後、“hadbm status HADB_NAME”を実行して見ましょう。
上記で、１台づつマシンをリブートした時と比べ、いつまで経っても
状態がHAFaultTolerant,FaultTolerantに変わりません。
さらには、状態は“NonOperational”として表示されています。
この状態は、HADBとしてサービスを提供できていない状態を表しています。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** 2007-09-12 14:38:44.813 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 NonOperational |
HADBデバイスのクリーンアップ
上記のように、”NonOperational”の状態から”HAFaultTolerant,FaultTolerant”の
状態に戻すためには、下記の手順に従い修復を行います。
HADBの修復を行うために、“hadbm clear HADB_NAME”を実行して下さい。
“hadbm clear”を実行した後、“hadbm status HADB_NAME”を実行すると
HADBの状態が”NonOperational”から“FaultTolerant”に変わる事を確認できます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm clear app-cluster1 Please enter the password for the database system user:[***********] Please retype the password for database system user:[***********] WARNING: The –dbpassword option is deprecated since it is insecure. Using this option can compromise your password. Please use either the command prompt or the –dbpasswordfile option. Please enter the password for the admin system user:[***********] 2007-09-12 14:42:32.552 INFO hadbm clear –fast=false –quiet=false –version=false –yes=false –force=false –echo=false –dbpassword=****** app-cluster1 This command will clear database app-cluster1. Type “yes” or “y” to confirm this operation, anything else to cancel: y 2007-09-12 14:42:38.555 INFO Node app-cluster1:0 is currently starting at config version 3, stopping node in order to stop database 2007-09-12 14:43:19.240 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.nilog.0 for node app-cluster1:0 2007-09-12 14:43:19.244 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.relalg.0 for node app-cluster1:0 2007-09-12 14:43:19.247 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.noman.0 for node app-cluster1:0 2007-09-12 14:43:19.249 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 for node app-cluster1:0 2007-09-12 14:44:16.059 INFO Starting node app-cluster1:0 at level firststart, config version 5, in order to start database 2007-09-12 14:44:16.255 INFO n:0 NSUP INF 2007-09-12 14:44:16.248 p:685 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 Database app-cluster1 successfully cleared. appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user: [***********] 2007-09-12 14:46:50.316 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 FaultTolerant appserver1 > |
上記でHADBでバイスのクリーンアップ行った後、HADBの状態が
“FaultTolerant”に変わりました。
そこで、HADBのサービスが上記で使用可能になったのではないかと
思われるかもしれません。
しかし、実際は上記を行っただけではApplication Serverから
HADBに対して接続できません。
理由は、“hadbm clear”を実行するとHADBのデバイスの初期化が
行われるため、Application Serverから接続する為に必要なテーブルや
スキーマ等、全て初期化されてしまうからです。
これを、clusqlコマンドを使用し確認しましょう。
hadbm clear実行直後のHADBのテーブル一覧
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ;
HADB-I-11930: Selected 22 row(s) SQL: quit ; appserver1 > |
HADBが正常に動作している時のテーブル一覧
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 system+adminadmin SQL: select * from sysroot.alltables ;
HADB-I-11930: Selected 27 row(s) |
上記２つのテーブル一覧を御確認ください。
確認すると、「hadbm clear実行直後のHADBのテーブル一覧」には
下記の5つのテーブルが存在していない事が確認できます。
● sessionattribute
● singlesignon
● statefulsessionbean
● blobsessions
● sessionheader
また、“hadbm clear HADB_NAME”を実行した直後、Application Serverから
HADBに接続する際に使用するユーザ(admin)でHADBに接続しようとした際、
ユーザが存在していないため、下記のエラーが出力されます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin HADB-E-11601: Invalid user name or password |
asadmin configure-ha-clusterの実行
そこで、HADBデバイスの初期化（”hadbm clear”）の後で、
HADBのテーブル、スキーマそしてユーザを再度構築する為に、
asadmin configure-ha-clusterコマンドを実行して下さい。
appserver1 > asadmin configure-ha-cluster –devicesize 1024 –hosts appserver01,appserver02 –user admin app-cluster1 HADBMGMT008:The database, app-cluster1, already exists Command configure-ha-cluster executed successfully. appserver1 > |
上記、asadmin configure-ha-clusterコマンドを実行すると、
Appplication ServerからHADBのサービスを利用する為に必要な、
DBスキーマ、テーブル、ユーザ等が作成されます。
そこで、Application Serverから接続するユーザ(admin)で接続が可能となります。
clusqlでHADBに接続した後、作成されたテーブルの内容をそれぞれ確認してみましょう。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/clusql localhost:15205 admin+adminadmin SQL: SELECT schemaname, tablename, tableid FROM sysroot.alltables ;
HADB-I-11930: Selected 5 row(s) SQL: show table sessionattribute ;
SQL: show table singlesignon;
SQL: show table blobsessions ;
SQL: show table sessionheader ;
SQL: show table statefulsessionbean ;
SQL: quit ; |
備考：
clusqlで接続する際に、(system , admin)というユーザで接続しています。
systemはHADBのシステム管理用に使用するユーザで、adminユーザは
Application Serverから接続する際に使用するユーザ名です。
Application Serverから接続する際に使用するユーザ名、パスワード、
接続するHADBのノード名、ノードのポート番号はApplication Serverの
管理画面よりHADBのコネクションプールの設定情報(下記御参照)より確認
する事もできます。
以上で、HADBの両ノード障害が発生した場合の復旧方法について説明しましたが、
如何でしょうか。
実は、私もHADBを触り始めた当初、両ノードの同時リブートを行ってはいけない事を
知らず、やってしまい驚いてしまった事があります。
仮に同様の事をしてしまった場合には、上記を試してください。
そして、それでも駄目な場合は、弊社サポートセンターに御問い合わせください。
HADBノードの再起動と状態確認方法
さて本日は、HADBノードの再起動と状態確認方法について説明します。
１. HADBを構成するノードの再起動方法について
前回の説明で、HADBを構成するノード(appserver01,appserver02)を
再起動する際は、両ノード同時にリブートする事は避けて頂きたいと説明しました。
そこで、今回まずは片ノードづつリブートした際における、HADBの状態変化について
説明したいと思います。
片ノードをリブートした際にHADBの状態としてどのように変化するか
下記より確認してみましょう。
正常時のステータス
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:[***********] Database Status app-cluster1 FaultTolerant |
正常時に“hadbm status”を実行するとDatabaseのステータスとして、
“HAFaultTolerant”（スペアノード付き）もしくは”FaultTolerant”
（スペアノード無し）が表示されます。
この状態で、片ノードに何らかの障害が発生したとします。
するとHADBは単一ノードでしかサービスを提供していませんので、
ステータスは下記のように”Operational”にかわります。
片ノードで起動している時のステータス
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational |
実際に、ステータスが変更するかを実際に確認してみましょう。
手順；
1. 初めに片ノード(appserver02)をリブートします。
2. リブートが完了した後、appserver02にログインします。
3. HADBの管理エージェントプロセス(ma)を起動します。
4. 状態の変更を確認します。
appserver2 > sync appserver2 > reboot |
上記の状態で、起動しているノード(appserver01)で
HADBのステータスを確認してみて下さい。
すると下記のようにステータスが変更されている事を確認できます。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational |
次に、システムのリブートが完了した後、システムにログインし、
HADBの管理エージェントプロセス(ma)を起動して下さい。
> ssh -l root 192.168.0.2 パスワード: [********] Last login: Wed Sep 12 11:17:51 2007 from 192.168.0.10 Sun Microsystems Inc. SunOS 5.10 Generic January 2005 You have new mail. # tcsh appserver2 > /sun/SUNWappserver91/hadb/4/bin/ma-initd start appserver2 > Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.938 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-12 14:03:43.956 INFO Using property: ma.server.type=jmxmp 2007-09-12 14:03:43.960 INFO Using property: ma.server.mainternal.interfaces=192.168.0.2 2007-09-12 14:03:43.962 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-12 14:03:43.966 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-12 14:03:43.968 INFO Using property: console.loglevel=INFO 2007-09-12 14:03:43.969 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-12 14:03:43.971 INFO Using property: ma.server.jmxmp.port=1862 2007-09-12 14:03:43.972 INFO Using property: logfile.loglevel=INFO 2007-09-12 14:03:43.974 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-12 14:03:43.975 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:03:45.108 INFO Listening for client connections on port 1862 2007-09-12 14:03:45.398 INFO Repository REP:-54e808d5_114ee5e4be0_-8000: Multicast address=228.8.8.8, Port=1862, Bind address=192.168.0.2, Path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-12 14:05:14.959 INFO Starting node app-cluster1:1 at level auto, config version 3 2007-09-12 14:05:15.520 INFO n:1 NSUP INF 2007-09-12 14:05:15.518 p:606 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 |
HADBの管理エージェントプロセスが起動すると、上記のように
メッセージが表示されます。ここで、注意して頂きたいのは
上記のメッセージが表示された直後はまだ、HADBとして
正常な状態には戻っていないという事です。
上記メッセージが出力された直後にステータスを確認してください。
すると、まだ”Operational”の状態になっている事を確認できます。
理由は、前回「High Availability Session Store(HADB)の概要」
でも説明致しましたが、appserver01のテーブルの内容と同期を取る
作業等を行っているためです。
そこで、作業完了までしばらく待った後、再度コマンドを実行して下さい。
すると、ステータスが“HAFaultTolerant”/”FaultTolerant”に変わる事が
確認できるかと思います。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 Operational …..しばらく時間を経過した後（テーブルの同期が完了した後） appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:*********** Database Status app-cluster1 FaultTolerant |
このように、HADBノードを再起動する際は、片ノードづつ実行して頂き、
片ノードが完全に立ち上がって、HADBのステータスが
“HAFaultTolerant”/”FaultTolerant”の状態に戻った事を確認した後
もう一台のHADBノードを再起動するようにして下さい。
HADB環境の構築手順
さて、今日はSJS Applicatin Server 9.1 with HADBを使用して
実際にHADBの構成を組んでみたいと思います。
HADBの構成を組む前に事前にOS側で準備して置かなければならない事が
３点あります。
HADB構成前の準備：
● OSのカーネルパラメータの編集
● IPMPの構成
● NTPによる時間同期
● 準備１：OSのカーネルパラメータの編集
HADBの設定を行う前に、必ずOSのカーネルパラメータで、
共有メモリとセマフォの値を設定して下さい。
同一システム上でHADB以外のアプリケーションが
共有メモリやセマフォを使用している場合、HADBに必要な値を加算して
共有メモリやセマフォの設定を行って下さい。
共有メモリは、Solaris上では/etc/systemファイルにshminfo_shmmaxを
編集して設定を行います。
shminfo_shmmaxは、該当のホスト上で、共有メモリセグメントの
最大サイズを指定しますが、実際にはこの値はHADBをインストールする
ホストの物理メモリの合計サイズを16進数表記で指定します。
ただし、2GB以上の値は指定しないで下さい。
例えば、下記のように1GBの物理メモリを保持するシステムの場合、
16進数表記では、0x40000000を指定します。
appserver1 > prtconf|grep Memory Memory size: 1024 Megabytes |
/etc/system (共有メモリセグメントの最大サイズ)
set shmsys:shminfo_shmmax=0x40000000 |
※ Solaris 9以降shmsys:shminfo_shmseg は使用されなくなりました。
今回はSolaris 10にインストールする為、shmsys:shminfo_shmseg は
指定しません。Solaris 8以前のシステムにHADBを導入する場合は、
下記のように１プロセス辺りのセグメント数を指定して下さい。
set shmsys:shminfo_shmseg=36
次に、セマフォ識別子数の最大値をseminfo_semmniで指定します。
全てのHADBノードでは必ず一つのセマフォ識別子を必要とします。
１台の物理的なマシン上に6つのHADBノードを構築可能ですが、
6つのHADBノードを構築する場合でも下記の値で問題ありません。
/etc/system (セマフォ識別子数の最大値)
set semsys:seminfo_semmni=10 |
次に、システム上でのセマフォの最大数をseminfo_semmnsで指定します。
全てのHADBノードでそれぞれ8つのセマフォを必要とします。
６つのHADBノードを構築する場合でも下記の値で問題ありません。
/etc/system (セマフォの最大数)
set semsys:seminfo_semmns=60 |
最後に、システム上でセマフォの取り消し機能を使用する最大数を
seminfo_semmnuで指定します。
1つの接続（NumberOfSessionsで接続数を指定、デフォルト100）に対して
1つの取り消し機能が必要です。
６つのHADBノードを構築する場合で下記の値で問題ありません。
/etc/system (セマフォの取り消し機能を使用する最大値)
set semsys:seminfo_semmnu=600 |
上記を設定した後、OSのリブートを行ってください。
＊ リブートを行う前に、手動でノードエージェントの停止・ドメインの停止を
行ってください。
ノードエージェントの停止・ドメインの停止を行わないでリブートした場合、
MQのプロセスでロックファイルが削除されずに残ってしまう場合があります。
次に、２点目はHADBを導入するシステム上でIPMP(IPマルチパッシング)構成
を組んでいる場合（推奨）、IPMPのネットワークインタフェースの障害検出
時間の設定値（FAILURE_DETECTION_TIME）を変更する必要があります。
下記のように値を1,000ミリ秒に設定して下さい。
/etc/default/mpathd
FAILURE_DETECTION_TIME=1000
● 準備２：IPMPの構成
- ● 準備３：NTPによる時刻同期
Solaris 10の管理ガイド「第 3 章 システムの時刻関連サービス」を
参照し、HADBのノード間の時刻を同期して下さい。
- 上記で、準備が完了です。
SJS Application Server 9.1のドメインが起動していない場合、
Application Server 9.1のドメインとノードエージェントをそれぞれ起動して下さい。
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
Redirecting application output to /sun/SUNWappserver91/nodeagents/appserver01/agent/logs/server.log
Command start-node-agent executed successfully.
appserver1 >
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.
それでは、実際にHADBを使用するように設定を行いましょう。
- HADBの設定
- Data storageを管理
- SQLサーバからHADBのinstruction setでリクエストの受信
- Logレコードをミラーノードに転送
1. HADBの管理エージェントの起動
HADBの管理エージェント(Management Agent)を起動して下さい。
appserver1側のHADB管理エージェントの起動
appserver1 > cd /sun/SUNWappserver91/hadb/4.4.3-6/bin appserver1 > ls clusql hadbm ma ma-initd ma.cfg appserver1 > /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma-initd start Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:54:14.081 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-10 12:54:14.102 INFO Using property: ma.server.type=jmxmp 2007-09-10 12:54:14.106 INFO Using property: ma.server.mainternal.interfaces= 2007-09-10 12:54:14.108 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-10 12:54:14.112 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-10 12:54:14.114 INFO Using property: console.loglevel=INFO 2007-09-10 12:54:14.116 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:54:14.117 INFO Using property: ma.server.jmxmp.port=1862 2007-09-10 12:54:14.119 INFO Using property: logfile.loglevel=INFO 2007-09-10 12:54:14.121 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-10 12:54:14.123 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 12:54:15.157 INFO Listening for client connections on port 1862 |
appserver2側のHADB管理エージェントの起動
appserver2 > /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma-initd start Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting Logging to /sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:49:39.194 INFO Management Agent version 4.4.3.6 [V4-4-3-6 2007-06-21 17:59:42 pakker@astra07] (SunOS_5.9_sparc) starting 2007-09-10 12:49:39.214 INFO Using property: ma.server.type=jmxmp 2007-09-10 12:49:39.218 INFO Using property: ma.server.mainternal.interfaces= 2007-09-10 12:49:39.221 INFO Using property: ma.server.dbhistorypath=/sun/SUNWappserver91/hadb/4.4.3-6/history 2007-09-10 12:49:39.225 INFO Using property: ma.server.dbconfigpath=/sun/SUNWappserver91/config/hadb 2007-09-10 12:49:39.227 INFO Using property: console.loglevel=INFO 2007-09-10 12:49:39.228 INFO Using property: logfile.name=/sun/SUNWappserver91/hadb/4.4.3-6/log/ma.log 2007-09-10 12:49:39.230 INFO Using property: ma.server.jmxmp.port=1862 2007-09-10 12:49:39.232 INFO Using property: logfile.loglevel=INFO 2007-09-10 12:49:39.233 INFO Using property: ma.server.dbdevicepath=/sun/SUNWappserver91/hadb/4.4.3-6/device 2007-09-10 12:49:39.235 INFO Using property: repository.dr.path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 12:49:40.158 INFO Listening for client connections on port 1862 |
※ 仮に論理IPを使用して通信をさせたい場合は、管理エージェントの
設定ファイルを編集し、下記の１行を追加した後、
ma-initd startを実行して下さい。
appserver1 > cd /sun/SUNWappserver91/hadb/4.4.3-6/bin appserver1 > vi ma.cfg ma.server.mainternal.interfaces=192.168.0.1 //<–追加 |
2.アプリケーションに対する設定
HADBの管理エージェントが起動したので、まずはデプロイ済みのアプリケーションに対して
可用性を有効にする設定を行います。
Application Server 9.1の管理コンソールより、「Enterprise Application」→「clusterjsp」と展開して下さい。
ここで、デプロイ済みのアプリケーション「clusterjsp」に対して、
「Availability：[ ] Enabled」の項目にチェックを付け、
「Save」ボタンを押下して下さい。すると下記の画面が表示されます。
３.既存クラスタに対する設定
既存のクラスタ(app-cluster1)をHigh Availabilityにするために下記のコマンドを実行して下さい。
下記のコマンドはクラスタに対する設定の他、データベースのテーブルを作成する処理等も行います。
そこで、データベース中に作成するデバイスサイズ(devicesize)の大きさに
応じてコマンドの終了までに要する時間は異なります。
下記のコマンドでは既存のクラスタ「app-cluster1」に対してHADBのノードとして
「appserver01, appserver02」のホストを指定しHADBを2ノード作成しています。
appserver1 > asadmin configure-ha-cluster –devicesize 1024 –hosts appserver01,appserver02 –user admin app-cluster1 2007-09-10 16:42:09.576 INFO hadbm create –quiet=true –no-cleanup=false –datadevices=1 –portbase=15200 –spares=0 –devicesize=1024 –adminpasswordfile=/sun/SUNWappserver91/domains/domain1/config/adminpassword –dbpasswordfile=/sun/SUNWappserver91/domains/domain1/config/dbpassword –hosts=192.168.0.1,192.168.0.2 –agent=192.168.0.1,192.168.0.2:1862 –set=LogBufferSize=48 –no-clear=false –version=false –yes=false –force=false –echo=false app-cluster1 2007-09-10 16:42:10.985 INFO Creating new domain -54e808d5_114ee5e4be0_-8000 2007-09-10 16:42:11.010 INFO Repository REP:-54e808d5_114ee5e4be0_-8000: Multicast address=228.8.8.8, Port=1862, Bind address=192.168.0.1, Path=/sun/SUNWappserver91/hadb/4.4.3-6/rep 2007-09-10 16:43:00.538 INFO Ready to accept client requests 2007-09-10 16:43:21.378 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.noman.0 for node app-cluster1:0 2007-09-10 16:43:21.382 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 for node app-cluster1:0 2007-09-10 16:43:21.383 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.nilog.0 for node app-cluster1:0 2007-09-10 16:43:21.385 INFO Initializing device /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.relalg.0 for node app-cluster1:0 2007-09-10 16:44:02.694 INFO Starting node app-cluster1:0 at level firststart, config version 1, in order to start database 2007-09-10 16:44:03.082 INFO n:0 NSUP INF 2007-09-10 16:44:03.069 p:921 Legal realtime priorities are 0 (lowest) to 59 (highest) set it to:29 Command configure-ha-cluster executed successfully. |
上記以外で指定可能なコマンドオプションについては、下記のオンラインヘルプを
御参照ください。
appserver1> asadmin configure-ha-cluster –help | less Administration Commands configure-ha-cluster(1) NAME configure-ha-cluster – configures an existing cluster to be highly available SYNOPSIS configure-ha-cluster [–terse={true|false}][ –echo={true|false} ] [ –interactive={true|false} ] [ –host host] [–port port] [–secure| -s ] [ –user admin_user] [–passwordfile filename] [–help] [ –devicesize devicesize] [–haagentport port_number] [–haadminpassword password] [–haadminpasswordfile file_name] –hosts hadb-host-list [–autohadb={true|false}] [ –portbase port_number] [–property (name=value)[:name-value]*] {clusterName} |
上記コマンドが完了した後、システム上にはhadbに関連する
下記の8プロセスが自動的に起動されます。
appserver1 > ps -ef | grep hadb root 794 1 0 16:36:00 ? 0:00 /sun/SUNWappserver91/hadb/4.4.3-6/bin/ma –umask=077 /sun/SUNWappserver91/hadb/ root 807 805 0 16:39:31 ? 0:17 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sql_srv -d 0x00000000 root 805 799 1 16:39:27 ? 2:36 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_nsup_srv -c /sun/SUNWappserver root 808 805 0 16:39:31 ? 0:17 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sqlshm_srv -d 0x00000000 root 809 805 0 16:39:31 ? 0:15 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_relalg_srv -d 0x00000000 -Drel root 806 805 1 16:39:31 ? 2:42 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_trans_srv -d 0x00000000 -m /su root 810 805 1 16:39:31 ? 1:48 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_noman_srv -d 0x00000000 -Dnoma root 1030 807 0 18:55:06 ? 0:04 /sun/SUNWappserver91/hadb/4.4.3-6/lib/server/clu_sql_srv -d 0x00000000 -Dsql_th |
仮にプロセス数が少ない場合は、HADBが正常に起動できていない可能性があるため、
HADBの管理エージェントのログを御確認頂き、エラーが出力されていないか確認してください。
HADB 管理エージェントのログ
appserver1 > cat /sun/SUNWappserver91/hadb/4/log/ma.log |
４.動作確認
それでは、HADBの構成が完了しましたので、動作確認をしてみましょう。
ブラウザでWeb Server経由(192.168.0.3)でデプロイしたアプリケーション
(clusterjsp)にアクセスして見ましょう。
ブラウザで接続すると下記のような画面が表示されます。
ここで、「Name of Session Attribute」、「Value of Session Attribute」の
欄にそれぞれ、適当な文字列を入力し「ADD Session DATA」ボタンを押下して下さい。
すると、ページの下側に入力した文字列(aaaa,bbbb等)が表示されます。
ここで、１点確認しておいて下さい。「Executed From Server:」、
「Executed Server IP Address:」の欄にそれぞれ、アプリケーションを実際に
実行しているアプリケーションサーバ名とIPアドレスがそれぞれ表示されています。
下記の例では、アプリケーションは「appserver01」、「192.168.0.1」で
実行されている事が確認できます。
※ アプリケーションに接続しているブラウザの画面を閉じずそのままの
画面にしたまま、下記の手順を行ってください。
アプリケーションを実行しているサーバは「appserver01」である事が
上記より確認できましたので、「appserver01」に障害が発生した事を仮定し、
「appserver01」のインスタンスを停止してみましょう。
疑似アプリケーションサーバ停止状態
Application Server 9.1の管理コンソールより、「Clusters」→「app-cluster1」
→「appserver01-instance1」を選択します。すると下記の画面が表示されますので、
「Stop Instance」ボタンを押下して下さい。
「Stop Instance」ボタンを押下すると下記の画面が表示されます。
インスタンスが停止した事を確認し、再度ブラウザに戻ってください。
そして、以前表示された画面のまま、「RELOAD PAGE」ボタンを押下してください。
すると、下記の画面が表示されます。
内容は殆ど同じですが、変更点を確認してみましょう。
先ほどは「Executed From Server:」欄に「appserver01」が記載されていましたが、
画面を再読み込みすると「appserver02」、「192.168.0.2」にかわっている事が確認できます。
さらには、画面下部には先ほど入力した内容（aaaa,bbbb等）が、そのまま
表示されている事が確認できるかと思います。
このように、HADBを使用すると、アプリケーションサーバが稼働するシステムに
何らかの障害が発生し停止した場合でも、セッション情報がHADB内に保持されているため、
引き続き���ービスを提供できる事ができます。
以上で、HADB２ノード構成のシステムを構築しましたが、実際にはHADB2ノードでは
耐障害性は十分ではありません、スペアノードを作成し、より可用性レベルの高いシステムを
構築する事が必要になってまいりますが、その方法についてはまた改めて説明したいと思います。
５.HADBシステムの停止方法
HADBの環境はプライマリーとミラーの両ノード間で通信を行っています。
仮に相手と通信ができなくなった場合、自分のミラーとして使用していた
セグメントレプリカをプライマリに変更し、自分が両方のプライマリを持っていると判断します。
このようにHADBは対となるノードに障害が発生した場合、一時的に片ノードだけでサービスを提供します。
そこでHADBの環境下でシステムを停止する際は、必ず片ノードづつリブートを行うように
して下さい。（片方が完全に立ち上がった事を確認しもう片方をリブートして下さい。）
仮に両ノードが同時に停止すると両方のノードが自分がプライマリとして判断し
データベースが壊れてしまいます。そのような場合、データベースを再構築しなくては
なりません。（その方法は別途紹介します。）
計画停電等でどうしても両ノードを停止する必要がある場合は、下記のコマンドを実行し
HADBのプロセスを明示的に停止して下さい。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm stop app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 21:54:32.811 INFO hadbm stop –force=false –quiet=false –version=false –yes=false –echo=false app-cluster1 This command will stop the database app-cluster1. Type “yes” or “y” to confirm this operation, anything else to cancel:y 2007-09-10 21:54:36.076 INFO Node app-cluster1:1 is currently running at config version 1, stopping node in order to stop database Database app-cluster1 successfully stopped. |
最後に、補足事項を下記に説明します。是非参考にしてください。
補足１：HADBの各プロセスの意味
下記にHADBを実行する事により起動されるプロセスの一覧とその意味をまとめます。
| HADB | /opt/SUNWhadb/4/bin/ma /etc/opt/SUNWhadb/mgt.cfg |
HADB Management Agent起動コマンド |
| HADB | java -Djava.class.path= /opt/SUNWhadb/4.4.1-7/lib/hadbm… |
HADB Management Agent |
| HADB | clu_nsup_srv # Node supervisor (NSUP) |
HADB Node Supervisor 各HADB node毎に起動します。Node Supervisorは５つの子プロセスを監視し、ハートビートがなくなったときそれらを再起動します。 |
| HADB (Node supervisorの子プロセス) |
clu_sql_srv # SQL (SQLC) |
SQLサーバプロセス JDBC driver , clusql CLIから接続可能です。HADB instructionにコンパイルし、TRANSに送信します。また、その結果を受信しクライアントに返します。クライアント接続毎に1つのサブサーバを持ちます。 |
| HADB (Node supervisorの子プロセス) |
clu_trans_srv # Transaction (TRANS) |
トランザクションサーバプロセス 分散されたノード上のトランザクションを調整します。主な役割として次のものがあります。 |
| HADB (Node supervisorの子プロセス) |
clu_relalg_srv # Relational algebra (RELALG) |
Relational algebra query サーバプロセス。sort/join等の関係代数クエリーを調整・実行する。 |
| HADB (Node supervisorの子プロセス) |
clu_sqlshm_srv # SQL shared memory (SQLSHM) |
Shared memory segmentを管理するサーバプロセス。 SQL dictionary cacheを管理する。 |
| HADB (Node supervisorの子プロセス) |
clu_noman_srv # Node manager (NOMAN) |
Node manager サーバプロセス。 Management agentがhadbmから発行された管理コマンドを実行するために使用します。また、nodeの最新の状態を把握し、nodeが停止したときと同じ状態で起動します。 |
補足２：HADBの状態確認
hadbmコマンドを使用するとHADBの状態を確認する事ができます。
HADBは内部的に、下記の６つの状態を判定します。
| 1. High-Availability Fault Tolerant (HAFT) | データベースに耐障害性があり、DRU毎にすくなくとも１つのスペアノードを備えている。 |
| 2. Fault Tolerant (FT) | 全てのミラーノードペアが実行中である。 |
| 3. Operational (O) | 各ミラーノードペアの内少なくとも１つのノードが実行中である。 |
| 4. Non Operational (NO) | １つ以上のミラーノードペアで、両方のノードが無くなっている。 |
| 5. Stopped (S) | データベース内に実行中のノードが存在しない。 |
| 6. Unknown (U) | データベースの状態を判定できない。 |
下記のコマンドの実行例では、上から２番目の可用性(Fault Tolerant)が確保されています。
より高い可用性を確保する為には、HADBのスペアノードを追加し、HADBノードの障害時に
ノードを切り替えられるようにする必要があります。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm status app-cluster1 Please enter the password for the admin system user:[***********] 2007-09-10 16:47:37.161 INFO hadbm status –nodes=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Database Status app-cluster1 FaultTolerant appserver1 > |
補足3： HADBのデバイス情報の確認方法：
下記のコマンドでHADBのデバイスに関する使用状況や空きサイズ等の情報を取得可能です。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm deviceinfo –details app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 16:51:48.538 INFO hadbm deviceinfo –details=true –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 NodeNo TotalSize FreeSize Usage NReads NWrites DeviceName 0 1024 841 18% 0 341 /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.0 1 1024 841 18% 0 364 /sun/SUNWappserver91/hadb/4.4.3-6/device/app-cluster1.data-0.1 appserver1 > |
補足4： HADBのリソースの確認方法：
下記のコマンドでHADBのリソースに関する使用状況や空きサイズ等の情報を取得可能です。
appserver1 > /sun/SUNWappserver91/hadb/4/bin/hadbm resourceinfo app-cluster1 Please enter the password for the admin system user:*********** 2007-09-10 16:53:08.408 INFO hadbm resourceinfo –databuf=false –locks=false –logbuf=false –nilogbuf=false –quiet=false –version=false –yes=false –force=false –echo=false app-cluster1 Data buffer pool: NodeNo Avail Free Access Misses Copy-on-Write 0 198 194 25166 0 0 1 198 194 23988 0 23 Locks: NodeNo Avail Free Waits 0 50000 50000 na 1 50000 50000 na Log buffer: NodeNo Avail Free 0 44 40 1 44 40 Node internal log buffer: NodeNo Avail Free 0 11 11 1 11 11 |
補足5: ドメインを停止せずにリブートしMQが起動できなくなった場合の対処方法：
Application Serverのドメインの起動時にMQが起動できずに、
結果としてApplication Serverが正常に起動できなくなる事があります。
そのような場合、MQのlockファイルを手動で削除した後、再度ドメインを起動して下さい。
起動失敗時のサーバのログ
[#|2007-09-07T17:39:33.792+0900|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.lifecycle|_ThreadID=10; _ThreadName=main;_RequestID=7ce995f7-ea5b-4e95-ae20-60e91c9888d8;|MQJMSRA_RA4001: start:Aborting:Exception starting EMBEDDED broker=EMBEDDED Broker start failure:code = 1|#] [#|2007-09-07T17:39:33.814+0900|WARNING|sun-appserver9.1|javax.enterprise.system.stream.err| _ThreadID=10;_ThreadName=main;_RequestID=7ce995f7-ea5b-4e95-ae20-60e91c9888d8;| java.lang.RuntimeException: EMBEDDED Broker start failure:code = 1 at com.sun.messaging.jms.ra.EmbeddedBrokerRunner.start(EmbeddedBrokerRunner.java:268) at com.sun.messaging.jms.ra.ResourceAdapter.start(ResourceAdapter.java:472) |
対処方法
appserver1 > pwd /sun/SUNWappserver91/domains/domain1/imq/instances/imqbroker appserver1 > ls -lF 合計 10 drwx—— 2 root root 512 9月 3日 11:46 etc/ drwxr-xr-x 3 root root 512 9月 3日 12:32 fs370/ -rw-r–r– 1 root root 27 9月 3日 12:32 lock drwx—— 2 root root 512 9月 3日 11:46 log/ drwx—— 2 root root 512 9月 3日 11:46 props/ appserver1 > less lock imqbroker:appserver01:7676 appserver1 > rm lock |
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で負荷分散（ロードバランサ）の設定を行います。
寺田 佳央 - Yoshio Terada 