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