test

Sun Java System Application Server 9.1 配備計画ガイド

第 1 章 製品概念

Sun Java System Application Server は、Java EE アプリケーションの開発、配備、および管理のための堅牢なプラットフォームを提供します。主な機能には、スケーラブルなトランザクション管理、コンテナ管理による持続性ランタイム、Web サービスのパフォーマンス、クラスタ化、高可用性セッション状態、セキュリティー、および統合機能があります。

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

Java EE プラットフォームの概要

Application Server は、Java Platform Enterprise Edition (Java EE) 5 テクノロジを実装します。Java EE プラットフォームは、アプリケーションコンポーネント、API、およびアプリケーションサーバーの実行時コンテナとサービスについて記述した標準仕様のセットです。

Java EE アプリケーション

Java EE アプリケーションは、JavaServer Pages (JSP)、Java サーブレット、Enterprise JavaBeans (EJB) モジュールなどのコンポーネントで構成されます。ソフトウェア開発者はこれらのコンポーネントを利用して、大規模分散アプリケーションを構築できます。開発者は Java EE アプリケーションを、zip ファイルに似た Java アーカイブ (JAR) ファイルにパッケージ化して本番サイトに配布できます。管理者は、Java EE JAR ファイルを 1 つ以上のサーバーインスタンス (またはインスタンスのクラスタ) に配備することにより、Java EE アプリケーションを Application Server 上にインストールします。

次の図は、以降の節で説明する Java EE プラットフォームのコンポーネントを示したものです。

申し訳ございません: 現在、図が用意できておりません。

コンテナ

各サーバーインスタンスには、2 つのコンテナ (Web コンテナと EJB コンテナ) が含まれます。コンテナは、Java EE コンポーネントのセキュリティーやトランザクション管理などのサービスを提供する実行時環境です。JavaServer Pages (JSP) やサーブレットなどの Web コンポーネントは、Web コンテナ内で実行されます。Enterprise JavaBeans は EJB コンテナ内で実行されます。

Java EE サービス

Java EE プラットフォームは、次のようなサービスをアプリケーションに対して提供します。

Web サービス

クライアントは HTTP、RMI/IIOP、JMS 経由でのアクセスに加えて、リモート Web サービスとして Java EE 1.4 アプリケーションにアクセスできます。Web サービスは、Java API for XML-based RPC (JAX-RPC) を使用して実装されます。Java EE アプリケーションは Web サービスに対するクライアントとして動作することもでき、これはネットワークアプリケーションで典型的な構成です。

Web Services Description Language (WSDL) は、Web サービスのインタフェースを記述する XML 形式です。Web サービスのコンシューマは、WSDL ドキュメントを動的に解析して、Web サービスが提供する操作とその実行方法を特定できます。Application Server では、ほかのアプリケーションが Java API for XML Registries (JAXR) を経由してアクセス可能なレジストリを使用して、Web サービスインタフェースの記述を分散させています。

クライアントアクセス

クライアントは複数の方法で Java EE アプリケーションにアクセスできます。ブラウザクライアントは、ハイパーテキストトランスファープロトコル (HTTP) を使用して Web アプリケーションにアクセスします。セキュリティー保護された通信のために、ブラウザでは、Secure Sockets Layer (SSL) を使用する HTTPS プロトコルを利用します。

アプリケーションクライアントコンテナ内で動作するリッチクライアントアプリケーションは、オブジェクトリクエストブローカ (ORB)、リモートメソッド呼び出し (RMI) および IIOP (internet inter-ORB protocol)、または IIOP/SSL (セキュリティー保護された IIOP) を使用して Enterprise JavaBeans (EJB) を直接検索し、アクセスできます。そのようなアプリケーションは、HTTP/HTTPS、JMS、および JAX-RPC を使用してアプリケーションや Web サービスにアクセスできます。それらのアプリケーションでは JMS を使用して、アプリケーションおよびメッセージ駆動型 Beans との間でメッセージを送受信します。

Java EE Web サービスにアクセスできるのは、WS-I Basic Profile (Web サービス相互運用性基本プロファイル) に準拠したクライアントです。WS-I は Java EE 標準の根幹的な部分であり、Web サービスの相互運用性について定義しています。WS-I に準拠することにより、サポートされているすべての言語で記述されたクライアントが、Application Server に配備された Web サービスにアクセスできます。

最適なアクセス機構は、個別のアプリケーションおよび予想されるトラフィック量によって異なります。Application Server は、HTTP、HTTPS、JMS、IIOP、および IIOP/SSL のそれぞれに対応した設定が可能なリスナーをサポートします。各プロトコルに対して複数のリスナーを設定し、スケーラビリティーと信頼性を高めることができます。

