Hot-Migration von Rechenzentren – „We did it!“

Aktualisierung nicht mehr unterstützter Versionen, Erweiterung oder Austausch eines Rechenzentrums, Implementierung eines Disaster Recovery Plans – es gibt viele Gründe, Workloads zwischen verschiedenen Rechenzentren zu verschieben. Aber noch nie konnte man so einfach und schnell von der amerikanischen Westküste an die Ostküste wechseln oder von Amsterdam nach Limburg. Mit nur wenigen Klicks können Workloads über gesicherte HCX-Tunnel zwischen unterschiedlichen Rechenzentren verschickt werden.

Um ein paar Zahlen zu nennen: Ein Kunde brauchte für die Migration von 300 TB an VMs inklusive Planung, Installation, Replikation und die eigentliche Umstellung gerade einmal fünf Wochen. Dieser Kunde konnte an einem Tag bis zu 23 TB an Daten, also knapp 1 TB/Stunde, zwischen zwei Rechenzentren in Deutschland übertragen. Ein anderer Kunde hat mehr als 200 TB aus seinem Rechenzentrum migriert, verteilt auf 750 VMs, ganz ohne Downtime.

Noch vor einem Jahr hätte wohl niemand geglaubt, dass solche Migrationen im laufenden Betrieb möglich wären. Schon die Idee der Migration von Workloads zwischen zwei Rechenzentren an sich klang wie ein Hirngespinst, ganz zu schweigen von der Hot-Migration.

Die Übertragung von Workloads basiert auf der VMware-Technologie HCX, die speziell für die Private Cloud Plattform konzipiert wurde. Diese Technologie garantiert nicht nur die sichere Migration der Workloads, sondernermöglicht darüber hinaus einen nahtlosen Übergang, da zwischen Quellrechenzentrum und Zielrechenzentrum eine Verbindung über ein erweitertes L2-Netzwerk („Stretched Network“) bereitgestellt wird. Die virtuelle Maschine, die in der Private Cloud „heiß“ versendet wird, verliert also zu keinem Zeitpunkt die Verbindung zu den anderen Maschinen, mit denen sie unter Nennbedingen arbeitet.

HCX verwendet dabei drei Appliances: Cloud Gateway (CGW) für das Management des Transfers der virtuellen Maschinen von einem Rechenzentrum zum anderen, WAN Accelerator als Ergänzung zum CGW, und schließlich L2C für das Stretched Network. Diese Appliances werden automatisch aufseiten der Private Cloud bereitgestellt, erfordern aber noch eine vierte Appliance vor Ort, um Deployment und Konfiguration dieser drei wesentlichen Elemente zu steuern.

Hinweis: Das CGW erscheint im Inventory als registrierter Host.

Für die Migration werden mindestens zwei Tunnel zwischen dem Quellrechenzentrum und dem Zielrechenzentrum, der OVH Private Cloud, erstellt: ein Tunnel zwischen den CGW für die Übertragung der VMs und ein weiterer Tunnel zwischen den L2C, der das Stretched Network erstellt, falls ein Subnetz erweitert werden muss. Natürlich können in Abhängigkeit von der Anzahl der zu erweiternden Netzwerke auch mehrere L2C zum Einsatz kommen.

Wenn die On-Premise-Architektur erst einmal steht, bietet ein Dashboard eine Übersicht aller Migrationsmöglichkeiten und eine History.

Es gibt grundsätzlich drei Arten, virtuelle Maschinen zu migrieren, wörtlich die „heiße“, die sogenannte „warme“ und schließlich die „kalte“ Migration.

Dabei ist die Hot-Migration mit Abstand die beeindruckendste Variante. Nur ein paar Klicks sind notwendig, um eine virtuelle Maschine in ein gewünschtes Zielrechenzentrum zu transferieren – und das ohne Status-, Konnektivitäts- oder Kontextverlust. Der Prozess ähnelt vMotion, das VMware-Kunden bereits kennen, und so trägt diese Methode denn auch den Namen vMotion Migration. Zunächst wird der VM-Datastore an das Zielrechenzentrum gesendet, und sobald die Synchronisation hier vollständig abgeschlossen ist, werden Speicher und CPU synchronisiert und das Zielrechenzentrum übernimmt. Bei dieser Methode besteht eine gewisse Einschränkung durch die Sequenzierung des Prozesses, weil es hier Auswirkungen auf solche Workloads geben kann, die auf mehrere VMs verteilt sind und eine geringe Latenz zwischen den VMs erfordern. Wenn die Migration der VM abgeschlossen ist, wird die Latenz zwischen den Rechenzentren sichtbar:

Dieses Problem lässt sich mit der „Bulk Migration“ vermeiden, bei der wir zusätzlich auch Funktionalitäten für eine kontrollierte Migration bieten. Das Ziel dieser Art der Migration besteht darin, eine oder mehrere VMs mit dem Zielrechenzentrum zu synchronisieren, während sie noch auf dem Quellrechenzentrum laufen, und die Synchronisation eine gewisse Zeit lang aufrechtzuerhalten. Die Umstellung aller VMs findet dann zu einem vom Administrator der Migration gewählten Zeitpunkt statt, der hierfür besonders günstig erscheint; die VM wird dann vom Quellrechenzentrum gelöscht und auf dem Zielrechenzentrum gestartet. Dabei kann nicht nur der Zeitpunkt der Umstellung exakt festgelegt werden, auch eine Anpassung der VM ist möglich (Update der VMware-Tools, Upgrade der virtuellen Hardware etc.). Und weil bei diesem Verfahren alle VMs gleichzeitig migriert werden, ist die Latenz im Stretched Network kein Thema mehr.

Die zuvor letztgenannte Migrationsmethode wäre für Produktionsserver störend und ist somit eher für Templates, Archive und Backups geeignet. Hier erfolgt die Migration kalt, die VM ist also abgeschaltet und die Umstellung erfolgt automatisch nach abgeschlossener Synchronisation der Daten auf dem Zielrechenzentrum.

Wir haben mehr als drei Jahre Erfahrung mit der sicheren Migration von Workloads, zunächst mit den Rechenzentren von vCloud Air, dann mit den unternehmenseigenen OVH Rechenzentren. In dieser Zeit haben wir Exabytes an Daten auf der ganzen Welt migriert.

HCX wurde als Tool speziell dafür entwickelt, verschiedene Herausforderungen im Zusammenhang mit der Migration zu bewältigen: die Betriebsbereitschaft der virtuellen Maschinen während des Transfers, die Migration ganzer Gruppen von VMs und die Netzwerkverbindung zwischen den beteiligten Rechenzentren. Hierfür ist auch Arbeit an der Architektur nötig. Eine Migration muss nämlich von unten her vorbereitet werden, angefangen bei einer ausreichenden Größe des Rechenzentrums. Das kann bei der OVH Private Cloud im Laufe der Zeit angepasst werden. Auch eine Schätzung der Umstellungsdauer sollte erfolgen, und die Migrationsstrategie für die verschiedenen Workloads des Quellrechenzentrums muss festgelegt werden. Alles Weitere sind dann nur noch ein paar Klicks in HCX.