BizTalk Server アーキテクチャは、スケーラビリティに非常に優れたサポートを提供します。 選択するスケーリング パターンは、シナリオの複雑さ、ハードウェア、スループット/待機時間の要件によって異なります。 最初は小さいトポロジから始めて、このセクションのガイドラインに基づいてスケールアップまたはスケールダウンを試みる必要があります。
スケールアウトとスケールアップ
BizTalk Server システムをスケーリングするには、次の 2 つの方法があります。
スケールアウトは、コンピューターを追加するプロセスです。 たとえば、BizTalk Server が CPU リソースによってボトルネックになっている場合、別のサーバーを追加すると、2 倍の CPU リソースが提供され、スループットが 2 倍になる可能性があります。
スケールアップは、既存のコンピューターをアップグレードするプロセスです。 たとえば、BizTalk Server コンピューターを 4 つのプロセッサ コンピューターから 8 プロセッサにアップグレードできます。
BizTalk Server システムには、BizTalk Server 層と、メッセージ ボックス データベースを含む SQL Server 層の 2 つの層があります。 どのシナリオでも、各レベルをスケールアウトまたはスケールアップできます。 つまり、BizTalk Server と MessageBox データベースをスケールアウトするか、両方をスケールアップできます。
ほとんどの場合、BizTalk レベルが最初にボトルネックになり、スケール アウトしてパフォーマンスの向上を開始します。ただし、ある時点で、システムと使用するハードウェアの複雑さに応じて、BizTalk 層をスケールアウトできなくなり、SQL Server 層がボトルネックになります。 次に、SQL Server 層をスケールアップし、次に MessageBox データベースを追加してスケールアウトします。
注
新しい MessageBox データベースは、必ずしもここで別のサーバーを意味するとは限りません。 1 つの SQL サーバーに複数の MessageBox データベースを含めることができます。 また、データベースが異なるコンピューター上にある場合、複数の MessageBox データベースで DTC コストとネットワーク ホップが発生します。
理論上、マスター メッセージ ボックス データベースが飽和していない限り、SQL Server 層は無期限にスケールアウトできます。
このセクションのトピックでは、これらのスケーリング パターンについて詳しく説明します。 また、各パターンをスケーリングする方法と、そのパターンを使用してシステムをスケーリングできなくなった場合を判断する方法についても説明します。
このセクションにて
こちらもご覧ください
受信ホストScaled-Out
Scaled-Out 処理ホスト
ホストの送信Scaled-Out
Windows Server クラスターを使用した BizTalk Server Hosts2 の高可用性の提供
Scaled-Out データベース
BizTalk Server データベースのクラスタリング