Java EE アプリケーションは、ほかのサーバー上に配備された EJB モジュールなどの Java EE コンポーネントのクライアントとしても動作でき、これらのアクセス機構のうち任意のものを使用できます。

外部システムとリソース

Java EE プラットフォームでは、外部のシステムのことを「リソース」と呼びます。たとえば、データベース管理システムは JDBC リソースです。各リソースは、その Java Naming and Directory Interface (JNDI) 名によって一意に識別されます。アプリケーションは、次の API とコンポーネントを通して外部システムにアクセスします。

Application Server のコンポーネント

この節では、Sun Java System Application Server のコンポーネントについて説明します。

次の図は、高可用性を提供する単純なサンプルトポロジを使用して、これらの Application Server コンポーネントが、どう相互に作用するかを示しています。このサンプルトポロジでは、クラスタとして編成された 2 台のマシンを 1 人の管理者が管理します。HADB プロセスと Application Server プロセスは同じマシン上に位置します。ドメイン管理サーバーは、独立したマシンに単独で配置することも、アプリケーションサーバーインスタンスをホストしているいずれかのマシンに配置することもできます。図中の線は通信または制御を示します。

まず、ブラウザベースの管理コンソールなどの管理ツールがドメイン管理サーバー (DAS) と通信し、その後 DAS がノードエージェントまたはサーバーインスタンスと通信します。

サーバーインスタンス

サーバーインスタンスは、単一の Java 仮想マシン (JVM) プロセス内で実行される Application Server です。Application Server は、Java 2 Standard Edition (J2SE) 5.0 および Java SE 6 での動作が検証されています。推奨される Java EE 配布は Application Server のインストールに含まれています。

Application Server と付属の JVM はともに、マルチプロセッサ構成で拡大縮小するように設計されているため、通常は 1 台のマシン上に 1 つのサーバーインスタンスを作成すれば十分です。ただし、アプリケーションの隔離と順次アップグレードのために、1 台のマシン上に複数のインスタンスを作成すると有利な場合もあります。場合によっては、複数のインスタンスが動作する 1 台の大規模サーバーを複数の管理ドメインで使用できます。管理ツールを使用することで、複数のマシンにまたがってサーバーインスタンスを容易に作成、削除、および管理できます。

管理ドメイン

「管理ドメイン」(または単に「ドメイン」) は、まとめて管理されるサーバーインスタンスのグループです。1 つのサーバーインスタンスは単一の管理ドメインに属します。ドメイン内のインスタンスは、複数の異なる物理ホスト上で実行できます。

Application Server の 1 つのインストールから複数のドメインを作成できます。サーバーインスタンスをドメインにグループ化することにより、さまざまな組織および管理者が 1 つの Application Server インストールを共有できます。各ドメインには、固有の設定、ログファイル、およびアプリケーションの配備領域があり、これらはほかのドメインとは無関係です。あるドメインの構成を変更しても、ほかのドメインの構成には影響しません。同様に、あるドメインにアプリケーションを配備しても、そのアプリケーションがほかのドメインに配備されたり、ほかのドメインから認識可能になることはありません。管理者は常に 1 つのドメインに対する認証しか受けられず、そのドメイン上での管理しか実行できません。

ドメイン管理サーバー (DAS)

ドメインには 1 つのドメイン管理サーバー (DAS) があります。これは、管理アプリケーションのホストとなる、特別に設計されたアプリケーションサーバーインスタンスです。DAS は管理者を認証し、管理ツールからの要求を受け付け、ドメイン内のサーバーインスタンスと通信して要求を実行します。

管理ツールには、コマンド行ツールの asadmin と、ブラウザベースの管理コンソールがあります。Application Server では、サーバー管理のための JMX ベースの API も提供されます。管理者が同時に表示および管理できるのは 1 つのドメインのみであり、これによってセキュリティーで保護された分離が実現されています。

DAS のことを「管理サーバー」または「デフォルトサーバー」と呼ぶ場合もあります。DAS をデフォルトサーバーと呼ぶ理由は、一部の管理操作のデフォルトターゲットであるためです。

DAS はアプリケーションサーバーインスタンスであるため、テスト目的で Java EE アプリケーションをホストすることもできます。ただし、本番アプリケーションのホストを目的として DAS を使用しないでください。たとえば、本番アプリケーションをホストする予定のクラスタやインスタンスをまだ作成していない場合に、アプリケーションを DAS に配備することができます。

