Von lokaler VM zur Cloud VM: Virtuelle Maschinen mittels Commvault migrieren

Viele Unternehmen haben sicher bereits mit dem Gedanken gespielt, ihre auf lokaler Hardware installierten virtuellen Maschinen in eine Cloud zu migrieren. Das kann verschiedene Gründe haben. Vielleicht sollen die Kosten reduziert werden, die z.B. durch Strom- und Hardware-Beschaffung entstehen, oder es soll der eigene Aufwand für das Hardwaremanagement (Hardware reparieren, auswechseln, etc.) reduziert werden. Wenn dies der Fall ist, dann ist eine Cloudumgebung genau das richtige Ziel für die Migration der lokalen VMs. 

Die Vorteile einer Cloud liegen darin, dass die zugeordnete Hardware komplett von der Cloud selbst verwaltet wird und Kosten nur für tatsächlich genutzten Speicher und Ressourcen entstehen. Dieser Artikel zeigt, wie lokale VMs im VMware vCenter, mittels Commvault Restore in eine Cloud migriert und Cloud VMs zu einem anderen Cloud Provider verschoben werden können. Dabei wird auf die Migration zu Amazon Web Services (AWS) und Microsoft Azure genauer eingegangen. 

Als Ziel für unsere Backupdaten wählen wir nicht das Azure oder Amazon S3 Storage, sondern einen externen Object Storage Anbieter. Aufgrund der günstigeren Preise für Datenlagerung und den kostenlosen Engress Traffic haben wir uns hier für Wasabi entschieden.

Voreinstellungen in der Cloud

Vor der Migration müssen in der Cloud einige Konfigurationen durchgeführt werden. Das Erste und Wichtigste, was in jeder Cloud konfiguriert werden muss, ist das Netzwerk oder auch VPC (Virtual Private Cloud), zusammen mit einem zugehörigen Subnetz. Darüber hinaus muss auch mindestens ein IP-Adressbereich angegeben werden.

Da wir hier mit Netzwerken arbeiten, ist es natürlich auch wichtig, eine Firewall bzw. Sicherheitsgruppe zu konfigurieren. Dazu müssen auf der Cloud-Seite die benötigten Ports geöffnet werden.

Damit wäre die Konfiguration des Netzwerkes abgeschlossen. Als nächstes müssen die Zugangsdaten erstellt werden, damit Commvault auf die Cloud zugreifen kann. Diese werden in der Regel als Access Key und Secret Key bezeichnet. Für Azure werden noch weitere Zugangsdaten und Berechtigungen benötigt. Wichtig ist, dass die Zugangsdaten sofort notiert und sicher gespeichert werden, da manche Daten nur einmal nach dem Erstellen sichtbar sind.

Zuletzt wird ein Bucket/Container in einer Cloud als Storage erstellt. Alternativ kann auch ein lokal erstelltes Storage verwendet werden. In diesem Storage werden die Backups gespeichert, die auch für den Restore genutzt werden.

Damit ist die Konfiguration auf der Cloud-Seite abgeschlossen.

Voreinstellungen in Commvault

Bevor auf das Thema "Restore" eingegangen wird, muss zuerst festgestellt, was die nötigen Konfigurationen für das Speichern von Backups in einem Cloud-Storage sind. Dazu muss in Commvault zuerst ein Storage Pool mit einer Library und eine zugehörige Storage Policy erstellt werden. 

Zu Beginn muss der Cloud Storage Typ (hier: Wasabi Hot Cloud Storage; alternativ Amazon S3, Microsoft Azure Storage, Google Cloud Storage etc.) und dann die nötigen Zugangsdaten (Access Key, Secret Key o.ä.) angegeben werden. Der folgende Screenshot zeigt, welche Informationen für die Registrierung der Wasabi Cloud in Commvault benötigt werden:

Als nächstes werden für den Restore in eine Cloud weitere Konfigurationen in Commvault benötigt. Dazu wird ein Virtualisierungs-Client in der Commcell Console oder ein Hypervisor im Command Center erstellt.

Der folgende Screenshot aus der Commcell Console zeigt die verfügbaren Typen von Virtualisierungs-Clients:

Um einen Virtualisierungs-Client/Hypervisor für AWS und Azure zu erstellen, werden die im vorherigen Abschnitt erstellten Zugangsdaten und ein VPC benötigt. Dieser Client wird auch für die Backup-Erstellung von Cloud VMs verwendet.

Damit ist die Konfiguration auf der Commvault-Seite abgeschlossen. Als nächstes wird zu sehen sein, wie die Migration auf Basis dieser Einstellungen durchgeführt wird.

Durchführung der Migration 

