MorphIT Servermove

Der MorphIT-Server unterstützt mit dem move_server-Serverbefehl eine im Live-Betrieb unterbrechungsfrei durchführbare Migration des MorphIT-Server auf eine andere Maschine. Ein solcher Servermove ist hilfreich, wenn Wartung am aktuellen Live-Server ansteht und man ein Update ohne Wartungsfenster einspielen will. Ein Servermove ermöglicht auch ein blue/green-Deployment des MorphIT-Servers und der ClassiX-Applikation.

Dieser Mechanismus hat einen integrierten Rollback-Mechanismus, sodass sich beide Server beim Abbruch der move_server-Verbindung automatisch auf den Ausgangszustand vor dem Servermove zurückversetzen.

 

Ablauf

1. Init-Schritt

Ein Servermove wird initiiert, indem der move_server-Serverbefehl von einer ClassiX-Instanz ausgeführt wird, die mit dem aktuellen Live-Server (im Folgenden als source oder Quellserver bezeichnet) verbunden ist. Damit dieser Befehl erfolgreich ausgeführt werden kann, muss auf dem Zielserver (auch als target bezeichnet) bereits ein MorphIT-Server laufen. Auf beiden Servern müssen folgende Konfigurationsoptionen gesetzt sein:

• ws.move_server.enabled=true
• ws.admin.enabled=true
• ws.admin.allowed_ips - muss auf dem Zielserver die IP des Quellservers enthalten.

Zusätzlich muss die Firewall so konfiguriert sein, dass eine Verbindung zwischen den beiden MorphIT-Servern in beide Richtungen auf dem ws.move_server.port&ws.admin.port erlaubt ist.

Das folgende Schaubild zeigt den Zustand der beiden Server nach dem init-Schritt.

Sobald die move_server-Verbindung (hier violett gestrichelt) aufgebaut wurde, werden alle ClassiX-Prozesse auf dem Zielserver beendet und die Launch-Strategie deaktiviert, da der Quellserver diese Aufgaben im Moment übernimmt. Beide Server kennen nun die MorphIT-Launcher des jeweils anderen Servers und können auf dem jeweils anderen Server dedizierte ClassiX-Prozesse starten. Auf dem Ziel-Server eingehende MorphIT-Verbindungen (hier rot gepunktet) und Webservice-Anfragen (hier orange gepunktet) werden durch die move_server-Verbindung hindurch geleitet, sodass der DNS-Eintrag/die IP ab jetzt auf den Zielserver umgestellt werden kann.

 

2. Launch-Strategie und Webservices verschieben

Sobald die move_server-Verbindung steht, kann die Launch-Strategie verschoben werden (move_ls-Schritt), sodass neue ClassiX-Instanzen nun auf dem Ziel-Server vorgestartet werden (dies hat keinen Einfluss auf den Start von dedizierten ClassiX-Instanzen).

Über den move_ws-Schritt können im Anschluss die Webservice-Konfigurationen Schritt für Schritt auf den Ziel-Server verschoben werden. Dabei wird immer zunächst die ClassiX-Instanz für den die Konfiguration gestartet und sobald diese bereit ist, wird die Konfiguration auf dem Quell-Server deaktiviert und eine Umleitung (durch die move_server-Verbindung hindurch) eingerichtet. Dieser Ablauf stellt sicher, dass die Webservice-Konfiguration während des Verschiebens immer erreichbar ist.

Die ClassiX-Instanz, die diese Serverbefehle ausführt, muss (im Gegensatz zum init-Step) nicht zwingend mit dem Quell-Server verbunden sein, sondern kann auch mit dem Ziel-Server verbunden sein.

Hinweis: Da eine Webservice-Konfiguration (ohne Startbefehl) ClassiX-Instanzen aus dem Pool der vorgestarteten Instanzen wählt, sollte immer zuerst die Launch-Strategie verschoben werden und erst im Anschluss die Webservice-Konfigurationen.

