VMware-Technik aufgepeppt

OVH erlaubt Hot-Migration von Rechenzentren

| Redakteur: Ulrike Ostler

Das Rechenzentrum soll umzihen? Mithilfe von „HCX“, eine von VMware übernommene und verbesserte Technik, laasen sich Rechezentren von OVH-Kunden ohne Downtime migrieren.
Das Rechenzentrum soll umzihen? Mithilfe von „HCX“, eine von VMware übernommene und verbesserte Technik, laasen sich Rechezentren von OVH-Kunden ohne Downtime migrieren. (Bild: OVH)

Aber seit März dieses Jahres können OVH-Kunden schnell einmal von der amerikanischen Westküste an die Ostküste wechseln oder von Amsterdam nach Limburg – und zwar ohne Downtime, im laufenden Betrieb. Möglich ist das über gesicherte „HCX“-Tunnel, eine Technik, die OVH von VMware übernommen und nach eigenen Aussagen zum Fliegen gebracht hat.

Aktualisierung nicht mehr unterstützte Versionen, Erweiterung oder Austausch eines Rechenzentrums, Implementierung eines Disaster Recovery Plans – es gibt viele Gründe, Workloads zwischen verschiedenen Rechenzentren zu verschieben.

Dazu zwei Beispiele: Ein Kunde brauchte für die Migration von 300 Terabyte (TB) an virtuellen Maschinen inklusive Planung, Installation, Replikation und die eigentliche Umstellung gerade einmal fünf Wochen. Dieser Kunde konnte an einem Tag bis zu 23 Terabyte 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.

HCX wurde speziell für Private Cloud Plattformen konzipiert. Die Technik garantiert nicht nur die sichere Migration der Workloads, sondern ermö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 versendet wird, verliert also zu keinem Zeitpunkt die Verbindung zu den anderen Maschinen, mit denen sie unter Nennbedingen arbeitet.

Drei Appliances

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 auf Seiten der Private Cloud bereitgestellt, erfordern aber noch eine vierte Appliance vor Ort, um Deployment und Konfiguration dieser drei wesentlichen Elemente zu steuern.

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 einen Verlauf. Es gibt grundsätzlich drei Arten, virtuelle Maschinen zu migrieren, wörtlich die „heiße“, die so genannte „warme“ und schließlich die „kalte“ Migration.

Drei Möglichkeiten der Migration

Hot-Migration ist sicher mit Abstand die beeindruckendste Variante. Laut OVH sind lediglich „ein paar Klicks“ sind notwendig, um eine virtuelle Maschine in ein gewünschtes Zielrechenzentrum zu transferieren. Dabei gehen weder Status, noch Konnektivität und Kontext verloren. Der Prozess ähnele „vMotion“, so dass diese Methode mit „vMotion Migration“ bezeichnet wird.

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. Die Einschränkung bei der Methode entsteht durch die Sequenzierung des Prozesses. Das kann Auswirkungen auf solche Workloads haben, 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:

Es gibt grundsätzlich drei Arten, virtuelle Maschinen zu migrieren.
Es gibt grundsätzlich drei Arten, virtuelle Maschinen zu migrieren. (Bild: OVH)

Dieses Problem lässt sich mit der „Bulk Migration“ vermeiden, bei der OVH zusätzlich auch Funktionen für eine kontrollierte Migration anbietet. 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 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 können Kunden nicht nur der Zeitpunkt der Umstellung festgelegen werden, sondern auch Anpassungen der VM vornehmen, etwa Updates der VMware-Tool und Upgrades der virtuellen Hardware. Da bei diesem Verfahren alle VMs gleichzeitig migriert werden, ist die Latenz im Stretched Network kein Thema mehr.

Die Migrationsmethode „cold“ ist für Produktionsserver ungeeignet und somit eher für Templates, Archive und Backups geeignet. Dabei sind die VMs ist also abgeschaltet und die Umstellung erfolgt automatisch nach abgeschlossener Synchronisation der Daten auf dem Zielrechenzentrum.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46055545 / IT-Services)