Operation „Migration“: So erfolgt der Umzug in die Cloud von DataLine

Vor etwa 7 Jahren zogen die ersten Projekte einfach und unkompliziert in unsere Cloud um. Abbildungen virtueller Maschinen wurden auf einen FTP-Server hochgeladen oder auf Festplatten transportiert. Dann wurden die VMs über einen speziellen Import-Server in die Cloud geladen.

Wenn es für den Kunden kein Problem ist, die virtuelle Maschine für ein oder zwei Tage abzuschalten (oder wenn es keine anderen Optionen gibt), kann man das so machen. Doch wenn die Ausfallzeit maximal eine Stunde betragen darf, ist dieses Vorgehen nicht geeignet. Heute erläutere ich, welche Werkzeuge helfen, mit minimaler Ausfallzeit in die Cloud zu migrieren und wie der Migrationsprozess bei uns funktioniert.

Migration mit Veeam Backup and Replication

Veeam Backup and Replication ist als Werkzeug zur Erstellung von Backups und Replikaten bekannt. Wir verwenden es für die Migration zwischen unseren Plattformen und für den Umzug von Kunden von privater Virtualisierung in unsere Cloud. Die virtuellen Maschinen der Kunden werden auf unser vCenter repliziert, danach fügt der Ingenieur sie dem vCloud Director hinzu.

Die erste Replikation erfolgt auf der eingeschalteten virtuellen Maschine. Zu einem vereinbarten Zeitpunkt wird die Maschine beim Kunden abgeschaltet. Die Replikation wird ein weiteres Mal gestartet, um die Änderungen zu übertragen, die seit der ersten Replikation aufgetreten sind. Danach wird die virtuelle Maschine bereits in unserer Cloud gestartet.

In der Regel vergehen vom Zeitpunkt der Abschaltung der Maschine in der Infrastruktur des Kunden bis zur Einschaltung in unserer Cloud nicht mehr als eine halbe Stunde, eher 15–20 Minuten.

Dabei bleibt die ursprüngliche virtuelle Maschine beim Kunden vor Ort. Falls etwas schiefgeht, kann man sie immer wieder aktivieren. Für den Kunden hat dieses Verfahren den Vorteil, dass er kein Veeam benötigt.

Anwendungsfall 1
Der Kunde hatte seine eigene virtuelle Infrastruktur auf Basis von VMware – 40 VMs mit einem Volumen von 30 TB. Die Hardware, auf der der Cluster eingerichtet war, war bereits veraltet, und der Kunde beschloss, sich nicht mit dem Kauf neuer Hardware zu beschäftigen und in die öffentliche Cloud umzuziehen. Die Anforderung an die Ausfallzeit kritischer Systeme lag bei maximal einer Stunde. Als Werkzeug wurde Veeam Replication gewählt. Positiv war auch, dass der Internetanbieter des Kunden in unserem Rechenzentrum präsent war, was einen guten Kanal ermöglichte. Die Migration dauerte etwa einen Monat, die Ausfallzeit beim Wechsel betrug bis zu 30 Minuten für eine Gruppe virtueller Maschinen.

Migration mit Veeam Cloud Connect

Veeam Cloud Connect – ein Werkzeug, das hilft, die Replikation von virtuellen Maschinen einzurichten und Replikate in der Cloud des Dienstanbieters zu starten. Nach dem Update im 2019 Jahr wurde die Möglichkeit eingeführt, virtuelle Maschinen direkt in den vCloud Director zu replizieren. Die einzige Voraussetzung ist, dass auf der Kundenseite eine eigene Veeam Backup and Replication-Version nicht älter als 9 bereitgestellt wird. Kurz gesagt (die detaillierte Version hier), sieht der gesamte Prozess wie folgt aus.

Im vCloud Director wird eine Organisation mit den notwendigen Ressourcen und Netzwerken erstellt. In Veeam Cloud Connect richten wir ein Konto ein, das der Kunde über sein Veeam B&R verbindet, wählt den Anbieter DataLine und die Organisation aus und konfiguriert Aufgaben für die Replikation. Neben der Tatsache, dass die Ausfallzeit während dieser Migration 15–20 Minuten betragen wird, ist der Kunde nicht auf den Support des Anbieters angewiesen und verwaltet den gesamten Prozess selbst: er erstellt Aufgaben zur Replikation, führt die eigentliche Replikation durch, schaltet Maschinen aus und startet sie an neuer Stelle.

Fall 2
Die Infrastruktur des Kunden, von wo 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 100 Mbit/s betrug. Wenn ein Backup gemacht und sofort in unsere Cloud hochgeladen wird, würde das bei einigen VMs mehrere Tage in Anspruch nehmen. In dieser Zeit würde eine große Delta auf den VMs entstehen, was sich negativ auf die Leistung der Maschinen oder, noch schlimmer, auf den Speicherplatz im Datastore auswirken könnte. Wir haben wie folgt vorgegangen: Zuerst hat der Kunde ein lokales vollständiges Backup gemacht und eine Kopie davon über Veeam Cloud Connect in unsere Cloud übertragen. Danach hat er ein inkrementelles Backup gemacht und in die Cloud übertragen. Die ursprüngliche virtuelle Maschine arbeitete weiter. Nach dem Ausschalten der VM hat der Kunde ein weiteres inkrementelles Backup gemacht und ebenfalls in die Cloud übertragen. Auf unserer Seite haben wir die virtuelle Maschine aus dem vollständigen Backup bereitgestellt und dann zwei inkrementelle Backups darauf aufgespielt. Dieses Vorgehen ermöglichte es letztendlich, die Ausfallzeit beim Wechsel auf unsere Plattform auf 2 Stunden zu minimieren.

Migration mit VMware vCloud Availability

