test

Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド

第 1 章 Application Server の高可用性 (HA)

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

注 –

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

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

高可用性の概要

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

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

高可用性セッション持続性

Application Server は、HTTP 要求およびセッションデータ (HTTP セッションデータとステートフルセッション Bean データの両方) の高可用性を提供します。

Java EE アプリケーションは一般に、大量のセッション状態データを保持しています。Web ショッピングカートは、セッション状態の古典的な例です。アプリケーションはまた、頻繁に必要になるデータをセッションオブジェクトにキャッシュすることもできます。実際、ユーザーとの対話が多いほぼすべてのアプリケーションには、セッション状態の保持が必要になります。HTTP セッションとステートフルセッション Bean (SFSB) はどちらも、セッション状態データを保持しています。

サーバー障害の前後でのセッション状態の保持が、エンドユーザーにとって重要になることがあります。高可用性を実現するために、Application Server では、セッション状態データの格納方式として次の各タイプが用意されています。

ユーザーセッションを保持している Application Server インスタンスに障害が発生しても、セッション状態を復元することができ、セッションは情報を失うことなく動作を継続できます。

高可用性セッション持続性を設定する方法の詳細については、第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

高可用性 JMS (Java Message Service)

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

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

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

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

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

MQ クラスタ

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

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

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

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

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

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

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

詳細情報

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

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

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

高可用性とともに最適なパフォーマンスを得るためにアプリケーションや Application Server を設定および調整する方法については、『Sun Java System Application Server 9.1 Performance Tuning Guide』を参照してください。このマニュアルでは、次のようなトピックが説明されています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高可用性データベース

注 –

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

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

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

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

高可用性クラスタ

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

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

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

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

クラスタと設定

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

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

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

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

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

障害からの回復

Sun Cluster の使用

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

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

手動での復旧

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

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

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

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

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

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

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

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

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

  2. AS8.1 UR2 パッチ 4 をインストールする手順を参照してください。

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

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

ロードバランサおよび 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 Java System Application Server の Application Server スタンドアロン配布 で提供されます。Sun Java System Application Server の利用可能な配布については、『Sun Java System Application Server 9.1 Installation Guide』の「Distribution Types and Their Components」を参照してください。HADB 機能はエンタープライズプロファイルでのみ利用可能です。プロファイルの詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「使用法プロファイル」を参照してください。

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

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

Netbackup の使用

注 –

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

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

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

Application 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 番目のマシンにインストールしたときと同様に、アプリケーションサーバーを 3 番目のマシンにインストールします。

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

    1. コマンド行 (対話型) モードを使用して、アプリケーションサーバー管理パッケージをインストールします。

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


      ./bundle-filename -console

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

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

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

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

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

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


    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 コマンドを使用してクラスタインスタンスを起動し、復元されたドメインと同期できるようにします。