Das folgende Schaubild zeigt die Server nachdem die Launch-Strategie und Webservice-Konfigurationen verschoben wurden und als nächstes der commit-Schritt ausgeführt werden kann.

Bestehende MorphIT-Verbindungen (hier rot gepunktet) werden durch keinen der Schritte geschlossen, sodass die Anwender durch den Servermove nicht beeinträchtigt werden. Webservice-Anfragen (hier orange gepunktet) werden hier nun nicht mehr zum Quellserver geleitet. Gehen auf dem Quellserver neue MorphIT-Verbindungen ein (hier blau gepunktet), dann werden diese durch die move_server-Verbindung zum Zielserver durchgeleitet und mit einer dort gestarteten ClassiX-Instanz verbunden.

Hierbei ist es die Aufgabe des ClassiX-Prozesses, der die dedizierte Instanz startet, diese nun auf dem Zielserver zu starten. (Es ist kein Fehler, die Instanz weiterhin auf dem Quellserver zu starten - die Instanz würde sich korrekt mit MorphIT verbinden - , jedoch kann der Servermove erst dann abgeschlossen werden, wenn keine ClassiX-Instanzen mehr auf dem Quellserver verwendet wird.)

3. commit-Schritt

Sobald die Launch-Strategie und alle Webservice-Konfigurationen verschoben wurden, kann der commit-Schritt ausgeführt werden (auf Ziel- oder Quellserver). Dieser Schritt benachrichtigt beide Server, dass ein Abbruch der move_server-Verbindung ab sofort keinen Rollback mehr auslöst.

Sobald die letzte ClassiX/MorphIT-Verbindung zum Quellserver geschlossen wird, schaltet sich der Quellserver automatisch in den Wartungsmodus und kann im Anschluss komplett beendet werden. Zu dem Zeitpunkt sollten keine neuen MorphIT-Verbindungen und Webservice-Anfragen auf dem Quellserver eingehen. (Ein vorgeschalteter Proxy kann hierfür eine HTTP-Redirection aktivieren)

Über den Server-Befehl classix_status kann kontrolliert werden, welche ClassiX-Instanzen noch mit dem Quellserver verbunden sind und diese können bei längerer Inaktivität auch per shutdown_classix-Befehl beendet werden. Dies kann auch über die Admin-Konsole und die dortigen status und kill-Befehle erfolgen.

Das folgende Schaubild zeigt den Zustand nach einem erfolgreichen Servermove. Der Zielserver hat die Aufgaben des Quellservers übernommen und der Quellserver kann nun komplett heruntergefahren werden.

 

Rollback-Mechanismus

Jede Änderung der Server-Konfiguration durch einen der Schritte obigen Schritte (commit ausgenommen) wird von beiden Servern in einem Rollback-Log hinterlegt und beim Verlust der move_server-Verbindung automatisch zurückgerollt.

Da hierfür potenziell ClassiX-Instanzen nachgestartet werden müssen, kann dieser Rollback einige Sekunden bis Minuten in Anspruch nehmen. Während dieser Zeit kann das Zuweisen von ClassiX-Instanzen lange dauern und die Webservices nicht erreichbar sein. Dies sollte der einzige Fall sein, in welchem der Server-Move bemerkt wird.

Im init-Schritt kann über den rollback_ws-Parameter eine Webservice-Anfrage konfiguriert werden, die über den Mechanismus des send_webservice_request-Serverbefehls an eine Webserivce-Instanz des Quellservers gesendet wird, sobald ein Rollback durchgeführt wurde, um ClassiX darüber zu benachrichtigen, dass der Servermove nicht erfolgreich war und dedizierte Instanzen wieder auf dem Quellserver gestartet werden müssen. Falls noch keine ClassiX-Instanz auf dem Quellserver der entsprechenden Webservice-Konfiguration zugewiesen ist, dann wird das Auslösen dieser Webservice-Anfrage so lange verzögert, bis eine ClassiX-Instanz zugewiesen wurde.