DAS は、各ドメインおよびすべての配備済みアプリケーションの設定を格納するリポジトリを保持します。DAS がアクティブでないか停止している場合、アクティブなサーバーインスタンスのパフォーマンスまたは可用性への影響はありませんが、管理上の変更は実行できません。状況によっては、セキュリティー上の理由から、本番構成を凍結することなどを目的として意図的に DAS プロセスを停止すると便利な場合があります。

ドメイン設定やアプリケーションをバックアップおよび復元するための管理コマンドが用意されています。標準のバックアップ手順および復元手順を使用して、作業中の構成を迅速に復元できます。DAS ホストで障害が発生した場合、以前のドメイン設定を復元するために新しい DAS インストールを作成する必要があります。手順については、『Sun Java System Application Server 9.1 管理ガイド』の「ドメイン管理サーバーの再作成」を参照してください。

Sun Cluster Data Services は、DAS ホストの IP アドレスのフェイルオーバーと、グローバルファイルシステムの使用によって高可用性を実現します。このソリューションにより、多くの種類の障害に対してほとんど停止しないレベルの可用性が、DAS およびリポジトリに対して提供されます。Sun Cluster Data Services は、Sun Java Enterprise System に付属するか、または Sun Cluster とともに別途購入する形で提供されます。詳細は、Sun Cluster Data Services のマニュアルを参照してください。

クラスタ

クラスタとは、同じアプリケーション、リソース、および設定情報を共有するサーバーインスタンスの集まりに名前を付けたものです。異なるマシン上のサーバーインスタンスを 1 つの論理クラスタにまとめ、それらのインスタンスを 1 つの単位として管理できます。マルチマシンクラスタのライフサイクルは、DAS を使用して容易に制御できます。

クラスタにより、水平方向のスケーラビリティー、負荷分散、およびフェイルオーバー保護が使用可能になります。定義により、クラスタ内のすべてのインスタンスに対してリソースとアプリケーションの設定は同じになります。あるサーバーインスタンスまたはクラスタ内のあるマシンに障害が起きると、ロードバランサは障害を検出し、障害の起きたインスタンスからクラスタ内のほかのインスタンスにトラフィックをリダイレクトし、ユーザーセッションの状態を回復します。クラスタ内のすべてのインスタンス上には同一のアプリケーションとリソースがあるため、インスタンスはクラスタ内のほかのどのインスタンスにも処理を継続させることができます。

クラスタ、ドメイン、およびインスタンスの関係は次のようになります。

ノードエージェント

ノードエージェントは、DAS をホストするマシンを含め、サーバーインスタンスをホストするすべてのマシン上で実行される軽量プロセスです。ノードエージェントは次の機能を実行します。

各物理ホストには、ホストが属する各ドメインに対して少なくとも 1 つのノードエージェントが必要です。1 台の物理ホストに、複数のドメインに属するインスタンスを配置する場合、そのホストにはそれぞれのドメインに対するノードエージェントが必要です。ホスト上のドメインごとに複数のノードエージェントを持つことは許可されていますが、利点はありません。

ノードエージェントはサーバーインスタンスを起動および停止するため、常に実行中である必要があります。したがって、ノードエージェントはオペレーティングシステムの起動時に起動されます。Solaris およびその他の Unix プラットフォームでは、ノードエージェントを inetd プロセスによって起動できます。Windows では、ノードエージェントを Windows のサービスにすることができます。

ノードエージェントの詳細は、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 8 章「ノードエージェントの設定」を参照してください。

名前付き設定

「名前付き設定」は、Application Server のプロパティー設定をカプセル化する抽象化オブジェクトです。クラスタおよびスタンドアロンのサーバーインスタンスは、名前付き設定を参照してそれぞれのプロパティー設定を取得します。名前付き設定を使用することにより、IP アドレス、ポート番号、ヒープメモリー容量など一部の設定を除く Java EE コンテナの設定が、そのコンテナが位置する物理マシンから分離されます。名前付き設定を使用することにより、Application Server の管理をより強力に、また柔軟に行えるようになります。

設定変更を適用するには、単に名前付き設定のプロパティー設定を変更します。変更すると、その設定を参照するすべてのクラスタおよびスタンドアロンインスタンスが変更内容を取得します。名前付き設定の削除は、その設定へのすべての参照が削除済みの場合にしか行えません。1 つのドメインに複数の名前付き設定を含めることができます。

Application Server には、default-config という名称のデフォルト設定が付属します。デフォルト設定は、Application Server Platform Edition の場合は開発者の生産性を高めるように、Application Server Enterprise Edition の場合はセキュリティーと可用性を高めるように最適化されています。

