Vor etwa 7 Jahren verlagerte sich das erste Projekt ganz unkompliziert in unsere Cloud. Die Abbilder virtueller Maschinen wurden auf einem FTP-Server hochgeladen oder auf Festplatten angeliefert. Dann wurden die VMs über einen speziellen Import-Server in die Cloud hochgeladen.
Wenn es für den Kunden kein Problem ist, die virtuelle Maschine für ein oder zwei Tage auszuschalten (oder keine anderen Optionen zur Verfügung stehen), kann man es so machen. Aber wenn der Stillstand maximal eine Stunde betragen soll, ist diese Methode ungeeignet. Heute werde ich erklären, welche Werkzeuge helfen, die Migration in die Cloud mit minimaler Ausfallzeit durchzuführen und wie der Migrationsprozess bei uns abläuft.
Migration mit Veeam Backup and Replication
Veeam Backup and Replication ist bekannt als das Werkzeug zur Erstellung von Backups und Replikaten. Wir verwenden es für die Migration zwischen unseren Standorten und für den Transfer von Kunden von privater Virtualisierung in unsere Cloud. Die virtuellen Maschinen des Kunden werden auf unser vCenter repliziert, anschließend fügt der Ingenieur sie in den vCloud Director ein.
Die primäre Replikation erfolgt auf der aktivierten virtuellen Maschine. Zum passenden Zeitpunkt wird die Maschine auf der Clientseite heruntergefahren. Die Replikation wird erneut gestartet, um die Änderungen zu übertragen, die seit der ersten Replikation aufgetreten sind. Danach wird die virtuelle Maschine in unserer Cloud gestartet.
In der Regel vergehen vom Herunterfahren der Maschine in der Infrastruktur des Kunden bis zum Einschalten in unserer Cloud nicht mehr als eine halbe Stunde, meistens jedoch 15 bis 20 Minuten.
Die ursprüngliche virtuelle Maschine bleibt dabei beim Kundenstandort. Sollte etwas schiefgehen, kann jederzeit zurückgekehrt und sie eingeschaltet werden. Für den Kunden hat dieser Ansatz den Vorteil, dass er kein Veeam benötigt.
Fall 1
Der Kunde verfügte über eine eigene virtuelle Infrastruktur auf Basis von VMware – 40 VMs mit einem Volumen von 30 TB. Die Hardware, auf der der Cluster implementiert war, war bereits veraltet, und der Kunde entschied sich, nicht in neue Hardware zu investieren und in die Public Cloud zu migrieren. Die Anforderung an die Ausfallzeit kritischer Systeme betrug nicht mehr als eine Stunde. Als Tool wurde Veeam Replication ausgewählt. Positiv war auch, dass der Internetanbieter des Kunden in unserem Rechenzentrum vertreten war, was einen guten Kanal ermöglichte. Die Migration dauerte etwa einen Monat, die Ausfallzeit beim Umschalten betrug bis zu 30 Minuten für eine Gruppe von virtuellen Maschinen.
Migration mit Veeam Cloud Connect
Veeam Cloud Connect ist ein Tool, das hilft, die Replikation von virtuellen Maschinen einzurichten und Replikate in der Cloud des Serviceanbieters zu starten. Nach dem Update im Jahr wurde es möglich, virtuelle Maschinen direkt in den vCloud Director zu replizieren. Die einzige Bedingung ist, dass auf der Kundenseite eine eigene Veeam Backup and Replication in der Version 9 oder höher eingerichtet sein muss. Kurz gesagt (eine ausführliche Version ), sieht der gesamte Prozess folgendermaßen aus.
Im vCloud Director wird eine Organisation mit den notwendigen Ressourcen und Netzwerken erstellt. Mit Veeam Cloud Connect richten wir ein Konto ein, auf das der Kunde über sein Veeam B&R zugreift. Dort wählt er den Anbieter DataLine und die Organisation aus, und konfiguriert die Aufgaben für die Replikation. Bei dieser Migration beträgt die Downtime lediglich etwa 15–20 Minuten. Der Kunde ist dabei unabhängig vom Support des Anbieters und steuert den gesamten Prozess selbst: Er erstellt die Replikationsaufgaben, führt die Replikation durch, schaltet die Maschinen aus und startet sie auf dem neuen Standort.
Fallstudie 2
Die Infrastruktur des Kunden, von der die Migration geplant wurde, befand sich in Weißrussland. Es galt, 90 VMs mit einem Gesamtvolumen von 27 TB zu übertragen, während die Internetverbindung nur 100 Mbit/s betrug. Wenn wir ein Backup erstellen und es sofort in unsere Cloud hochladen würden, könnte das bei einigen VMs mehrere Tage in Anspruch nehmen. In dieser Zeit wäre eine erhebliche Delta-Differenz auf den VMs entstanden, was sich negativ auf die Leistung der Maschinen auswirken oder im schlimmsten Fall dazu führen könnte, dass der Speicherplatz im Datastore erschöpft ist. So gingen wir vor: Zuerst erstellte der Kunde ein lokales vollständiges Backup und übertrug eine Kopie über Veeam Cloud Connect in unsere Cloud. Anschließend erstellte er ein inkrementelles Backup und übertrug dieses ebenfalls in die Cloud. Die ursprüngliche virtuelle Maschine blieb währenddessen in Betrieb. Nach dem Abschalten der VM erstellte der Kunde ein weiteres inkrementelles Backup und übertrug es ebenfalls in die Cloud. Auf unserer Seite haben wir die virtuelle Maschine aus dem vollständigen Backup wiederhergestellt und anschließend die beiden inkrementellen Backups nachgetragen. Diese Vorgehensweise ermöglichte es, die Ausfallzeit beim Wechsel zu unserem Standort auf insgesamt 2 Stunden zu minimieren.
Migration mit VMware vCloud Availability
Im März dieses Jahres hat VMware vCloud Availability 3.0 veröffentlicht, das die Migration von virtuellen Maschinen zwischen verschiedenen Clouds (vCloud Director – vCloud Director) und von den privaten Virtualisierungsständen des Kunden in die Cloud (vCenter – vCloud Director) ermöglicht. Der Hauptvorteil ist die Integration mit der vCloud Director-Oberfläche. Dies vereinfacht den Replikationsmanagementprozess erheblich und minimiert die Ausfallzeiten beim Umschalten.
Mit diesem Tool haben wir einen unserer Kunden aus unserer Moskauer Cloud in unsere Cloud in St. Petersburg migriert. Es galt, 18 virtuelle Maschinen mit einer Gesamtkapazität von 14 TB zu übertragen. Für den Kunden wurde in der St. Petersburger Cloud eine Organisation eingerichtet und die notwendigen Netzwerke organisiert. Anschließend wechselte der Kunde über die vCloud Director-Oberfläche zu den Einstellungen von vCloud Availability, erstellte Replikationsaufträge und wechselte zu einem für ihn passenden Zeitpunkt auf die St. Petersburger Plattform. Die Ausfallzeit beim Umschalten betrug 12 Minuten.
Das Migrationdiagramm zwischen den DataLine Clouds in St. Petersburg und Moskau.
vCloud Availability bietet eine Lösung zur Migration von virtuellen Maschinen vom Client-Standort in unsere Cloud. Dazu wird in der vCenter-Umgebung des Kunden ein spezieller Appliance für vCloud Availability eingerichtet. Nach einer einfachen Konfiguration erfolgt die Verbindung zur Cloud und die Migrationseinheiten werden eingerichtet. Der Kunde verwaltet den gesamten Prozess selbst, wodurch die Migrationszeit auf ein Minimum reduziert wird.
Diagramm zur Migration virtueller Maschinen aus einer privaten Installation in die Cloud.
VMware vCloud Availability bietet viele weitere Einsatzszenarien, über die wir bald in einem separaten Artikel berichten werden.
Vorbereitung zur Migration
Um das richtige Werkzeug auszuwählen und mit der Migration zu beginnen, sollten die folgenden Punkte festgelegt werden:
Von wo migrieren wir. Wenn Sie von einer privaten Lösung migrieren, haben Sie die volle Freiheit bei der Wahl der Werkzeuge. Wenn Sie jedoch von einem Provider wechseln, gestaltet sich das komplexer. Es ist wahrscheinlich, dass Sie die Infrastrukturen beider Anbieter nicht einfach verbinden und die VM aufgrund von Sicherheitsbedenken verschieben können. Manchmal beginnt der Provider, von dem der Kunde sich trennen möchte, sogar zu schikanieren und zieht die Dinge in die Länge. Die Abwanderung von einem Provider kann traditionell erfolgen: durch das Exportieren der VMs auf Datenträger und FTP oder durch eine Migration auf Anwendungsebene. Letzteres ist ein eigener Begriff und sieht in etwa so aus.
Fall 3
Wir mussten das SAP-System eines Kunden von einem europäischen Anbieter migrieren: 34 VMs mit einem Volumen von 54 TB. Dem Kunden wurden Ressourcen in unserer Cloud zugewiesen. Zwischen uns und der Infrastruktur des europäischen Anbieters wurde eine Netzwerkverbindung eingerichtet. Die Anwendungsserver wurden neu bereitgestellt, mit den erforderlichen Konfigurationen. Große Datenbanken wurden durch das Hochladen von Backups in unsere Cloud migriert. Anschließend wurde eine Replikation zwischen den Datenbanken in unserer und der ursprünglichen Umgebung eingerichtet. Zu einem vereinbarten Zeitpunkt haben wir auf die Datenbanken in unserer Cloud umgeschaltet.
Datenvolumen und Internetkanal. Wir bitten in der Regel den Kunden, einen Export der Systeme mit den Spezifikationen zu Arbeitsspeicher, CPU und Festplatten bereitzustellen. Wir bewerten, ob die Bandbreite ausreicht, um Replikate oder Backups von virtuellen Maschinen direkt zu übertragen.
Akzeptabler Ausfall. Je nach Systemen und entsprechend den virtuellen Maschinen kann dies unterschiedlich sein, abhängig von ihrer Geschäftskritikalität. In der Regel bringt der Kunde bereits spezifische Anforderungen an den Ausfall bei der Migration mit, anhand derer wir das passende Tool und den Migrationsplan auswählen. Wir versuchen, den endgültigen Switch in die Nacht oder auf das Wochenende zu planen, sodass selbst ein geringfügiger Ausfall für die Endbenutzer des Kunden nicht wahrnehmbar ist.
Basierend auf diesen Daten kann das Tool ausgewählt und mit der Migration begonnen werden. So geht es weiter.
- Einrichtung der Netzwerkverbindung. Wir organisieren die Netzwerkverbindung zwischen unserer Cloud und der Infrastruktur des Kunden. Über dieses Netzwerk werden die virtuellen Maschinen kopiert. Wenn Veeam Backup and Replication verwendet wird, dann über einen dedizierten Kanal, seltener über einen VPN-Kanal. Bei Veeam Cloud Connect erfolgt alles über das Internet oder denselben dedizierten Kanal.
Dann wird das Netzwerk für die VM in der Cloud eingerichtet. Die Maschinen werden normalerweise in Gruppen und nicht an einem Tag umgezogen. Nachdem die VMs zu uns migriert und gestartet wurden, müssen sie mit Maschinen interagieren, die weiterhin am ursprünglichen Standort verbleiben.
- Migrationszeitplan. Wenn viele Maschinen vorhanden sind, ist es sinnvoll, sie in Gruppen aufzuteilen und in Chargen zu transportieren. Gemeinsam mit dem Kunden stimmen wir einen Plan ab, in dem festgelegt wird, wann und welche Maschinen umziehen und wann die finale Replikation und der Wechsel zum neuen Standort stattfinden.
- Testmigration. Wir migrieren eine Test-VM und überprüfen, ob alles korrekt konfiguriert ist: die Netzwerkverbindung zwischen den Standorten, die Erreichbarkeit der VM für Maschinen am ursprünglichen Standort, die Kontoberechtigungen und weiteres. Solch ein Test hilft, Verzögerungen während der tatsächlichen Migration zu vermeiden.
Das wäre alles von meiner Seite. Stellen Sie Ihre Fragen in den Kommentaren und teilen Sie Ihre Erfahrungen mit der Migration.
Quelle: habr.com
