HTTP バインディングコンポーネントのクラスタ化サポート

クラスタは、0 個以上のサーバーインスタンスを含んでいる論理エンティティーです。簡単に言えば、クラスタはアプリケーションサーバーインスタンスの集まりであり、クラスタ化されたアプリケーションインスタンス全体に作業負荷を分散してパフォーマンスを最適化できます。このようなサーバーインスタンスは、同じアプリケーション、リソース、および設定情報を共有します。クラスタ化されたサーバーインスタンスは、1 つのクラスタだけに属し、すべてをその親クラスタから継承します。クラスタ内のインスタンスは、任意の数のコンピュータに分散している可能性があります。

Sun Java System Application Server では、単一のホストまたは複数のホストにインストールされた同種の (同じ JBI コンポーネント、アプリケーション、および設定情報を持つ) アプリケーションサーバーインスタンスをクラスタ化できます。各アプリケーションサーバーインスタンスで実行されるアプリケーションは独立していますが、Web ブラウザベースの (DAS) クライアントまたはコマンド行クライアントを介した管理インフラストラクチャーによって管理することもできます。

HTTP ロードバランサ

HTTP ロードバランサは、HTTP 要求および HTTPS 要求を受け入れ、それらをクラスタ内のアプリケーションサーバーインスタンスに分散する、Web サーバープラグインです。これにより、HTTP バインディングコンポーネントを水平に拡大縮小して、Sun Java System Application Server クラスタ内の複数のインスタンスで実行することができます。

クラスタ化には、次のような多数の利点があります。

• 複数の物理的マシンに作業負荷を分散することにより、全体的なシステムスループットが増加します

• 各サーバーのハードウェア容量が異なる場合は、より強力なホストに優先的に作業負荷を分散することができます

• ある特定のアプリケーションサーバーインスタンスが過負荷または使用不可の状態になった場合、もっとも負荷の少ないアプリケーションサーバーインスタンスに要求を再ルーティングできます

• クラスタ化はクライアントには意識されません。クライアントに関するかぎり、HTTP 要求はすべて、ロードバランサが設定されている Web サーバーインスタンスに送信されます

HTTP ロードバランサには次の機能があります。

• スティッキーラウンドロビン負荷分散アルゴリズム

• 複数クラスタのサポート

• 設定可能な健全性フェイルオーバー機能 (30 ミリ秒未満)

• ロードバランサに動的に加えられた変更の確認と再読み込み

• 静止化のサポート - Web サービスのローリングアップグレードを可能にします

• べき等 URL に対する失敗した要求の自動再試行

• 設定可能なエラーページ

HTTP バインディングコンポーネントをクラスタ化用に設定する

HTTP バインディングコンポーネントをクラスタ化用に設定する処理の大部分は、Sun Java System Application Server (GlassFish) によって行われます。HTTP バインディングコンポーネントは、アプリケーションサーバーにインストール済みのコンポーネントです。デフォルトの HTTP および HTTPS ポート番号は、バインディングコンポーネントがサーバーインスタンスにインストールされたときに計算され、事前に割り当てられています。HTTP バインディングコンポーネントによって提供される Web サービスは、「http://<hostname>:<port>/<context>」という構造の一意の URL 識別子で識別されます。

クラスタ内の各コンポーネントインスタンスはリソースに対して排他的アクセスを持つ必要があるため、各コンポーネントインスタンスに一意のポート番号が割り当てられます。コンポーネントが各インスタンスに配備されるときに、WSDL アーティファクトで定義済みのトークン名を使用して、実際のポート値が解決されます。

定義済み HTTP ポートトークン

定義済みトークンの名前は次のとおりです。

• HTTP ポートの場合は ${HttpDefaultPort}

• HTTPS ポートの場合は ${HttpsDefaultPort}

これらのトークンは、アプリケーションクライアントが HTTP 要求をデフォルトポートに送信できるように、エンドポイント URL (soap:address) で実際のポート番号の代わりに使用されます。その後、アプリケーションの配備時に、トークンの値は設定されているデフォルト値に基づいて HTTP バインディングコンポーネントによって解決されます。

HTTP バインディングコンポーネントを再インストールした場合、各コンポーネントインスタンスのデフォルトポートを適切に設定する必要があります。

${HttpDefaultPort} トークンについて

ここでは、${HttpDefaultPort} トークンの概略と、アプリケーションの配備時にこれがどのように解決されるかについて説明します。

GlassFish Web サービスは常に指定の HTTP ポート (設定済みのデフォルトは 8080) に配備されますが、それと同様に HTTP バインディングコンポーネントにも、Web サービスが配備されるデフォルトの HTTP ポートがあります。HTTP バインディングコンポーネントは GlassFish にインストール済みのコンポーネントとして付属しているため、デフォルトの HTTP ポートが常に割り当てられています。デフォルトポートは、GlassFish のインストール時に JBI ランタイムモジュールで設定されます。その際、GlassFish ドメイン内の各 HTTP バインディングコンポーネントインスタンスに、使用可能なポートが割り当てられます。

最初、このデフォルトポート設定と ${HttpDefaultPort} トークンは、クラスタ化をサポートするために WSDL URL に置かれ、同じマシンで複数の HTTP BC インスタンスを実行できるようになっていました。そのため、各インスタンスに割り当てられたポートの実際のポート値は、衝突が発生しないように、アプリケーションの配備時にポートトークンを使用して解決されます。

それ以降、ポートの使用法が発展して、HTTP バインディングコンポーネント (JBI の Web サービスコンテナ) は GlassFish Web サービスコンテナと同様の動作をするようになりました。アプリケーションがバインディングコンポーネントに「到着」すると、バインディングコンポーネントはそのデフォルトの HTTP ポート設定を検索し、URL 内のトークンを実際のポート番号で置き換えます。デフォルトのポート番号が設定されていない場合は、「初期化失敗」例外がスローされます。