クラスタリングを行うマルチサーバー・バス

ユーザーは、複数のサーバーで構成されるバスを使用する際に、 その一部またはすべてのサーバーをクラスターのメンバーとすることができます。 サーバーがクラスターのメンバーである場合、複数のサーバーが異なるマシン上で 共通アプリケーションを実行することが許可されます。異なるマシン上に複数のサーバーを持つクラスター上にアプリケーションをインストールすると、 可用性を高めることができます。 1 台のマシンで障害が発生しても、クラスター内の他のサーバーでは障害は発生しません。

サーバー・バス・メンバーを構成する際には、そのサーバーによってメッセ ージング・エンジンが実行されます。多くの目的ではこれで十分ですが、そのようなメッセージング・エンジンを実行できるのは、そのエンジンが 作成されたサーバー上のみです。したがって、そのサーバーは Single Point of Failure となります。つまり、サーバーを稼働できない場合には、メッセージン グ・エンジンを利用できません。その代わりにクラスター・バス・メンバー を構成することにより、メッセージング・エンジンはクラスター内のいずれ か 1 台のサーバーで稼働することができ、そのサーバーで障害が発生した場合 、メッセージング・エンジンは代替サーバーで稼働できます。これについては 、図 1に示します。詳しくは、バス・メンバーのタイプと高可用性およびワークロード共有に対するその影響を参照してください。

クラスター・バス・メンバーを構成することのもう 1 つの利点は、複 数のサーバーに渡る宛先に関連付けられたワークロードを共有できるというこ とです。追加のメッセージング・エンジンをクラスターにデプロイできます。クラスター・バス・メンバーにデプロイされた宛先は、クラスタ ー・サーバーによって実行されるメッセージング・エンジンのセット全体で区画化されます。クラスター内の各メッセージング・エンジンは、その宛 先に着信するメッセージの割り当て分を処理します。これについては 、図 2に示します。この概念は、IBM MQ のクラスター・キューについて知識のあるユーザーにとっては馴染みのある概念です。詳しくは、ワークロード共有を参照してください。

要約すると、クラスター・バス・メンバーを使用することにより、(フェイルオーバーによって) 高可用性を実現することができます。 また、メッセージング・エンジン用に構成するポリシーによっては、ワークロード共有、あるいは高可用性を備えたワークロード共有を実現するようにクラスターを構成することもできます。 メッセージング・エンジンのポリシーについて詳しくは 、サービス統合のポリシーを参照してください。

図 1. クラスター化サーバーを備えたサービス統合バス
この図では、サービス統合バスに 1 つのクラスター・バス・メンバーが含まれます。
クラスターには 2 つのアプリケーション・サーバーが含まれます。クラスター内の 1 つのサーバーがメッセージング・エンジンをホストします。そのサーバーに障害が発生しても、メッセージング・エンジンは代替サーバーで稼働できます。
図 2. 区画化された宛先を持つサービス統合バス
この図では、サービス統合バスに 1 つのクラスター・バス・メンバーが含まれます。
クラスターには 3 つのアプリケーション・サーバーが含まれます。クラスター内の各サーバーがメッセージング・エンジンを稼働します。
バス宛先は、クラスター・メンバーで稼働するメッセージング・エンジン全体で区画化されます。

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cjj0072_
ファイル名:cjj0072_.html