test

Sun GlassFish Enterprise Server 2.1 高可用性 (HA) 管理ガイド

第 1 章 Enterprise Server の高可用性

この章では、クラスタプロファイルおよびエンタープライズプロファイルで利用できる Sun GlassFish Enterprise Server の高可用性機能について説明します。

注 –

HADB ソフトウェアは、Sun GlassFish Enterprise Server の Enterprise Server スタンドアロン配布 で提供されます。Sun GlassFish Enterprise Server の利用可能な配布の詳細については、『Sun GlassFish Enterprise Server 2.1 Installation Guide』の「Distribution Types and Their Components」を参照してください。HADB 機能はエンタープライズプロファイルでのみ利用可能です。プロファイルの詳細については、『Sun GlassFish Enterprise Server 2.1 管理ガイド』の「プロファイル」を参照してください。

この章の内容は、次のとおりです。

高可用性の概要

高可用性アプリケーションおよびサービスは、ハードウェアやソフトウェアの障害には関係なく、機能を継続的に提供します。このようなアプリケーションは、99.999% の時間利用可能であることから、ファイブナインの信頼性を実現していると言われることがあります。

Enterprise Server では、次の高可用性機能を提供します。

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

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

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

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

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

HTTP ロードバランサプラグインの負荷分散およびフェイルオーバーの設定については、第 4 章HTTP 負荷分散の設定を参照してください。

高可用性 JMS (Java Message Service)

Java Message Service (JMS) API は、Java EE アプリケーションおよびコンポーネントに対して、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この API によって、緩やかに結合され、信頼性が高く、非同期の分散通信が可能となります。Sun Java System Message Queue (MQ) は JMS を実装し、Enterprise Server と密接に統合されているため、MQ を使用してメッセージ駆動型 Bean (MDB) などの JMS に依存するコンポーネントを作成できます。

接続のプールおよびフェイルオーバーと、MQ クラスタを通じて、JMS の高可用性が実現されます。詳細については、第 8 章Java Message Service 負荷分散とフェイルオーバーを参照してください。

接続プールとフェイルオーバー

Enterprise Server は JMS 接続プールとフェイルオーバーをサポートします。Enterprise Server は JMS 接続を自動的にプールします。デフォルトでは、 Enterprise Server は、指定されたホストリストから主 MQ ブローカをランダムに選択します。フェイルオーバーが発生すると、MQ は負荷を別のブローカに透過的に転送し、JMS セマンティクスを保持します。

JMS 接続のプールおよびフェイルオーバーの詳細については、「接続プールとフェイルオーバー」を参照してください。

MQ クラスタ

MQ Enterprise Edition は、ブローカクラスタと呼ばれる、相互に接続した複数のブローカインスタンスをサポートします。ブローカクラスタによって、クライアント接続はクラスタ内のすべてのブローカに分散されます。クラスタ化することで、水平方向のスケーラビリティーが提供され、可用性が向上します。

MQ クラスタの詳細については、「MQ クラスタと Enterprise Server の併用」を参照してください。

RMI-IIOP 負荷分散とフェイルオーバー

RMI-IIOP 負荷分散では、IIOP クライアント要求が別のサーバーインスタンスまたはネームサーバーに分散されます。目標は、負荷をクラスタ間に均等に拡散して、スケーラビリティーを実現することです。また、IIOP 負荷分散を EJB のクラスタリングおよび可用性と結合すれば、EJB フェイルオーバーも実現されます。

クライアントがオブジェクトに対して JNDI 検索を実行すると、ネームサービスは、原則的に要求を特定のサーバーインスタンスにバインドします。それ以降、そのクライアントからの検索要求はすべて、同じサーバーインスタンスに送信されます。こうして、すべての EJBHome オブジェクトは、同じターゲットサーバーにホストされます。また、それ以降に取得された Bean 参照もすべて、同じターゲットホスト上に作成されます。JNDI 検索の実行時に、すべてのクライアントがターゲットサーバーのリストをランダムに選択するため、これにより負荷分散が効果的に実現されます。ターゲットサーバーインスタンスが停止すると、検索または EJB メソッド呼び出しは、別のサーバーインスタンスに処理が引き継がれます。

RMI-IIOP 負荷分散とフェイルオーバーは、透過的に発生します。アプリケーションの配備中に、特別な手順は必要ありません。アプリケーションクライアントが配備される Enterprise Server インスタンスがクラスタに参加する場合、Enterprise Server は、クラスタ内で現在アクティブなすべての IIOP 端点を自動的に検出します。ただし、端点の 1 つで障害が発生した場合に備えて、クライアントにはブートストラップ目的で少なくとも 2 つの端点を指定しておくことをお勧めします。