デフォルト設定をベースにして独自の名前付き設定を作成し、その設定を目的に合わせてカスタマイズできます。名前付き設定の作成と管理には、管理コンソールおよび asadmin コマンド行ユーティリティーを使用します。

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

ロードバランサは、複数の物理マシン間で作業負荷を分散させることによって、システムの全体的なスループットを向上させます。Application Server Enterprise Edition には、Sun Java System Web Server、Apache Web Server、および Microsoft Internet Information Server 用のロードバランサプラグインが含まれます。

ロードバランサプラグインは、HTTP および HTTPS 要求を受け付け、それをクラスタ内のアプリケーションサーバーインスタンスのうちの 1 つに転送します。(ネットワーク障害により) インスタンスが停止して使用不能または応答不能になると、要求は既存の使用可能なマシンにリダイレクトされます。ロードバランサはまた、障害のあったインスタンスが復旧したことを認識し、それに応じて負荷を再配分することもできます。

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

システムで負荷分散を設定するには、Application Server に加えて、Web サーバーおよびロードバランサプラグインをインストールする必要があります。その後、次のことを行う必要があります。

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

asadmin コマンド行ツールを使用して、ロードバランサ設定を作成し、クラスタおよびサーバーインスタンスへの参照をその設定に追加し、クラスタでロードバランサによる参照を有効にし、アプリケーションで負荷分散を有効にし、必要に応じて健全性検査を作成し、ロードバランサ設定ファイルを生成し、最後に、ロードバランサ設定ファイルを Web サーバーの config ディレクトリにコピーします。管理者は、スクリプトを作成してこのプロセス全体を自動化できます。

詳細および完全な設定手順については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 5 章「HTTP 負荷分散の設定」を参照してください。

セッション持続性

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

セッション状態はデータベースに格納されるトランザクション状態ほど重要ではありませんが、サーバー障害の前後でセッション状態を保持することがエンドユーザーにとって重要な場合があります。Application Server は、このセッション状態をリポジトリに保存する (持続する) ための機能を提供します。ユーザーセッションをホストするアプリケーションサーバーインスタンスで障害が発生した場合、そのセッション状態の復元が可能です。情報を失うことなくそのセッションを継続できます。

Application Server は、次のタイプのセッション持続性ストアをサポートします。

メモリーを使用した持続性では、状態は常にメモリー内に保持され、障害が発生すると情報は失われます。HA 形式の持続性では、Application Server は HTTP セッションと SFSB セッションの両方で HADB を持続性ストアとして使用します。ファイルを使用した持続性では、Application Server はセッションオブジェクトを直列化し、それらのオブジェクトを、セッションマネージャーのプロパティーで指定されたファイルシステム上の位置に格納します。SFSB に関しては、HA 形式の持続性を指定しない場合、Application Server はこの位置の session-store サブディレクトリに状態情報を格納します。

保存が必要な変更がないかどうか、SFSB の状態をチェックする処理のことを「チェックポイント設定」と呼びます。チェックポイント設定を有効にした場合、この処理は通常、トランザクションがロールバックした場合を含め、SFSB が関係するすべてのトランザクションの完了後に発生します。ステートフルセッション Bean 開発の詳細は、『Sun Java System Application Server 9.1 Developer’s Guide』の「Using Session Beans」を参照してください。SFSB フェイルオーバーの有効化の詳細は、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の「ステートフルセッション Bean のフェイルオーバー」を参照してください。

Application Server がサービスを提供している要求の数とは別に、セッション持続性の設定は、各要求内のセッション情報だけでなく、HADB が 1 分あたりに受信する要求の数にも影響します。

セッション持続性の設定の詳細は、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

クラスタ内の IIOP 負荷分散

IIOP 負荷分散では、IIOP クライアントの要求が複数の異なるサーバーインスタンスまたはネームサーバーに分散されます。目標は、負荷をクラスタ間に均等に拡散して、スケーラビリティーを実現することです。IIOP 負荷分散と、EJB クラスタ化および Sun Java System Application Server の 可用性機能を組み合わせることにより、負荷分散に加えて EJB フェイルオーバーも実現されます。

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

