高可用性を備えたワークロード共有の構成
この構成は、それぞれのメッセージング・エンジンが 1 つ以上 の代替サーバーにフェイルオーバーすることができる、クラスター内で稼働す る複数のメッセージング・エンジンから成ります。
- メッセージング・エンジン・ポリシー・アシスタンスを使用して クラスターをサービス統合バスに追加し、高可用性メッセージング・エンジン・ポリシーを持つスケーラビリティーを使用できます。 この手順では、クラスター内のサーバーごとに単一のメッセージング・エンジンを作成します。 各メッセージング・エンジンは、 クラスター内の指定された他の 1 台のサーバーにフェイルオーバーすることができます。サーバー間に順序付けられた環状の関係が形成されるように、サーバーごとに 2 つまでのメッセージング・エンジンをホストすることができます。 各メッセージング・エンジンはフェイルバック可能です。つまり、あるメッセージング・エンジンが別のサーバーにフェイルオーバーした後で、元のサーバーが再度使用可能になった場合、そのメッセージング・エンジンの処理は自動的に元のサーバーに戻ります。
- メッセージング・エンジン・ポリシー・アシスタンスを使用して クラスターをサービス統合バスに追加し、カスタム・メッセージング・エンジン・ポリシーを使用できます。クラスターに必要な数のメッセージング・エンジンを作成できます。 作成するメッセージング・エンジンごとに、メッセージング・エンジン・ポリシーを構成して、 必要なメッセージング・エンジンの動作を指定する必要があります。
- メッセージング・エンジン・ポリシー・アシスタンスを使用せずに、
クラスターをサービス統合バスに追加できます。メッセージング・エンジンが 1 つ、
自動で作成されるので、次に、必要なメッセージング・エンジンをさらにクラスターに追加します。
標準的な構成では、クラスター内のサーバーごとに 1 つのメッセージング・エンジンがあります。
クラスター内のメッセージング・エンジンごとに、新しい「One of N」コア・グループ・ポリシーを作成します。
各サーバーで 1 つのメッセージング・エンジンが稼働し、
高可用性の振る舞いがある (例えば、各メッセージング・エンジンが 1 つの指定サーバーにフェイルオーバーできる) ように、
ポリシーを構成します。
- メッセージング・エンジンを実行でき、そのフェイルオーバーの対象になっている優先サーバーの番号付きリストを設定できます。
- メッセージング・エンジンをクラスター内の任意のサーバーで実行できるようにするか、 それとも優先サーバー・リストに含まれるサーバー上でのみ実行できるようにするかを指定できます。
- 優先度のより高いサーバーが使用可能になった場合、メッセージング・エンジンがそのサーバーにフェイルバックできるかどうかを指定できます。
デフォルトのサービス統合ポリシー「Default SIBus Policy」ではこの動作は提供されないので、 新規コア・グループ・ポリシーを作成する必要があります。
このタイプの構成では、サーバーが使用不可になった場合にそれぞれのメッセージング・エンジンがフェイルオーバーできるため、可用性が提供されます。この構成では、 宛先を経由したトラフィックを共有するメッセージング・エンジンが複数あるため、ワークロード共有が提供され、 クラスター内の既存のメッセージング・エンジンに影響を与えずに クラスターに新規サーバーを追加できるため、スケーラビリティーが提供されます。
以下の図に、このタイプの構成例を示します。ここには、3 つのメッセージング・エンジン、 ME1、ME2、および ME3 があり、それぞれにデータ・ストア A、B、および C があります。これらのメッセージング・エンジンは、 3 つのサーバーのクラスターで稼働し、宛先を通過するトラフィックを共有します。各サーバーは別個のノード上にあるため、 1 つのノードに障害が起こっても、残りのノードのサーバーは引き続き使用できます。
各メッセージング・エンジンには、1 つの優先ロケーションと 1 つの 2 次ロケーションがあります。 クラスター内の各サーバーは、サーバー上で稼働できる 2 つのメッセージング・エンジンの定義を含んでおり、 各メッセージング・エンジンのインスタンスを作成して、 メッセージング・エンジンはそのインスタンスで優先ロケーションとして稼働し、 一方のサーバーで障害が起こった場合にもう一方のインスタンスを活動化できるようにします。ME1 は server1 で稼働し、server2 にフェイルオーバーできます。ME2 は server2 で稼働し、 server3 にフェイルオーバーできます。ME3 は server3 で稼働し、server1 にフェイルオーバーできます。
各メッセージング・エンジンのメッセージ・ストアは、 優先サーバーおよび 2 次サーバーからアクセス可能でなければなりません。これを実現する方法は、 使用するデータ・ストア・トポロジーによって異なります。ネットワークで接続されたデータベース・サーバーを使用している場合は、 メッセージング・エンジンを実行する可能性があるクラスター内のすべての サーバーからデータベース・サーバーに確実にアクセスできるようにする必要があります。その代わりに、共有ディスクを使用してデータベースを管理する外部の高可用性フレームワークを使用することもできます。
この構成例は、3 台のサーバーのクラスターにメッセージング・エンジン・ポリシー・アシスタンスおよび 高可用性を備えたスケーラビリティー・メッセージング・エンジン・ポリシーを使用するときに作成される構成です。