RMI-IIOP 負荷分散およびフェイルオーバーの詳細については、第 9 章RMI-IIOP 負荷分散とフェイルオーバーを参照してください。

詳細情報

ハードウェア要件の評価、ネットワーク構成の計画、およびトポロジの選択を含む、高可用性配備の計画については、『Sun GlassFish Enterprise Server 2.1 配備計画ガイド』を参照してください。また、このドキュメントでは、次に示すような概念への高レベルな導入も提供しています。

高可用性機能を利用するアプリケーションの開発の詳細については、『Sun GlassFish Enterprise Server 2.1 Developer’s Guide』を参照してください。

高可用性サーバーおよびアプリケーションの調整

高可用性とともに最適なパフォーマンスを得るためにアプリケーションや Enterprise Server を設定および調整する方法については、docs.sun.com で『パフォーマンスチューニングガイド』を参照してください。このドキュメントでは、次のようなトピックが説明されています。

Enterprise Server による高可用性の提供方法

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

セッション状態データ用ストレージ

セッション状態データを格納することにより、クラスタ内のサーバーインスタンスのフェイルオーバー後にセッション状態を復元できるようになります。セッション状態の復元により、情報を失うことなくセッションを継続できます。Enterprise Server では、HTTP セッションおよびステートフルセッション Bean のデータを格納するための、次のタイプの高可用性ストレージが用意されています。

クラスタ内の別のサーバーにおけるインメモリーレプリケーション

ほかのサーバー上でインメモリーレプリケーションを実行することにより、HADB などの別個のデータベースを入手しなくてもセッション状態データの軽量ストレージを用意できます。このタイプのレプリケーションは、ほかのサーバー上のメモリーを使用して HTTP セッションとステートフルセッション Bean データの高可用性ストレージを実現します。クラスタ化されたサーバーインスタンスはセッション状態をリングトポロジで複製します。各バックアップインスタンスは複製されたデータをメモリーに格納します。セッション状態データをほかのサーバー上のメモリーに複製することによって、セッションを分散することが可能になります。

インメモリーレプリケーションを使用するには、「グループ管理サービス (GMS)」 を有効にする必要があります。GMS の詳細については、「グループ管理サービス」を参照してください。

クラスタ内の複数のサーバーインスタンスが異なるマシンに配置されている場合は、次の前提条件が満たされていることを確認してください。

高可用性データベース

注 –

HADB ソフトウェアは、Sun GlassFish Enterprise Server の Enterprise Server スタンドアロン配布 で提供されます。Sun GlassFish Enterprise Server の利用可能な配布の詳細については、『Sun GlassFish Enterprise Server 2.1 Installation Guide』の「Distribution Types and Their Components」を参照してください。HADB 機能はエンタープライズプロファイルでのみ利用可能です。プロファイルの詳細については、『Sun GlassFish Enterprise Server 2.1 管理ガイド』の「プロファイル」を参照してください。

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

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

ハードウェアの設定、サイズ、およびトポロジの決定など、インストールで HADB による高可用性を計画および設定する方法については、『Sun GlassFish Enterprise Server 2.1 配備計画ガイド』を参照してください。

高可用性クラスタ

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

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

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

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

クラスタと設定

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

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

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

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

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

障害からの回復

Sun Cluster の使用

Sun Cluster では、ドメイン管理サーバー、ノードエージェント、Enterprise Server インスタンスおよびメッセージキューの自動フェイルオーバーを提供しています。詳細については、docs.sun.com で『Sun Cluster Data Service for Sun Java System Application Server Guide for Solaris OS』を参照してください。

標準の Ethernet 相互接続および Sun Cluster 製品のサブセットを使用します。この機能は、Java ES に含まれています。

手動での復旧

さまざまな方法を使用して、個別のサブコンポーネントを手動で復旧できます。

ドメイン管理サーバーの回復

ドメイン管理サーバー (DAS) が失われて影響があるのは、管理だけです。たとえ DAS が到達不可能であっても、Enterprise Server クラスタおよびアプリケーションは、それまでどおり稼働し続けます。

DAS を復旧するには、次のいずれかの方法を使用します。

ノードエージェントおよびサーバーインスタンスの回復