たとえば、この図で示されている ic1、ic2、および ic3 は、クライアント 2 のコードで作成される 3 つの異なる InitialContext インスタンスです。それらはクラスタ内の 3 つのサーバーインスタンスに分散されます。そのため、このクライアントによって作成される EJB は 3 つのインスタンス間に分散されます。クライアント 1 が作成した InitialContext オブジェクトは 1 つだけであり、このクライアントからの Bean 参照はサーバーインスタンス 1 のみが対象です。サーバーインスタンス 2 が停止した場合、ic2 に対する検索要求は別のサーバーインスタンス (サーバーインスタンス 3 とは限らない) にフェイルオーバーされます。以前にサーバーインスタンス 2 でホストされていた Bean に対するすべての Bean メソッド呼び出しも、そのように処理するのが安全であれば、別のインスタンスに自動的にリダイレクトされます。検索のフェイルオーバーは自動的ですが、EJB モジュールは再試行が安全なときに限りメソッド呼び出しを再試行します。

RMI-IIOP 負荷分散とフェイルオーバーは、透過的に発生します。アプリケーションの配備中に、特別な手順は必要ありません。クラスタに新しいインスタンスを追加したり削除したりしても、そのクラスタに関する既存のクライアントの表示は更新されません。クライアント側で、端点の一覧を手動で更新する必要があります。

Message Queue と JMS リソース

Sun Java System Message Queue (MQ) は、分散アプリケーションのための、信頼性のある非同期メッセージングを提供します。MQ は Java Message Service (JMS) 標準を実装するエンタープライズメッセージングシステムです。MQ は、メッセージ駆動型 Beans (MDB) などの Java EE アプリケーションコンポーネントに対してメッセージングを提供します。

Application Server は Sun Java System Message Queue を Application Server に統合することにより Java Message Service (JMS) API を実装します。Application Server Enterprise Edition には、フェイルオーバー、クラスタ化、および負荷分散の各機能を持つ Enterprise バージョンの MQ が含まれます。

基本的な JMS 管理タスクには、Application Server の管理コンソールおよび asadmin コマンド行ユーティリティーを使用します。

Message Queue クラスタの管理など、高度なタスクの場合は、install_dir/imq/bin ディレクトリに用意されたツールを使用します。Message Queue の管理の詳細は、『Sun Java System Message Queue 管理ガイド』を参照してください。

メッセージフェイルオーバーのための JMS アプリケーションの配備および MQ クラスタ化の詳細は、「Message Queue ブローカの配備の計画」を参照してください。

高可用性データベース

この節では、次の項目について説明します。

概要

「セッション持続性」では、Java EE アプリケーションでのセッション持続性の必要性について説明しました。Application Server では、高可用性セッションストアとして高可用性データベース (HADB) を使用します。HADB は Application Server Enterprise Edition に含まれていますが、配備では独立したホスト上で実行できます。HADB は、HTTP セッションおよびステートフルセッション Bean データの高可用性データストアを提供します。

この分離型アーキテクチャーには、次のような利点があります。

注 –

HADB は Application Server による使用のために最適化されており、汎用データベースなどのアプリケーションによる使用は想定されていません。

HADB ハードウェアおよびネットワークシステムの要件については、『Sun Java System Application Server 9.1 リリースノート』の「ハードウェアとソフトウェアの要件」を参照してください。HADB で必要な追加のシステム構成手順については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 2 章「高可用性 (HA) データベースのインストールと設定」を参照してください。

システム要件

HADB ホストのシステム要件は次のとおりです。

ネットワーク構成の要件については、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 2 章「高可用性 (HA) データベースのインストールと設定」を参照してください。さらに高度な可用性を実現するための追加要件については、「二重障害の防止」を参照してください。

HADB のアーキテクチャー

HADB は、「ノード」のペアで構成される分散システムです。「データ冗長ユニット」で示すように、ノードは 2 つのデータ冗長ユニット (DRU) に分割され、1 つのノードは各 DRU 内の各ペアに属します。

各ノードは次の要素で構成されます。

HADB ノードの 1 つのセットが、1 つ以上の「セッションデータベース」をホストすることができます。各セッションデータベースは、個別のアプリケーションサーバークラスタと関連付けられます。クラスタを削除すると、関連付けられたセッションデータベースも削除されます。

HADB ハードウェアの要件については、『Sun Java System Application Server 9.1 リリースノート』の「ハードウェアとソフトウェアの要件」を参照してください。

ノードとノードプロセス

HADB ノードには、次の 2 種類があります。

各ノードには、1 つの親プロセスと複数の子プロセスがあります。ノードスーパーバイザー (NSUP) と呼ばれる親プロセスは、管理エージェントによって起動されます。このプロセスは、子プロセスの作成とその実行の継続の役割を果たします。

子プロセスには次のものがあります。

データ冗長ユニット

