クラスタリングを行うマルチサーバー・バス
ユーザーは、複数のサーバーで構成されるバスを使用する際に、 その一部またはすべてのサーバーをクラスターのメンバーとすることができます。 サーバーがクラスターのメンバーである場合、複数のサーバーが異なるマシン上で 共通アプリケーションを実行することが許可されます。異なるマシン上に複数のサーバーを持つクラスター上にアプリケーションをインストールすると、 可用性を高めることができます。 1 台のマシンで障害が発生しても、クラスター内の他のサーバーでは障害は発生しません。
サーバー・バス・メンバーを構成する際には、そのサーバーによってメッセ ージング・エンジンが実行されます。多くの目的ではこれで十分ですが、そのようなメッセージング・エンジンを実行できるのは、そのエンジンが 作成されたサーバー上のみです。したがって、そのサーバーは Single Point of Failure となります。つまり、サーバーを稼働できない場合には、メッセージン グ・エンジンを利用できません。その代わりにクラスター・バス・メンバー を構成することにより、メッセージング・エンジンはクラスター内のいずれ か 1 台のサーバーで稼働することができ、そのサーバーで障害が発生した場合 、メッセージング・エンジンは代替サーバーで稼働できます。これについては 、図 1に示します。詳しくは、バス・メンバーのタイプと高可用性およびワークロード共有に対するその影響を参照してください。
クラスター・バス・メンバーを構成することのもう 1 つの利点は、複 数のサーバーに渡る宛先に関連付けられたワークロードを共有できるというこ とです。追加のメッセージング・エンジンをクラスターにデプロイできます。クラスター・バス・メンバーにデプロイされた宛先は、クラスタ ー・サーバーによって実行されるメッセージング・エンジンのセット全体で区画化されます。クラスター内の各メッセージング・エンジンは、その宛 先に着信するメッセージの割り当て分を処理します。これについては 、図 2に示します。この概念は、IBM MQ のクラスター・キューについて知識のあるユーザーにとっては馴染みのある概念です。詳しくは、ワークロード共有を参照してください。
要約すると、クラスター・バス・メンバーを使用することにより、(フェイルオーバーによって) 高可用性を実現することができます。 また、メッセージング・エンジン用に構成するポリシーによっては、ワークロード共有、あるいは高可用性を備えたワークロード共有を実現するようにクラスターを構成することもできます。 メッセージング・エンジンのポリシーについて詳しくは 、サービス統合のポリシーを参照してください。

