BizTalk レベルをスケールアウトするには、既存のトポロジにハードウェアを追加します。 次のシナリオでは、ハードウェアを追加することをお勧めします。
BizTalk Server がボトルネックになります。 ボトルネック自体は、次のいずれかの問題が原因である可能性があります。
CPU: シナリオで CPU 負荷の高いパイプライン、マップ、またはオーケストレーションを使用する場合、BizTalk サーバーには余分な CPU ヘッドルームはありません。
メモリと I/O: 既存のコンピューターがメモリと IO の上限に達した場合、リソースを追加する唯一の方法は、別の物理コンピューターを追加することです。
スケールアップはコストがかかりすぎます。 たとえば、BizTalk CPU が最大容量である 1 つの BizTalk Server トポロジを考えてみましょう。 デュアル プロセッサをクワッド プロセッサにアップグレードするのではなく、追加のデュアル プロセッサ マシンを追加する方が安価な場合は、代わりにシステムをスケールアウトする必要があります。
スケールアップしてもボトルネックは解決されません。 スケールアップは、次のシナリオでは機能しない可能性があります。
IO は BizTalk コンピューターの最大レベルであるため、IO をスケーリングするには別のコンピューターが必要です。
メモリは、オペレーティング システムの最大レベルです。 このシナリオでは、システムをスケーリングする唯一の方法は、トポロジに追加の BizTalk コンピューターマシンを追加することです。
一部のシナリオでは、メッセージの受信、メッセージの送信、および処理に専用サーバーが必要な場合があります。 専用サーバーがある場合は、問題を特定し、他のコンピューターに影響を与えずに 1 台のコンピューターでメンテナンスを行う方が簡単です。 BizTalk レベルをスケーリングすることで、これらのコンピューターを追加できます。
BizTalk レベルをスケールアウトできない場合
MessageBox データベースがボトルネックです。
アダプターがボトルネックになります。 たとえば、SQL アダプターを使用している場合、BizTalk レシーバーの数を増やした後、BizTalk SQL アダプターがデータをプルしている SQL データベースでロックの競合が増加します。 これにより、SQL アダプターをスケールアウトする機能が制限されます。
次の図は、BizTalk レベルをスケールアウトする方法の例を示しています。
この図は、1 台の BizTalk サーバーから 2 台の BizTalk サーバーにスケール アウトされた BizTalk トポロジを示しています。 1 つの BizTalk サーバー トポロジでは、3 つのホスト インスタンスが BizTalk コンピューター リソースを共有しています。 2 つの BizTalk サーバー トポロジでは、送信ホストが別のサーバーに分離され、スループットが向上します。
BizTalk 層をスケールアウトするときの考慮事項
別の BizTalk Server コンピューターを追加する前に、次の質問を考慮する必要があります。
BizTalk レベルをスケールアウトするときに、負荷分散とフォールト トレランスのためにシステムを構成するにはどうすればよいですか?
負荷分散とフォールト トレランス テクノロジの選択は、シナリオで使用されているアダプターによって異なります。 SOAP および HTTP アダプターの場合は、NLB を使用することをお勧めします。 詳細については、NLB のドキュメントを参照してください。
ホスト インスタンスをリファクタリングするにはどうすればよいですか?
BizTalk レベルをスケールアウトするときにホスト インスタンスをリファクタリングする方法を決定するルールは 1 つもありません。 ホスト インスタンスを考慮する場合は、シナリオの複雑さに依存します。 ホスト インスタンスを考慮する方法の例を次に示します。
シナリオ 1
1 つの BizTalk サーバー構成と受信および送信ホスト インスタンスが同じコンピューター上にあります。
CPU のボトルネックがあるとします。 別の同一の BizTalk コンピューターをグループに追加してスケールアウトし、ホスト インスタンスを考慮する 2 つの方法を提供します。
この問題の 2 つの解決策を次に示します。
解決策 1: このシナリオで考慮する最も簡単な方法は、1 台目のコンピューターから 2 台目のコンピューターにホスト インスタンスの要素化を複製することです。 したがって、2台目のコンピュータは、機能の用語の最初の正確なコピーです。また、受信ホストと送信ホストの両方を持つことができます。 他のボトルネックがないと仮定すると、CPU リソースが 2 倍になるにつれて、スケール ファクターが 2 になる可能性があります。
解決策 2: ホスト インスタンスを考慮するもう 1 つの方法は、受信機能と送信関数を別のコンピューターに分離することです。 そのため、BizTalk サーバーの 1 つは受信専用であり、他のサーバーは送信専用です。
ソリューション 1 とソリューション 2 の比較
解決策 1 では、ホスト インスタンスの数が 1 つの BTS 構成から 2 倍になります。 これは、SQL サーバーでのロックの競合が増加することを意味します。 ロックの競合がどれだけ増加するかによって、スケール ファクターが決まります。 ロックの競合がボトルネックになる制限内にある場合は、スケーリング係数が 2 であることがわかります。
ソリューション 2 の利点は、ホスト インスタンスが 2 つしかないため、SQL サーバーでのロックの競合がソリューション 1 と比較して少なくなります。 ただし、スケーリング係数は、受信および送信ホスト インスタンスの複雑さに完全に依存します。 ソリューション 2 では、次のケースを考慮してください。
受信ホスト インスタンスと送信ホスト インスタンスの両方が同じように集中的であり、それぞれが 1 つの BizTalk サーバー トポロジで 50% の CPU を使用しているとします。 2 つの BizTalk サーバー トポロジでは、送信ホスト インスタンスを別のコンピューターに移動し、受信と送信の両方が 2 倍のリソースを取得します。 これは、他のボトルネックがないと仮定して、2 のスケーリング係数を提供する必要があります。 このケースは、ホスト インスタンスが 2 つしかないため、ソリューション 1 よりも優れています。そのため、les lock 競合が発生します。
送信は受信よりも負荷が高く、1 つの BizTalk サーバー トポロジで 80% CPU リソースを使用するとします。 送信ホスト インスタンスを別のマシンに移動すると、CPU リソースが 20% 増えるだけで、最大スケール ファクターは 1.2 になります。 さらに、受信ホスト インスタンスを持つコンピューターでは、20 から 30% の CPU リソースしか使用されないため、スケールアウトの利点ははるかに少なくなります。
4 台の BizTalk サーバーがある次の図を考えてみましょう。 各コンピューターは受信側と送信側の両方であり、各種類 (受信と送信) の合計 4 つのホスト インスタンスを提供します。
このトポロジは、可能な限り最良のトポロジではない可能性があります。 また、シナリオの複雑さに応じて、他の因子分解の順列もテストする必要があります。 例えば次が挙げられます。
受信用に 2 台、送信用に 2 台のコンピューターを専用にします。 これにより、受信と送信の両方が均等に集中している場合に、可能な限り最適なスケーリングが提供されます。
受信が送信よりも集中的な場合は、受信用に 3 台のコンピューターと送信用のコンピューターを専用にします。
送信が受信よりも集中的な場合は、受信用に 1 台、送信用に 3 台専用にします。
すべてのシナリオで、各ホストのホスト インスタンスの数を最小限に抑えて、MessageBox データベースの競合を減らし、同時にコンピューター リソースを最大限に使用することをお勧めします。 最適な因数分解の順列は、シナリオの複雑さとボトルネックの種類によって異なります。 順列を確定する前に、必ず因子分解をテストしてください。
こちらもご覧ください
BizTalk Server 層のスケールアップ
SQL Server 層のスケールアップ
SQL Server 層のスケールアウト
受信ホストScaled-Out
Scaled-Out 処理ホスト
ホストの送信Scaled-Out
Windows Server クラスターを使用した BizTalk Server Hosts2 の高可用性の提供
Scaled-Out データベース
BizTalk Server データベースのクラスタリング