none
Architekturfrage: Instanzen für das Empfangen und Verarbeiten von Nachrichten

    Frage

  • Hallo zusammen,

    wir denken derzeit über eine neue Architektur unserer EAI Landschaft nach. Folgende Anforderungen würde ich gerne umsetzen:

    - 1 Biztalk Server, welcher in der DMZ steht und nur Nachrichten von extern empfängt und in die Message Box (oder Message Boxen) weitergibt.

    - 2 Biztalk Server, welche die Transaktionen verarbeiten und die Nachrichten wieder versenden

    - 2 SQL Server (FailOver Cluster), welche die Message Boxen zur Verfügung stehen.

    Ist dies möglich? Bzw. gibt es hier Punkte, auf welche ich besonders achten muss?

    Funktioniert die Architektur mit dem Empfangs-Server auch, wenn mehrere Message Boxen zur Verfügung stehen - sprich im Hintergrund vier SQL Server (2 FailOver SQL Cluster) ihre Arbeit erledigen?

    Kann ich beim Empfangs-Server auch zwei Server verwenden? Was passiert hier mit Http Empfang-Ports? 

    Danke & schöne Grüße

    Florian

    Montag, 28. Februar 2011 08:35

Antworten

  • Hallo Florian,

    wenn ich es richtig verstanden habe, benötigst Du eine externe EDI-Anbindung. Vermutlich über AS/2. Eine Möglichkeit wäre kein eigenes BTS Server in DMZ zu installieren, sondern einen IIS 7.0 Server mit der Weiterleitung an BizTalk Server in LAN. Man benutzt dementsprechend 2 IIS 7.0 Server: eine in DMZ als Reverse Proxy und der anderen auf dem BTS Server für http Empfangs Port.

     

    Eventuell könnte folgendes Beispiel Dir helfen:

    (Sample Architecture: HTTP and SOAP Adapters)

    http://msdn.microsoft.com/en-us/library/aa577383.aspx

     

    Und

     

    Reverse Proxy with URL Rewrite v2 and Application Request Routing

    http://learn.iis.net/page.aspx/659/reverse-proxy-with-url-rewrite-v2-and-application-request-routing/

     

     

    Viele Grüße,

     

    Alex.

    Montag, 28. Februar 2011 09:16
  • Hallo Florian,

    "FTP adapter receive handlers should not, however, be configured to run in multiple BizTalk host instances simultaneously."

    Grundsätzlich geht's also, aber es sollte immer nur  einer aktiv sein. Hintergrund ist, dass sonst beide Adapter (die ja in 2 Windows Services auf zwei Servern laufen) auf die gleiche Datei zugreifen könnten und sich so selbst behindern und Fehler verursachen können.

    Wenn du ein MSCS Cluster aufsetzt, hast du alles automatisiert. Dann kannst du aber leider kein Load Balancing nutzen (was bei der Nachrichtenzahl vielleicht zu empfehlen wäre). Wenn du zwei BizTalk Server in eine Gruppe ziehst, kannst du zum Beispiel einen für Receive und Send sowie Orchestrations und einen nur für Orchestrations nutzen. Dafür musst du im Fehlerfall eventuell von Hand eingreifen. Dies kann man jedoch auch Scripten (SCOM + Scripte), erforder aber etwas mehr Know-How. Ich würde diese Lösung aber auf jeden Fall vorziehen.

    200.000 pro Tag -> 2 pro Sekunde. Das sollte problemlos machbar sein. Vor allem kannst du mit dem Feintuning der Instanzparameter und zwei Servern in einer Gruppe mehr erreichen als mit zwei Messageboxen. Ansonsten frag mal die SQL Experten, ob die noch weitere Optimierungsmöglichkeiten sehen.

    Der mir bekannte "Rekord" liegt bei > 1000 Nachrichten pro Sekunde.


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://pi.hauth.me

    Montag, 28. Februar 2011 14:57
  • Hallo Florian,

    Ein Multi-Messagebox Design sieht so aus das es immer eine Master - Message Box gibt welche die Nachrichten an die weiteren MessageBox Datenbanken weiterleitet. Das bedeutet also dass Nachrichten immer durch die Master - Messagebox laufen werden. Grundsätzlich ist zu beachten dass beim skalieren der MessageBox immer drei MessageBox Datenbanken angelegt werden. Ansonsten erhöht man lediglich den Aufwand den BizTalk Server mit der Verwaltung der Datenbanken hat.

    Des weiteren sollte man für die Skalierung der MessageBox Datenbank gute Gründe haben. Nur wenn die MessageBox Datenbank auch tatsächlich der Flaschenhals ist sollte das Design hier angepasst werden. Meistens sind Themen wie Disk I/O, Netzwerk oder Speicher der erste Flaschenhals und nicht Konkurenzsituation auf der MessageBox Datenbank.

    Mehr Informationen dazu auch hier:

    http://msdn.microsoft.com/en-us/library/cc296848(v=bts.10).aspx

    und im BizTalk Server Performance Guide:

    http://msdn.microsoft.com/en-us/library/ee377064(v=BTS.70).aspx

    Viele Grüße,

    Stephan    

    Donnerstag, 10. März 2011 09:46
    Moderator

