Skalieren der SQL Server-Ebene

Für jede BizTalk-Gruppe fügen Sie eine Master MessageBox-Datenbank hinzu. Alle nachfolgenden MessageBox-Datenbanken, die Sie hinzufügen, werden als sekundäre MessageBoxes bezeichnet. Das Hauptnachrichtenfeld verarbeitet alle Abonnements und nachrichtenweiterleitungen. Sie kann auch Nachrichten veröffentlichen. Sekundäre MessageBox-Datenbanken veröffentlichen nur Nachrichten, wenn sie speziell für diese Aufgabe konfiguriert sind.

So fügen Sie eine sekundäre MessageBox-Datenbank hinzu

Es gibt zwei Möglichkeiten, sekundäre MessageBox-Datenbanken hinzuzufügen:

• Fügen Sie die sekundäre MessageBox-Datenbank auf demselben physischen Server hinzu.

  Führen Sie dies aus, wenn der vorhandene physische MessageBox-Server über genügend CPU- und E/A-Ressourcen verfügt und nur durch Sperrkonkurrenz ein Engpass besteht. Erstellen Sie die sekundäre MessageBox-Datenbank auf separaten E/A-Laufwerken.

  Vorteile:

  • Der zusätzliche CPU-Kopfraum kann von einem anderen Meldungsfeld genutzt werden.

  • Weniger SQL Server-Lizenzen sind erforderlich.

  • Der Netzwerk-Hop wird eliminiert.

• Hinzufügen der sekundären MessageBox-Datenbank auf einem anderen physischen Server

  Verwenden Sie in diesem Fall einen dedizierten physischen Server mit eigener E/A als zusätzliche MessageBox-Datenbank.

  Die folgende Abbildung zeigt ein Szenario, in dem die SQL-Ebene aus einer MessageBox-Datenbank auf drei MessageBoxes-Datenbanken skaliert wird.

  

Wann die MessageBox-Datenbank skaliert werden sollte

• Die MessageBox-Datenbank wird zum Engpass. Diese Engpässe können folgendes sein:

  • CPU Bei sehr kostspieligen und komplexen Orchestrierungsszenarien verbraucht die MessageBox-Datenbank schwere CPU-Ressourcen. Das Hinzufügen einer weiteren Veröffentlichung der MessageBox-Datenbank sollte dazu beitragen, den Durchsatz zu erhöhen.

  • Sperrwettbewerb Komplexe Szenarien mit mehreren Hostinstanzen oder Orchestrierungen neigen dazu, Sperrwettbewerb in der MessageBox-Datenbank zu erzeugen. Auch hier sollte das Hinzufügen einer weiteren Veröffentlichungs-MessageBox-Datenbank dazu beitragen, den Durchsatz zu erhöhen.

• Das Hochskalieren löst den Engpass nicht. Wenn z. B. die Master MessageBox-Datenbank durch Sperrkonflikte gebunden ist, ist eine Skalierung nach außen die einzige Option.

• Die Skalierung ist zu teuer. Wenn beispielsweise das Upgrade des vorhandenen Quad proc-Servers auf 8-Wege-Server teurer ist als das Hinzufügen eines anderen Quad-Proc-Servers, ist die Skalierung eine bessere Option.

Wenn Sie die SQL-Ebene nicht skalieren können

Theoretisch sollte die SQL-Ebene unbegrenzt skaliert werden, solange die Master MessageBox-Datenbank nicht der Engpass ist. Um dies zu erreichen, erwägen Sie, die Master MessageBox-Datenbank zu einer nicht veröffentlichenden Datenbank zu machen, sodass nur Routing erfolgt. Sobald der Master jedoch durch Lock-Contention eingeschränkt ist, können Sie die SQL-Ebene nicht mehr skalieren.

Skalierungsstrategien und Überlegungen

• Zuerst die Master MessageBox-Datenbank hochskalieren und dann verteilen.

• Skalieren von 1 auf 3 SQL MessageBox-Datenbanken anstelle von 1 auf 2. Betrachten Sie die 1 SQL Server-Topologie, die in der obigen Abbildung mit dem Titel "4 BizTalk Server, 1 SQL Server Topology" dargestellt ist, 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-gebunden, und die sekundäre MessageBox-Datenbank wird unterausgelastet. Der Skalierungsfaktor ist also fast 1. Wenn Sie die Veröffentlichung in der Master MessageBox-Datenbank deaktivieren und die Master MessageBox-Datenbank nur für die Weiterleitung verwenden, führt die sekundäre MessageBox-Datenbank die Veröffentlichung durch. Dies hilft jedoch nicht, den gesamten Durchsatz zu erhöhen, da die sekundäre MessageBox-Datenbank der einzige Herausgeber ist und immer noch zum Engpass wird. Das Hinzufügen von zwei sekundären MessageBox-Datenbanken und das Deaktivieren der Veröffentlichung in der Master MessageBox-Datenbank wäre also die empfohlene Möglichkeit zum Skalieren in diesem Szenario.

• Die Master MessageBox-Datenbank wird schließlich der Engpass sein. Der physische Computer, auf dem die Master MessageBox-Datenbank gehostet wird, sollte also schneller und größer sein.

• Um das Senden von Daten über das Netzwerk (und den damit verbundenen DTC-Aufwand) zu minimieren, sollten Sie mehrere MessageBox-Datenbanken auf demselben physischen Computer mit dedizierten Laufwerken platzieren. Stellen Sie gleichzeitig sicher, dass der Computer, auf dem diese mehreren Datenbanken gespeichert sind, nicht zum Engpass wird, da die Ressourcen von mehreren MessageBox-Datenbanken geteilt werden.

• Alle sekundären MessageBox-Datenbanken sollten vergleichbare Hardware verwenden, da die Arbeit gleichmäßig auf die Veröffentlichungsdatenbanken von MessageBox verteilt wird.

• Da Sie sekundäre MessageBox-Datenbanken skalieren können, solange die MessageBox-Masterdatenbank nicht eng ist, können sekundäre MessageBox-Datenbanken auf Computern mit weniger CPU-Ressourcen ausgeführt werden, als vom Master-MessageBox-Datenbankserver benötigt werden.

Siehe auch

Skalieren der BizTalk Server-Ebene
Skalieren der BizTalk Server-Ebene
Skalieren der SQL Server-Ebene
Scaled-Out Empfänger-Hosts
Scaled-Out Verarbeitung von Hosts
Scaled-Out Senden von Hosts
Verwenden des Windows Server-Clusters zur Bereitstellung hoher Verfügbarkeit für BizTalk Server Hosts2
Scaled-Out Datenbanken
Clustering the BizTalk Server Databases