すでに説明したように、1 つの HADB インスタンスには DRU のペアが 1 つ含まれます。各 DRU には、もう一対の DRU と同数のアクティブノードとスペアノードが存在します。DRU 内の各アクティブノードに対し、もう一方の DRU 内に「ミラーノード」が存在します。ミラーリングにより、各 DRU がデータベースの完全なコピーを保持します。

次の図は、6 つのノードが存在するサンプルの HADB アーキテクチャーを示したものです。4 つのアクティブノードと 2 つのスペアノードが存在します。ノード 0 と 1 はミラーペアであり、ノード 2 と 3 も同様です。この例では、各ホストに 1 つのノードが存在します。一般に、ホストに十分なシステムリソースがあれば、複数のノードを 1 つのホストに共存させることができます (「システム要件」を参照)。

注 –

HADB ノードをホストするマシンは、ペアで (各 DRU に 1 台ずつ) 追加する必要があります。

HADB では、データおよびサービスをレプリケートすることによって高可用性を実現します。ミラーノード上のデータレプリカは、「プライマリレプリカ」および「ホットスタンバイレプリカ」として指定されます。プライマリレプリカは、挿入、削除、更新、読み取りなどの操作を実行します。ホットスタンバイレプリカは、プライマリレプリカの操作のログレコードを受信し、トランザクションの寿命内にそれらの操作を再実行します。読み取り操作はプライマリレプリカによってのみ実行されるため、ログに記録されません。各ノードにはプライマリレプリカとホットスタンバイレプリカの両方が含まれ、同じ役割を果たします。データベースは、DRU 内のアクティブノード間で断片化および分散されます。ミラーペア内の各ノードには、データフラグメントの同じ集合が含まれます。ミラーノードにデータを複製することを「レプリケーション」と呼びます。レプリケーションにより、HADB で高可用性を提供できます。あるノードで障害が発生した場合、ほとんど即時 (数秒以内) にそのミラーノードへの引き継ぎが行われます。レプリケーションにより可用性が保証され、データやサービスを失うことなくノードまたは DRU の障害が隠蔽されます。

障害が発生したノードの機能を引き継ぐとき、ミラーノードでは 2 つの作業を実行する必要があります。ミラーノード自体の作業と、障害が発生したノードの作業です。ミラーノードに十分なリソースがない場合、過負荷によってミラーノードのパフォーマンスが低下し、ミラーノードの障害の可能性も高まります。あるノードで障害が発生すると、HADB はそのノードの再起動を試みます。ハードウェアの故障などが原因で、障害が発生したノードが再起動しない場合、システムは動作を続けますが可用性は低下します。

HADB は 1 つのノード、DRU 全体、または複数のノードの障害に対する耐性を備えますが、ノードおよびそのミラーで障害が発生したときの「二重障害」への耐性はありません。二重障害の可能性を下げる方法の詳細は、「二重障害の防止」を参照してください。

スペアノード

あるノードで障害が発生すると、そのミラーノードが元のノードの役割を引き継ぎます。障害が発生したノードにスペアノードがない場合、この時点で、障害が発生したノードにミラーがないことになります。スペアノードは、障害が発生したノードのミラーを自動的に置き換えます。スペアノードを用意しておくことにより、ミラーノードのない状態でシステムを運用する時間を短縮できます。

スペアノードは通常時はデータを保持しませんが、DRU 内のアクティブノードの障害を常に監視しています。ノードで障害が発生し、指定された期間内に復旧しない場合、スペアノードはミラーノードからデータをコピーし、ミラーノードとの同期を行います。この処理にかかる時間は、コピーされるデータの量と、システムおよびネットワークの能力によって異なります。同期後は、手動操作なしで、スペアノードによって自動的にミラーノードが置き換えられます。その結果、ミラーノードの過負荷が防止され、ミラー上の負荷が分散されます。この処理のことを「フェイルバック」または「自己修復」と呼びます。

障害が発生したホストが、ハードウェアの切り替えまたはソフトウェアのアップグレードによって復旧および再起動した場合、元のスペアノードがこの時点でアクティブノードになっているため、そのホストで実行中の 1 つ以上のノードがスペアノードとしてシステムに参加します。

スペアノードは必須ではありませんが、1 台のマシンで障害が発生した場合でも、システムが全体的なサービスレベルを維持できるようにする効果があります。また、スペアノードを用意しておくことにより、アクティブノードのホストマシン上で計画的な保守を実施しやすくなります。スペアマシンの役割を果たす 1 台のマシンを各 DRU に割り当てて、マシンのうち 1 台で障害が発生した場合でも、HADB システムがパフォーマンスと可用性を低下させることなく運用を継続できるようにします。

