SQL Server 層のスケール アウト

各 BizTalk グループには、マスター メッセージ ボックス データベースを 1 つ追加します。 以降追加したメッセージ ボックス データベースはすべて、セカンダリ メッセージ ボックスと呼ばれます。 マスター メッセージ ボックスは、すべてのサブスクリプションとメッセージ ルーティングを処理し、 メッセージの公開も行えます。 セカンダリ メッセージ ボックス データベースは、特定の構成を行った場合にのみ、メッセージを公開します。

セカンダリ メッセージ ボックス データベースを追加する方法

セカンダリ メッセージ ボックス データベースを追加する方法は 2 とおりあります。

• セカンダリ メッセージ ボックス データベースを同じ物理サーバー上に追加する。

  既存のメッセージ ボックス物理サーバーに十分な CPU および I/O リソースがあり、ボトルネックの発生原因がロックの競合に限られている場合は、この方法を使用します。 セカンダリ メッセージ ボックス データベースを別の IO ドライブ上に作成します。

  長所:

  • 余分な CPU ヘッドルームを他のメッセージ ボックスに利用できます。

  • SQL サーバー ライセンスが少なくて済みます。

  • ネットワーク ホップがなくなります。

• セカンダリ メッセージ ボックス データベースを別の物理サーバー上に追加する。

  この場合は、追加のメッセージ ボックス データベースとして固有の IO を持つ専用の物理サーバーを使用します。

  次の図は、SQL 層を 1 つのメッセージ ボックス データベースから 3 つのメッセージ ボックス データベースにスケール アウトするシナリオを示しています。

  する

メッセージ ボックス データベースのスケール アウトが必要になるケース

• メッセージ ボックス データベースがボトルネックとなる場合。 次のボトルネックが考えられます。

  • Cpu 非常に高価で複雑なオーケストレーション シナリオの場合、MessageBox データベースは大量の CPU リソースを消費します。 公開メッセージ ボックス データベースを追加すると、スループットが向上します。

  • ロックの競合 複数のホスト インスタンスまたはオーケストレーションを使用する複雑なシナリオでは、MessageBox データベースでロック競合が発生する傾向があります。 この場合も、公開メッセージ ボックス データベースを追加すると、スループットが向上します。

• スケール アップしても、ボトルネックが解消されない場合。 たとえば、マスター メッセージ ボックス データベースがロックの競合による制約を受けている場合、スケール アウトするしかありません。

• スケール アップのコストが高すぎる場合。 たとえば、既存のクアッド プロセッサ サーバーを 8 ウェイ サーバーにアップグレードするコストが、クアッド プロセッサをもう 1 つ追加するコストを上回るような場合は、スケール アウトすることをお勧めします。

SQL 層をスケール アウトできないケース

マスター メッセージ ボックス データベースがボトルネックにならない限り、理論上は、SQL 層は無限にスケール アウトできます。 そのためには、マスター メッセージ ボックス データベースを非公開データベースにして、ルーティング専用にすることを検討してください。 ただし、マスター メッセージ ボックス データベースがロックの競合によってボトルネックとなった場合は、SQL 層をそれ以上スケール アウトすることはできません。

スケール アウトの方法と検討事項

• まずマスター メッセージ ボックス データベースをスケール アップし、その後スケール アウトします。

• 1 から 2 ではなく、1 から 3 個の SQL MessageBox データベースへのスケールアウト。 上の図に示した 1 つの SQL Server トポロジ ("4 BizTalk Server、1 SQL Server トポロジ" について考えてみます。つまり、CPU 処理がボトルネックであると仮定します。 このトポロジにメッセージ ボックス データベースを 1 つしか追加しない場合は、依然としてマスター メッセージ ボックス データベースが CPU に依存しており、セカンダリ メッセージ ボックス データベースは有効に利用されません。 したがって、スケーリング係数はほぼ 1 です。 Master MessageBox データベースでの発行を無効にし、マスター メッセージ ボックス データベースをルーティングのみを行う場合、セカンダリ MessageBox データベースによって発行が実行されます。 これでは、セカンダリ メッセージ ボックス データベースが唯一のパブリッシャーであり、やはりボトルネックとなってしまうので、全体のスループットは改善されません。 したがって、セカンダリ メッセージ ボックス データベースを 2 つ追加し、マスター メッセージ ボックス データベースでの公開を無効にして、このシナリオをスケールアウトすることをお勧めします。

• マスター メッセージ ボックス データベースは、いずれはボトルネックとなります。 そのため、マスター メッセージ ボックス データベースをホストする物理コンピューターの処理速度を速く、容量を大きくする必要があります。

• ネットワーク上で送信するデータ (および関連する DTC オーバーヘッド) を最小限に抑えるには、専用のドライブを持つ同一の物理コンピューター上に複数のメッセージ ボックス データベースを配置することを検討してください。 それと同時に、これらの複数のデータベースを保持しているコンピューターでは、複数のマスター メッセージ ボックス データベースによってリソースが共有されているので、ボトルネックが生じないようにしてください。

• すべての公開メッセージ ボックス データベース間で処理が均一に分散されるので、すべてのセカンダリ メッセージ ボックス データベースで同等のハードウェアを使用する必要があります。

• マスター メッセージ ボックス データベースがボトルネックとならない限り、セカンダリ メッセージ ボックス データベースをスケール アウトできるので、セカンダリ メッセージ ボックス データベースは、マスター メッセージ ボックス データベース サーバーで必要とする CPU リソースよりも少ない CPU リソースのコンピューターで実行できます。

参照

BizTalk Server 層のスケール アウト
BizTalk Server 層のスケール アップ
SQL Server 層のスケール アップ
受信ホストのスケールアウト
スケールアウトした処理ホスト
スケールアウトした送信ホスト
Windows Server クラスターを使用したBizTalk Server ホストの高可用性の提供2
スケールアウト データベース
BizTalk Server データベースのクラスタリング