test

Sun GlassFish Communications Server 1.5 配備計画ガイド

第 1 章 製品概念

Sun GlassFish Communications Server は、Java EE の統合および SIP アプリケーションの開発、融合、および管理のための堅牢なプラットフォームを提供します。主な機能には、スケーラブルトランザクション管理、Web サービスパフォーマンス、クラスタ化、セキュリティー、および統合機能があります。

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

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

Communications Server は、Java 2 Enterprise Edition (Java EE) 1.4 テクノロジを実装します。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 アプリケーションにアクセスできます。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 のコンポーネントについて説明します。

まず、ブラウザベースの管理コンソールなどの管理ツールがドメイン管理サーバー (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 GlassFish Communications Server 1.5 管理ガイド』の「ドメイン管理サーバーの再作成」を参照してください。

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 GlassFish Communications Server 1.5 High Availability Administration Guide』の第 4 章「ノードエージェントの設定」を参照してください。

名前付き設定

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

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

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

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

融合ロードバランサ

ロードバランサは、複数の物理マシン間で作業負荷を分散させることによって、システムの全体的なスループットを向上させます。

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

クラスタ内の 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 を実装します。Communications Server には、フェイルオーバー、クラスタ化、および負荷分散機能を備えた、Enterprise バージョンが含まれています。

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

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

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