test

Sun GlassFish Communications Server 1.5 高可用性 (HA) 管理ガイド

第 1 章 Communications Server の高可用性

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

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

高可用性の概要

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

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

融合ロードバランサ

融合ロードバランサは HTTP/HTTPS および SIP/SIPS 要求の両方を受け入れ、クラスタ内のアプリケーションサーバーインスタンスに転送します。ネットワーク障害のためにインスタンスが失敗して使用不可になるか、または応答しなくなると、ロードバランサは要求を既存の使用可能なマシンにリダイレクトします。ロードバランサはまた、障害が起きたインスタンスが復旧したことを認識し、それに応じて負荷を再配分することもできます。Communications Server は融合ロードバランサを提供します。クラスタ (Communications Server インスタンスの) またはスタンドアロンインスタンスは、専用ロードバランサになります。クラスタ内の各インスタンスは負荷分散にかかわることができます。この場合、クラスタは「自己負荷分散」です。

ロードバランサによって、ワークロードが複数の物理マシンに分散されるため、全体的なシステムスループットが向上します。HTTP および SIP 要求のフェイルオーバーを通して、より高い可用性も提供されます。融合ロードバランサは、システム配備のスケーラビリティーの実現にも役立ちます。

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

負荷分散にかかわるサーバーインスタンスとクラスタは、同種の環境を確保する必要があります。

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

高可用性 JMS (Java Message Service)

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

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

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

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

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

MQ クラスタ

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

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

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

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

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

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

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

詳細情報

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

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

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

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

障害からの回復

Sun Cluster の使用

Sun Cluster では、ドメイン管理サーバー、ノードエージェント、Communications 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 が到達不可能であっても、Communications Server クラスタおよびアプリケーションは、それまでどおり稼働し続けます。

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

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

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

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

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

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

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

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

メッセージキューの回復

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

Netbackup の使用

注 –

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

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

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

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

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

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

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

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

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

注 –

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

ProcedureDAS を移行する

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

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

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

    1. コマンド行 (対話型) モードを使用して、Communications 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 コマンドを使用してクラスタインスタンスを起動し、復元されたドメインと同期できるようにします。