Im März dieses Jahres hat VMware vCloud Availability 3.0 veröffentlicht, das es ermöglicht, virtuelle Maschinen zwischen verschiedenen Clouds (vCloud Director – vCloud Director) und von privaten Virtualisierungsumgebungen der Kunden in die Cloud (vCenter – vCloud Director) zu migrieren. Der Hauptvorteil ist die Integration mit der vCloud Director-Oberfläche. Dies vereinfacht den Prozess der Replikationsverwaltung erheblich und minimiert die Ausfallzeiten beim Wechsel.

Mit diesem Tool haben wir einen unserer Kunden aus unserer Moskauer Cloud in unsere Cloud in St. Petersburg migriert. Es mussten 18 virtuelle Maschinen mit einer Gesamtkapazität von 14 TB übertragen werden. Für den Kunden wurde in der St. Petersburger Cloud eine Organisation erstellt und die erforderlichen Netzwerke eingerichtet. 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 zur St. Petersburger Instanz. Die Ausfallzeit beim Wechsel betrug 12 Minuten.

Das Schema der Migration zwischen den Clouds DataLine in St. Petersburg und Moskau.

vCloud Availability hat einen Mechanismus zur Migration von VM vom Standort des Kunden in unsere Cloud. Dafür wird im vCenter des Kunden eine spezielle vCloud Availability Appliance bereitgestellt. Nach einer einfachen Konfiguration erfolgt die Verbindung zur Cloud und die Migration wird eingerichtet. Der Kunde verwaltet zudem den gesamten Prozess selbst, wodurch die Migrationszeit auf ein Minimum reduziert wird.

Das Schema der Migration von virtuellen Maschinen aus einer privaten Installation in die Cloud.

VMware vCloud Availability hat viele weitere Anwendungsszenarien, über die wir bald in einem separaten Artikel berichten werden.

Vorbereitung zur Migration

Um ein Werkzeug auszuwählen und mit der Migration zu beginnen, müssen die folgenden Punkte geklärt werden:

Woher migrieren wir? Wenn Sie von einer privaten Lösung migrieren, haben Sie völlige Freiheit bei der Auswahl der Werkzeuge. Wenn Sie von einem Anbieter wechseln, wird es komplizierter. Höchstwahrscheinlich wird es aufgrund von Sicherheitsüberlegungen nicht möglich sein, die Infrastrukturen beider Anbieter zu verbinden und die VM einfach zu verschieben. Manchmal beginnt der Anbieter, von dem sich der Kunde trennen möchte, sogar zu schikanieren und verzögert den Prozess. Man kann auf alte Weise von einem Anbieter wechseln: durch das Exportieren von VMs auf Festplatten und FTP oder durch eine migrationsbasierte Anwendung. Letzteres wird als eine bedingte Bezeichnung verwendet und sieht folgendermaßen aus.

Fall 3
Es war notwendig, das SAP-System des Kunden von einem europäischen Anbieter zu 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 hergestellt. Die Anwendungsserver wurden neu bereitgestellt, mit den erforderlichen Konfigurationen. Große Datenbanken wurden durch das Laden von Backups in unsere Cloud migriert. Danach wurde die Replikation zwischen den Datenbanken auf unseren und den ursprünglichen Standorten eingerichtet. Zum vereinbarten Zeitpunkt haben wir auf die Datenbanken in unserer Cloud umgeschaltet.

Datenvolumen und Internetkanal. Wir bitten den Kunden normalerweise, einen Export der Systeme mit den Parametern RAM, CPU, Festplatten bereitzustellen. Wir bewerten, ob der Kanal ausreicht, um Replikate oder Backups der virtuellen Maschinen direkt zu senden.

Akzeptable Ausfallzeit. Für verschiedene Systeme und dementsprechend virtuelle Maschinen kann diese je nach Kritikalität für das Geschäft variieren. Normalerweise kommt der Kunde mit vorbereiteten Anforderungen an die Ausfallzeit während der Migration, und darauf basierend wählen wir das geeignete Werkzeug und den Migrationsplan aus. Wir versuchen, den endgültigen Wechsel auf die Nacht oder das Wochenende zu planen, damit selbst eine geringe Ausfallzeit von den Endbenutzern des Kunden nicht bemerkt wird.

Auf Grundlage dieser Daten kann das Werkzeug gewählt werden und die Migration kann beginnen. So geht es weiter.

1. 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. Wenn Veeam Cloud Connect verwendet wird, dann läuft alles über das Internet oder denselben dedizierten Kanal.

   Dann wird das Netzwerk für die VMs in der Cloud konfiguriert. Die Maschinen werden normalerweise in Gruppen verschoben und nicht an einem Tag. Nachdem die VMs zu uns transferiert und gestartet wurden, müssen sie mit Maschinen interagieren, die weiterhin am ursprünglichen Standort bleiben.

2. Migrationszeitplan. Wenn es viele Maschinen gibt, ist es sinnvoll, sie in Gruppen aufzuteilen und in Chargen zu transportieren. Gemeinsam mit dem Kunden stimmen wir einen Plan ab, in dem festgelegt ist, wann und welche Maschinen umziehen und wann die endgültige Replikation und der Wechsel auf den neuen Standort erfolgen.
3. Testmigration. Wir migrieren die Test-VM und überprüfen, ob alles richtig konfiguriert ist: Netzwerkverbindung zwischen den Standorten, Erreichbarkeit der VM von Maschinen am ursprünglichen Standort, Berechtigungen des Benutzerkontos usw. Ein solcher Test hilft, Verzögerungen während der eigentlichen Migration zu vermeiden.

Das war's von meiner Seite. Stellen Sie Fragen in den Kommentaren und berichten Sie von Ihren Migrationserfahrungen.

Quelle: habr.com