test

Sun GlassFish Communications Server 2.0 管理ガイド

Communications Server の概念

Communications Server は、1 つまたは複数のドメインから構成されます。ドメインは管理上の境界であり、コンテキストです。各ドメインには管理サーバー (ドメイン管理サーバーまたは DAS とも呼ばれる) が関連付けられ、0 またはそれ以上のスタンドアロンインスタンスまたはクラスタ、あるいはその両方から構成されています。各クラスタには、1 つ以上の同機種サーバーインスタンスが含まれます。サーバーインスタンスは、単一の物理マシンで Application Server を実行する単一の Java 仮想マシン (JVM) です。ドメイン内のサーバーインスタンス (スタンドアロンでもクラスタ構成でも) は異なる物理ホストで実行できます。

ここでは、次の内容について説明します。

ドメイン

ドメインは同時に管理されるインスタンスのグループです。ただし、アプリケーションサーバーインスタンスは 1 つのドメインにのみ属することができます。管理上の境界線であることに加え、ドメインは基本的なセキュリティー構造を提供し、これによってさまざまな管理者がアプリケーションサーバーインスタンスの特定のグループ (ドメイン) を管理できます。サーバーインスタンスを個別のドメインにグループ化することにより、さまざまな組織や管理者が 1 つの Communications Server インストールを共有できます。各ドメインには、固有の設定、ログファイル、およびアプリケーションの配備領域があり、これらはほかのドメインとは無関係です。1 つのドメインの設定が変更されても、ほかのドメインの設定は影響を受けません。

Sun GlassFish Communications Server インストーラにより、デフォルトの管理ドメイン (domain1 という名前) が作成されます。さらに、関連するドメイン管理サーバー (server という名前) も作成されます。インストール時には管理サーバーポート番号を指定する必要があります。デフォルトの管理サーバーポートは 4848 です。インストーラは、管理ユーザー名とマスターパスワードの入力も要求します。インストール後は、管理ドメインを作成して追加できます。

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

各ドメインは、一意のポート番号を持ったドメイン管理サーバー (DAS) を持っています。管理コンソール は特定の DAS と通信し、関連するドメインを管理します。管理コンソール の各セッションにより、特定のドメインを設定し、管理できます。

ドメイン管理サーバー (DAS) は管理対象アプリケーションの制御専用に設計されたアプリケーションサーバーインスタンスです。DAS は管理者を認証し、管理ツールからの要求を受け付け、ドメイン内のサーバーインスタンスと通信して要求を実行します。DAS は管理サーバーまたはデフォルトサーバーと呼ばれることもあります。デフォルトサーバーと呼ばれる理由は、Sun GlassFish Communications Server のインストール時に作成される唯一のサーバーインスタンスで、配備に使用できるからです。DAS は単に追加の管理機能を備えたサーバーインスタンスです。

管理コンソール の各セッションでは、単一のドメインを設定し、管理できます。複数のドメインを作成している場合は、追加の 管理コンソール セッションを起動して、ほかのドメインを管理する必要があります。管理コンソール の URL を指定する場合は、管理するドメインに関連付けられた DAS のポート番号を使用してください。

プロファイル

すべての管理ドメインは、そのドメインの機能を特定するプロファイルに関連付けられます。Communications Server には次のプロファイルが用意されています。

ドメインは、事前に設定されたランタイムをユーザーアプリケーションに提供します。プロファイルにより、インストールされた Application Server 自体の実行バイナリと、実行環境の設定を区別しやすくなります。つまり、プロファイルにより、Communications Server の 1 つの実行バイナリを使用して、特定のニーズに合った異なるドメインを作成できます。たとえば、場合によっては最新の Java EE 仕様を理解するために Communications Server を使用する開発者もいます。そのような開発者には、厳格なセキュリティー設定は必要ありません。一方、本稼動環境でアプリケーションを配備するユーザーには、当然ながらセキュリティー保護された環境が必要です。

表 1–1 に、各プロファイルで使用できる機能の一覧を示します。

表 1–1 各プロファイルで使用できる機能

機能 

開発者プロファイル 

クラスタプロファイル 

エンタープライズプロファイル (Sun GlassFish Communications Server では使用不可) 

セキュリティーストア 

JKS 

JKS 

NSS 

クラスタ化/スタンドアロンインスタンス 

使用不可 

利用可能 

利用可能 

セキュリティーマネージャー 

無効 

有効 

有効 

HADB 

使用不可 

使用不可 

利用可能 

負荷分散 

使用不可 

利用可能 

利用可能 

ノードエージェント 

使用不可 

利用可能 

利用可能 

クラスタ

クラスタ は、一連の同じアプリケーション、リソース、および設定情報を共有するサーバーインスタンスの集まりに名前を付けたものです。1 つのサーバーインスタンスは 1 つのクラスタにのみ属することが可能です。クラスタを使用すると、複数のマシン間で負荷が分散されることによって、サーバーインスタンスのロードバランスが容易になります。また、インスタンスレベルのフェイルオーバーによって、高可用性を実現します。管理上の観点では、クラスタは仮想エンティティーを表し、クラスタへの操作 (アプリケーションの配備など) は、そのクラスタを構成するすべてのインスタンスに反映されます。

クラスタに Communications Server インスタンスを追加することで水平方向への拡張が実現され、それによってシステムの処理能力が向上します。サービスを中断せずに、クラスタに Communications Server インスタンスを追加することができます。HTTP、RMI/IIOP、および JMS のロードバランスにより、クラスタ内の正常な Communications Server インスタンスに要求を分散させます。

