Vor ungefähr 7 Jahren zogen die allerersten Projekte einfach und unprätentiös in unsere Cloud. Images von virtuellen Maschinen wurden auf einen FTP-Server hochgeladen oder auf Festplatten gespeichert. Anschließend wurden die VMs über einen speziellen Importserver in die Cloud hochgeladen.
Wenn es für den Client kein Problem ist, die virtuelle Maschine für ein oder zwei Tage auszuschalten (oder es gibt keine anderen Optionen), ist dies möglich. Sollte die Ausfallzeit jedoch maximal eine Stunde betragen, funktioniert diese Methode nicht. Heute werde ich Ihnen mitteilen, mit welchen Tools Sie mit minimalen Ausfallzeiten in die Cloud migrieren können und wie der Migrationsprozess bei uns funktioniert.
Migration mit Veeam Backup and Replication
Jeder kennt Veeam Backup and Replication als Tool zum Erstellen von Backups und Replikaten. Wir verwenden es für die Migration zwischen unseren Standorten und für den Transport von Kunden mit privater Virtualisierung in unsere Cloud. Virtuelle Client-Maschinen werden in unser vCenter repliziert und anschließend vom Ingenieur zu vCloud Director hinzugefügt.
Die primäre Replikation wird auf einer aktivierten virtuellen Maschine durchgeführt. Zum vereinbarten Zeitpunkt schaltet sich der Rechner auf der Client-Seite aus. Die Replikation beginnt erneut, um die Änderungen zu übertragen, die seit der ersten Replikation vorgenommen wurden. Danach startet die virtuelle Maschine bereits in unserer Cloud.
Normalerweise vergehen von dem Moment an, in dem der Computer in der Infrastruktur des Clients ausgeschaltet ist, bis zu dem Moment, in dem er eingeschaltet ist, nicht mehr als eine halbe Stunde, sondern 15 bis 20 Minuten in unserer Cloud.
Gleichzeitig bleibt die ursprüngliche virtuelle Maschine auf dem Client-Standort. Wenn plötzlich etwas schief geht, können Sie es jederzeit zurücksetzen und einschalten. Für den Kunden ist diese Methode auch insofern praktisch, als Veeam von ihm nicht benötigt wird.
Fall 1
Der Client verfügte über eine eigene virtuelle Infrastruktur auf Basis von VMware - 40 VMs mit einer Kapazität von 30 TB. Die Ausrüstung, auf der der Cluster bereitgestellt wurde, ist bereits veraltet, und der Kunde hat beschlossen, sich nicht an der Anschaffung eines neuen zu beteiligen und auf eine öffentliche Cloud umzusteigen. Die Ausfallzeit kritischer Systeme betrug nicht mehr als eine Stunde. Veeam Replication wurde als Tool ausgewählt. Das Plus war auch, dass der Internetprovider des Kunden in unserem Rechenzentrum präsent war, wodurch wir einen guten Kanal organisieren konnten. Die Migration dauerte ungefähr einen Monat, während der Wechsel zu einer Gruppe virtueller Maschinen einfach war und bis zu 30 Minuten dauerte.Migrieren Sie mit Veeam Cloud Connect
Veeam Cloud Connect ist ein Tool, mit dem Sie die Replikation virtueller Maschinen konfigurieren und Repliken in der Cloud des Dienstanbieters ausführen können. Nach dem Update im Jahr
2019 war es möglich, virtuelle Maschinen direkt in vCloud Director zu replizieren. Die einzige Bedingung ist, dass auf der Clientseite Veeam Backup and Replication mindestens Version 9 bereitgestellt sein muss. Kurz gesagt (eine ausführliche Version finden Sie
hier ), sieht der gesamte Prozess wie folgt aus.
VCloud Director erstellt eine Organisation mit den erforderlichen Ressourcen und Netzwerken. In Veeam Cloud Connect erstellen wir ein Konto, der Client stellt über Veeam B & R eine Verbindung dazu her, wählt den DataLine-Anbieter und die Organisation aus und richtet Aufgaben für die Replikation ein. Neben der Tatsache, dass während einer solchen Migration die Ausfallzeit innerhalb von 15 bis 20 Minuten liegt, ist der Client nicht auf den technischen Support des Anbieters angewiesen und verwaltet den gesamten Prozess unabhängig: Er erstellt Replikationsaufgaben, repliziert sich selbst, schaltet die Computer aus und startet ihren Start an einem neuen Standort.
Fall 2
Die Kundeninfrastruktur, von der aus die Migration geplant war, befand sich in Belarus. Es mussten 90 VMs mit einem Gesamtvolumen von 27 TB transportiert werden, obwohl der Internetkanal 100 MBit / s betrug. Wenn Sie ein Backup erstellen und es sofort in unsere Cloud hochladen, dauert dies bei einigen VMs mehrere Tage. In dieser Zeit würde auf der VM ein großes Delta wachsen, was sich bereits nachteilig auf die Leistung der Maschinen auswirken könnte, oder, noch schlimmer, der Platz im Datenspeicher ist erschöpft. Die Vorgehensweise war wie folgt: Zunächst erstellte der Client ein lokales Voll-Backup und übermittelte uns eine Kopie davon über Veeam Cloud Connect in die Cloud. Dann machte er und warf das Inkrement in die Wolke. Die ursprüngliche virtuelle Maschine funktionierte weiterhin. Nach dem Herunterfahren der VM nahm der Client ein weiteres Inkrement vor und übertrug es ebenfalls in die Cloud. Auf unserer Seite haben wir eine virtuelle Maschine aus einem vollständigen Backup bereitgestellt und dann zwei Inkremente darauf gerollt. Ein solches Schema ermöglichte es uns, die Ausfallzeit beim Wechsel zu unserer Site auf 2 Stunden zu minimieren.Migration mit VMware vCloud-Verfügbarkeit
Im März dieses Jahres veröffentlichte VMware vCloud Availability 3.0, mit dem virtuelle Maschinen zwischen verschiedenen Clouds (vCloud Director - vCloud Director) und von der Virtualisierung privater Clients zur Cloud (vCenter - vCloud Director) migriert werden können. Der Hauptkomfort ist die Integration in die vCloud Director-Oberfläche. Dies vereinfacht das Replikationsmanagement erheblich und minimiert Ausfallzeiten beim Wechsel.
Mit diesem Tool haben wir einen der Clients aus unserer Moskauer Cloud in unsere Cloud in St. Petersburg migriert. Es mussten 18 virtuelle Maschinen mit einer Gesamtkapazität von 14 TB transportiert werden. Für den Kunden wurde eine Organisation in der St. Petersburg Cloud erstellt und die notwendigen Netzwerke organisiert. Anschließend wechselte der Client über die vCloud Director-Oberfläche zu den vCloud-Verfügbarkeitseinstellungen, erstellte Replikationsaufgaben und wechselte zu einem geeigneten Zeitpunkt zum Standort St. Petersburg. Die Ausfallzeit beim Umschalten betrug 12 Minuten.
Das Migrationsschema zwischen den DataLine-Wolken in St. Petersburg und Moskau.VCloud Availability verfügt über einen Mechanismus zum Migrieren von VMs von einem Clientstandort in unsere Cloud. Zu diesem Zweck wird im vCenter-Client eine spezielle vCloud-Verfügbarkeitsanwendung bereitgestellt. Nach einer einfachen Einrichtung sind Sie mit der Cloud verbunden und die Migrationsaufgaben sind konfiguriert. Der Client verwaltet den gesamten Prozess auch unabhängig und die Migrationszeit wird minimiert.
Ein Diagramm der Migration virtueller Maschinen von einer privaten Installation in die Cloud.In VMware vCloud Availability gibt es viele andere Anwendungsfälle, über die wir in Kürze in einem separaten Artikel sprechen werden.
Vorbereitung für die Migration
Um ein Tool auszuwählen und tatsächlich mit der Migration fortzufahren, müssen Sie sich für die folgenden Punkte entscheiden:
Woher migrieren wir? Wenn Sie von einer privaten Lösung migrieren, haben Sie die volle Freiheit bei der Auswahl der Tools. Wenn Sie den Anbieter verlassen, ist es schwieriger. Die Verbindung der Infrastruktur der beiden Anbieter und das einfache Ziehen der VM schlägt höchstwahrscheinlich aus Sicherheitsgründen fehl. Manchmal ist der Anbieter, den der Kunde ablehnt, völlig schädlich und braucht Zeit. Sie können den Anbieter auf die altmodische Weise verlassen: indem Sie die VM auf Festplatten und FTP hochladen oder auf Anwendungsebene migrieren. Der Name des letzteren ist willkürlich und sieht ungefähr so aus.
Fall 3
Das SAP-System des Kunden musste von einem europäischen Anbieter migriert werden: 34 VMs mit einem Volumen von 54 TB. Die Ressourcen wurden dem Kunden in unserer Cloud zugewiesen. Zwischen uns und der Infrastruktur des europäischen Anbieters wurde die Netzwerkanbindung organisiert. Anwendungsserver wurden mit dem Rollup der erforderlichen Konfigurationen erneut bereitgestellt. Große Datenbanken wurden migriert, indem Sicherungen in unsere Cloud hochgeladen wurden. Als Nächstes wurde die Replikation zwischen den Datenbanken auf unseren und den Quellwebsites konfiguriert. Zum vereinbarten Zeitpunkt haben wir auf die Datenbanken in unserer Cloud umgestellt.Die Datenmenge und der Internet-Kanal. Normalerweise bitten wir den Client, das Entladen auf Systemen mit Parametern für Arbeitsspeicher, CPU und Festplatten bereitzustellen. Wir schätzen, ob der Kanal ausreicht, um Replikate oder Backups von virtuellen Maschinen direkt zu senden.
Einfach gültig. Für verschiedene Systeme und dementsprechend auch für virtuelle Maschinen kann dies je nach Kritikalität für das Geschäft unterschiedlich sein. In der Regel stellt ein Client vorgefertigte Anforderungen für Ausfallzeiten während der Migration. Auf dieser Grundlage wählen wir das richtige Tool und den richtigen Migrationsplan aus. Wir versuchen, die endgültige Umstellung auf Nacht oder Wochenende so zu planen, dass selbst eine geringfügige Ausfallzeit für die Endbenutzer des Kunden nicht spürbar ist.
Basierend auf diesen Daten können Sie ein Tool auswählen und mit der Migration selbst fortfahren. Folgendes passiert als nächstes.
- Netzwerkverbindung konfigurieren. Wir organisieren die Netzwerkkonnektivität zwischen unserer Cloud und der Kundeninfrastruktur. Virtuelle Maschinen werden über dieses Netzwerk kopiert. Wenn Veeam Backup and Replication verwendet wird, ist dies ein dedizierter Kanal, seltener ein VPN-Kanal. Wenn Veeam Cloud Connect verwendet wird, erfolgt alles über das Internet oder denselben dedizierten Kanal.
Anschließend wird das Netzwerk für die VM in der Cloud konfiguriert. Autos bewegen sich normalerweise in Gruppen und mehr als einem Tag. Nachdem die VMs an uns übertragen und gestartet wurden, sollten sie mit den Maschinen interagieren, die noch am Startort verbleiben. - Zeitplan für die Migration. Wenn es viele Autos gibt, ist es sinnvoll, sie in Gruppen aufzuteilen und in Chargen zu transportieren. Gemeinsam mit dem Kunden vereinbaren wir einen Plan, in dem wir vorschreiben, wann und auf welchen Maschinen die endgültige Replikation und der Wechsel zu einem neuen Standort durchgeführt werden.
- Testen Sie die Migration. Wir migrieren die virtuelle Testmaschine und prüfen, ob alles richtig konfiguriert ist: Netzwerkkonnektivität zwischen Standorten, Verfügbarkeit der virtuellen Maschine für Maschinen am Quellstandort, Kontorechte und mehr. Ein solcher Test hilft, Probleme in der Phase der Kampfmigration zu vermeiden.
Das ist alles für mich. Stellen Sie Fragen in den Kommentaren und berichten Sie über Ihre Migrationserfahrung.