Suche

über alle News und Events

 

Alle News

 

Wir haben während unseres...

Weiterlesen

Azure Functions benötigen oft einen...

Weiterlesen

In der heutigen Zeit nehmen Erreichbarkeit,...

Weiterlesen

Viele unserer Kunden überlegen derzeit, was sie in...

Weiterlesen

Lösungsansatz – was benötigt man dafür:

  • Einen...
Weiterlesen

Es gibt im Preview die Möglichkeit Azure Blob...

Weiterlesen

Die wichtigste Konferenz zu Integration auf der...

Weiterlesen

In diesem Blogeintrag werden wir drei sichere und...

Weiterlesen

Im vergangenen Jahr war bei uns in Hamburg viel in...

Weiterlesen

Heutzutage werden Token für die Authentifizierung...

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