ノードエージェントおよびサーバーインスタンスを回復する方法は 2 つあります。

バックアップの zip ファイルを保持する。ノードエージェントおよびサーバーインスタンスをバックアップする明確なコマンドはありません。ノードエージェントディレクトリの内容を持つ zip ファイルを単に作成します。障害発生後に、同じホスト名と IP アドレスを持つ新しいマシンで保存済みのバックアップを解凍します。インストールディレクトリの場所、OS なども同じものを使用します。ファイルベースのインストール、パッケージベースのインストール、または復元されたバックアップイメージがマシン上に存在する必要があります。

手動での回復。同じ IP アドレスを持つ新しいホストを使用する必要があります。

  1. Enterprise Server をノードエージェントとともにマシンにインストールします。

  2. ノードエージェントを再作成します。サーバーインスタンスを作成する必要はありません。

  3. 同期によって、設定およびデータが DAS からコピーされ更新されます。

HTTP ロードバランサおよび Web Server の回復

Web Server の設定だけをバックアップする明確なコマンドは ありません。Web Server のインストールディレクトリを単に圧縮します。障害発生後に、同じネットワーク ID を持つ新しいマシンで保存済みのバックアップを解凍します。新しいマシンの IP アドレスが異なる場合は、DNS サーバーまたはルーターを更新します。

注 –

これは、あらかじめ Web Server にイメージが再インストールまたは復元されていることを前提としています。

ロードバランサプラグイン (plugins ディレクトリ) および設定は、Web Server のインストールディレクトリ (通常は /opt/SUNWwbsvr) にあります。web-install/web-instance/config ディレクトリには loadbalancer.xml ファイルがあります。

メッセージキューの回復

メッセージキュー (MQ) の設定およびリソースは、DAS に格納され、インスタンスに同期できます。その他のデータおよび設定情報は、すべて MQ ディレクトリ (通常は /var/imq の下) にあるため、必要に応じてこれらのディレクトリをバックアップおよび復元します。新しいマシンには、あらかじめ MQ インストールが含まれている必要があります。マシンを復元するときは、それまでどおり MQ ブローカが起動していることを必ず確認してください。

HADB の復元

注 –

HADB ソフトウェアは、Sun GlassFish Enterprise Server の Enterprise Server スタンドアロン配布 で提供されます。Sun GlassFish Enterprise Server の利用可能な配布の詳細については、『Sun GlassFish Enterprise Server 2.1 Installation Guide』の「Distribution Types and Their Components」を参照してください。HADB 機能はエンタープライズプロファイルでのみ利用可能です。プロファイルの詳細については、『Sun GlassFish Enterprise Server 2.1 管理ガイド』の「プロファイル」を参照してください。

アクティブな HADB ノードが 2 つある場合は、障害時に引き継ぐことができる 2 つのスペアノードを (別々のマシン上に) 設定できます。HADB のバックアップおよび復元では不整合セッションが復元される可能性があるため、この方法のほうがクリーンです。

スペアノードのあるデータベースを作成する方法については、「データベースの作成」を参照してください。スペアノードをデータベースに追加する方法については、「ノードの追加」を参照してください。復旧および自己修復に失敗すると、スペアノードによって自動的に引き継がれます。

Netbackup の使用

注 –

この手順は、Sun QA によって確認されていません。

各マシンのイメージを保存するには、Veritas Netbackup を使用します。BPIP の場合は、Web サーバーおよび Application Server とともに 4 つのマシンをバックアップします。

復元されたそれぞれのマシンについて、元のマシンと同じ設定 (同じホスト名、IP アドレスなど) を使用します。

Enterprise Server のようなファイルベース製品では、関連するディレクトリだけをバックアップおよび復元します。ただし、Web サーバーイメージのようなパッケージベースのインストールでは、マシン全体をバックアップおよび復元する必要があります。パッケージは、Solaris パッケージデータベースにインストールされます。そのため、ディレクトリだけをバックアップし、続いて新しいシステムに復元すると、パッケージデータベースには情報のない、「展開された」Web サーバーになります。このため、今後のパッチ適用やアップグレードで問題が発生する可能性があります。