次の図は、server1 に障害が発生した状態を示しています。 メッセージング・エンジン ME1 は、そのメッセージング・エンジンの優先サーバー・リスト内の次のサーバーである server2 で活動化されます。ME2 は server2 で稼働し続け、 ME3 は server3 で稼働し続けます。

次の図は、server1 が再度使用可能になり、server2 に障害が発生した状態を示しています。 メッセージング・エンジン ME1 は、そのメッセージング・エンジンの優先サーバー・リスト内の最初のサーバーである server1 で活動化されます。 フェイルバックが ME1 に設定されているためです。ME2 は、そのメッセージング・エンジンの優先サーバー・リスト内の次のサーバーである server3 で活動化されます。ME3 は server3 で稼働し続けます。

事前定義されている、高可用性を備えたスケーラビリティー・メッセージング・エンジン・ポリシーは、スケーラビリティーと高可用性という特性を持つ構成を作成します。 次の図に、メッセージの送信を優先した、高可用性とワークロード共有を提供するもう一つの構成例を示します。 ここには、2 つのメッセージング・エンジン、ME1 と ME2 があり、 それぞれにデータ・ストア A と B があります。 これらは、3 台のサーバーから成るクラスター内で稼働し、 宛先を経由したトラフィックを共有しています。通常のオペレーションでは、 ME1 は server1 で稼働し、ME2 は server2 で稼働します。Server3 は、 両方のメッセージング・エンジンにフェイルオーバー・ロケーションを提供します。これは、予備のサーバーが 1 台あることから「N+1」構成と呼ばれます。

ME1 の優先サーバー・リストは server1、server3 で、 ME2 の優先サーバー・リストは server2、server3 です。この構成の利点は、 1 台のサーバーで障害が発生すると、残りの各サーバーが 1 つのメッセージング・エンジンのみをホスティングすることです。 この構成の問題点は、予備のサーバーの費用です。 このタイプの構成を実現するために、カスタム・メッセージング・エンジン・ポリシーを使用できます。
メッセージング・エンジン・ポリシー・アシスタンスを使用せずに、 メッセージング・エンジンに優先サーバーを使用させるには、 メッセージング・エンジンに 1 台以上の優先サーバーを指定する必要があります。優先サーバーが使用可能な場合は常に、HA マネージャー (HAManager) はその優先サーバーでメッセージング・エンジンを実行します。 使用できる優先サーバーがない場合、 メッセージング・エンジンは代替サーバーで実行されます。優先サーバーが再度使用可能になったときに HAManager がメッセージング・エンジンをそこに戻すように、「フェイルバック」オプションをポリシーに設定することもできます。