Dezentrale Skalierung der SQL Server-Ebene
Fügen Sie für jede BizTalk-Gruppe eine MessageBox-Masterdatenbank hinzu. Alle MessageBox-Datenbanken, die Sie nachfolgend hinzufügen, werden als "sekundäre MessageBox-Datenbanken" bezeichnet. Die MessageBox-Masterdatenbank verarbeitet alle Abonnements und die gesamte Nachrichtenweiterleitung. Sie kann außerdem Nachrichten veröffentlichen. Sekundäre MessageBox-Datenbanken veröffentlichen Nachrichten nur dann, wenn sie explizit dazu konfiguriert wurden.
Hinzufügen einer sekundären MessageBox-Datenbank
Es gibt zwei Methoden zum Hinzufügen sekundärer MessageBox-Datenbanken:
Hinzufügen der sekundären MessageBox-Datenbank auf demselben physischen Server
Verfahren Sie auf diese Weise, wenn der vorhandene physische MessageBox-Server über ausreichende CPU- und E/A-Ressourcen verfügt und Engpässe nur bei Sperrkonflikten zu erwarten sind. Erstellen Sie die sekundäre MessageBox-Datenbank auf separaten E/A-Laufwerken.
Vorteile:
Die zusätzlichen CPU-Reserven können von einer anderen MessageBox-Datenbank genutzt werden.
Es sind weniger SQL Server-Lizenzen erforderlich.
Der Networkhop wird eliminiert.
Hinzufügen der sekundären MessageBox-Datenbank auf einem anderen physischen Server
Verwenden Sie in diesem Fall einen dedizierten physischen Server mit eigenem E/A-System als zusätzliche MessageBox-Datenbank.
In der folgenden Abbildung ist ein Szenario dargestellt, in dem die SQL-Ebene von einer MessageBox-Datenbank durch dezentrale Skalierung auf drei MessageBox-Datenbanken verteilt wird.
Der richtige Zeitpunkt für die dezentrale Skalierung der MessageBox-Datenbank
Die MessageBox-Datenbank wird zu einem Engpass. Solche Engpässe können sein:
CPU Bei sehr teuren und komplexen Orchestrierungsszenarien verbraucht die MessageBox-Datenbank hohe CPU-Ressourcen. Durch Hinzufügen einer weiteren veröffentlichenden MessageBox-Datenbank kann der Durchsatz gesteigert werden.
Sperrkonflikte Komplexe Szenarien mit mehreren Hostinstanzen oder Orchestrierungen führen in der Regel zu Sperrenkonflikten in der MessageBox-Datenbank. Durch Hinzufügen einer weiteren veröffentlichenden MessageBox-Datenbank kann auch in diesem Fall der Durchsatz gesteigert werden.
Eine zentrale Skalierung behebt den Engpass nicht. Wenn die MessageBox-Masterdatenbank beispielsweise an Sperrkonflikte gebunden ist, ist die dezentrale Skalierung die einzige Möglichkeit.
Das Hochskalieren ist zu teuer. Wenn beispielsweise das Aktualisieren eines vorhandenen Servers mit vier Prozessoren auf einen Server mit acht Prozessoren kostspieliger ist als das Hinzufügen eines weiteren Servers mit vier Prozessoren, ist die dezentrale Skalierung die bessere Option.
Wann ist eine dezentrale Skalierung der SQL-Ebene nicht möglich?
Theoretisch müsste eine unbegrenzte Skalierung der SQL-Ebene möglich sein, so lange die MessageBox-Masterdatenbank nicht den Engpass darstellt. Sie können dies erzielen, indem Sie in Erwägung ziehen, die MessageBox-Masterdatenbank zu einer Datenbank zu machen, die nicht veröffentlicht, sondern nur für die Weiterleitung zuständig ist. Wenn in der MessageBox-Masterdatenbank jedoch aufgrund von Sperrkonflikten Engpässe auftreten, ist eine dezentrale Skalierung der SQL-Ebene nicht mehr möglich.
Strategien und Überlegungen für die dezentrale Skalierung
Führen Sie zunächst eine zentrale Skalierung der MessageBox-Masterdatenbank durch, bevor Sie sie dezentral skalieren.
Hochskalieren von 1 auf 3 SQL MessageBox-Datenbanken anstelle von 1 bis 2. Betrachten Sie die 1 SQL Server-Topologie, die in der obigen Abbildung mit dem Titel "4 BizTalk Server, 1 SQL Server Topologie" veranschaulicht wird, und gehen Sie davon aus, dass der SQL Server CPU-gebunden ist, d. h. die CPU-Verarbeitung ist ein Engpass. Wenn Sie dieser Topologie nur eine MessageBox-Datenbank hinzufügen, bleibt die Master-MessageBox weiterhin CPU-abhängig, während die zweite MessageBox-Datenbank nur unzureichend genutzt wird. Der Skalierungsfaktor ist also fast 1. Wenn Sie die Veröffentlichung in der Master MessageBox-Datenbank deaktivieren und die Master-MessageBox-Datenbank nur dem Routing widmen, führt die sekundäre MessageBox-Datenbank die Veröffentlichung durch. Dadurch wird der Durchsatz insgesamt jedoch nicht gesteigert, denn die sekundäre MessageBox-Datenbank ist nun allein für das Veröffentlichen zuständig und wird ihrerseits zum Engpass. Aus diesem Grund würde in diesem Szenario empfohlen, zum dezentralen Skalieren zwei sekundäre MessageBox-Datenbanken hinzuzufügen und die Veröffentlichungsfunktion in der MessageBox-Masterdatenbank zu deaktivieren.
Die MessageBox-Masterdatenbank wird schließlich zum Engpass. Daher sollte ein größerer und schnellerer physischer Computer als Host für die MessageBox-Masterdatenbank verwendet werden.
Damit nicht so viele Daten über das Netzwerk gesendet werden (und der zugehörige DTC-Overhead in Grenzen bleibt), sollten Sie eventuell mehrere MessageBox-Datenbanken auf demselben physischen Computer mit dedizierten Laufwerken unterbringen. Stellen Sie gleichzeitig sicher, dass der Computer, auf dem sich diese Datenbanken befinden, nicht zum Engpass wird, wenn die Ressourcen von mehreren MessageBox-Datenbanken gemeinsam genutzt werden.
Alle sekundären MessageBox-Datenbanken sollten vergleichbare Hardware verwenden, da die Arbeit gleichmäßig zwischen den veröffentlichenden MessageBox-Datenbanken aufgeteilt wird.
Da sekundäre MessageBox-Datenbanken dezentral skaliert werden können (so lange nicht die MessageBox-Masterdatenbank zum Engpass wird) können sekundäre MessageBox-Datenbanken auf Computern ausgeführt werden, die eine geringere CPU-Leistung als der Server mit der MessageBox-Masterdatenbank haben.
Weitere Informationen
Dezentrales Skalieren der BizTalk Server-Ebene
Zentrales Skalieren der BizTalk Server-Ebene
Zentrales Skalieren 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