(Fast) Ausfallfreier Umzug unserer Webserver in ein anderes Rechenzentrum mit Hyper-V unter Windows Server 2012
Wir haben diese Woche unsere Webserver umgezogen. Die Systeme sind virtuelle Hyper-V VMs und liefen bis vor kurzem in einem Rechenzentrum in Frankfurt. Nachdem wir uns zu einem Wechsel des Anbieters entschieden haben haben wir das Hostsystem auf Windows Server 2012 Beta umgestellt. Mit der neuen Version von Hyper-V bietet die Funktion Replica interessante und nützliche Möglichkeiten. Wie genau die Umstellung gelaufen ist, welche Dinge zu beachten waren und in welchem Zeitraum die Migration durchgeführt wurde, möchte ich hier gerne beschreiben, um dem ein oder anderen Leser Anreize, Ideen oder Möglichkeiten aufzeige bei ähnlichen Projekten.
Zu Beginn des Projekts befinden sich alle Webserver auf einem Hyper-V Host (HyperV4) im RZ in Frankfurt, Betriebssystem des Hosts ist ein Windows Server 2012 Beta. Bei uns in der Firma wird ebenfalls ein Server (Hyperv1) mit Windows Server 2012 Beta installiert und mit Hyper-V ausgestattet. Nun wird auf dem Server in Frankfurt eine Replikation eingerichtet, Ziel ist der Server bei uns im Büro. Bandbreitenmäßig ist dies recht vorteilhaft, das RZ in Frankfurt ist per Gigabit angebunden, bei uns kann eine DSL16000-Leitung komplett genutzt werden (exklusive Leitung für diese Replikation, bei einer Produktivleitung sollte man eine Bandbreitenbegrenzung konfigurieren). Nachdem die erstmalige Komplett-Replikation fertig ist werden danach nur noch die Änderungen repliziert, die Dateigrößen liegen hier im zwei- bis dreistelligen MB-Bereich.
Im nächsten Schritt wird die Replikation zwischen RZ und Firma aufgehoben und die Systeme bei uns in der Firma werden ohne Netzwerk gestartet und an ihre lokalen, externen IP-Adressen angepasst. Nachdem alle Einstellungen so wie gewünscht sind werden die Systeme gestartet und getestet, bei Erfolg können nun die IP-Adressen der Webseiten auf die IPs bei uns in der Firma angepasst werden. Dieses Vorgehen hat den Charme, dass Benutzer mit einer “alten” IP (aus dem Bereich des RZ in Frankfurt) auf dem Server in Frankfurt landen, Benutzer mit einer “neuen” IP bekommen die Daten von den Servern bei uns in Hallenberg geliefert. Nach einem Tag haben wir die Server in Frankfurt (Hyperv4) ausgeschaltet und den Server zu uns ins Büro geholt. Hier wird der mittlerweile verfügbare Release Candidate von Windows Server 2012 aufgespielt. An dieser Stelle mussten wir leider feststellen, dass eine Migration von Beta zu RC (Hyperv1 –> Hyperv4) leider nicht möglich war:
An dieser Stelle kommt ein kleiner Ausfall ins Spiel, wir haben die VMs per Export und Import temporär auf den Server 2012 RC (Hyperv4) gespielt, um in der Zwischenzeit den ursprünglich genutzten Host (Hyperv1) ebenfalls auf Server 2012 RC zu aktualisieren (durch eine Neuinstallation). Das Zurückspielen der VMs hat dann wieder ohne Ausfall funktioniert, da wir die VMs per “Shared Nothing”-Migration auf den aktualisierten Host zurückgeschoben haben.
Kleine Zusammenfassung: Aktuell liegen in dieser Beschreibung die Webserver auf dem Host bei uns in der Firma (Hyperv1), der Host nutzt Windows Server 2012 RC als Betriebssystem und der Hardware-Server, der in Frankfurt im Rechenzentrum aktiv war (Hyperv4), macht momentan nichts (installiert ist ein Windows Server 2012 RC).
Im nächsten Schritt habe ich nun dem Server Hyperv4, welcher in das Ziel-RZ kommen soll, die dem RZ angepassten IP-Adressen gegeben. Ein kleiner Hardware-Router sorgt für eine Verbindung zwischen unserem Netz und dem simulierten RZ-Netz. Dies hat den Vorteil, dass alle Einstellungen nachträglich nicht mehr angepasst werden müssen. Ich richte nun eine Replikation zwischen Hyperv1 und Hyperv4 ein, alle Webserver werden über meinen 100MBit-Router repliziert, dies dauert bei weitem nicht so lange wie wenn ich alle Daten über die DSL16000-Leitung hochladen muss (1MBit). Nachdem alle Daten erfolgreich repliziert sind wird der Host Hyperv4 ausgeschaltet und in seinem Ziel-Rechenzentrum verbaut und eingeschaltet. Sobald Hyperv1 eine Verbindung zu dem System bekommt werden die in der Zwischenzeit angefallenen Änderungen repliziert und beide Systeme sind wieder auf dem gleichen Stand. Zu diesem Zeitpunkt lösen wir erneut die Replizierung auf, konfigurieren die VMs auf dem Hyperv4 entsprechend ihrer IP-Adressen im RZ und bringen die Systeme anschließend wieder live. Wenn alle Tests erfolgreich verlaufen können wir die DNS-Einträge der Internetseiten wieder anpassen und haben den gleichen Vorteil wie bei der ersten Umstellung: Wenn jemand mit “alten” IP-Adressen kommt werden ihm Daten aus Hallenberg geliefert, sobald die DNS-Einträge aktualisiert oder live abgefragt werden bekommt der Besucher die IP des Systems im RZ und bekommt die Daten aus dem neuen RZ. Nach 24 Stunden können die Systeme bei uns in der Firma abgeschaltet und gelöscht werden, danach kann erneut eine Replikation von Hyperv4 auf Hyperv1 eingerichtet werden, um bei einem Ausfall des Servers oder der Internetanbindung zur Not die Webserver wieder hier in Hallenberg live zu nehmen.
Um die Daten bei einer Replikation möglichst gering zu halten, haben wir sowohl Auslagerungsdatei als auch Cache-Verzeichnis in eine eigene VHD ausgelagert, die nicht mit repliziert wird. Eine Anleitung hierzu finden Sie im Technikblog, beschrieben durch meinen Kollegen Daniel Althaus: W3 Total Cache – Auslagern der Cachedateien
