クラスターおよびワークロード管理
クラスターとは、まとめて管理され、ワークロード管理の対象となるサーバーの集合です。 クラスターにより、エンタープライズ・アプリケーションは、 単一のアプリケーション・サーバーで実行できるスループット量を上回ることが可能になります。また、クラスターによって、エンタープライズ・アプリケーションの高可用性も可能になります。これは、障害が発生した際に、要求が稼働中のサーバーに自動的に経路指定されるためです。 クラスターのメンバーであるサーバーは、異なるホスト・マシン上に存在させることも可能です。 これとは対照的に、同じノードの一部であるサーバーは、同じホスト・マシン上になければなりません。 セルには、クラスターが全くないか、クラスターが 1 つあるか、または複数のクラスターがあるかのいずれかです。
クラスターに属するサーバーはそのクラスター・セットのメンバーで、 それらのサーバーすべてに、同一のアプリケーション・コンポーネントをデプロイする必要があります。 クラスターのメンバーは、 そのサーバーで実行されるように構成されるアプリケーション以外の他のどの構成データも共有する必要がありません。 あるクラスターのメンバーが巨大なマルチプロセッサー・エンタープライズ・サーバー・システム上で 稼働している一方で、同じクラスターの別メンバーはより小さいシステムで稼働していることもあります。 これらの 2 つのクラスター・メンバーのサーバー構成設定値は、かなり異なっています。 ただし、両者に割り当てられるアプリケーション・コンポーネントの領域は例外です。構成内のこの領域では、両者は同一です。 これにより、すべてのワークロードが 1 つのアプリケーション・サーバーによって処理されるのではなく、 クライアントの作業をクラスターのすべてのメンバーに分散することが可能になります。
クラスターを作成する際に、既存のアプリケーション・サーバーのテンプレートをコピーします。 このテンプレートは通常、既に構成済みのアプリケーション・サーバーであると考えられます。 そのサーバーをクラスターのメンバーにするというオプションが提供されています。 しかし、そのサーバーをテンプレートとしてのみ使用できるようにしておくことをお勧めします。 その理由は、クラスター・メンバーを除去するには、アプリケーション・サーバーを削除する以外に方法がないためです。 クラスターを削除すると、そのクラスターのメンバーであるアプリケーション・サーバーもすべて削除されます。 クラスターのいかなるメンバーも保存する方法はありません。 オリジナル・テンプレートを元のまま保持することにより、 構成の再ビルドが必要になった場合、そのテンプレートを再利用できます。
垂直クラスターでは、同一ノード、 または物理マシン上にクラスター・メンバーがあります。 水平クラスターでは、 セル内の多くのマシンにまたがる複数ノード上にクラスター・メンバーがあります。 どちらのタイプのクラスターも構成できますし、 垂直クラスターと水平クラスターの組み合わせを持つこともできます。
Web コンテナーをホストするアプリケーション・サーバーのクラスタリングは、アプリケーション・サーバーのプラグイン・ワークロード管理、およびそれらがホストするサーブレットを自動的に使用可能にします。サーブレット要求のルーティングは、HTTP トランスポートまたは HTTP トランスポート・チャネルを使用して、Web サーバー・プラグインとクラスター済みアプリケーション・サーバー間で発生します。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)

このルーティングは、クラスター・メンバーに関連したウェイトを基にしています。すべてのクラスター・メンバーが同一のウェイトを持つ場合、
強類縁構成は存在しないと想定して、プラグインはすべてのクラスター・メンバーに等しい要求を送信します。
ウェイトがゼロから 20 までの範囲でスケーリングされる場合、
プラグインは通常、より高いウェイト値でこれらのクラスター・メンバーへ要求を送付します。
管理コンソールを使用して、 クラスター・メンバーのウェイトを指定できます。 クラスター・メンバーに割り当てるウェイトは、 そのおおよその作業能力に比例している必要があります。 特定のメンバーに指定されたウェイト値は、クラスター内の他のメンバーに指定したウェイトのコンテキストにおいてのみ意味を持ちます。 ウェイト値は、絶対的な能力を示すものではありません。クラスター・メンバーが使用不可になっている場合、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 つのクラスター・メンバーが稼働していている限り、 クライアント要求の処理は続行されます。
バックアップ・クラスターは、1 次クラスターの
すべてのメンバーが使用不可になっても、引き続き機能します。