Dezentrales Skalieren der BizTalk Server-Ebene

Beim dezentralen Skalieren der BizTalk-Ebene fügen Sie der vorhandenen Topologie zusätzliche Hardware hinzu. In den folgenden Szenarien ist es empfehlenswert, Hardware hinzuzufügen:

• BizTalk Server wird zu einem Engpass. Der Engpass kann durch eines der folgenden Probleme verursacht werden:

• CPU: Verwendet das Szenario CPU-intensive Pipelines, Zuordnungen oder Orchestrierungen, stehen den BizTalk Servern keine CPU-Reserven zur Verfügung.

• Arbeitsspeicher und E/A: Wenn die vorhandenen Computer ihr maximales Limit für Arbeitsspeicher und E/A erreicht haben, besteht die einzige Möglichkeit zum Hinzufügen von Ressourcen darin, einen anderen physischen Computer hinzuzufügen.

• Zentrales Skalieren ist zu teuer. Betrachten Sie zum Beispiel die 1-BizTalk Server-Topologie, in der die Kapazität der BizTalk-CPU maximal ausgeschöpft ist. Wenn es billiger ist, zusätzliche Computer mit Dualprozessoren hinzuzufügen, anstatt den Dualprozessor in einen Quadprozessor aufzurüsten, sollten Sie Ihr System dezentral skalieren.

• Das Hochskalieren behebt den Engpass nicht. In den folgenden Szenarien funktioniert eine zentrale Skalierung möglicherweise nicht:

  • E/A-Vorgänge werden für den BizTalk-Computer maximal ausgeschöpft, daher benötigen Sie einen weiteren Computer, um die E/A-Vorgänge zu skalieren.

  • Der Arbeitsspeicher hat bereits die maximale, von Ihrem Betriebssystem unterstützte Größe. In diesem Szenario können Sie Ihr System nur skalieren, indem Sie der Topologie einen weiteren BizTalk-Computer hinzuzufügen.

  In einigen Szenarien benötigen Sie möglicherweise dedizierte Server zum Empfangen, Senden und Verarbeiten von Nachrichten. Mit dedizierten Servern ist es leichter, Probleme zu isolieren und einen Computer zu warten, ohne die anderen Computer zu beeinträchtigen. Diese Computer können hinzugefügt werden, indem Sie die BizTalk-Ebene dezentral skalieren.

Wann ist eine dezentrale Skalierung der BizTalk-Ebene nicht möglich

• Der Engpass liegt in der MessageBox-Datenbank.

• Ein Adapter wird zu einem Engpass. Wenn Sie beispielsweise den SQL-Adapter verwenden und die Anzahl an BizTalk-Empfängern in der SQL-Datenbank erhöhen, aus der der BizTalk-SQL-Adapter Daten entnimmt, treten häufiger Sperrkonflikte auf. Hierdurch wird die Möglichkeit, den SQL-Adapter dezentral zu skalieren, eingeschränkt.

  In der folgenden Abbildung wird ein Beispiel zum dezentralen Skalieren der BizTalk-Ebene gezeigt.

  

  In dieser Abbildung wird eine dezentral skalierte BizTalk-Topologie dargestellt, wobei von einem BizTalk-Server auf zwei BizTalk-Server skaliert wird. In der Topologie mit einem BizTalk-Server greifen drei Hostinstanzen gemeinsam auf die BizTalk-Computerressourcen zu. In der Topologie mit zwei BizTalk-Servern befindet sich der Übermittlungshost auf einem anderen Server, wodurch mehr Durchsatz erzielt wird.

Überlegungen beim dezentralen Skalieren der BizTalk-Ebene

Bevor Sie einen weiteren BizTalk Server-Computer hinzufügen, müssen Sie die folgenden Fragen überdenken:

Wie wird das System beim dezentralen Skalieren der BizTalk-Ebene für den Lastenausgleich und die Fehlertoleranz konfiguriert?

Die Auswahl von Lastenausgleich- und Fehlertoleranztechnologie richtet sich nach dem im Szenario verwendeten Adapter. Für SOAP- und HTTP-Adapter wird die Verwendung von NLB (Network Load Balancing, Netzwerklastenausgleich) empfohlen. Einzelheiten dazu finden Sie in der NLB-Dokumentation.

Wie werden die Hostinstanzen umgestaltet?

Wie Sie die Hostinstanzen beim dezentralen Skalieren der BizTalk-Ebene umgestalten sollten, lässt sich nicht in einer Regel ausdrücken. Ob und wie Hostinstanzen umgestaltet werden, hängt von der Komplexität des Szenarios ab. Im Folgenden finden Sie einige Beispiele für die Umgestaltung von Hostinstanzen.

Szenario 1

Konfiguration mit einem BizTalk-Server, wobei sich empfangende und sendende Hostinstanzen auf demselben Computer befinden.

Gehen Sie beispielsweise von einem CPU-Engpass aus. Sie fügen der Gruppe einen weiteren identischen BizTalk-Computer hinzu, um eine dezentrale Skalierung durchzuführen. Nun haben Sie zwei Möglichkeiten zum Umgestalten der Hostinstanzen.