高可用性 - 可用性を有効にすると、クラスタ内の Communications Server インスタンスをフェイルオーバーによって保護できます。1 つのアプリケーションサーバーインスタンスが停止すると、利用できなくなったサーバーに割り当てられていたセッションは別の Communications Server インスタンスに引き継がれます。セッション情報は、セッションレプリケーション機能を使用するか、高可用性データベース (HADB) を使用して保存されます。HADB は、持続的な HTTP セッションとステートフルセッション Beans をサポートします。

ノードエージェント

インスタンスのリモートライフサイクル管理を容易にするには、ドメインの各ノードに、軽量エージェント (JMX ランタイムのみで稼動できるなど) が必要です。この主な目的は、DAS の指示どおりに、サーバーインスタンスを起動、停止、作成することです。さらに、ノードエージェントはウォッチドッグとして機能し、障害の発生したプロセスを再起動します。DAS と同様に、ノードエージェントは特定の管理操作にのみ必要で、高可用性を期待するべきではありません。ただし、ノードエージェントは「常時稼働」コンポーネントであるため、ネィティブ O/S ノードブートストラップ (Solaris/Linux inetd または Windows サービスとしてなど) によって起動するように設定する必要があります。ノードエージェントは DAS には必要ありません。

サーバーインスタンス

サーバーインスタンスは、単一のノードの Communications Server 上で稼動する単一の Java EE 互換 Java 仮想マシン (JVM) です。ドメインの各サーバーインスタンスは一意の名前を持ちます。クラスタ化されたサーバーインスタンスはクラスタのメンバーであり、親クラスタからすべてのアプリケーション、リソース、および設定を受け取るため、クラスタのすべてのインスタンスは均一になります。クラスタ化されていないサーバーインスタンスはクラスタに属さないため、アプリケーション、リソース、および設定で独立したセットを使用します。次の図は、アプリケーションサーバーインスタンスの詳細を示しています。アプリケーションサーバーインスタンスは、Communications Server のクラスタリング、ロードバランス、セッションの持続性といった各機能の基本を構成するものです。

図 1–1 Communications Server インスタンス

図は、サーバーインスタンスの機能と、サーバーインスタンスがさまざまなクライアント、データベース、およびその他のサーバーやシステムと通信する様子を示している。

Sun GlassFish Communications Server は、インストール時に server という名前のアプリケーションサーバーインスタンスを作成します。多くのユーザーは、1 つのアプリケーションサーバーインスタンスがあれば、要件は満たされるでしょう。ただし、環境によっては、1 つ以上の追加のアプリケーションサーバーインスタンスを作成する場合があります。たとえば、開発環境で、異なるアプリケーションサーバーインスタンスがあれば、異なる Communications Server 設定でテストしたり、異なるアプリケーション配備を比較およびテストしたりすることができます。アプリケーションサーバーインスタンスは簡単に追加または削除できるため、これらを使用して、一時的にサンドボックス領域を作成して試用することができます。

さらに、各アプリケーションサーバーインスタンスに対して、仮想サーバーを作成することもできます。単一のインストールされているアプリケーションサーバーインスタンス内で、企業または個人のドメイン名、IP アドレス、いくつかの管理機能を提供できます。ユーザーにとっては、ハードウェアを持つことも、サーバーの基本的な保守を行うこともなく、自分の Web サーバーを所有しているのとほぼ同じです。このような仮想サーバーは、複数のアプリケーションサーバーインスタンスにまたがりません。仮想サーバーの詳細は、第 13 章HTTP サービスの設定を参照してください。

運用上において、複数のアプリケーションサーバーインスタンスの代わりに仮想サーバーをさまざまな用途に応じて使用できます。ただし、仮想サーバーがニーズを満たさない場合、複数のアプリケーションサーバーインスタンスを使用することも可能です。アプリケーションサーバーインスタンスを停止すると、そのアプリケーションサーバーインスタンスは新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。マシンがクラッシュしたり、オフラインになったりすると、サーバーは終了し、処理中の要求が失われる可能性があります。

Communications Server のポート

次の表に、 Communications Server のポートリスナーを示します。

表 1–2 ポートを使用する Communications Server リスナー

リスナー  

デフォルトのポート番号  

説明  

管理サーバー 

4848 

 

ドメイン管理サーバーには、管理コンソールと asadmin ユーティリティーを使ってアクセスします。管理コンソールには、ブラウザの URL にポート番号を指定します。リモートから asadmin コマンドを実行する場合は、--port オプションを使用してポート番号を指定します。

HTTP 

8080 

サーバーはポート上で HTTP 要求を待機します。配備された Web アプリケーションとサービスにアクセスするために、クライアントはこのポートに接続します。 

HTTPS 

8181 

セキュリティー保護された通信用に設定された Web アプリケーションは、個別のポートで待機します。 

IIOP 

3700 

EJB コンポーネントであるエンタープライズ Beans のリモートクライアントは IIOP リスナー経由で Beans にアクセスします。 

IIOP_SSL 

3820  

セキュリティー保護された通信用に設定された IIOP リスナーは、ほかのポートを使用します。 

IIOP_MUTUALAUTH 

3920  

相互 (クライアントおよびサーバー) 認証用に設定された IIOP リスナーは、もう一方のポートを使用します。 

SIP 

5060 

サーバーはポート上で SIP 要求を待機します。 

SIPS 

5061 

セキュリティー保護された通信用に設定された SIP および融合アプリケーションは、個別のポートで待機します。 

JMX_ADMIN 

8686 

 

JMS 

7676