test

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

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 ブローカの配備の計画」を参照してください。