Die beiden Lösungen lauten wie folgt:

• Lösung 1: Die einfachste Möglichkeit zum Factoring in diesem Szenario besteht darin, den Host instance Factoring vom ersten Computer zum zweiten Computer zu klonen. Hinsichtlich der Funktionalität ist hierbei der zweite Computer eine genaue Kopie des ersten und besitzt ebenfalls empfangende und sendende Hostinstanzen. Sofern es keinen weiteren Engpass gibt, erhalten Sie einen Skalierungsfaktor von 2, da die CPU-Ressourcen verdoppelt werden.

• Lösung 2: Eine weitere Möglichkeit, die Hostinstanzen zu berücksichtigen, besteht darin, die Empfangs- und Sendefunktionen auf verschiedene Computer zu isolieren. Auf diese Weise dient ein BizTalk-Server nur zum Empfangen und ein anderer nur zum Senden.

  Vergleich von Lösung 1 und Lösung 2

  In Lösung 1 wird die Anzahl der Hostinstanzen gegenüber der 1-BTS-Konfiguration verdoppelt. Dies führt zu einer höheren Anzahl an Sperrkonflikten auf dem SQL-Server. Die genaue Steigerungsrate bestimmt den Skalierungsfaktor. Wenn die Sperrkonflikte keinen weiteren Engpass verursachen, haben Sie einen Skalierungsfaktor von 2.

  Der Vorteil von Lösung 2 besteht darin, dass Sie nur über zwei Hostinstanzen verfügen, sodass der Sperrkonflikt auf dem SQL Server im Vergleich zu Lösung 1 geringer sein sollte. Der Skalierungsfaktor hängt jedoch vollständig von der Komplexität der Empfangs- und Sendehostinstanzen ab. Betrachten Sie die folgenden Fälle für die Lösung 2:

  Gehen Sie beispielsweise davon aus, dass die empfangenden und sendenden Hostinstanzen dieselbe Datenmenge verarbeiten und in der Topologie mit einem BizTalk-Server jeweils 50 % der CPU beanspruchen. In der Topologie mit zwei BizTalk-Servern verlegen Sie die sendende Hostinstanz auf einen anderen Computer, wobei sich die Ressourcen zum Empfangen und Senden jeweils verdoppeln. Sofern es keinen weiteren Engpass gibt, erhalten Sie einen Skalierungsfaktor von 2. Dieser Fall ist günstiger als Lösung 1, da bei nur zwei Hostinstanzen weniger Sperrkonflikte auftreten.

  Gehen Sie nun davon aus, dass die sendende Hostinstanz gegenüber der empfangenden Hostinstanz in der Topologie mit einem BizTalk-Server 80 % der CPU-Ressourcen beansprucht. Wenn Sie den Übertragungshost instance auf einen anderen Computer verschieben, erhalten Sie nur 20 % mehr CPU-Ressourcen, sodass der maximale Skalierungsfaktor 1,2 beträgt. Darüber hinaus verwendet der Computer mit dem Empfangshost instance nur 20-30 % CPU-Ressourcen, sodass der Vorteil der horizontalen Skalierung viel geringer ist.

  Betrachten Sie die nachfolgende Abbildung mit vier BizTalk-Servern. Jeder Computer ist sowohl Empfänger als auch Absender, sodass Sie insgesamt vier Hostinstanzen jedes Typs (Empfangen und Übertragen) erhalten.

  

  Diese Topologie ist eher ungünstig gestaltet. Sie sollten daher weitere Gestaltungsmöglichkeiten testen, je nach Komplexität des Szenarios. Beispiel:

• Weisen Sie zwei Computer für den Empfang und zwei für die Übertragung zu. Sofern beim Empfangen und Senden etwa die gleichen Datenmengen verarbeitet werden, erhalten Sie den größtmöglichen Skalierungsfaktor.

• Ist der Empfang intensiver als das Senden, verwenden Sie drei Computer zum Empfangen und nur einen zum Senden.

• Ist das Senden intensiver als das Empfangen, verwenden Sie drei Computer zum Senden und nur einen zum Empfangen.

  In allen Szenarien empfiehlt es sich, die Anzahl an Hostinstanzen auf jedem Host möglichst gering zu halten, sodass die Menge an Konflikten in der MessageBox-Datenbank reduziert und die Computerressourcen gleichzeitig optimal genutzt werden. Die beste Gestaltungsmöglichkeit hängt von der Komplexität des Szenarios und der Art des Engpasses ab. Testen Sie stets alle möglichen Szenarien, bevor Sie eine Umgestaltung abschließen.

Weitere Informationen

Zentrales Skalieren der BizTalk Server-Ebene
Zentrales Skalieren der SQL Server-Ebene
Dezentrale Skalierung der SQL Server-Ebene
Ausskalierte empfangende Hosts
Ausskalierte verarbeitende Hosts
Ausskalierte sendende Hosts
Verwenden des Windows Server-Clusters zum Bereitstellen von Hochverfügbarkeit für BizTalk Server Hosts2
Ausskalierte Datenbanken
Clustern von BizTalk Server-Datenbanken