BizTalk グループごとに、マスター メッセージ ボックス データベースを 1 つ追加します。 追加する後続のすべての MessageBox データベースは、セカンダリ メッセージ ボックスと呼ばれます。 マスター メッセージ ボックスは、すべてのサブスクリプションとメッセージ ルーティングを処理します。 また、メッセージを発行することもできます。 セカンダリ メッセージボックス データベースは、メッセージを発行するように特別に構成されている場合にのみメッセージを発行します。
セカンダリ メッセージ ボックス データベースを追加する方法
セカンダリ メッセージ ボックス データベースを追加するには、次の 2 つの方法があります。
セカンダリ メッセージ ボックス データベースを同じ物理サーバーに追加します。
既存の MessageBox 物理サーバーに十分な CPU リソースと I/O リソースがあり、ロックの競合によってのみボトルネックになっている場合は、これを行います。 別の IO ドライブにセカンダリ メッセージ ボックス データベースを作成します。
利点:
追加の CPU ヘッドルームは、別のメッセージ ボックスで利用できます
必要な SQL Server ライセンスの数を減らします
ネットワーク ホップが削除される
別の物理サーバーにセカンダリ メッセージ ボックス データベースを追加する
専用のIOを備えた専用の物理サーバーを、追加のMessageBoxデータベースとして使用します。
次の図は、SQL 層が 1 つの MessageBox データベースから 3 つの MessageBoxes データベースにスケールアウトされるシナリオを示しています。
メッセージ ボックス データベースをスケールアウトするタイミング
MessageBox データベースがボトルネックになります。 これらのボトルネックは次のようになります。
CPU 非常にコストが高く複雑なオーケストレーション シナリオの場合、MessageBox データベースは大量の CPU リソースを消費します。 MessageBox データベースのさらなる公開は、スループットの向上に役立ちます。
ロックの競合 複数のホスト インスタンスまたはオーケストレーションを使用する複雑なシナリオでは、MessageBox データベースでロックの競合が発生する傾向があります。 ここでも、別の発行メッセージ ボックス データベースを追加すると、スループットが向上します。
スケールアップしてもボトルネックに対処できません。 たとえば、マスター メッセージ ボックス データベースがロック競合バインドされている場合は、スケールアウトのみがオプションです。
スケールアップはコストがかかりすぎます。 たとえば、既存の quad proc サーバーを 8 方向サーバーにアップグレードする方が、別のクワッド プロセスを追加するよりもコストが高い場合は、スケールアウトの方が適しています。
SQL 層をスケールアウトできない場合
理論上、マスター メッセージ ボックス データベースがボトルネックでない限り、SQL 層は無期限にスケーリングする必要があります。 これを実現するには、マスター メッセージ ボックス データベースを非発行データベースにして、ルーティングのみを行うことを検討してください。 ただし、ロックの競合によってマスターがボトルネックになると、SQL 層をスケールアウトすることはできません。
スケールアウト戦略と考慮事項
最初にマスター メッセージ ボックス データベースをスケールアップし、次にスケールアウトします。
1 から 2 ではなく、1 から 3 の SQL MessageBox データベースへのスケールアウト。 上の図に示した 1 つの SQL Server トポロジについて考えてみます。"4 BizTalk Server、1 SQL Server トポロジ" と見なして、SQL Server が CPU にバインドされている、つまり CPU 処理がボトルネックであると仮定します。 このトポロジに MessageBox データベースを 1 つだけ追加した場合、マスター メッセージ ボックスは引き続き CPU バインドされ、セカンダリ メッセージ ボックス データベースの使用率が不足します。 そのため、倍率はほぼ 1 です。 マスター メッセージ ボックス データベースでの発行を無効にし、マスター メッセージ ボックス データベースのみをルーティング専用にした場合、セカンダリ MessageBox データベースによって発行が実行されます。 セカンダリ メッセージ ボックス データベースが唯一の発行元であり、依然としてボトルネックになるため、全体的なスループットを向上させるのに役立つわけではありません。 そのため、このシナリオでは、2 つのセカンダリ メッセージ ボックス データベースを追加し、マスター メッセージ ボックス データベースでの発行を無効にすることをお勧めします。
マスター メッセージ ボックス データベースが最終的にボトルネックになります。 そのため、マスター メッセージ ボックス データベースをホストしている物理コンピューターの方が、より高速で大きくなる必要があります。
ネットワーク経由のデータ送信 (および関連する DTC オーバーヘッド) を最小限に抑えるには、専用ドライブを備えた同じ物理コンピューターに複数の MessageBox データベースを配置することを検討してください。 同時に、リソースが複数の MessageBox データベースによって共有されているため、これらの複数のデータベースを保持しているコンピューターがボトルネックにならないことを確認します。
すべてのセカンダリ MessageBox データベースでは、発行している MessageBox データベース間で作業が均等に分散されるため、同等のハードウェアを使用する必要があります。
マスター メッセージ ボックス データベースがボトルネックでない限り、セカンダリ メッセージ ボックス データベースをスケールアウトできるため、セカンダリ メッセージ ボックス データベースは、マスター MessageBox データベース サーバーに必要な CPU リソースが少ないコンピューターで実行できます。
こちらもご覧ください
BizTalk Server 層のスケールアウト
BizTalk Server 層のスケールアップ
SQL Server 層のスケールアップ
受信ホストScaled-Out
Scaled-Out 処理ホスト
ホストの送信Scaled-Out
Windows Server クラスターを使用した BizTalk Server Hosts2 の高可用性の提供
Scaled-Out データベース
BizTalk Server データベースのクラスタリング