 Print-friendly Version
GlassFish JavaEE Application Server Version 2 は、クラスタ化機能を向上させた多数の新機能を備えています。新しいクラスタ化機能は、インメモリーセッション状態レプリケーションにより、配備アーキテクチャーに対する高可用性とスケーラビリティーを強化します。インメモリー状態レプリケーションにより、クラスタ化されたサーバーインスタンスはセッション状態をリングトポロジでレプリケートし、レプリケートされた情報をメモリーに保存します。 この記事では、アプリケーションを GlassFish クラスタに配備する際に参考になるよう、GlassFish Version 2 のクラスタ化機能を説明します。 Sun Java System Application Server 9.1 は、オープンソースである GlassFish Version 2 アプリケーションサーバーの Sun がサポートしているディストリビューションです。この記事では、GlassFish Version 2 の表記でこの両方を表します。 目次
基本的な概念
アプリケーションサーバーにおけるクラスタは、スケーラビリティと可用性を向上させます。これらは関連のある概念です。 高可用性のサービスを提供するには、ソフトウェアシステムが次の機能を備えている必要があります。
まとめると、これらの要求に対して必要なのは、効率を犠牲にして高可用性を実現するためのシステムです。 スケーラビリティーと高可用性の目標をサポートするために、GlassFish アプリケーションサーバーは次のサーバー側エンティティを提供します。
あとで説明するように、ノードエージェント、サーバーインスタンス、およびクラスタは、GlassFish のインストール時に作成できます。クラスタとインスタンスは次のように「管理ドメイン」としてまとめられ、ドメイン管理サーバー (Domain Administration Server、DAS) によって特性が決定されます。 ドメイン管理アーキテクチャー
GlassFish クラスタ化アーキテクチャーの中心となるのは、管理ドメインの概念です。管理ドメインは、管理者または管理者グループのアクセス権を表します。次の図では、単一ドメインのコンテキストでのドメイン管理アーキテクチャーの概要を示しています。
管理ドメインは 2 つの特性を持つエンティティです。
ファイルシステムでは、管理ドメインは一連の設定ファイルで構成されます。実行時には、各サーバーインスタンス、クラスタ、アプリケーション、およびリソースを管理するプロセスになります。 一般的に、高可用性のインストールには独立したサーバーインスタンスではなく、クラスタが必要です。GlassFish アプリケーションサーバーは同種のクラスタを提供し、各クラスタが単一のエンティティであるかのように管理および変更を可能にします。 図に示すように、各ドメインにはドメイン管理サーバー (Domain Administration Server、DAS) があり、ドメイン内の Java EE Server インスタンスを管理するために使用されます。図の中央にある管理ノードは、DAS をサポートします。アプリケーション、リソース、および設定情報は、DAS のすぐ近くに保存されます。DAS によって管理されている設定情報は、「集中リポジトリ」の設定と呼ばれます。 各ドメインプロセスは、物理ホスト上で実行する必要があります。実行時に、ドメインは自身を DAS として示します。同様に、すべてのサーバーインスタンスは物理ホスト上で実行する必要があり、Java 仮想マシン (Java Virtual Machine、JVM) を必要とします。GlassFish アプリケーションサーバーは、サーバーインスタンスを実行する各マシン上にインストールする必要があります。
図の右側には 2 つのノード (ノード 1 とノード 2) があり、2 つの GlassFish サーバーインスタンスをそれぞれホストしています。 各ノードエージェントは、既定のドメインのそれぞれのマシン上で設定されるインスタンスのライフサイクルを管理します。一般的に、それぞれのライフサイクルは管理者の要求に従って、 DAS によって管理されます。 DAS は、各インスタンスの実際のライフサイクル管理を対応するノードエージェントに委任します。ノードエージェントは、自身では Java EE アプリケーションを実行しない軽量なプロセスです。 ノードエージェントは、インスタンスのライフサイクルの管理に加え、担当するサーバーインスタンスの監視 (ウォッチドッグ) も行います。サーバーインスタンスに問題が発見された場合、ノードエージェントは管理者や DAS の介在を必要とせずに、インスタンスのバックアップを取るようにします。 図 1 の左側には、複数の管理クライアントが示されています。 DAS の管理インフラストラクチャーは、Java Management Extensions (JMX) テクノロジに基づきます。DAS のインフラストラクチャーは、 JAX 仕様のインストゥルメンテーションレベルに従い、Managed Beans (MBeans) 形式の管理情報を採用します。これは、管理対象のリソースを表す Java オブジェクトです。 MBeans は JMX 標準に準拠するため、これらはリモートの標準 JMX クライアント (Java SE 5.0 以上で配布される JConsole など) で参照できます。図 1 に示す組み込みクライアントは、JMX API を使用してドメインを管理します。これらのクライアントでは、ドメインを管理するために管理者特権が必要です。次のような管理クライアントがあります。
クラスタ化アーキテクチャー
図 2 は、実行時を中心とした観点から GlassFish のクラスタ化アーキテクチャーを示しています。この図では、アーキテクチャーの高可用性の面を強調しています。図 2 には DAS が示されていません。また、アプリケーションサーバーインスタンスのあるノードは、クラスタ化されたインスタンスとしてグループ化して示されています。
図 2 の上部には、 HTTP、 JMS、 RMI-IIOP などのさまざまトランスポートがあり、負荷分散層を通してクラスタ化されたインスタンスと通信していることが示されています。エンタープライズ情報システムなどのカスタムリソースは、Java コネクタアーキテクチャーのリソースアダプタを通して、ロードバランサに接続します。すべてのトランスポートは、シングルポイント障害の発生時に利用可能な冗長ユニットによって実装されたスケーラビリティーおよび耐障害の両方の戦略に対し、クラスタ間で負荷分散が可能です。 図の一番下は、高可用性アプリケーション状態アプリケーションリポジトリです。これは、セッション状態ストレージの抽象化オブジェクトです。リポジトリには、HTTP セッション状態、ステートフル EJB セッション状態、およびシングルサインオン情報を含む、セッション状態が格納されます。この状態情報は、メモリーレプリケーションまたはデータベースを使っていずれかを保存できます。 高可用性データベースの代用
サン・マイクロシステムズは、高可用性データベース (HADB) テクノロジに基づくアプリケーションサーバーに関して、強固な高可用性ソリューションを提供してきました。HADB は、セッション状態情報の維持に関して、100% に近い割合の可用性を提供します。ただし、実装と保守のコストは比較的高く、自由に利用できますが、オープンソース版では提供されていません。 オープンソースの GlassFish アプリケーションサーバーを伴う軽量なオープンソース版の代替機能を求める要求により、GlassFish Version 2 でメモリーレプリケーション機能が提供されました。メモリーレプリケーションは、クラスタ内のインスタンスを利用して、互いの状態情報をデータベースではなくメモリーに保存します。ただし、HADB ソリューションも利用可能で、多くのインストールで優先される場合があります。 クラスタでのメモリーレプリケーション
状態情報をメモリーに保持する GlassFish 互換の耐障害システムには、いくつかの機能が必要です。このシステムには、HTTP セッション状態、シングルサインオン状態、および EJB セッション状態に対して、高可用性を提供する必要があります。また、既存の HADB ベースのアーキテクチャーと互換性を維持する必要があります。 メモリーレプリケーション機能は、GlassFish のクラスタ化機能を利用して、インストールおよび管理オーバーヘッドが少ない HADB 戦略の多くの利点を提供します。 GlassFish アプリケーションサーバーでは、クラスタインスタンスはリングトポロジで管理されます。リングの各メンバーは、メモリー状態データをリングの次のメンバー (複製パートナー) に送信し、前のメンバーからの状態データを受信します。状態データは各メンバーで更新され、リング内でレプリケートされます。単純な形式のトポロジを図 3 に示します。
トポロジのリングの構成は、インスタンスに設定した名前のアルファベット順で決定されます。したがって、図 3 のようにインスタンスに名前を付けた場合、インスタンス 1 はインスタンス 2 にレプリケートし、インスタンス 2 は インスタンス 3 にレプリケートするようにリングが構成されます。 一般的なクラスタトポロジを図 4 に示します。この図では、インスタンスが 2 台の物理マシンでホストされています。インスタンス 1 とインスタンス 3、および インスタンス 2 とインスタンス 4 をそれぞれ 1 台のマシンに配置することで、可用性が最大となります。いずれかのマシンで重大な問題が発見された場合、すべてのデータは、元の形式または問題が発見されたマシンにあるインスタンスの複製物としてもう一方のマシンに保護されます。
一般的なフェイルオーバーシナリオ
GlassFish アプリケーションサーバーは、問題発見時の適切な動作に対して、負荷分散層で特別な情報を必要としないように設計されています。たとえば、セッションをインスタンス 1 に経路指定している場合、インスタンス 1 に問題が発見されたときにセッションをインスタンス 2 に経路指定すべきという情報はロードバランサでは必要はありません。ロードバランサは、フェイルオーバー要求をクラスタ内の任意のインスタンスに発行できます。これは、位置透過性として説明される状況です。障害に対する応答がクラスタ内で発生します。ロードバランサが、動作しているインスタンスにセッションを再度経路指定すると、そのインスタンスは保存されたセッション情報を必要に応じてほかのインスタンスから取得します。 ロードバランサからのフェイルオーバー要求は、次のどちらかに分類されます。
図 5 に、クラスタをさらに詳しく示します。左側に負荷分散層があります。多くの場合、Web サーバー上に置かれます。各サーバーインスタンスでは、HTTP セッション情報がローカルキャッシュに保存され、キャッシュは次のインスタンスの複製キャッシュにコピーされます。
図 6 は、ケース 1 のフェイルオーバーを示しています。この場合、経路を再指定されたサーバーインスタンスは、すぐにセッション状態データにアクセスできます。この図では、インスタンス 1 で問題が発見され、サービスに対するロードバランサの要求はインスタンス 2 に経路指定されています。インスタンス 2 には、必要なセッション状態情報の複製があります。
図 7 は、ケース 2 のフェイルオーバーを示しています。この場合、負荷分散層はセッション状態データにすぐにアクセスできないサーバーインスタンスにセッションを再経路指定しています。この図では、インスタンス 4 が必要なセッション状態データがないことを認識し、クラスタ内のほかのインスタンスに SASE をブロードキャスト通信して、データを要求しています。要求は黄色い矢印で示されています。
インスタンスの 1 つ (図 7 ではインスタンス 2) が、保持している複製に要求されたデータが含まれていることを認識し、SASE 要求に応答します。インスタンス 2 はセッションデータをインスタンス 4 に転送し、以降はインスタンス 4 がこのセッションを提供します。 インスタンスが複製データを使用してセッションを提供する場合は (ケース 1 とケース 2 のどちらも)、複製データがまずテストされ、最新バージョンであることが確認されます。 クラスタの形状の動的な変更
クラスタ内のインスタンスに問題が発見された場合や、管理者がインスタンスを故意にオフラインにしている場合、クラスタのトポロジは必然的に変化します。 前の例では、インスタンス 1 で問題が発見されたため、セッションキャッシュのレプリケーションを維持するために、クラスタのトポロジを変更する必要があります。図 8 では、インスタンス 2 とインスタンス 4 はインスタンス 1 の消失を認識します。インスタンス 1 で問題が発見されているため、このインスタンスと通信しようとすると I/O の例外が発生して失敗します。インスタンスが意図的に停止されている場合、JXTA テクノロジはインスタンス 1 へのパイプが閉じられていることを示すメッセージを送信します。
図 9 に示すように、インスタンス 1 の消失に応答して、インスタンス 4 は新しいレプリケーションパートナーを選択します。インスタンス 4 は、古い接続を消去して、インスタンス 2 との接続を確立します。クラスタは、4 つのサーバーインスタンスから 3 つのサーバーインスタンスに縮小されます。
縮小されたクラスタで処理するセッションアクティビティーの全体的な量はこれまでと変わらないため、各インスタンスでは作業量が増加することに注意してください。リソース計画では、インメモリーレプリケーションはヒープメモリーを使用することに注意してください。高可用性を備えるには、クラスタを縮小する必要がある場合に、各インスタンスに対して十分なメモリーの空き領域があることを確認してください。 インスタンスがクラスタに参加 (または再参加) する場合は、本質的に逆の処理が発生します。クラスタ内の新しいインスタンスが負荷分散層からの要求を受信すると、インスタンスはレプリケーションパートナーを要求するブロードキャスト通信をし、いずれか 1 つを選択します。トポロジは新しいインスタンスを含むように、自動的に調整されます。 グループ管理サービス
グループ管理サービス (Group Management Service、GMS) は、クラスタおよびそのメンバーインスタンスに関する動的なメンバーシップ情報を提供します。GMS の設計は、Java テクノロジに基づくクラスタ化フレームワークの Project Shoal に大きく依存しています。GMS の中心は、JXTA テクノロジにも基づいています。 GMS は、メンバーの参加、メンバーの正常な停止、またはメンバーの障害などのイベントを調整しながら、GlassFish のクラスタ形状の変更イベントを管理します。GMS を通じて、メモリーレプリケーションはこれらのイベントに対して必要なアクションを実行し、サービスの継続的な可用性を提供します。 GMS は、GlassFish Application Server でクラスタの健全性を監視するために使用され、メモリーレプリケーションモジュールをサポートします。 まとめると、GMS は次のサポートを提供します。
メモリーレプリケーションの設定
クラスタのメモリーレプリケーションを設定するには、次の 3 つの手順を実行する必要があります。
これらの手順は、 GUI と CLI のどちらでも実行できます。 さらにチューニングが必要な場合もあります。たとえば、クラスタの管理プロファイルのデフォルトヒープサイズは 512M バイトです。エンタープライズ規模の配備では、この値を 1G バイト以上に設定するとよいでしょう。この処理は、ドメイン管理サーバーで JVM オプションに次のタグを設定することで簡単に設定できます。
また、Web アプリケーションの
メモリーレプリケーションの実装
GlassFish Version 2 アプリケーションサーバーのメモリーレプリケーション機能は、JXTA テクノロジのトランスポート機能およびメッセージング機能に基づいています。 JXTA テクノロジは、ピア・ツー・ピアテクノロジとして広く知られています。これは、ネットワークに接続されたデバイスが、ネットワークトポロジに影響を受けずにメッセージを交換したり協調できるようにする、一連の XML ベースのプロトコルとして定義されます。GlassFish Version 2 Application Server の開発では、メモリーレプリケーションの高容量および高スループットの要件を処理できるように JXTA テクノロジが調整されました。スケーラビリティとパフォーマンスを向上させるために、メモリーレプリケーション機能の開発者は Grizzly Project との連携も利用できました。これは、Java New I/O API (NIO) を利用してスケーラブルで強固なサーバーを構築する役に立ちます。 JXTA テクノロジのグループメンバーシップの抽象化オブジェクトは、GlassFish Application Server のクラスタおよびインスタンスモデルにうまく対応します。JXTA グループが GlassFish クラスタに対応し、JXTA ピアが GlassFish サーバーインスタンスに対応します。GMS はこれらのグループメンバーシップの抽象化オブジェクトを利用し、メモリーレプリケーションなどの消費コンポーネントを提供します。これは、クラスタの実行時イベントの通知イベントモデルです。 GlassFish Version 2 Application Server の開発では、クラスタ化トポロジは単一のサブネットに制限されています。将来的な計画では、クラスタ化トポロジの地理的な分散を含むように JXTA を利用します。 最後に、JXTA テクノロジのわかりやすい API により、GlassFish クラスタ化の設定条件は非常に単純になりました。 アプリケーションサーバーのインストール
GlassFish Application Server をインストールするには、次の手順に従います。
続いて、GlassFish Application Server を設定する必要があります。 クラスタ化の設定
インストールディレクトリには、2 つの
クラスタプロファイルを使用してデフォルトドメインを作成するには、次の手順に従います。
GlassFish の設定はこれで完了です。 ドメインの確認
CLI ( コマンド行インタフェースでのドメインの確認
設定の手順で、インストールディレクトリに
たとえば、次のコマンドを使用して、すべてのドメインとそれらの状態を表示できます。
まだ domain1 を起動していない場合は、上のコマンドで次の出力が表示されます。
domain1 を起動するには、次のコマンドを入力します。
ドメインが 1 つしかない場合は、引数の Sun Java System Application 管理コンソールでのドメインの確認
管理コンソールは、 既存ドメインのクラスタサポート
既存のドメインにクラスタ化のサポートを追加できます。開発者プロファイルを持つドメインは、設定を変更しなければクラスタ化をサポートしません。GlassFish インストールディレクトリで次のコマンドを実行して、開発者プロファイルドメインを作成できます。
開発者プロファイルドメインからクラスタ化を有効にするには、次の手順に従います。
HTTP ロードバランサプラグイン
ロードバランサは、複数のアプリケーションサーバーインスタンスの間でワークロードを分散し、システム全体のスループットを向上させます。セッション要求をサーバーインスタンスに経路指定する際に、負荷分散層は特別な情報を必要としませんが、利用可能なノードのリストを維持する必要があります。ノードが予想される要求に対して応答を返せない場合、ロードバランサは別のノードを選択します。 ロードバランサは、ソフトウェアまたはハードウェアで実装できます。デバイスの実装については、ハードウェアベンダーから提供される情報を参照してください。 GlassFish Version 2 Application Server では、HTTP ロードバランサプラグインを利用できます。プラグインは、Sun Java System Application Server 9.1 のほか、Apache Web Server と Microsoft IIS でも動作します。ロードバランサは、あるサーバーインスタンスからほかのインスタンスへのフェイルオーバーの要求も有効にして、高可用性インストールに貢献します。 ロードバランサプラグインの設定方法については、Sun Java System Application Server 9.1 管理コンソールのオンラインヘルプを参照してください。詳細は、『Sun Java System Application Server 9.1 High Availability Administration Guide』の第 5 章「Configuring HTTP Load Balancing」を参照してください。 まとめ
GlassFish Version 2 Application Server は、管理ドメイン、ドメイン管理サーバー、サーバーインスタンス、および物理マシンで構成される、柔軟なクラスタ化アーキテクチャーを提供します。アーキテクチャーは高可用性と水平方向のスケーラビリティーを向上させるために、使いやすさと高度な管理コントロールを兼ね備えています。
謝辞
この記事の準備にあたり、Larry White、Abhijit Kumar、および Dinesh Patil の協力に感謝します。 参照情報
|
 
BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | ||||||||||||||||||||||||||||||||||||||||||||
 | |
