test

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

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

この章では、Sun Java SystemApplication Server Enterprise Edition の高可用性機能について、次のトピックで説明します。

高可用性の概要

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

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

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

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

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

サーバー障害の前後でのセッション状態の保持が、エンドユーザーにとって重要になることがあります。高可用性に対応するために、Application Server は、セッション状態を HADB に保持する機能を提供します。ユーザーセッションを保持している Application Server インスタンスに障害が発生しても、セッション状態を復元することができ、セッションは情報を失うことなく動作を継続できます。

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

高可用性 JMS (Java Message Service)

Java Message Service (JMS) API は、J2EE アプリケーションおよびコンポーネントに対して、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この 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 負荷分散とフェイルオーバーは、透過的に発生します。アプリケーションの配備中に、特別な手順は必要ありません。ただし、クラスタに新しいインスタンスを追加したり削除したりしても、そのクラスタに関する既存のクライアントの表示は更新されません。それには、クライアントで、端点の一覧を手動で更新する必要があります。

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

詳細情報

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

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

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

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 アプリケーションに対して実行環境を提供します。高可用性クラスタでは、状態レプリケーションサービスと、クラスタおよびロードバランサが統合されています。

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

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

ドメイン内のすべてのクラスタが一意の名前を持ちます。また、この名前は、すべてのノードエージェント名、サーバーインスタンス名、クラスタ名、および設定名の間でも一意である必要があります。この名前を 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 ノードが 2 つある場合は、障害時に引き継ぐことができる 2 つのスペアノードを (別々のマシン上に) 設定できます。HADB のバックアップおよび復元では不整合セッションが復元される可能性があるため、この方法のほうがクリーンです。

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

Netbackup の使用

注 –

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

各マシンのイメージを保存するには、Veritas Netbackup を使用します。BPIP の場合は、Web サーバーおよびアプリケーションサーバーとともに 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 の作業コピーを再作成するには、次の環境が必要です。

注 –

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

Procedureドメイン管理サーバーを移行する

DAS を 1 番目のマシン (machine1) から 3 番目のマシン (machine3) に移行するには、次の手順に従います。

  1. 1 番目のマシンにインストールしたときと同様に、アプリケーションサーバーを 3 番目のマシンにインストールします。

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

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

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


      ./bundle-filename -console

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

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

      バックアップされたドメインの復元は、2 台のマシンのアーキテクチャーが同じで、インストールパスがまったく同じ (両方のマシンで同じ install-dir と domain-root-dir) である場合だけサポートされています。

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

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

  3. asadmin restore-domain コマンドを実行して、zip ファイルを 3 番目のマシンに復元します。


    asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip domain1

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

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

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

    次に例を示します。

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

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

  5. 3 番目のマシンの domain.xml ファイルで、プロパティーのホスト値を変更します。

  6. 3 番目のマシンの domain-root-dir/domain1/config/domain.xml を更新します。

    たとえば、machine1 を検索し、machine3 に置き換えます。次の箇所を変更できます。

    <jmx-connector><property name=client-hostname value=machine1/>...

    次のようにします。

    <jmx-connector><property name=client-hostname value=machine3/>...

  7. 次の箇所を変更します。

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

    次のようにします。

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

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


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

  9. machine2 で、ノードエージェントの下にあるプロパティーの DAS ホスト値を変更します。

  10. machine2 で、install-dir/nodeagents/nodeagent/agent/config/das.properties の agent.das.host プロパティー値を変更します。

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

    注 –

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