Operation „Migration“: So wechseln Sie in die DataLine-Cloud

Vor etwa 7 Jahren zogen die allerersten Projekte einfach und unkompliziert in unsere Cloud. Abbilder virtueller Maschinen wurden auf einen FTP-Server hochgeladen oder auf Festplatten bereitgestellt. Anschließend wurden die VMs über einen speziellen Importserver in die Cloud hochgeladen.

Wenn es für den Client kein Problem darstellt, die virtuelle Maschine für ein oder zwei Tage auszuschalten (oder es keine anderen Möglichkeiten gibt), kann dies getan werden. Sollte die Ausfallzeit aber maximal eine Stunde betragen, dann wird diese Methode nicht funktionieren. Heute erzähle ich Ihnen, welche Tools Ihnen bei der Migration in die Cloud mit minimalen Ausfallzeiten helfen und wie unser Migrationsprozess selbst funktioniert.

Migration mit Veeam Backup and Replication

Jeder kennt Veeam Backup and Replication als Tool zum Erstellen von Backups und Replikaten. Wir nutzen es für die Migration zwischen unseren Standorten und für den Transport von Clients von der privaten Virtualisierung in unsere Cloud. Die virtuellen Maschinen des Kunden werden in unserem vCenter repliziert, woraufhin der Techniker sie zu vCloud Director hinzufügt.

Die primäre Replikation erfolgt auf einer eingeschalteten virtuellen Maschine. Zum vereinbarten Zeitpunkt wird die clientseitige Maschine ausgeschaltet. Die Replikation wird erneut ausgeführt, um die seit der ersten Replikation vorgenommenen Änderungen zu übernehmen. Danach startet die virtuelle Maschine in unserer Cloud.

Typischerweise vergeht vom Ausschalten der Maschine in der Infrastruktur des Kunden bis zum Einschalten in unserer Cloud nicht mehr als eine halbe Stunde, sondern eher 15–20 Minuten.

In diesem Fall verbleibt die ursprüngliche virtuelle Maschine auf der Client-Site. Wenn plötzlich etwas schief geht, können Sie jederzeit einen Rollback durchführen und es wieder einschalten. Diese Methode ist auch für den Kunden praktisch, da er kein Veeam benötigt.

Fall 1
Der Kunde verfügte über eine eigene virtuelle Infrastruktur auf Basis von VMware – 40 VMs mit einer Kapazität von 30 TB. Die Geräte, auf denen der Cluster bereitgestellt wurde, waren bereits veraltet, und der Kunde beschloss, sich nicht die Mühe zu machen, neue Geräte zu kaufen, und wechselte in die öffentliche Cloud. Die erforderliche Ausfallzeit für kritische Systeme betrug nicht mehr als eine Stunde. Als Tool wurde Veeam Replication gewählt. Ein weiterer Pluspunkt war, dass der Internetprovider des Kunden in unserem Rechenzentrum vorhanden war, was die Organisation eines guten Kanals ermöglichte. Die Migration dauerte etwa einen Monat, die Ausfallzeit während des Wechsels betrug bis zu 30 Minuten pro Gruppe virtueller Maschinen.

Migrieren Sie mit Veeam Cloud Connect

Veeam Cloud Connect ist ein Tool, mit dem Sie die Replikation virtueller Maschinen einrichten und Replikate in der Cloud des Dienstanbieters starten können. Nach dem Update auf 2019 Jahr wurde 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 werden muss. Kurz gesagt (ausführliche Version). hier), dann sieht der ganze Prozess so aus.

In vCloud Director wird eine Organisation mit den notwendigen Ressourcen und Netzwerken erstellt. In Veeam Cloud Connect erstellen wir ein Konto, der Kunde stellt von seinem Veeam B&R aus eine Verbindung dazu her, wählt einen DataLine-Anbieter und eine DataLine-Organisation aus und konfiguriert Aufgaben für die Replikation. Abgesehen davon, dass bei einer solchen Migration die Ausfallzeit innerhalb von 15 bis 20 Minuten liegt, ist der Kunde in keiner Weise auf den technischen Support des Anbieters angewiesen und verwaltet den gesamten Prozess selbstständig: Er erstellt Replikationsaufgaben, schaltet die Replikation selbst ab die Maschinen und startet sie auf der neuen Site.

Fall 2
Die Infrastruktur des Kunden, von wo aus die Migration geplant war, befand sich in Weißrussland. 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, würde es bei manchen VMs mehrere Tage dauern. In dieser Zeit wäre auf der VM ein großes Delta gewachsen, was sich negativ auf die Leistung der Maschinen auswirken könnte oder, noch schlimmer, der Platz im Datenspeicher wäre erschöpft. Wir sind wie folgt vorgegangen: Zunächst hat der Kunde ein lokales Voll-Backup erstellt und eine Kopie davon über Veeam Cloud Connect in unsere Cloud übertragen. Dann habe ich das Inkrement erstellt und in die Cloud übertragen. Die ursprüngliche virtuelle Maschine lief weiter. Nach dem Herunterfahren der VM führte der Client ein weiteres Inkrement durch 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 ausgeführt. Durch dieses Schema konnte letztendlich die Ausfallzeit beim Wechsel auf unsere Website auf 2 Stunden minimiert werden.

Migration mit VMware vCloud-Verfügbarkeit

Im März dieses Jahres veröffentlichte VMware vCloud Availability 3.0, mit dem Sie virtuelle Maschinen zwischen verschiedenen Clouds (vCloud Director – vCloud Director) und von privaten Client-Virtualisierungsständen in die Cloud (vCenter – vCloud Director) migrieren können. Der größte Vorteil liegt in der Integration mit der vCloud Director-Schnittstelle. Dies vereinfacht den Replikationsverwaltungsprozess erheblich und minimiert Ausfallzeiten bei Umstellungen.

Mit diesem Tool haben wir einen unserer Kunden von 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. Petersburger Cloud erstellt und die notwendigen Netzwerke organisiert. Als nächstes ging der Kunde über die vCloud Director-Schnittstelle zu den vCloud-Verfügbarkeitseinstellungen, erstellte Replikationsjobs und wechselte zu einem für ihn passenden Zeitpunkt zum Standort St. Petersburg. Die Ausfallzeit während des Umschaltens betrug 12 Minuten.

Migrationsschema zwischen DataLine-Clouds in St. Petersburg und Moskau.

vCloud Availability verfügt über einen Mechanismus zum Migrieren von VMs vom Standort des Kunden in unsere Cloud. Dazu wird eine spezielle vCloud Availability-Anwendung im vCenter des Kunden bereitgestellt. Nach der einfachen Einrichtung stellen Sie eine Verbindung zur Cloud her und konfigurieren Migrationsaufgaben. Der Kunde verwaltet zudem den gesamten Prozess selbstständig und die Migrationszeit wird auf ein Minimum reduziert.

Schema zur Migration virtueller Maschinen von einer privaten Installation in die Cloud.

Die Verfügbarkeit von VMware VCloud hat viele andere Anwendungsfälle. Wir werden bald in einem separaten Artikel darüber sprechen.

Vorbereitung auf die Migration

Um ein Tool auszuwählen und tatsächlich mit der Migration zu beginnen, müssen Sie sich über die folgenden Punkte entscheiden:

Woher migrieren wir? Wenn Sie von einer privaten Lösung migrieren, haben Sie völlige Freiheit bei der Auswahl der Tools. Wenn Sie Ihren Anbieter verlassen, wird es komplizierter. Die Verknüpfung der Infrastrukturen zweier Anbieter und das einfache Ziehen und Ablegen einer VM wird aus Sicherheitsgründen höchstwahrscheinlich nicht funktionieren. Manchmal verhält sich der Anbieter, den der Kunde im Begriff ist, abzulehnen, schelmisch und zögert auf Zeit. Sie können sich auf altmodische Weise vom Anbieter entfernen: indem Sie VMs auf Festplatten und FTP hochladen oder indem Sie auf Anwendungsebene migrieren. Der Name des letzteren ist bedingt und sieht in etwa so aus.

Fall 3
Es war notwendig, das SAP-System des Kunden von einem europäischen Anbieter zu migrieren: 34 VMs mit einer Kapazität von 54 TB. Dem Kunden wurden Ressourcen in unserer Cloud zugewiesen. Die Netzwerkanbindung wurde zwischen uns und der Infrastruktur des europäischen Anbieters organisiert. Die Anwendungsserver wurden erneut bereitgestellt und die erforderlichen Konfigurationen übernommen. Große Datenbanken wurden durch das Hochladen von Backups in unsere Cloud migriert. Als nächstes wurde die Replikation zwischen den Datenbanken auf unserer und der ursprünglichen Site konfiguriert. Zum vereinbarten Zeitpunkt sind wir auf Datenbanken in unserer Cloud umgestiegen.

Datenvolumen und Internetkanal. Normalerweise bitten wir den Kunden, einen Upload nach System mit Speicher-, CPU- und Festplattenparametern bereitzustellen. Wir bewerten, ob der Kanal ausreicht, um Replikate oder Backups virtueller Maschinen direkt zu versenden.

Akzeptable Ausfallzeit. Für verschiedene Systeme und dementsprechend virtuelle Maschinen kann es je nach Geschäftskritikalität unterschiedlich sein. In der Regel stellt der Kunde vorgefertigte Anforderungen für Ausfallzeiten während der Migration und auf dieser Grundlage wählen wir das geeignete Tool und den Migrationsplan aus. Wir versuchen, die endgültige Umstellung nachts oder am Wochenende zu planen, sodass selbst geringfügige Ausfallzeiten für die Endbenutzer des Kunden nicht spürbar sind.

Basierend auf diesen Daten können Sie ein Tool auswählen und mit der eigentlichen Migration beginnen. Folgendes passiert als nächstes.

1. Einrichten der Netzwerkkonnektivität. Wir organisieren die Netzwerkkonnektivität zwischen unserer Cloud und der Infrastruktur des Kunden. Virtuelle Maschinen werden über dieses Netzwerk kopiert. Wenn Veeam Backup and Replication verwendet wird, handelt es sich um einen dedizierten Kanal, seltener um einen VPN-Kanal. Wenn Veeam Cloud Connect, dann läuft alles über das Internet oder den gleichen dedizierten Kanal.

   Anschließend wird das Netzwerk für die VM in der Cloud konfiguriert. Autos bewegen sich normalerweise in Gruppen und für mehr als einen Tag. Sobald die VMs zu uns gebracht und gestartet wurden, müssen sie mit den Maschinen kommunizieren, die noch am ursprünglichen Standort verbleiben.

2. Migrationsplan. Bei vielen Autos ist es sinnvoll, sie in Gruppen aufzuteilen und schubweise zu transportieren. Gemeinsam mit dem Kunden vereinbaren wir einen Plan, in dem wir festlegen, wann und welche Maschinen umziehen und wann die endgültige Replikation und Umstellung auf den neuen Standort durchgeführt wird.
3. Testmigration. 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 auf dem Quellstandort, Kontorechte usw. Dieser Test hilft, Probleme in der Kampfmigrationsphase zu vermeiden.

Das ist alles für mich. Stellen Sie in den Kommentaren Fragen und erzählen Sie uns von Ihren Migrationserfahrungen.

Source: habr.com