Migrieren vom MSMQT-Adapter zum MSMQ-Adapter
In diesem Thema werden hinsichtlich der geordneten End-to-End-Übermittlung, der Transaktionskonsistenz, der Hochverfügbarkeit und Skalierbarkeit zu berücksichtigende Punkte besprochen, bevor Lösungen des BizTalk Message Queuing-Adapters (MSMQT) zum Message Queuing-Adapter (MSMQ) migriert werden. Die unter diesem Thema aufgeführte geordnete Übermittlung, die Transaktionskonsistenz, die Hochverfügbarkeit und die Skalierbarkeit werden wie folgt definiert:
Geordnete Übermittlung: Diese garantiert, dass Nachrichten von BizTalk Server in derselben Reihenfolge versendet werden, in der sie auch empfangen wurden.
Transaktionskonsistenz: Diese garantiert, dass verarbeitete Nachrichten nicht aufgrund von Hardware-, Software- oder Netzwerkfehlern verloren gehen oder dupliziert werden.
Hochverfügbarkeit. Diese garantiert, dass die zum Verarbeiten von Nachrichten verwendeten Dienste immer für die Verarbeitung zur Verfügung stehen.
Skalierbarkeit. Beschreibt die Möglichkeit, vorhandene Kapazitäten für die Nachrichtenverarbeitung zu erhöhen.
End-to-End-Lieferung
Der MSMQT-Adapter stellt die geordnete End-to-End-Übermittlung von Nachrichten sicher. Das bedeutet, dass wenn eine MSMQ-Anwendung die Nachrichten 1, 2 und 3 an einen Empfangsspeicherort sendet, der an den MSMQT-Adapter gebunden ist, dann werden diese Nachrichten in derselben Reihenfolge an eine Orchestrierung oder an einen Sendeport in BizTalk Server übermittelt: 1, 2, 3. Eine dieser Funktionen kann Börsengeschäfte einbeziehen, die in derselben Reihenfolge übermittelt und ausgeführt werden müssen, in der sie empfangen werden.
Die geordnete End-to-End-Übermittlung mit MSMQT erfordert, dass viele Komponenten zusammenarbeiten. Die folgende Sequenz von Ereignissen veranschaulicht, wie dies mit dem MSMQT-Adapter ausgeführt wird:
Die MSMQ-API auf einem Remotecomputer empfängt die Nachrichten 1, 2 und 3 in dieser Reihenfolge und stellt diese in derselben Reihenfolge in eine lokale Transaktionswarteschlange: 1, 2, 3.
Ein MSMQ-Client auf dem Remotecomputer nimmt die Nachrichten aus der Warteschlange und sendet sie in der folgenden Reihenfolge an die MSMQT-Warteschlange: 1, 2, 3.
Der MSMQT-Adapter empfängt die Nachrichten in der Reihenfolge 1, 2, 3 und übergibt sie in derselben Reihenfolge an die BizTalk MessageAgent-Komponente: 1, 2, 3.
Die BizTalk MessageAgent-Komponente stellt sicher, dass die Nachrichten in der folgenden Reihenfolge an die MessageBox gesendet werden: 1, 2, 3.
Die MessageBox leitet die Nachrichten weiter und stellt für den Fall sicher, dass sie an dieselbe Instanz einer Orchestrierung oder eines Sendeports weitergeleitet werden, dass sie in derselben Reihenfolge an diese Instanz übermittelt werden: 1, 2, 3.
Im BizTalk Server 2004 war MSMQT der einzige Adapter, der eine End-to-End-Lieferung garantieren konnte. Alle anderen integrierten BizTalk-Adapter können die Reihenfolge der Nachrichten in den zuvor aufgeführten Schritten 3 bis 5 potenziell ändern. Die meisten anderen integrierten Adapter beenden Schritt 3 mithilfe einer Komponente, die als Endpunkt-Manager (EPM) bekannt ist und von Natur aus im Multithread-Modus ausgeführt wird und daher die Reihenfolge nicht bewahrt. Der BizTalk Server 2004-MSMQ-Adapter hat ein Feature "Serielle Verarbeitung" verwendet, das die Reihenfolge für Schritt 3 behält, aber der MessageAgent wird dann nicht aufgefordert, die Reihenfolge beizubehalten, sodass die Nachrichten möglicherweise an eine Orchestrierung weitergeleitet werden oder den Port in ungeordneter Reihenfolge senden.
End-to-End-Lieferung mit dem MSMQ-Adapter
Führen Sie die folgenden Schritte aus, um eine End-to-End-Lieferung mit dem MSMQ-Adapter zu erzielen:
Aktivieren Sie die Ordered Delivery-Eigenschaft am Empfangsport für die abonnierende Orchestrierung oder den Sendeport. In BizTalk Server verfügen Empfangsports in Orchestrierungen und Sendeports über die Konfigurationsoption Ordered Delivery. Wenn diese Option aktiviert ist, fordert der Empfangsport der Orchestrierung oder der Sendeport die MessageBox auf, die Nachrichten in derselben Reihenfolge an sie zu senden, in der sie an die MessageBox übermittelt wurden.
Legen Sie die Ordered Processing-Eigenschaft für den Empfangsspeicherort, der an den MSMQ-Adapter gebunden ist, auf fest
True
. In BizTalk Server können Empfangsspeicherorte, die den MSMQ-Transport verwenden, für die Verwendung der geordneten Verarbeitung konfiguriert werden. Bei Aktivierung wird sichergestellt, dass Nachrichten in der gleichen Reihenfolge an die MessageBox gesendet werden, in der sie empfangen wurden.Legen Sie die Transactional-Eigenschaft für den Empfangsspeicherort, der an den MSMQ-Adapter gebunden ist, auf fest
True
.Stellen Sie sicher, dass alle von den MSMQ-Empfangsspeicherorten überwachten MSMQ-Warteschlangen als „Transaktional“ gekennzeichnet sind. Diese Eigenschaft muss für die Warteschlangen festgelegt werden, um die geordnete Übermittlung von Nachrichten sicherzustellen.
Hinweis
Die geordnete Übermittlung ist nur garantiert, wenn die MSMQ-Warteschlange(n), die von BizTalk-Empfangsspeicherorten überwacht wird/werden, nur von einem Computer versorgt werden. Dies kann Probleme hinsichtlich der Skalierbarkeit bedeuten, wie nachfolgend beschrieben.
Transaktionsverwendung beim Verarbeiten von Nachrichten mit dem MSMQT-Adapter im Vergleich zum MSMQ-Adapter
Hinsichtlich der Transaktionsnutzung gibt es einen wesentlichen Unterschied zwischen der Verarbeitung von Nachrichten durch den MSMQT- und dem MSMQ-Adapter.
Bei der Verwendung des MSMQT-Adapters wird das Empfangen einer Nachricht aus dem Netzwerk und deren Verarbeitung mit BizTalk Server unter einer einzelnen Transaktion behandelt. Bei der Verwendung des MSMQT-Adapters stellen für den Absender generierte Bestätigungsmeldungen ein Anzeichen dar, dass die Nachricht empfangen und erfolgreich von BizTalk Server verarbeitet wurde.
Bei der Verwendung des MSMQ-Adapters wird das Empfangen einer Nachricht aus dem Netzwerk und deren Verarbeitung mit BizTalk Server unter zwei separaten Transaktionen abgehandelt. Eine Transaktion zum Empfangen aus dem Netzwerk und eine Transaktion für die Verarbeitung mit BizTalk Server. Bei der Verwendung des MSMQ-Adapters stellen für den Absender generierte Bestätigungsmeldungen nur ein Anzeichen dar, dass die Nachricht erfolgreich empfangen wurde, aber nicht, dass sie von BizTalk Server erfolgreich verarbeitet wurde. Der Absender empfängt eine Bestätigung vom Microsoft Message Queuing-Server, wenn die Nachricht aus dem Netzwerk empfangen wird und in die lokale MSMQ-Warteschlange gesendet wird, unabhängig davon, ob BizTalk Server installiert ist. Nachdem die Nachricht in die MSMQ-Warteschlange gesendet wurde, nimmt der BizTalk MSMQ-Adapter sie auf, verarbeitet sie und veröffentlicht die Nachricht dann in der MessageBox. Wenn dieser Prozess fehlschlägt, wird die Nachricht entweder an die angehaltene BizTalk-Warteschlange gesendet oder in der lokalen MSMQ-Warteschlange belassen (bei der Verwendung der Transaktionsverarbeitung), und der Absender erhält kein Anzeichen, dass ein Fehler bei der Verarbeitung in BizTalk Server aufgetreten ist.
Wenn es Ihre Architektur erfordert, dass Sie nach dem erfolgreichen der Nachrichten durch BizTalk Server Bestätigungen erhalten, dann müssen Sie Bestätigungen auf Anwendungsebene hinzufügen, wenn die Migration vom MSMQT-Adapter zum MSMQ-Adapter erfolgt. Sie müssen Ihre Orchestrierung und Sendeanwendung aktualisieren, um Bestätigungen auf Anwendungsebene zu implementieren.
Hohe Verfügbarkeit (Transaktional, geordnet)
Um Hochverfügbarkeit für den MSMQT-Adapter bereitzustellen, können Sie dem Empfangshost entweder mehrere Computer hinzufügen und netzwerklastenausgleich (Network Load Balancing, NLB) für Fehlertoleranz konfigurieren oder den BizTalk-Standardhost clustern. Wenn Sie den MSMQT-Adapter zusammen mit dem Netzwerklastenausgleich ausführen, übernimmt beim Ausfall eines Servers der andere Server die Bearbeitung der Last. Wenn Sie die MSMQT-Adapterhandler auf einem Clusterhost ausführen, schlägt beim Ausfall eines Hostknotens die Clustersoftware über den Clusterhost auf dem anderen Knoten fehl. Wenn Sie den MSMQ-Adapter verwenden, funktioniert der Netzwerklastenausgleich nicht, wenn die Transaktionsverarbeitung ohne Datenverlust erforderlich ist, da der MSMQ-Adapter lokale MSMQ-Warteschlangen für die Zwischenspeicherung verwendet. Wenn in diesem Szenario eine Nachricht an die lokale MSMQ-Warteschlange übermittelt, aber nicht vom MSMQ-Adapter verarbeitet wurde, dann ist die Nachricht verloren, wenn der Computer fehlschlägt.
Gehen Sie wie folgt vor, um Hochverfügbarkeit und Transaktionskonsistenz mit dem MSMQ-Adapter zu gewährleisten:
Konfigurieren Sie Microsoft Message Queuing (MSMQ) als geclusterte Ressource in einer Windows Server-Clustergruppe auf Ihren BizTalk-Servern.
Konfigurieren Sie den MSMQ-Adapterempfangshandler in einer BizTalk-Hostinstanz, die als Clusterressource in derselben Clustergruppe wie die geclusterte MSMQ-Ressource konfiguriert wurde.
Konfigurieren Sie die Clusterressource für die BizTalk-Hostinstanz, damit diese eine Abhängigkeit zur MSMQ-Clusterressource bewahrt.
Um die geordnete Übermittlung mit dieser Architektur zu implementieren, führen Sie die schritte aus, die zuvor unter "End-to-End-geordnete Zustellung mit dem MSMQ-Adapter" beschrieben wurden.
Hohe Verfügbarkeit (Nichttransaktional, geordnet)
Wenn Hochverfügbarkeit, aber keine Transaktionsverarbeitung erforderlich ist, können Sie dies mit dem MSMQ-Adapter erreichen, indem Sie den Netzwerklastenausgleich implementieren und Instanzen eines Hosts ausführen, der mit den MSMQ-Sende- und -Empfangshandlern auf mehreren BizTalk-Servern hinter dem Netzwerklastenausgleich konfiguriert wurde. Bei der Implementierung von NLB mit MSMQ sollten Sie die bewährten Methoden befolgen, die im Microsoft Knowledge Base-Artikel 899611 : Funktionsweise von Message Queuing über Netzwerklastenausgleich (NLB) dokumentiert sind. Wenn in diesem Szenario ein Server ausfällt, sind die in der Hostinstanz auf diesem BizTalk-Server ausgeführten Nachrichten nicht verfügbar, bis der BizTalk-Server wiederhergestellt wurde. Diese Konfiguration bietet Hochverfügbarkeit, da der Netzwerklastenausgleich bei mangelnder Verfügbarkeit eines BizTalk-Servers die Anforderungen an den anderen BizTalk-Server weiterleitet.
Skalierbarkeit (Nichttransaktional, nicht geordnet)
Sie können die Skalierbarkeit erreichen, indem Sie die Richtlinien für die Hochverfügbarkeit (Nichttransaktional) befolgen und zusätzliche Hostinstanzen hinzufügen. Diese Architektur bietet eine schnelle Übermittlung sowie die Skalierbarkeit, stellt jedoch keine geordnete Übermittlung bereit.
Skalierbarkeit (Transaktional, nicht geordnet)
Für die transaktionale Übermittlung von Nachrichten ohne eine geordnete Übermittlung können Sie die Verwendung des Netzwerklastenausgleichs mit MSMQ und dem Windows-Clusterdienst kombinieren. Diese Architektur erfordert, dass Sie mindestens zwei Clustergruppen in zwei separaten Windows-Clusterumgebungen konfigurieren, wobei Sie für jeden Windows-Cluster die Schritte unter „Hohe Verfügbarkeit (Transaktional, geordnet)“ befolgen. Dann implementieren Sie den Netzwerklastenausgleich, um die Last zwischen den Clustergruppen zu verteilen. Da der Windows-Netzwerklastenausgleich nicht für die Ausführung auf einem Windows-Cluster unterstützt wird, erfordert dieses Szenario eine Hardwarelösung für den Netzwerklastenausgleich. Diese Architektur wird anhand des folgenden Diagramms veranschaulicht.
Hinweis
Diese Architektur bietet keine geordnete Übermittlung.
Skalierbarkeit (Transaktional, geordnet)
Die Skalierung einer Architektur, die Hochverfügbarkeit, eine Transaktionskonsistenz und eine geordnete Übermittlung bietet, ist problematisch, wenn Sie MSMQ 3.0 oder früher verwenden, da transaktionale Remotelesevorgänge nicht unterstützt werden, so lange nicht sowohl der BizTalk Server-Computer als auch der MSMQ-Remoteserver MSMQ 4.0 ausführen. Wenn Sie MSMQ 3.0 oder früher ausführen, muss die Skalierung mithilfe mehrerer lokaler MSMQ-Warteschlangen erreicht werden. Außerdem muss in diesem Szenario, wenn die TCP/IP-Verbindung für die MSMQ-Sitzung mit dem Netzwerklastenausgleich unterbrochen ist, diese anschließend wieder vom Netzwerklastenausgleich mit einem anderen Computer wiederhergestellt werden, was zu einer ungeordneten Übermittlung führen kann.
Eine mögliche Problemumgehung für diese Einschränkung ist der manuelle Lastenausgleich für die Nachrichtenübermittlung, indem Zielwarteschlangen auf verschiedenen Computern zugeordnet werden. Dazu binden Sie bestimmte BizTalk-Hostinstanzen an bestimmte MSMQ-Warteschlangen. Wenn Sie z. B. eine große Anzahl von Dokumenten von einem bestimmten Handelspartner empfangen, dann erstellen Sie einen separaten Host und eine Empfangswarteschlange ausschließlich für diesen Handelspartner auf einem bestimmten BizTalk-Server.
Führen Sie nach Möglichkeit MSMQ 4.0 auf Remotecomputern aus, wenn sowohl transaktionale Remotelesevorgänge als auch der Lastenausgleich erforderlich sind.
Zusammenfassung
In der folgenden Tabelle sind die Architekturen zusammengefasst, die Sie implementieren können, um bestimmte Funktionen aufzunehmen.
Funktion | Weder Netzwerklastenausgleich noch Cluster | NLB | Cluster | Netzwerklastenausgleich und Cluster |
---|---|---|---|---|
Geordnete End-to-End-Übermittlung | Ja | Nein | Ja | Möglich durch manuelle Konfiguration |
Transaktionskonsistenz | Nein (Nachrichten können bei Dienstfehlern verloren gehen oder dupliziert werden) | Nein | Ja | Yes |
Hoch verfügbar | Nein | Ja | Yes | Yes |
Skalierbar | Nein | Ja | Nein | Ja |