Solaris パッケージデータベースを手動でコピーおよび復元しないでください。代替方法は、Web サーバーなどのコンポーネントのインストール後にマシンのイメージをバックアップすることです。これをベースライン tar ファイルと呼びます。Web サーバーに変更を加えた場合は、たとえば /opt/SUNWwbsvr の下にあるこれらのディレクトリをバックアップします。復元するには、ベースライン tar ファイルから開始し、次に変更した Web サーバーディレクトリを上書きコピーします。同様に、MQ でもこの手順を使用できます (BPIP のパッケージベースのインストール)。元のマシンをアップグレードまたはパッチ適用する場合、新しいベースライン tar ファイルを作成する必要があります。

DAS のあるマシンがダウンすると、復元するまで利用できない時間が発生します。

DAS は、中央リポジトリです。サーバーインスタンスを復元して再起動すると、DAS にある情報とのみ同期されます。そのため、すべての変更は asadmin または 管理コンソール を使用して実行する必要があります。

イメージにアプリケーションセッションの古い状態が含まれる可能性があるため、HADB の日次バックアップは機能しないことがあります。

ドメイン管理サーバーの再作成

ドメイン管理サーバー (DAS) をホストしているマシンで障害が発生した場合、以前に DAS をバックアップしたことがあれば DAS を再作成できます。DAS の作業コピーを再作成するには、次の環境が必要です。

注 –

1 番目のマシンからの DAS のバックアップを保持している必要があります。現在のドメインをバックアップするには、asadmin backup-domain を使用します。

ProcedureDAS を移行する

ドメイン管理サーバーを 1 台目のマシン (machine1) から 3 台目のマシン (machine3) に移行するには、次の手順が必要です。

  1. 1 台目のマシンと同様に、Enterprise Server を 3 台目のマシンにインストールします。

    これは、DAS が 3 番目のマシンに正しく復元され、パスの競合が起きないようにするために必要です。

    1. コマンド行 (対話型) モードを使用して、Enterprise Server 管理パッケージをインストールします。

      対話型コマンド行モードを有効にするには、次のように console オプションを使用してインストールプログラムを呼び出します。


      ./bundle-filename -console

      コマンド行インタフェースを使用してインストールするには、ルート権限が必要です。

    2. デフォルトのドメインをインストールするオプションを選択解除します。

      バックアップされたドメインの復元は、同じアーキテクチャーおよびまったく同じインストールパスを持つ 2 台のマシンでのみサポートされます (すなわち両方のマシンが同じ as-install と domain-root-dir を使用する)。

  2. バックアップの ZIP ファイルを 1 番目のマシンから 3 番目のマシンの domain-root-dir にコピーします。

    ファイルを FTP 転送することもできます。

  3. ZIP ファイルを 3 番目のマシンに復元します。


    asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip 
--clienthostname machine3 domain1
    注 –

    --clienthostname オプションを指定することによって、domain.xml ファイル内の jmx-connector 要素の client-hostname プロパティーを変更する必要性を回避します。

    任意のドメインをバックアップできます。ただし、ドメインの再作成時に、ドメイン名を元のドメインと同じ名前にしてください。

  4. 3 番目のマシンの domain-root-dir/domain1/generated/tmp ディレクトリのアクセス権を変更し、1 番目のマシンの同じディレクトリのアクセス権と一致させます。

    このディレクトリのデフォルトのアクセス権は次のとおりです。 drwx------ (または 700)。

    次に例を示します。


    chmod 700 domain-root-dir/domain1/generated/tmp

    この例では、domain1 をバックアップしていることとします。ドメインを別の名前でバックアップしている場合は、上記の domain1 をバックアップしているドメインの名前で置き換えるようにしてください。

  5. 3 番目のマシン上の domain-root-dir/domain1/config/domain.xml ファイルで、jms-service 要素の host 属性の値を更新します。

    この属性の元の設定は次のとおりです。

    <jms-service... host=machine1.../>

    この属性の設定を次のように変更します。

    <jms-service... host=machine3.../>

  6. machine3 で復元されたドメインを起動します。


    asadmin start-domain --user admin-user --password admin-password domain1

    DAS は稼働中のすべてのノードエージェントと通信し、DAS と通信するための情報をノードエージェントに提供します。ノードエージェントはこの情報を使用して DAS と通信します。

  7. DAS の再起動時に稼働していないすべてのノードエージェントについて、machine2 で as-install/nodeagents/ nodeagent/agent/config/das.properties の agent.das.host プロパティー値を変更します。

    この手順は、DAS の再起動時に稼働しているノードエージェントについては不要です。

  8. machine2 でノードエージェントを再起動します。

    注 –

    asadmin start-instance コマンドを使用してクラスタインスタンスを起動し、復元されたドメインと同期できるようにします。