クラスターは、まとめて管理されている一連のサーバーであり、ワークロード管理に参加します。 クラスターにより、エンタープライズ・アプリケーションは、 単一のアプリケーション・サーバーで実行できるスループット量を上回ることが可能になります。また、障害発生時に要求が稼働中のサーバーに自動的に送信されるため、 クラスターはエンタープライズ・アプリケーションの高可用性も可能にします。 クラスターのメンバーであるサーバーは、別々のホスト・マシン上に存在することができます。これとは対照的に、同じノードの一部であるサーバーは、同じホスト・マシン上になければなりません。 セルには、クラスターが全くないか、クラスターが 1 つあるか、または複数のクラスターがあるかのいずれかです。
クラスターに属するサーバーはそのクラスター・セットのメンバー で、 それらのサーバーすべてに、同一のアプリケーション・コンポーネントをデプロイする必要があります。 クラスターのメンバーは、 そのサーバーで実行されるように構成されるアプリケーション以外の他のどの構成データも共用する必要がありません。 あるクラスターのメンバーが巨大なマルチプロセッサー・エンタープライズ・サーバー・システム上で 稼働している一方で、同じクラスターの別メンバーはより小さいシステムで稼働していることもあります。 これらの 2 つのクラスター・メンバーのサーバー構成設定値は、かなり異なっています。 ただし、両者に割り当てられるアプリケーション・コンポーネントの領域は例外です。構成内のこの領域では、両者は同一です。 これにより、すべてのワークロードが 1 つのアプリケーション・サーバーによって処理されるのではなく、 クライアントの作業をクラスターのすべてのメンバーに分散することが可能になります。
クラスターを作成する際に、既存のアプリケーション・サーバーのテンプレートをコピーします。 このテンプレートは通常、すでに構成済みのアプリケーション・サーバーであると考えられます。 そのサーバーをクラスターのメンバーにするというオプションが提供されています。 しかし、そのサーバーをテンプレートとしてのみ使用できるようにしておくことをお勧めします。 その理由は、クラスター・メンバーを除去するには、アプリケーション・サーバーを削除する以外に方法がないためです。 クラスターを削除すると、そのクラスターのメンバーであるアプリケーション・サーバーもすべて削除されます。 クラスターのいかなるメンバーも保存する方法はありません。 オリジナル・テンプレートを元のまま保持することにより、 構成の再ビルドが必要になった場合、そのテンプレートを再利用できます。
垂直クラスター では、同一ノード、 または物理マシン上にクラスター・メンバーがあります。 水平クラスター では、 セル内の多くのマシンにまたがる複数ノード上にクラスター・メンバーがあります。 どちらのタイプのクラスターも構成できますし、 垂直クラスターと水平クラスターの組み合わせを持つこともできます。
管理コンソールを使用して、 クラスター・メンバーのウェイトを指定できます。 クラスター・メンバーに割り当てるウェイトは、 そのおおよその作業能力に比例している必要があります。 特定のメンバーに指定されたウェイト値は、クラスター内の他のメンバーに指定したウェイトのコンテキストにおいてのみ意味を持ちます。 ウェイト値は、絶対的な能力を示すものではありません。クラスター・メンバーが使用不可になっている場合、Web サーバー・プラグインは一時的にそのクラスター・メンバーを迂回して要求をルーティングします。
例えば、2 つのメンバーで構成されるクラスターがある場合、1 および 2 というウェイトを割り当てると、最初のメンバーはワークロードの約 1/3 を受け取り、2 番目のメンバーはワークロードの約 2/3 を受け取ります。しかし、クラスターに第 3 のメンバーを追加し、その新規メンバーに 1 というウェイトを割り当てると、最初のメンバーに割り当てられるワークロードは約 1/4 に、2 番目のメンバーに割り当てられるワークロードは約 1/2 に、そして 3 番目のメンバーに割り当てられるワークロードは約 1/4 になります。最初のクラスター・メンバーが使用不可になった場合は、2 番目のメンバーがワークロードの約 2/3 を受け取り、3 番目のメンバーはワークロードの約 1/3 を受け取ります。
ウェイト値は、ロード・バランスの目標の目安にすぎません。それ以外にも、特定の要求の送信先を決定する際の要素でもあるアプリケーション依存性として、スレッドの並行性、ローカル設定、類縁性、リソースの可用性などがあります。そのため、特定のクラスター・メンバーにウェイトの割り当てを決定する場合は、厳密な要求パターンを使用しないでください。
EJB コンテナーのワークロード管理は、別個のアプリケーション・サーバー上で Web コンテナーおよび EJB コンテナーを構成することによって実行することができます。 EJB コンテナーを使用して、 複数のアプリケーション・サーバーをクラスター化できます。 これにより、さまざまなアプリケーション・サーバー上の EJB コンテナー間で、 エンタープライズ Bean 要求を配布できるようになります。
この構成では、EJB クライアント要求は、割り当てられたサーバーのウェイトに基づく ラウンドロビン方式で、使用可能な EJB コンテナーに送付されます。EJB クライアントは、 Web コンテナー、RMI/IIOP を使用するスタンドアロン Java プログラム、または他の EJB 内で 作動するサーブレットとすることができます。
サーバー加重ラウンドロビン・ルーティング・ポリシーは、 クラスターのメンバーに割り当てられたサーバーのウェイトのセットに基づく、バランスの取れたルーティング配布を保証します。 例えば、クラスター内のすべてのサーバーに同じウェイトがある場合、 予想されるクラスターへの配布は、すべてのサーバーが同数の要求を受け入れることです。 サーバーのウェイトが等しくない場合、 配布メカニズムは、ウェイト値の低いサーバーよりも、ウェイト値の高いサーバーへ より多くの要求を送信します。このポリシーは、クラスター・メンバーに割り当てられたウェイトに基づき、 望ましい配布を保証します。
ワークロード管理をセットアップすると、 異なるクラスター間でタスクのバランスを取ることができます。
クライアントが優先ルーティングとして存在するノードへ要求が送信されることを選択できます。 この場合、(ラウンドロビン・ウェイト・メソッドを使用して) そのノード上のクラスター・メンバーだけが選択されます。 ローカル・サーバーが使用可能でない場合のみ、リモート・ノード上のクラスター・メンバーが選択されます。
同一のクライアント要求を処理できる複数のサーバーが、フェイルオーバーのサポートの基本を形成します。 クライアント要求の処理中にサーバーで障害が発生した場合、 失敗した要求はクラスター内の別の任意のメンバーに再ルーティングすることができます。 複数のサーバーで障害が発生しても、 少なくとも 1 つのクラスター・メンバーが稼働していている限り、 クライアント要求の処理は続行されます。