Alle Antworten

  • Hallo Florian,

    wenn ich es richtig verstanden habe, benötigst Du eine externe EDI-Anbindung. Vermutlich über AS/2. Eine Möglichkeit wäre kein eigenes BTS Server in DMZ zu installieren, sondern einen IIS 7.0 Server mit der Weiterleitung an BizTalk Server in LAN. Man benutzt dementsprechend 2 IIS 7.0 Server: eine in DMZ als Reverse Proxy und der anderen auf dem BTS Server für http Empfangs Port.

     

    Eventuell könnte folgendes Beispiel Dir helfen:

    (Sample Architecture: HTTP and SOAP Adapters)

    http://msdn.microsoft.com/en-us/library/aa577383.aspx

     

    Und

     

    Reverse Proxy with URL Rewrite v2 and Application Request Routing

    http://learn.iis.net/page.aspx/659/reverse-proxy-with-url-rewrite-v2-and-application-request-routing/

     

     

    Viele Grüße,

     

    Alex.

    Montag, 28. Februar 2011 09:16
  • Hallo Alex,

    das hört sich für as/2 und http gut an! Das werde ich mir näher anschauen. Wie sieht es hier mit den FTP/FTPS Adaptern aus? 

    Die Möglichkeit mit dem Reverse Proxy würde aber "nur" den ersten Punkt meiner angedachten Architektur abdecken. Wie sieht es mit den FailOver Clustern und das Verwenden verschiedener Messageboxen aus?

     

    Danke & schöne Grüße

    Florian

    Montag, 28. Februar 2011 12:02
  • Hallo Florian,

    Ich würde ein BizTalk Failover Cluster installiere (ganz normal) und ein SQL Cluster. Diese würde ich ins innere Netz stellen ohne Zugang von außen. Dann in die DMZ einen IIS Server mit HTTP Reverse Proxy und FTP. Im Falle von HTTP leitest du einfach auf den inneren BizTalk Server weiter, bei FTP legst du die Dateien einfach auf ein Netzwerkshare oder lokal auf den DMZ ISS und pollst mit dem FILE Adapter.

     

    Grundsätzlich gibt es aber Adapter, die nicht Multi-Node-fähig sind (FTP, SQL Polling, usw.). Diese laufen dann nur auf einem Knoten und müssen im Ernstfall auf dem anderen Server aktiviert werden. Dazu richtest du die Host Instanz auf beiden Servern ein, lässt sie auf einem Knoten aber im gestoppten Status. Im Fehlerfall wird dann (notfalls per Script) schnell umgeschaltet.

     

    Wieso willst du mehrere Messageboxes machen?


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://pi.hauth.me

    Montag, 28. Februar 2011 13:52
  • Hallo Oliver,

    vielen Dank für Deine Antwort! Die Möglichkeit mit dem Reverse Proxy werde ich nun eindeutig in Betracht ziehen - diese hatte ja Alex bereits als Lösungsmöglichkeit angeboten.

    Meinst Du mit Biztalk Failover Cluster ein FailOver Cluster mit den Windows Bordmitteln (MSCS) oder einfach zwei Biztalk Server, welche auf die gleiche Message Box zugreifen?

    Übrigens, wenn ich dem Artikel http://technet.microsoft.com/en-us/library/aa561801(BTS.70).aspx hier trauen darf, dann kann man den FTP Adapter auch mit Biztalk Bordmitteln zu Clustering überreden, ohne dass man hier manuell eingreifen muss. Oder täusche ich mich da?

    Die Idee mit den mehreren Messageboxen kommt aus Scalability Gründen heraus - ich war der Meinung, dass man hier zusätzlich skalieren kann - wenn der Traffic an Messages größer wird.

    Übrigens, mein Nachrichtenpotential welches ich betrachten möchte:  derzeit 50.000 Nachrichten pro Tag - in Zukunft die Möglichkeit von 200.000 Nachrichten pro Tag. Wie ist das die Erfahrung mit den oben genannten Serverzahlen?


    Danke & schöne Grüße

    Florian

    Montag, 28. Februar 2011 14:34
  • Hallo Florian,

    "FTP adapter receive handlers should not, however, be configured to run in multiple BizTalk host instances simultaneously."

    Grundsätzlich geht's also, aber es sollte immer nur  einer aktiv sein. Hintergrund ist, dass sonst beide Adapter (die ja in 2 Windows Services auf zwei Servern laufen) auf die gleiche Datei zugreifen könnten und sich so selbst behindern und Fehler verursachen können.

    Wenn du ein MSCS Cluster aufsetzt, hast du alles automatisiert. Dann kannst du aber leider kein Load Balancing nutzen (was bei der Nachrichtenzahl vielleicht zu empfehlen wäre). Wenn du zwei BizTalk Server in eine Gruppe ziehst, kannst du zum Beispiel einen für Receive und Send sowie Orchestrations und einen nur für Orchestrations nutzen. Dafür musst du im Fehlerfall eventuell von Hand eingreifen. Dies kann man jedoch auch Scripten (SCOM + Scripte), erforder aber etwas mehr Know-How. Ich würde diese Lösung aber auf jeden Fall vorziehen.

    200.000 pro Tag -> 2 pro Sekunde. Das sollte problemlos machbar sein. Vor allem kannst du mit dem Feintuning der Instanzparameter und zwei Servern in einer Gruppe mehr erreichen als mit zwei Messageboxen. Ansonsten frag mal die SQL Experten, ob die noch weitere Optimierungsmöglichkeiten sehen.

    Der mir bekannte "Rekord" liegt bei > 1000 Nachrichten pro Sekunde.


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://pi.hauth.me

    Montag, 28. Februar 2011 14:57
  • Hallo Florian,

    Ein Multi-Messagebox Design sieht so aus das es immer eine Master - Message Box gibt welche die Nachrichten an die weiteren MessageBox Datenbanken weiterleitet. Das bedeutet also dass Nachrichten immer durch die Master - Messagebox laufen werden. Grundsätzlich ist zu beachten dass beim skalieren der MessageBox immer drei MessageBox Datenbanken angelegt werden. Ansonsten erhöht man lediglich den Aufwand den BizTalk Server mit der Verwaltung der Datenbanken hat.

    Des weiteren sollte man für die Skalierung der MessageBox Datenbank gute Gründe haben. Nur wenn die MessageBox Datenbank auch tatsächlich der Flaschenhals ist sollte das Design hier angepasst werden. Meistens sind Themen wie Disk I/O, Netzwerk oder Speicher der erste Flaschenhals und nicht Konkurenzsituation auf der MessageBox Datenbank.

    Mehr Informationen dazu auch hier:

    http://msdn.microsoft.com/en-us/library/cc296848(v=bts.10).aspx

    und im BizTalk Server Performance Guide:

    http://msdn.microsoft.com/en-us/library/ee377064(v=BTS.70).aspx

    Viele Grüße,

    Stephan    

    Donnerstag, 10. März 2011 09:46
    Moderator