注 –

原則として、十分な Application Server インスタンス数および HADB ノード数を持つスペアマシンが、使用不能になったマシンを代替するようにします。

スペアノード構成の例

HADB 配備でのスペアノードの使用例を次に示します。使用できる配備トポロジは 2 種類あります。「共存」トポロジでは HADB と Application Server を同じホストに配置し、「独立層」トポロジでは両者を別々のホストに配置します。配備トポロジの詳細は、第 3 章「トポロジの選択」を参照してください。

例: 共存構成

スペアノード構成の例として、4 台の Sun FireTM V480 サーバーを使用し、各サーバーに 1 つの Application Server インスタンスと 2 つの HADB データノードを配置する共存トポロジを考えます。

スペアノード用に、さらに 2 台のサーバーを割り当てます (各 DRU に 1 台ずつ)。各スペアマシンでは、1 つの Application Server インスタンスと 2 つのスペア HADB ノードを実行します。

例: 独立層構成

HADB 層に 2 台の Sun FireTM 280R サーバーを配置し、それぞれが 2 つの HADB データノードを実行する個別層トポロジを考えます。1 台のマシンが使用不能になった場合でもこのシステムの完全な能力を維持するには、Application Server インスタンス層と HADB 層のそれぞれに 1 台のスペアマシンを設定します。

Application Server インスタンス層のスペアマシンには、この層内のほかのマシンと同数のインスタンスが必要です。同様に、HADB 層用のスペアマシンには、この層内のほかのマシンと同数の HADB ノードが必要です。

二重障害の防止

HADB の組み込み型のデータレプリケーションにより、単一ノードまたは DRU 全体の障害に対する耐性を HADB に持たせることができます。デフォルトでは、HADB はミラーノードペアまたは両方の DRU で障害が発生した状況を指す「二重障害」を許容できません。そのような場合、HADB は使用不能になります。

前の節で説明したスペアノードの使用に加えて、次の手順に従うことにより、二重障害の可能性を最小化できます。

これらの手順は任意ですが、HADB インスタンスの全体的な可用性を高めます。

HADB 管理システム

HADB 管理システムは、組み込み型のセキュリティーを提供し、マルチプラットフォーム管理を促進します。次の図で示すように、HADB 管理アーキテクチャーには次のコンポーネントが含まれます。

図で示すように、HADB サービスを実行するすべてのマシン上で 1 つの HADB 管理エージェントが実行されます。各マシンは通常、1 つ以上の HADB ノードをホストします。Application Server ドメインと同様に、HADB 管理ドメインには多数のマシンが含まれます。データベースに耐障害性を持たせるには、ドメイン内に最低 2 台のマシンが必要であり、一般的には、DRU ペアを形成するために偶数のマシンを用意する必要があります。そのため、ドメインには多数の管理エージェントが含まれます。

図で示すように、ドメインには 1 つ以上のデータベースインスタンスを含めることができます。1 台のマシンに、1 つ以上のデータベースインスタンスに属する 1 つ以上のノードを含めることができます。

管理クライアント

HADB の「管理クライアント」はコマンド行ユーティリティー hadbm であり、HADB ドメインとそのデータベースインスタンスを管理するためのものです。HADB サービスは、関連付けられた Application Server クラスタが停止しているときでも実行を継続できますが、サービスを削除する場合は注意深くサービスをシャットダウンする必要があります。hadbm の使用方法の詳細は、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 3 章「高可用性データベースの管理」を参照してください。

asadmin コマンド行ユーティリティーを使用して、高可用性クラスタと関連付けられた HADB インスタンスを作成および削除できます。詳細は、『Sun Java System Application Server 9.1 高可用性 (HA) 管理ガイド』の第 9 章「高可用性 (HA) セッション持続性とフェイルオーバーの設定」を参照してください。

管理エージェント

HADB の管理エージェントは、ホスト上のリソースにアクセスできる ma という名前のサーバープロセスです。たとえば、このプロセスはデバイスの作成やデータベースプロセスの起動を実行できます。管理エージェントは、データベースインスタンスの起動や停止などの管理クライアントコマンドを調整および実行します。

管理クライアントは、エージェントのアドレスおよびポート番号を指定することによって管理エージェントに接続します。接続したあとは、管理クライアントは管理エージェントを通して HADB にコマンドを送信します。エージェントは要求を受け取って実行します。したがって、ホストに対して hadbm 管理コマンドを発行する前に、そのホスト上で管理エージェントが実行されている必要があります。管理エージェントは、自動的に起動するシステムサービスとして設定できます。

