Application Server による高可用性の実現

Application Server は、次のサブコンポーネントおよび機能を通して高可用性を提供します。

• 「ロードバランサプラグイン」

• 「高可用性データベース」

• 「高可用性クラスタ」

ロードバランサプラグイン

ロードバランサプラグインは、HTTP および HTTPS 要求を受け付け、それをクラスタ内のアプリケーションサーバーインスタンスに転送します。ネットワーク障害のためにインスタンスが失敗して使用不可になるか、または応答しなくなると、ロードバランサは要求を既存の使用可能なマシンにリダイレクトします。ロードバランサはまた、失敗したインスタンスが復旧したことを認識し、それに応じて負荷を再配分することもできます。Application ServerEnterprise Edition および Standard Edition は、Sun Java System Web Server と Apache Web Server 用のロードバランサプラグイン、および Microsoft Internet Information Server を提供しています。

ロードバランサによって、ワークロードが複数の物理マシンに分散されるため、全体的なシステムスループットが向上します。HTTP 要求のフェイルオーバーを通して、より高い可用性も提供されます。HTTP セッションの情報を持続させるには、HTTP セッションの持続性を設定する必要があります。

状態を持たない単純なアプリケーションであれば、負荷分散されたクラスタで十分なこともあります。しかし、セッション状態を持ったミッションクリティカルなアプリケーションの場合は、負荷分散されたクラスタを HADB とともに使用します。

負荷分散に関わるサーバーインスタンスとクラスタは、同種の環境を確保しています。これは、通常、サーバーインスタンスが同じサーバー設定を参照し、同じ物理リソースにアクセスでき、さらに配備された同じアプリケーションを持っていることを意味します。この均質性によって、障害の前後に、ロードバランサが常に負荷を均等にクラスタ内のアクティブなインスタンスに分散することが保証されます。

負荷分散とフェイルオーバーの設定については、第 5 章「HTTP 負荷分散の設定」を参照してください。

高可用性データベース

Application ServerEnterprise Edition は、HTTP セッションデータおよびステートフルセッション Bean データの高可用性ストレージのための高可用性データベース (HADB) を提供します。HADB は、負荷分散、フェイルオーバー、および状態復元により、最大 99.999% のサービスおよびデータの可用性をサポートするように設計されています。一般に、HADB は、Application Server とは独立に設定および管理する必要があります。

状態管理の機能を Application Server と切り離しておくことには、大きな利点があります。Application Server インスタンスは、状態レプリケーションを外部の高可用性状態サービスに委任した、スケーラブルで高性能なアプリケーションコンテナとしての動作に CPU サイクルを消費します。この疎結合のアーキテクチャーのために、Application Server インスタンスを容易にクラスタに追加したり、クラスタから削除したりできます。HADB の状態レプリケーションサービスを独立に拡張して、最適な可用性とパフォーマンスを得ることができます。Application Server インスタンスがレプリケーションも実行していると、J2EE アプリケーションのパフォーマンスが低下したり、ガベージコレクションの一時停止時間が長くなったりすることがあります。

ハードウェアの構成、サイズ、およびトポロジの決定を含む、HADB を用いた高可用性のためのアプリケーションサーバーインストールの計画と設定については、『Sun Java System Application Server Enterprise Edition 8.2 配備計画ガイド』の「可用性のための計画」および 『Sun Java System Application Server Enterprise Edition 8.2 配備計画ガイド』の第 3 章「トポロジの選択」を参照してください。

高可用性クラスタ

クラスタは、1 つの論理エンティティーとして一体となって動作する Application Server インスタンスの集まりです。クラスタは、1 つ以上の J2EE アプリケーションに対して実行環境を提供します。高可用性クラスタでは、状態レプリケーションサービスと、クラスタおよびロードバランサが統合されています。

クラスタの使用には、次の利点があります。

• 高可用性: クラスタ内のサーバーインスタンスに対するフェイルオーバーを可能にすることで実現します。1 つのサーバーインスタンスが停止すると、別のサーバーインスタンスが、利用できないサーバーインスタンスが処理していた要求を引き継ぎます。

• スケーラビリティー: クラスタにサーバーインスタンスを追加できるようにし、それによってシステムの能力が増強されることによって実現します。ロードバランサプラグインは、要求をクラスタ内の使用可能なサーバーインスタンスに分配します。管理者はより多くのサーバーインスタンスをクラスタに追加しているので、処理の中断の必要はありません。

クラスタ内のすべてのインスタンスが次のように動作します。

• 同じ設定を参照します。

• J2EE アプリケーションの EAR ファイル、Web モジュールの WAR ファイル、EJB JAR ファイルなど、配備されたアプリケーションの同じセットを所有します。

• 同じ一連のリソースを所有しているため、同じ JNDI 名前空間が構成されます。

ドメイン内のすべてのクラスタが一意の名前を持ちます。また、この名前は、すべてのノードエージェント名、サーバーインスタンス名、クラスタ名、および設定名の間でも一意である必要があります。この名前を domain に使用してはいけません。アプリケーションの配備やリソースの作成など、クラスタ化されていないサーバーインスタンスで実行する操作と同じ操作をクラスタ上で実行します。

クラスタと設定

クラスタの設定は、ほかのクラスタで共有される可能性のある、名前を付けられている設定から派生されます。設定をほかのサーバーインスタンスまたはクラスタと共有していないクラスタは、スタンドアロン設定を持っていると言われます。デフォルトで、この設定の名前は cluster_name -config です。ここで、cluster_name はクラスタの名前です。

設定をほかのクラスタまたはインスタンスと共有しているクラスタは、共有設定を持っていると言われます。

クラスタ、インスタンス、セッション、および負荷分散

クラスタ、サーバーインスタンス、ロードバランサ、およびセッションの関係は次のとおりです。

• サーバーインスタンスがクラスタの一部である必要はありません。ただし、クラスタの一部でないインスタンスは、1 つのインスタンスから別のインスタンスへとセッション状態を移すことによって得られる高可用性を利用することはできません。

• クラスタ内のサーバーインスタンスを 1 つまたは複数のマシンでホストすることができます。異なるマシンにまたがるサーバーインスタンスを 1 つのクラスタにグループ化できます。

• 特定のロードバランサは、複数のクラスタにあるサーバーインスタンスに要求を転送できます。ロードバランサのこの機能を使って、サービスを中断することなく、オンラインアップグレードを実行できます。詳細については、「サービスを停止せずにコンポーネントをアップグレードする」を参照してください。

• 単一のクラスタは、複数のロードバランサから要求を受信できます。クラスタが、2 つ以上のロードバランサからサービスを受ける場合、各ロードバランサで、まったく同一に、クラスタを設定する必要があります。

• 各セッションは、特定のクラスタに関連づけられます。そのため、1 つのアプリケーションを複数のクラスタに配備することは可能ですが、セッションフェイルオーバーは単一のクラスタ内でのみ発生します。

したがってクラスタは、そのクラスタ内のサーバーインスタンスがフェイルオーバーしたときには、安全境界として機能します。ロードバランサを使って、サービスを停止することなく、Application Server 内のコンポーネントをアップグレードすることができます。