このパターンでは、既存の SQL MessageBox データベースがアップグレードされ、スループットまたは待機時間の要件に従ってスケーリングされます。
次の図は、マスター メッセージ ボックス データベースがクワッド プロセッサ サーバーから 8 プロセッサ サーバーにアップグレードされるシナリオを示しています。
スケールアップ
SQL 層をスケールアップするタイミング
マスター メッセージ ボックス データベースをスケールアップできる場合。
マスター メッセージ ボックス データベースがボトルネックになったとき。 これらのボトルネックは次のようになります。
CPU 非常にコストが高く複雑なオーケストレーション シナリオの場合、メッセージ ボックスは大量の CPU リソースを消費します。 CPU を追加して SQL サーバーをスケールアップするには、シナリオをスケーリングする必要があります。
メモリまたは I/O メモリまたは I/O はボトルネックになり、アップグレードできます。
スケールアップがスケールアウトよりも安価で、スケールアップがボトルネックに対処できる場合。 たとえば、マスター MessageBox データベースに SQL ロックの競合に関する問題がある場合、この問題はスケールアップでは解決できません。
SQL がスケールアップできないのはいつですか?
スケールアップでは、SQL 層のロック競合のボトルネックに対処できません。 このようなボトルネックが発生した場合、スケールアウトはスケールアップよりも優れたオプションです。
SQL 層のスケールアップに関する戦略と考慮事項
最初にマスター メッセージ ボックス データベースをスケールアップしてからスケールアウトします。
最終的には、マスター メッセージ ボックス データベースがボトルネックになります。 そのため、マスター MessageBox データベースは、より高速で大きくする必要があります (たとえば、Itanium ベースの 64 ビットまたは x64 ベースのデュアル コア コンピューター)。
こちらもご覧ください
BizTalk Server 層のスケールアウト
BizTalk Server 層のスケールアップ
SQL Server 層のスケールアウト
受信ホストScaled-Out
Scaled-Out 処理ホスト
ホストの送信Scaled-Out
Windows Server クラスターを使用した BizTalk Server Hosts2 の高可用性の提供
Scaled-Out データベース
BizTalk Server データベースのクラスタリング