前の章で使用した設定では、サーバーインスタンスがダウンした場合、ユーザーはセッション状態を失います。ここでは、2 つの高度なトピックの 2 番目のものとして、高可用性データベース (HADB) のインストール、高可用性クラスタの作成、および HTTP セッション持続性のテストの手順について説明します。
Enterprise Server は、HTTP セッション持続性とステートフルセッション Bean の持続性の両方をサポートしています。この章の手順では、インメモリーレプリケーションまたは HADB を使用して高可用性を実現しています。
次の手順では、すでにこの『クイックスタートガイド』の前の項に記載されている手順を実行済みであると仮定しています。手順は、それらを完了させるために必要な順序で示されます。HADB 機能を使用するには、エンタープライズプロファイルでドメインを実行する必要があります。
このセクションの手順を完了するには、追加のハードウェアリソースが必要な場合があります。
このトピックは、次のセクションで構成されます。
Sun GlassFish Enterprise Server の高可用性クラスタは、状態の複製サービスを以前に作成したクラスタおよびロードバランサと統合し、その結果 HTTP セッションのフェイルオーバーが有効になります。
HttpSession オブジェクトとステートフルセッション Bean の状態は、HADB に格納されます。HADB は、セッション状態を格納するための高可用性データベースです。この水平的で拡張可能な状態管理サービスは、アプリケーションサーバー層とは無関係に管理できます。これは、ロードバランス、フェイルオーバー、および状態復元機能を含む、最大 99.999% のサービスとデータ可用性をサポートするように設計されています。
状態管理の機能を Enterprise Server と切り離しておくことには、大きな利点があります。インスタンスは、状態レプリケーションを外部の高可用性状態サービスに委任する、スケーラブルで高性能な JavaTM Platform, Enterprise Edition 5 (Java EETM 5 プラットフォーム) コンテナとしての動作に CPU サイクルを消費します。この疎結合のアーキテクチャーにより、容易にインスタンスをクラスタに追加したり、クラスタから削除したりできます。HADB の状態レプリケーションサービスを独立に拡張して、最適な可用性とパフォーマンスを得ることができます。アプリケーションサーバーインスタンスがレプリケーションも実行していると、Java EE アプリケーションのパフォーマンスが低下したり、ガベージコレクションの一時停止時間が長くなったりすることがあります。
各 HADB ノードは 512M バイトのメモリーを必要とするため、同じマシン上で 2 つの HADB ノードを実行するには、1G バイトのメモリーが必要です。メモリーが少ない場合は、各ノードを別のマシン上に設定してください。耐障害性がないため、配備の際に 1 台のホストのみで 2 ノードのデータベースを実行することはお勧めできません。
この手順は、最も一般的なインストール前のタスクを取り扱います。HADB をインストールするための前提条件、ネットワーク冗長性の設定、ファイルシステムのサポートなど、その他のインストール前のトピックについては、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の第 10 章「高可用性 (HA) データベースのインストールと設定」を参照してください。
このセクションで推奨されるシステム設定値は、最大 6 個の HADB ノードを実行するために十分なものであり、共有メモリーを使用するシステム上のその他のアプリケーションについては考慮されていません。
root ユーザーとしてアクセスします。
共有メモリーおよびセマフォーに関連する変数を定義します。
Solaris の場合:
/etc/system ファイルに次の行を追加します。次の行がコメントとしてファイル内にある場合は、それらのコメントを解除し、値が次の値と一致していることを確認します。
set shmsys:shminfo_shmmax=0x80000000
set shmsys:shminfo_shmseg=36
set semsys:seminfo_semmnu=600
shminfo_shmmax をシステムの合計メモリーに設定します (16 進数の表記では、示されている値 0x80000000 が 2G バイトのメモリーを表す)。
seminfo_* 変数がすでに定義されている場合は、示されている容量でそれらを増分します。seminfo_semmni と seminfo_semmns のデフォルト値は変更する必要はありません。shminfo_shmeg 変数は Solaris 8 以降は使用されなくなりました。
次のコマンドを使用して再起動します。
sync; sync; reboot
Linux の場合:
Windows の場合: システム設定は特に必要ありません。
スタンドアロンの Enterprise Server をインストールするときに既存の JDK ソフトウェアを使用した場合は、JDK バージョンを確認します。
HADB では Sun JDK 1.4.1_03 以上が必要です (JDK バージョンの最新情報は、『Sun GlassFish Enterprise Server 2.1 リリースノート』を参照)。インストールされているバージョンをチェックし、まだ行なっていない場合は、JDK がインストールされているディレクトリに JAVA_HOME 環境変数を設定します。
再起動後、必要に応じてドメイン、Web Server、およびノードエージェントを再起動します。
ドメインを再起動するには、asadmin start-domain domain1 コマンドを使用します。
Web サーバーを再起動するには、web_server_install_dir/https- hostname で起動プログラムを実行します。
ノードエージェントを再起動するには、asadmin start-node-agent hostname コマンドを使用します。hostname 変数を、Enterprise Server を実行するホスト名に置き換えます。
ここでは、高可用性データベース (HADB) のインストールの手順を説明します。
Enterprise Server マシンで高可用性データベースを実行する場合と、Enterprise Server のインストール時に HADB をインストールした場合は、「HADB の起動」に進みます。
2G バイトのメモリーと 1 ~ 2 個の CPU を持つマシンがある場合には、HADB コンポーネントを Enterprise Server システムと同じマシン上にインストールできます。それ以外の場合は、追加のハードウェアを使用します。次に例を示します。
それぞれが 512M バイトから 1G バイトのメモリーを持つ 2 つの 1 CPU システム
1G バイトから 2G バイトのメモリーを持つ 1 つの 1 ~ 2 CPU システム
ここでは、主に ma-initd スクリプトの実行による、HADB 管理エージェントの起動について説明します。本稼働配備の場合は、管理エージェントをサービスとして起動し、その可用性を保証します。詳細は、『Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド』の「HADB 管理エージェントの起動」を参照してください。
複数のホスト上で HADB ノードを含むデータベースを起動する場合は、それぞれのホスト上の管理エージェントを起動します。
Sun Java System を設定および実行すると、デフォルトで HADB が起動します。ただし、手動で起動する必要がある場合は、次の手順に従います。
「スタート」⇒「設定」⇒「コントロールパネル」の順に選択して、「管理ツール」をダブルクリックします。
「サービス」ショートカットをダブルクリックします。
「サービス」リストで HADBMgmtAgent Service を選択します。
「操作」メニューから「開始」を選択します。
Enterprise Server インストールの HADB bin ディレクトリに移ります。 as-install /hadb/4/bin
次のコマンドを実行して、エージェントを起動します。
./ma-initd start
端末ウィンドウで、Enterprise Server インストールの HADB bin ディレクトリに移ります。 as-install\hadb\4. x\bin
x は HADB のリリース番号を表しています。
次のコマンドを実行して、エージェントを起動します。
ma -i ma.cfg
HADB を使用するには FirstCluster クラスタを設定する必要があり、HTTP セッションの持続性を確認できるようにするには clusterjsp アプリケーションの高可用性を有効にする必要があります。asadmin configure-ha-cluster コマンドを使用して、既存のクラスタを高可用性のために設定します。このコマンドの使用方法については、asadmin コマンドプロンプトで configure-ha-cluster --help と入力するか、configure-ha-cluster(1) のマニュアルページを参照してください。
前のセクションで行なった変更を有効にするには、クラスタのインスタンスを再起動する必要があります。
管理コンソールで、「クラスタ」ノードを展開します。
「FirstCluster」をクリックします。
右側の区画で、「インスタンスの停止」をクリックします。
インスタンスが停止したら、「インスタンスの起動」をクリックします。
セッションデータのフェイルオーバーのテスト手順は、「ロードバランスの検証」で説明したロードバランスのテスト手順と似ています。ここでは、セッションデータは障害のあと保持されます。サンプルアプリケーションは障害が発生したあとに自動的に再試行するように設定されているため、フェイルオーバーはユーザーには透過的に行われます。
clusterjsp アプリケーションを表示するには、ブラウザで、次の URL を入力します。
http://localhost :web_server_port /clusterjsp
localhost 変数を、Web Server を実行するシステム名に置き換えます。
web_server_port 変数を、web_server_install_dir /https-hostname /config/server.xml の LS 要素のポート属性の値に置き換えます。この例では、ポート 38000 を使用しています。
「アプリケーションの配備を確認する」で表示されたのと同じようなページが表示されます。
セッションおよびホスト情報が次のとおり表示されるかどうかを確認します。次に例を示します。
Executed From Server: localhost
Server Port Number: 38000
Executed Server IP Address: 192.18.145.133
Session ID: 41880f618e4593e14fb5d0ac434b1
Session Created: Wed Feb 23 15:23:18 PST 2005
サーバーアクセスログファイルを表示して、アプリケーションを処理しているインスタンスを確認します。このログファイルは、次の場所にあります。
Solaris Java Enterprise System インストールの場合
/var/opt/SUNWappserver/nodeagents/nodeagent_name /i1/logs/access/server_access_log
/var/opt/SUNWappserver/nodeagents/nodeagent_name /i2/logs/access/server_access_log
Linux Java Enterprise System インストールの場合
/var/opt/sun/appserver/nodeagents/ nodeagent_name/i1/logs/access/server_access_log
/var/opt/sun/appserver/nodeagents/ nodeagent_name/i2/logs/access/server_access_log
Windows Java Enterprise System インストールの場合
as-install \nodeagents\nodeagent_name\i1\logs\access\server_access_log
as-install\nodeagents\nodeagent_name \i2\logs\access/server_access_log
スタンドアロンの Enterprise Server インストールの場合
as-install /nodeagents/nodeagent_name/i1/logs/access/server_access_log
as-install/nodeagents/nodeagent_name /i2/logs/access/server_access_log
このページを処理しているインスタンスを停止します。
clusterjsp サンプルアプリケーションページを読み込み直します。
セッション ID とセッション属性データは保持されます。
その他のインスタンスのアクセスログをチェックし、この時点でこれが要求を処理していることに注目します。
HTTP セッションは持続的に HADB に格納されるため、状態のフェイルオーバー機能が作動します。HTTP セッションの状態だけでなく、Enterprise Server も EJB の状態を HADB に格納することができます。