管理エージェントの可用性の保証

HADB ノードスーパーバイザープロセスに障害が起きると、管理エージェントプロセスを再起動して、その可用性を確保します。そのため、配備目的では、HADB の全体的な可用性を維持するために、ma プロセスの可用性を保証する必要があります。再起動のあと、管理エージェントはドメイン内のほかのエージェントからドメインおよびデータベースの設定データを復旧します。

管理エージェントの可用性を保証するには、ホストのオペレーティングシステム (OS) を使用します。Solaris または Linux では、プロセスの障害またはオペレーティングシステムの再起動のあと、init.d が ma プロセスの可用性を保証します。Windows では、管理エージェントは Windows サービスとして動作します。そのため、エージェントで障害が発生した場合や OS が再起動する場合、OS が管理エージェントを再起動します。

管理ドメイン

HADB の管理ドメインはホストの集合であり、各ホストでは同じポート番号で管理エージェントが実行されています。ドメイン内のホストには、1 つ以上の HADB データベースインスタンスを含めることができます。管理ドメインは、エージェントが使用する共通のポート番号と、ドメインを作成したりエージェントをドメインに追加したときに生成される「ドメインキー」と呼ばれる ID によって定義されます。管理エージェントはマルチキャストを使用して通信するため、ドメインの一意 ID を提供するドメインキーの役割は重要です。Application Server ドメインと一致するように、HADB 管理ドメインを設定できます。

複数のデータベースインスタンスを 1 つのドメインに含めると、複数の開発者グループが個別のデータベースインスタンスを使用できるため、この構成は開発環境で役立ちます。場合によっては、この構成は本番環境でも役立つことがあります。

エージェントの管理操作は、ドメインに属するすべてのエージェント間で協調されます。hadbm コマンドを使用してデータベース設定を変更すると、すべてのエージェントがそれに従って設定を変更します。ノードのホスト上の管理エージェントが実行されていない場合、ノードを停止または再起動できません。ただし、一部のエージェントが使用不能な場合でも、HADB 状態または設定変数の値を読み取る hadbm コマンドを実行できます。

管理ドメインを操作するには、次の管理クライアントコマンドを使用します。

リポジトリ

管理エージェントは、データベース設定を HADB の「リポジトリ」に格納します。リポジトリはすべての管理エージェント間でレプリケートされるため、高い耐障害性を備えています。サーバー上に設定を保持することにより、管理クライアントがインストールされている任意のコンピュータから管理操作を実行できるようになります。

リポジトリに対して何らかの変更を実行するには、ドメイン内の管理エージェントの大半が実行中である必要があります。したがって、ドメイン内に M 個のエージェントがある場合、リポジトリに変更を行うには、少なくとも M/2 + 1 (端数を切り捨てた整数値) 個のエージェントが実行中である必要があります。

ハードウェアの故障などが原因でドメイン内の一部のホストが使用不能であり、エージェント数不足のため一部の管理コマンドを実行できない場合は、hadbm disablehost コマンドを使用して、障害が発生したホストをドメインから削除します。

セットアップと設定のロードマップ

Procedure高可用性のために Application Server をセットアップおよび設定するには

  1. 第 2 章「配備の計画」の説明に従って、パフォーマンスおよび QoS の要件と目標を決定します。

  2. 第 2 章「配備の計画」の 「設計上の決定」の説明に従って、システムの規模を決定します。

    • Application Server インスタンスの数

    • HADB ノードおよび HADB ホストの数

    • HADB のストレージ容量

  3. 第 3 章「トポロジの選択」での説明に従って、システムトポロジを決定します。

    ここでは、Application Server と同じホストマシンまたは異なるマシンのどちらに HADB をインストールするかを決定します。

  4. HADB や Web サーバーなどの関連するサブコンポーネントとともに、Application Server インスタンスをインストールします。

  5. ドメインとクラスタを作成します。

  6. Web サーバーソフトウェアを設定します。

  7. ロードバランサプラグインをインストールします。

  8. 負荷分散をセットアップおよび設定します。

  9. HADB ノードおよび DRU をセットアップおよび設定します。

  10. HA セッション持続性のために AS Web コンテナおよび EJB コンテナを設定します。

  11. アプリケーションを配備し、高可用性およびセッションフェイルオーバーのために設定します。

  12. メッセージを多く利用する場合、フェイルオーバーのために JMS クラスタを設定します。

    詳細は、『Sun Java System Message Queue 管理ガイド』を参照してください。