Damit Backupdaten für einen Restore vorhanden sind, ist jeweils ein Backup für die zu migrierenden VMs durchzuführen. Die Backup-Daten können lokal oder in der Cloud gespeichert werden. Damit der Restore einer Linux VM nach Azure fehlerfrei läuft, müssen vor dem Backup noch Treiber installiert werden.

Das direkte Restore nach AWS und Azure ist komplett über Commvault möglich. Dazu wird in Commvault der Restore-Typ "Full Virtual Machine" mit der "Restore as" Option "Amazon" oder "Azure Ressource Manager" ausgewählt. Dabei werden für die Ziel-VMs noch weitere Angaben zu Ressourcen, Netzwerken und Sicherheitsgruppen gemacht. Während für Amazon die direkte Angabe einer festen privaten IP-Adresse erlaubt wird, kann diese bei Azure erst nach dem Restore auf der Cloud-Seite angegeben werden.

Sobald alles konfiguriert und durchgeführt wurde startet der Restore Prozess.

Nach dem Abschluss des Prozesses sind die gewünschten VMs in exakt dem gleichen Zustand wie zum Zeitpunkt des Backups in der Ziel-Cloud vorhanden. Die Migration wäre damit erfolgreich abgeschlossen.

Vorab besteht die Möglichkeit, bei Bedarf mittels der Commcell Ressouce "Dev-Test Groups" Probe-Restores durchzuführen. Damit können VMs direkt aus den Backup-Daten für Testzwecke erstellt werden. Das Ziel der VMs dieses Test-Restores kann sowohl lokal als auch in der Cloud sein. Diese VMs sind nur temporär und werden nach der angegebenen Zeit automatisch gelöscht.

Vergleich und Ergebnis 

Zum Schluss werden in diesem Abschnitt die Migrationen in die verschiedenen Cloud-Umgebungen auf Basis der Performance und Komplexität miteinander verglichen.

Das Testvorgehen und die Zeiten der Vergleichstabelle basieren auf folgender Architektur:

Zusätzlich zum oben gezeigten Testvorgehen, wird zum Vergleich in der folgenden Tabelle auch ein komplett lokales Backup und "In-Place" Restore der VM gezeigt:

* Es handelt sich um Durchschnittszeiten auf Basis von mehreren Tests mit verschiedenen APIs. Das Testobjekt ist eine Windows VM mit ca. 10GB belegtem Speicher.
** Die Komplexitätswerte (1=einfach, 10=komplex) sind rein subjektiv und können von jeder Person anders empfunden werden.

Wie der Tabelle zu entnehmen ist, dauert ein Restore in eine Cloud mindestens doppelt so lange, wie ein Backup. Das liegt daran, dass die Konvertierung der Backup-Daten in eine VM auf Cloud-Sseite etwas mehr Zeit in Anspruch nimmt. Je nach verwendeter API (HotAdd, Import/Export, EBS Direct Write) kann die benötigte Zeit variieren. Ein lokaler Restore benötigt hingegen etwa nur solange, wie das Backup selbst. Das liegt daran, dass die Backupdaten hier nicht zusätzlich noch konvertiert werden müssen.

Ein VSA (Virtual Server Agent) oder Access Node ist eine Commvault-Komponente, die Backup- und Restore Operationen auf dem jeweiligen Hypervisor durchführt. Bei der oben genannten Architektur befindet sich der externe VSA in nur AWS. Dies wäre für Azure auch möglich gewesen. Der VSA in AWS hat den Vorteil, dass dadurch die schnellere EBS API verwendet werden kann. Die Daten für Azure (Schritt 4) müssen hierbei zweimal durchs Internet transferiert werden, für alle anderen nur einmal.

Bei einem Test mit nur einem lokalen VSA werden die Daten für den Restore immer (außer bei Schritt 1) zweimal durchs Internet transportiert. Dabei ändert sich an den Laufzeiten von Schritt 2 und 3 nichts:

In unseren Tests konnten wir sehen, dass die Migration nach AWS die beste Performance und nur eine moderate Komplexität aufweist. Vor allem mit der neuen AWS-EBS-Direct-Write-Methode würde der Restore sogar noch schneller werden.

Schlussendlich zeigt sich, dass Backups und Restores als Grundlage für einfache Migrations-Szenarien geeignet sind und Commvault dies bereits für einige Cloud-Anbieter unterstützt. Auch für den Desaster Fall, bei dem einige VMs, aufgrund von fehlerhafter Hardware funktionsuntüchtig werden, kann es eine schnelle Hilfe sein. Solange neue Hardware angeschafft wird, können die betroffenen VMs weiter in der Cloud laufen. Wie man sieht, hat man durch die Migrationsmöglichkeiten auch einen Zusatznutzen für bereits vorhandene Backups.

Seminarempfehlung