概要: クラスター
クラスターは、まとめて管理されている一連のサーバーで、ワークロード管理の対象です。 クラスターには、ノードまたは個々のアプリケーション・サーバーを組み込むことができます。 ノードは通常、1 つ以上のアプリケーション・サーバーを実行する識別可能なホスト IP アドレスを持つ、 物理的なコンピューター・システムです。 クラスターは、セル構成でグループ化することができます。 これによって、異なる構成の多数のサーバーとクラスター、およびアプリケーションは、 管理者の判断と、組織環境に応じて、相互に論理的に関連付けされます。
クラスターは、サーバー間でのワークロードの平衡化を行います。 クラスターの一部であるサーバーは、クラスター・メンバー と呼ばれます。 クラスターにアプリケーションをインストールすると、アプリケーションはそれぞれのクラスター・メンバーに自動的にインストールされます。アプリケーション・サーバーでサービス統合またはメッセージ駆動型 Bean を使用してワークロード・バランシングを提供するようにクラスターを構成できます。
それぞれのクラスター・メンバーには、同一アプリケーションが含まれるため、
それぞれのサーバーに重みを割り当てることによって、異なるマシンの能力に応じて分散プラットフォームにクライアント・タスクを分散できます。
分散プラットフォームでは、クラスター内のサーバーに重みを割り当てることによって、パフォーマンスとフェイルオーバーが向上します。
タスクは、そのタスク操作を実行する能力を持つサーバーに割り当てられます。1 つのサーバーがそのタスクを実行できない場合には、他のクラスター・メンバーに割り当てられます。
この再割り当て機能は、要求が多すぎる場合に過負荷になる可能性がある単一アプリケーション・サーバーの実行に比べると、明確な利点があります。
クラスター始動プロセス・オプション
通常のランタイム処理では、 サーバー始動プロセス時にすべてのサーバー・コンポーネントが自動的に始動されます。この処理は、 クラスターの一部であるサーバーを含む、すべてのサーバーに適用されます。ただし、サーバー始動プロセス中にサーバー・コンポーネントのすべてを始動するわけではないように、 クラスター・メンバーであるサーバーを含めて、サーバーを構成できます。この機能では、サーバーが必要に応じてリソースを消費するため、 占有スペースがより小さくてより管理しやすくなり、通常、パフォーマンスが向上します。
クラスターまたは特定のクラスター・メンバーが始動したときに クラスター・メンバー・コンポーネントのすべてが始動するわけではないようにクラスター・メンバーを構成する場合、 クラスター・メンバー・コンポーネントは必要に応じて動的に始動されます。例えば、 特定のサーバー・コンポーネントを必要とするアプリケーション・モジュールが始動する場合、 そのコンポーネントは動的に始動します。
クラスターおよびノード・グループ
クラスターにインストールするアプリケーションは、そのクラスターのメ ンバーである任意のアプリケーション・サーバーで実行できなければなりません。 ノード・グループがクラスターの境界を形成するという理由から、 クラスターのすべてのメンバーは同じノード・グループのメンバーでなければなりません。 したがって、正常に実行するためにデプロイするアプリケーションでは、クラスターのすべてのメンバーが、そのアプリケーションの要件に適合するノードに配置されている必要があります。
多くの異なるサーバー構成を持つセルでは、ご使用のアプ リケーションをホストする機能を持っているノードを判別するのが難しい場合 があります。 ノード・グループを使用して、特定のクラスターのメンバーを ホストするのに十分共通性があるノードのグループを定義することができます。 クラスターのすべてのクラスター・メンバーは、同じノード・グループに属していなければなりません。
すべてのノードは少なくとも 1 つのノード・グループのメンバーです。クラスターを作成すると、 クラスターに最初に追加するアプリケーション・サーバーによって、 その他のクラスター・メンバーすべてが属す必要のあるノード・グループが定義されます。 クラスターに追加する他のクラスター・メンバーはすべて、この同じノ ード・グループのメンバーであるノードにのみ属することができます。 管理コンソールで新規クラスター・メンバーを作成する場合は、そのクラスターのノード・グループのメンバーであるノードにのみ、アプリケーション・サーバーを作成できます。
ノードは、複数のノード・グループのメンバーである場合があります。クラスターに追加する最初のクラ スター・メンバーに複数のノード・グループが定義されている場合、システ ムはクラスターの境界となるノード・グループを自動的に選択します。クラスター設定を変更してノード・グループを変更することができます。 「Server cluster settings」ページを使用すると、ノード・グループを変更できます。
クラスターおよびコア・グループ
HA 環境では、クラスターのグループは、コア・グループ として定義できます。コア・グループに含まれるクラスターの 1 つのメンバーとして定義されたアプリケーション・サーバーはすべて、自動的にそのコア・グループのメンバーになります。 クラスターのメンバーではない個々のアプリケーション・サーバーも、コア・グループのメンバーとして定義できます。 コア・グループを使用することによって、WebSphere® Application Server は、 エンド・ユーザーに対して常に提供されていなければならない、アプリケーションの高可用性を備えることが可能になります。 また、コア・グループ・ブリッジ を使用して複数のコア・グループを構成し、互いに通信できるようにすることもできます。 コア・グループは同じセル内、あるいは複数のセルをまたがって通信できます。
クラスター・メンバー
クラスター・メンバーの始動時にこれらのコンポーネントがすべて自動的に始動するのではなく、 それぞれのコンポーネントが必要に応じて動的に始動するように各クラスター・メンバーを構成すれば、 システム・パフォーマンスを向上できます。このオプションを選択すると、クラスター起動時間が短縮され、クラスター・メンバーのメモリー占有スペースを削減できます。コンポーネントを必要に応じて始動することは、クラスターにデプロイされたアプリケーションがすべて同じタイプである場合に最も効果的な方法となります。例えば、このオプションは、すべてのアプリケーションがサーブレット、および JavaServer Pages (JSP) を使用する Web アプリケーションである場合に、より効果的に機能します。 アプリケーションがサーブレット、JSP および Enterprise JavaBeans (EJB) を使用している場合、 このオプションはそれほど効果的に機能しません。

- Java™ シン・クライアントが含まれている
- 要求が複数のセル間でルーティングされている
- 要求が以前のバージョンの製品のノードが含まれている単一のセル内でルーティングされている
この状況が最もよく起こるのは、 すべてのクラスター・メンバーのポートが動的ポートで、要求が送信されていない期間中にそれらのすべてのクラスター・メンバーが再始動された場合です。 このような場合、クライアント・プロセスは、結果的に、 ノード・エージェントにルーティングしてクラスター・メンバーの新しいポート・データを受信し、 その新しいポート・データを使用してクラスター・メンバーにルーティングしようとします。
クライアントがノード・エージェントと通信する際に問題が発生した場合、 あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、 クライアントで要求が失敗する可能性があります。 これらの失敗は、一時的なものにすぎない場合もあります。 しかし、場合によっては、失敗を解決するために 1 つ以上のプロセスを再始動する必要があります。
このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、 クラスター・メンバーで静的ポートを構成するようにします。 静的ポートを構成すると、 クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。 クラスター・メンバーが再始動された場合や、 プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。 この回避策によって、 必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、 クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。
gotcha