CONNECTED Conference 2023 - Aufzeichnungen jetzt hier verfügbar +++                     

Suche

über alle News und Events

 

Alle News

 

Vom 5. bis 7. Juni findet in London wieder die...

Weiterlesen

Live Coding on stage in Hamburg - exklusiv für...

Weiterlesen

Um Azure Ressourcen von DevOps aus zu deployen,...

Weiterlesen

In diesem Artikel wird ein beispielhafter Aufbau...

Weiterlesen

Die QUIBIQ Gruppe wurde am 9. März 2023 von dem...

Weiterlesen

Der Schnelleinstieg in die Welt der Tests für den...

Weiterlesen

Wenn man eine, im Azure Portal, entwickelte Logic...

Weiterlesen

WinSCP für BizTalk wird für den SFTP-Adapter...

Weiterlesen

Mit diesem Artikel wird ein klares Verständnis von...

Weiterlesen

In einer Logic App werden häufig Variablen...

Weiterlesen

How-to: quiTeq Biztalk Cluster

Im Rahmen eines Projekts zur Bereitstellung einer Hochverfügbarkeitsumgebung für BizTalk Server war es erwünscht, die Konfiguration der Hostinstanzen automatisch während des Deployments auszuführen. Im Folgenden wollen wir kurz vorstellen, wie wir dieses Problem erfolgreich lösen konnten.

Hosts

Um Hosts in Biztalk automatisch für ein Clusterenviroment zu konfigurieren hat es sich gezeigt, dass sich hierzu Powershell in Verbindung mit WMI am besten eignet. Hierzu kann das WMI Objekt  MSBTS_Host ( https://docs.microsoft.com/en-us/biztalk/core/technical-reference/msbts-host-wmi ) verwendet werden.

Mithilfe von

Kann geprüft werden, ob der Host bereits clustered ist. Sollen Hosts unclustered werden, kann das mit der .uncluster Methode erreicht werden.

Um Hosts zu clustern wird die .cluster Methode aufgerufen, der als Parameter die Cluster Resource Group als String übergeben. Hierdurch werden alle Hostinstanzen des Hosts der mit $HostName ausgewählt wurde clustered.

Clustered Hosts sind active passive. Das heißt sie funktionieren als Failover Knoten in Hochverfügbarkeitsumgebungen. Hostinstanzen die in einem BizTalk Server Cluster nicht clustered sind und auf mehreren Knoten erstellt wurden, arbeiten als Active/Active Knoten.

Es empfiehlt sich zum Beispiel FTP- oder SFTP-Adapter Empfangs Handlers in einer geclusterten BizTalk-Host Instanz auszuführen, um nicht mehrere Kopien derselben Datei zu empfangen.

 

Applicationprobleme

Werden Applikationen clustered muss natürlich bedacht werden, dass sie auch failover fähig sein sollten. Das heißt es sollte zum Beispiel darauf verzichtet werden, lokales caching oder threadstatics zu verwenden, da sie Informationen verwenden, die nur für den jeweiligen Node zugänglich sind und nicht durch BizTalk persistiert werden. Das gleiche Probleme besteht folglich auch bei Memory caches.

Es sollte also darauf verzichtete werden, Daten zu cachen, die sich im Laufe der Verarbeitung ändern können. Wird trotzdem ein cache verwendet, ist zu empfehlen, vor dem Zugriff zu prüfen, ob die Daten aktualisiert werden müssen.

Weiterhin ist darauf zu achten, dass Nachrichten nicht parallel versendet werden sollten, um zu vermeiden, Nachrichten im Failoverfall doppelt zu versenden.

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz