none
BizTalk-Server Architektur-Problem

    Frage

  • Hallo,

    ich habe ein Problem mit meiner BizTalk-Architektur.

    Ich habe 2 BizTalk-Server (BizTalk Server Enterprise 2010) auf einer ESX-Serverfarm zur Verfügung. Die BizTalk-Datenbanken laufen auf einem separaten SQL-Server-Cluster (SQL Server 2008).

    Mein Problem ist jetzt, dass ich die BizTalk-Umgebung so aufbauen soll, dass ich Updates an den BizTalk-Servern, wenn möglich ohne Wartungsfenster, durchführen kann.

    BizTalk-Cluster oder NLB geht leider nicht, da sowohl HTTP- und SOAP-Adapter als auch POP-, FILE- und MSMQ-Adapter verwendet werden. Wir haben nur 2 BizTalk-Server zur Verfügung, dadurch fällt ja eine Lösung mit Cluster und NLB weg.

    Gibt es eine Möglichkeit die Architektur so aufzubauen, dass es dennoch möglich ist, einen Server nach dem anderen zu aktualisieren (ohne Wartungsfenster).
    Mein Problem ist vor allem das wir Angst haben, das während einem Serverupdate irgendwelche Nachrichten verloren gehen, wenn die Receive-Ports nicht erreichbar sind.

    Ich hoffe das ich nur irgendwie auf dem Schlauch stehen und es hoffentlich eine relativ einfache Lösung für das Problem gibt.

     

    Vielen Dank

    Steffi

    Freitag, 18. Februar 2011 06:17

Antworten

  • Hallo Steffi,

    das Problem ist zugegebener Maßen nicht ganz so ohne Weiteres zu lösen und hängt zum Beispiel davon ab, ob du die Versionsnummern der Assemblies hochzählst.

    Wenn du immer die gleiche Assembly-Version deployst (eher nicht zu empfehlen, da sehr wackelig):

    Was du machen könntest, wäre die beiden Server gleich auszulegen (von den Host Instanzen) und auch potentiell alles auf beiden Servern zu erlauben (yauch POP, FILE, usw.). Dann über Powershell, btstask, usw. und diverse Scripte alles auf Server 1 umziehen, um auf Server 2 das Deployment zu machen, dann alles auf Server 2 um auf Server 1 zu deployen und dann dann wieder zurück zum Normalbetrieb. Das ist jedoch mit viel ausprobieren und Handarbeit (am Anfang) verbunden.

    Bedenke aber folgendes:

    Solange Instanzen von bestimmten Artefakten aktiv sind (Orchestrations) kannst du diese nicht durch neue Versionen ersetzen. Das heißt du wirst eh einen Zeitpunkt abwarten müssen, wenn der Server für die sich ändernden Assemblies "leer" ist.

     

    Wenn du jedoch die Versionsnummern der Assemblies hochzählst, kannst du folgendes machen:

    Du musst die XSD Dateien in eine eigene Assembly auslagern (können beliebig viele sein, nur nicht mit Orchestrations usw. zusammen). Dies musst du deshalb machen, weil du sonst auch immer den Namespace der XSD anpassen müsstest (wegen Eindeutigkeit des Messagetypes). Hier zählt die Version der Assembly nicht.

    Bei einer neuen Version deiner Orchetrations deployst du dann (z.B.) Version 1.1.0.0 deiner Orchestration-Assembly. Dann erscheint zweimal die Orchestration in der Admin Konsole (einmal pro Version) und du setzt die alte auf "Running" und die neue auf "Enlisted" und hängst diese an den Receiveport. Damit laufen alte Instanzen weiter bis zum Ende und neue Messages lösen die neue Orchetrationversion aus. Sobald dann von der Version 1.0.0.0 alle Instanzen durch sind, kannst du die Assembly aus dem BizTalk löschen.

    Das ist eigentlich die bevorzugte Variante, wenn du nicht sicherstellen kannst, dass der Server irgendwann "instanzenfrei" ist und wenn du Versionen für .NET Assemblies verwenden kannst du darfst.


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

    http://pi.hauth.me

    Freitag, 18. Februar 2011 08:16
  • Hi Steffi,

    Ich würde zwei Server installieren und diese auch unterschiedlich nennen (BizTalk1 und BizTalk2). Dann würde ich beide in eine BizTalk Gruppe aufnehmen. Danach geht es an das Design der Hostinstanzen. Die würde ich wiefolgt aufteilen:

    Send_Receive_SingleServer_x64 (auf beiden Servern, aber nur auf BizTalk 1 gestartet)

    Send_Receive_SingleServer_x32 (auf beiden Servern, aber nur auf BizTalk 1 gestartet)

    Send_Receive_x64 (auf beiden Servern, beide gestartet)

    Send_Receive_x32 (auf beiden Servern, beide gestartet)

    Tracking (auf beiden Servern, aber nur auf BizTalk 2 gestartet)

    Process (auf beiden Servern, beide gestartet)

    Dann skaliert der großteil der Anwendungen schonmal ohne Probleme und ohne dein Zutun. Einziges Problem ist, wenn ein Server (z.B. BizTalk 1) sich verabschiedet. Dann müsstest du auf BizTalk 2 die entsprechenden Hostinstanzen starten (lassen) und der Server würde für die Zeit alle Aufgaben übernehmen. Gleiches natürlich auch andersrum.

    Dann musst du nur drauf achten, dass die Adapter, die nicht Multiclusterfähig sind, auf den xxx_SingleServer_xxx Instanzen laufen. Dies ist zum Beispiel der FTP Adapter.

    Ein wenig problematisch ist es allerdings, wenn du

    - über das Netzwerk Dateien auf einem der Server ablegst (Netzwerk-Share). Davon würd ich aber generell abraten und diese immer auf dem Quellsystem belassen.

    - WCF Services auf dem BizTalk Server aufrufst. Aber hier kannst du evtl. mit einem DNS Alias arbeiten (BTServices und diese notfalls kurzfristig anpassen).

    Du kannst natürlich auch einen Cluster rein auf Windows Basis aufsetzen ohne von den BizTalk Gruppen gebrauch zu machen, dann verlierst du aber die Möglichkeit der Skalierung. Das hängt ein wenig von deinen Anforderungen ab.

    Zwei Server mit gleichen Namen funktioniert nämlich nur bei einem Windows Cluster und da ist BizTalk eigentlich außen vor. Damit erreichst du eine Hochverfügbarkeit ohne manuellen Eingriff. Ist die Frage was du letztendlich willst.

    Wie genau sehen denn die Anforderungen aus?

    100% Hochverfügbarkeit ohne manuellen Eingriff oder mit 2 Servern auch skalieren zu können oder kann man erstmal die 2 für die 100% HA nehmen und für Skalierbarkeit dann evtl. nochmal 2 Server dazukaufen?

    Zu deinen Fragen 2-4: Wenn du über eine BizTalk Gruppe arbeitest ja, wenn du einen Windows Cluster erstellst läuft die Replikation automatisch im Hintergrund ohne dass du was machen musst.


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

    http://pi.hauth.me

    Mittwoch, 2. März 2011 14:57

Alle Antworten

  • Hallo Steffi,

    das Problem ist zugegebener Maßen nicht ganz so ohne Weiteres zu lösen und hängt zum Beispiel davon ab, ob du die Versionsnummern der Assemblies hochzählst.

    Wenn du immer die gleiche Assembly-Version deployst (eher nicht zu empfehlen, da sehr wackelig):

    Was du machen könntest, wäre die beiden Server gleich auszulegen (von den Host Instanzen) und auch potentiell alles auf beiden Servern zu erlauben (yauch POP, FILE, usw.). Dann über Powershell, btstask, usw. und diverse Scripte alles auf Server 1 umziehen, um auf Server 2 das Deployment zu machen, dann alles auf Server 2 um auf Server 1 zu deployen und dann dann wieder zurück zum Normalbetrieb. Das ist jedoch mit viel ausprobieren und Handarbeit (am Anfang) verbunden.

    Bedenke aber folgendes:

    Solange Instanzen von bestimmten Artefakten aktiv sind (Orchestrations) kannst du diese nicht durch neue Versionen ersetzen. Das heißt du wirst eh einen Zeitpunkt abwarten müssen, wenn der Server für die sich ändernden Assemblies "leer" ist.

     

    Wenn du jedoch die Versionsnummern der Assemblies hochzählst, kannst du folgendes machen:

    Du musst die XSD Dateien in eine eigene Assembly auslagern (können beliebig viele sein, nur nicht mit Orchestrations usw. zusammen). Dies musst du deshalb machen, weil du sonst auch immer den Namespace der XSD anpassen müsstest (wegen Eindeutigkeit des Messagetypes). Hier zählt die Version der Assembly nicht.

    Bei einer neuen Version deiner Orchetrations deployst du dann (z.B.) Version 1.1.0.0 deiner Orchestration-Assembly. Dann erscheint zweimal die Orchestration in der Admin Konsole (einmal pro Version) und du setzt die alte auf "Running" und die neue auf "Enlisted" und hängst diese an den Receiveport. Damit laufen alte Instanzen weiter bis zum Ende und neue Messages lösen die neue Orchetrationversion aus. Sobald dann von der Version 1.0.0.0 alle Instanzen durch sind, kannst du die Assembly aus dem BizTalk löschen.

    Das ist eigentlich die bevorzugte Variante, wenn du nicht sicherstellen kannst, dass der Server irgendwann "instanzenfrei" ist und wenn du Versionen für .NET Assemblies verwenden kannst du darfst.


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

    http://pi.hauth.me

    Freitag, 18. Februar 2011 08:16
  • Vielen Dank für den Lösungsvorschlag, ich werde mir das mal so genauer anschauen.

    Montag, 21. Februar 2011 07:14
  • Hallo Oliver,

    ich habe jetzt nocheinmal eine Frage bezüglich des Umzugs der BizTalk-Anwendung.
    1. Die beiden Server müssen ja den gleichen Namen haben, sonst habe ich evtl. Probleme mit den Receive-Ports.Ist das richtig?
    2. Für Server 2 verwende ich einfach eine Kopie des Server 1 und passe nur die IP-Adresse an.
    3. Ich exportiere die Anwendung und Binding von Server 1 und importiere diese in Server 2. Anschließend beende ich die Host-Instanz von Server 1 und starte die Hostinstanz von Server 2.
    4. Jetzt kann ich die Änderungen an Server 1 vornehmen und im Anschluss daran, beende ich die Hostinstanz von Server 2 und starte die Hostinstanz von Server 1.

    Sorry, das ich nochmal nachfrage, ich habe bisher noch kaum mit der BizTalk-Architektur zu tun gehabt und im Web habe ich auch keine ordentliche Anleitung für den Umzug einer BizTalk-Anwendung gefunden :-(
    Gibt es sonst noch etwas was ich beachten muss?

    Nochmal vielen Dank & Grüße
    Steffi

    Mittwoch, 2. März 2011 12:00
  • Hi Steffi,

    Ich würde zwei Server installieren und diese auch unterschiedlich nennen (BizTalk1 und BizTalk2). Dann würde ich beide in eine BizTalk Gruppe aufnehmen. Danach geht es an das Design der Hostinstanzen. Die würde ich wiefolgt aufteilen:

    Send_Receive_SingleServer_x64 (auf beiden Servern, aber nur auf BizTalk 1 gestartet)

    Send_Receive_SingleServer_x32 (auf beiden Servern, aber nur auf BizTalk 1 gestartet)

    Send_Receive_x64 (auf beiden Servern, beide gestartet)

    Send_Receive_x32 (auf beiden Servern, beide gestartet)

    Tracking (auf beiden Servern, aber nur auf BizTalk 2 gestartet)

    Process (auf beiden Servern, beide gestartet)

    Dann skaliert der großteil der Anwendungen schonmal ohne Probleme und ohne dein Zutun. Einziges Problem ist, wenn ein Server (z.B. BizTalk 1) sich verabschiedet. Dann müsstest du auf BizTalk 2 die entsprechenden Hostinstanzen starten (lassen) und der Server würde für die Zeit alle Aufgaben übernehmen. Gleiches natürlich auch andersrum.

    Dann musst du nur drauf achten, dass die Adapter, die nicht Multiclusterfähig sind, auf den xxx_SingleServer_xxx Instanzen laufen. Dies ist zum Beispiel der FTP Adapter.

    Ein wenig problematisch ist es allerdings, wenn du

    - über das Netzwerk Dateien auf einem der Server ablegst (Netzwerk-Share). Davon würd ich aber generell abraten und diese immer auf dem Quellsystem belassen.

    - WCF Services auf dem BizTalk Server aufrufst. Aber hier kannst du evtl. mit einem DNS Alias arbeiten (BTServices und diese notfalls kurzfristig anpassen).

    Du kannst natürlich auch einen Cluster rein auf Windows Basis aufsetzen ohne von den BizTalk Gruppen gebrauch zu machen, dann verlierst du aber die Möglichkeit der Skalierung. Das hängt ein wenig von deinen Anforderungen ab.

    Zwei Server mit gleichen Namen funktioniert nämlich nur bei einem Windows Cluster und da ist BizTalk eigentlich außen vor. Damit erreichst du eine Hochverfügbarkeit ohne manuellen Eingriff. Ist die Frage was du letztendlich willst.

    Wie genau sehen denn die Anforderungen aus?

    100% Hochverfügbarkeit ohne manuellen Eingriff oder mit 2 Servern auch skalieren zu können oder kann man erstmal die 2 für die 100% HA nehmen und für Skalierbarkeit dann evtl. nochmal 2 Server dazukaufen?

    Zu deinen Fragen 2-4: Wenn du über eine BizTalk Gruppe arbeitest ja, wenn du einen Windows Cluster erstellst läuft die Replikation automatisch im Hintergrund ohne dass du was machen musst.


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

    http://pi.hauth.me

    Mittwoch, 2. März 2011 14:57
  • Hallo Oliver,

    vielen Dank. Dann werde ich das jetzt mal genau nach deiner Anleitung ausprobieren ;-)

    Meine Anforderungen sind aktuell die BizTalk-Umgebung mit 2 Server so sicher wie möglich aufzusetzen. Aktuell läuft das ganz auf nur einem Server und kann daher nicht wirklich gewartet und aktualisiert werden, da keine grössere Wartungsfenster definiert sind.

    Vermutlich wird es auch bei den 2 Servern bleiben, aber mit deiner Lösung kan ja das Wartungsfenster relativ klein gehalten werden.

    Grüße
    Steffi

     

     

    Mittwoch, 2. März 2011 15:21
  • Also wenn du die höchstmögliche Verfügbarkeit inkl. der geringst möglichen Downtimes haben willst, würde ich tatsächlich ein Windows Cluster aufsetzen und bereits auf der Ebene alles erledigen. Die Serverreplikation läuft dann intern in der Clusterverwaltung, du brauchst aber definierte Downtimes für's Deployment. Aber besser wirst du es nicht hinkriegen. Da solltest du mal mit deinen Windows Server Experten sprechen (wenn vorhanden).

    Der manuelle Eingriff bei einer BizTalk Gruppe ist nur schwer zu umgehen und falls gerade kein Admin greifbar ist, kann hier zuviel Zeit verloren gehen.


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

    http://pi.hauth.me

    Mittwoch, 2. März 2011 15:53
  • Hallo Oliver,

    Entschuldigung das ich mich nach so langer Zeit nocheinmal melde, aber ich konnte jetzt endlich die Umgebung mit der BizTalk-Gruppe nachbauen und weiss jetzt auch sicher, welche Adapter verwendet werden.
    Ich würde diese wie folgt zuordnen:
    "Send_Receive_SingelServer"
     - WCF-Custom -> MSSQL
     - WCF-Custom -> SAP
     - SQL

    "Send_Receive"
     - HTTP
     - SOAP
     - FILE

    Passt meine Zuordnung soweit oder habe ich einen Fehler drinnen?

    Du hattest auch die BTServices erwähnt zu denen ich aber leider nichts finden konnte. Waren diese eine Alternative zu dem DNS-Alias?

    Nochmal vielen dank für deine Hilfe.

    Grüße
    Steffi

    Mittwoch, 23. März 2011 15:27
  • Hallo Oliver,

    eine kleine Anmerkung zum Thema Tracking Host.

    Der Tracking Host sollte auf mindestens zwei Servern laufen. (Redundanz in Fehlerfalle). Für optimale Performance sollte eine Instanz des Tracking Hosts pro MessageBox + 1 gestartet sein.
    Also bei einem Design mit einer Single MessageBox sollten grundsätzlich zwei Tracking Host Instanzen gestartet sein.

    Viele Grüße,

    Stephan

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

     

     

    Donnerstag, 24. März 2011 09:34
    Moderator
  • Hallo Steffi,

    ganz Grundsätzlich musst Du noch zwischen einem "In-Process" und einem "Isolated Host" unterscheiden.

    In Process Hosts können sämtliche BizTalk Artefakte beinhalten ausser dem SOAP, HTTP, WCF-SOAP, WCF-HTTP und eignen "Isolated" Adaptern.

    Mehr Details zu BizTalk Server Hosts findest Du hier:

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

    Für die von Dir aufgezählten Adapter brauchst Du also mindestens einen, bestenfalls zwei weitere Hosts mit jeweils zwei Host Instanzen.

    • Receive_SOAP - Isolated -Host
    • Receive_HTTP - Isolated Host
    • Send_SOAP - In-Process Host
    • Send_HTTP - In Process Host

    Da die SOAP und HTTP Receive Adapter jetzt zwei Unterschiedliche "Endpunkte" bereitstellen würden wäre es weiterhin von Vorteil ein Network Load Balancing aufzusetzen. Dies ermöglicht Dir einen einzigen Endpunkt bereit zu stellen und über den NLB beide BizTalk Server anzusprechen. (Redundanz und Lastverteilung)

    Mehr Details dazu findest Du hier:

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

    Keine der von Dir aufgezählten Standard - Adpter benötigt meines Wissens nach ein Szenario bei dem diese "geclustered" werden müssten, ausser Ihr nutzt Ordered Delivery.

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

    Also kannst Du folgende Hosts mit jeweils zwei Host Instanzen aufsetzen um Redundanz und Lastverteilung zu gewährleisten:

    • Send Host
    • Hier kannst Du alle Deine übrigen Send Adapter konfigurieren  
    • Receive Host
    • Hier kannst Du alle Deine übrigen Receive Adapter konfigurieren

    Da Du ja aktuell eine neue Umgebung aufsetzt möchte ich Dir den BizTalk Server 2010 Operations Guide sehr ans Herz legen. Dieser beinhaltet Checklisten welche es ermöglichen Schritt für Schritt eine hochperformante, redundante wartbare BizTalk Server Umgebung aufzusetzen.

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

    Viele Grüße,

    Stephan

    Donnerstag, 24. März 2011 10:04
    Moderator
  • Ja, da stimmt ich dir zu. Letztendlich sollte im Fehlerfalle der Tracking Host - genau wie die Orchestration Hosts - automatisch umschalten und somit auf beiden Systemen verfügbar sein. Theoretisch geht's auch auf einem, aber dann musst du händisch umschalten.

    Gerade für ein HA / Prod-System sollte man daher mehr als eine Tracking Instanz haben. Das Thema mit den Messageboxen > 1 hatten wir ja schon. Sowas macht zu Beginn nicht immer Sinn und sollte auch gut überlegt werden.


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

    http://pi.hauth.me

    Donnerstag, 24. März 2011 12:51