ワークロード共有またはスケーラビリティーの構成
この構成は、クラスター内で稼働する複数のメッセージング・エンジンから成り、 各メッセージング・エンジンは特定の 1 つのサーバー上で稼働するように制限されます。 ワークロード共有構成では、メッセージング負荷を複数のサーバーに分散することで、 メッセージのスループットを大きくすることができます。
- メッセージング・エンジン・ポリシー・アシスタンスを使用して クラスターをサービス統合バスに追加し、スケーラビリティー・メッセージング・エンジン・ポリシーを使用できます。 この手順では、クラスター内のサーバーごとにメッセージング・エンジンを作成します。 各メッセージング・エンジンの優先サーバーは 1 台のみで、 フェイルオーバーもフェイルバックもできません。つまり、そのサーバーでのみ稼働するように構成されています。 メッセージング・エンジンごとに、新規コア・グループ・ポリシーが自動的に作成、構成、および関連付けされます。
- メッセージング・エンジン・ポリシー・アシスタンスを使用せずに、
クラスターをサービス統合バスに追加できます。メッセージング・エンジンが 1 つ、
自動で作成されるので、次に、必要なメッセージング・エンジンをさらにクラスターに追加します。
例えば、クラスター内のサーバーごとにメッセージング・エンジンが 1 つあるようにします。
各メッセージング・エンジンにコア・グループ・ポリシーを作成します。 フェイルオーバーは不要であるため、 各メッセージング・エンジンを特定のサーバーに制限するようなポリシーを構成します。 メッセージング・エンジンを特性のサーバーに制限するには、 各メッセージング・エンジンに静的ポリシーを構成します。
新規ポリシーの作成後は、マッチング基準を使用して、各ポリシーを必要なメッセージング・エンジンに関連付けます。
このタイプのデプロイメントでは、 複数のメッセージング・エンジンにわたる宛先の分割によってワークロード共有が実現されます。 この構成ではフェイルオーバーは使用可能になりません。各メッセージング・エンジンは、1 つのサーバーでのみ実行可能であるためです。 クラスター内のサーバーまたはメッセージング・エンジンのいずれかで 障害が起こった場合、残りのメッセージング・エンジンにはまだ運用可能な宛先区画があるため、 障害の影響は単純デプロイメントと比べて小さくなります。ただし、 障害が発生したサーバーでメッセージング・エンジンが処理していたメッセージは、 サーバーを再始動できるまで利用できません。
ワークロード共有構成では、 クラスター内の既存のメッセージング・エンジンに影響を与えずに クラスターに新規サーバーを追加できるため、スケーラビリティーも提供します。
次の図は、ワークロード共有またはスケーラビリティー構成を示しています。 ここには、3 つのメッセージング・エンジン、 ME1、ME2、および ME3 があり、それぞれにデータ・ストア A、B、および C があります。これらのメッセージング・エンジンは、 3 つのサーバーのクラスターで稼働し、宛先を通過するトラフィックを共有します。各サーバーは別個のノード上にあるため、 1 つのノードに障害が起こっても、残りのノードのサーバーは引き続き使用できます。

次の図は、server1 に障害が発生した状態を示しています。 ME1 は稼働できず、データ・ストア A にはアクセスできません。ME1 は、 server1 がリカバリーするまでメッセージを処理できません。ME2 および ME3 は影響を受けず、 メッセージの処理を続行します。これら 2 つは、宛先を経由した すべての新規トラフィックを処理するようになります。

次の図は、server1 がリカバリーし、server2 に障害が発生した状態を示しています。 ME2 は稼働できず、データ・ストア B にはアクセスできません。ME2 は、 server2 がリカバリーするまでメッセージを処理できません。ME1 および ME3 はメッセージを処理でき、 宛先を経由したすべての新規トラフィックを処理するようになります。
