AWS SMS: So migrieren Sie Workloads von Azure auf Amazon
Der AWS Server Migration Service kann Azure-, Windows- und VMware-VMs in AWS verschieben, sei es eine einmalige Migration oder eine periodische Replikation zwischen den Umgebungen.
Wenn Unternehmen Workloads auf eine Cloud-Plattform migrieren, müssen ihre Administratoren die Replikation von Live-Server-VMs planen, implementieren und überwachen – unabhängig davon, ob diese VMs im Unternehmen oder in einer anderen Cloud ausgeführt werden. Und diese Herausforderungen nehmen zu, wenn es darum geht, große Mengen an VMs zu migrieren.
Viele Public Cloud-Anbieter offerieren VM-Replikationsdienste, um umfangreiche Migrationen von lokalen Rechenzentren auf ihre Plattformen zu erleichtern, einschließlich Funktionen für Automatisierung, Planung und Reporting. Ein Beispiel dafür ist der AWS Server Migration Service (SMS). Und obwohl AWS SMS nicht neu ist, wurde es vor kurzem erweitert, um Migrationen zwischen den beiden beliebtesten Public Cloud Umgebungen – AWS und Microsoft Azure – zu ermöglichen.
Lassen Sie uns einen genaueren Blick auf AWS SMS werfen und die Schritte zur Migration von Azure zu AWS betrachten.
AWS SMS verstehen
Ein Unternehmen kann AWS SMS verwenden, um die Replikation von Windows- und Linux-VMs in die AWS Public Cloud zu automatisieren und zu orchestrieren. SMS war auf lokale vSphere- und Hyper-V VM-Migrationen beschränkt, bevor die Unterstützung für Azure-VMs hinzugefügt wurde.
SMS identifiziert die zu migrierenden VMs und repliziert sie als Amazon Machine Image (AMI) Dateien. Sobald ein AMI erstellt ist, kann es automatisch – oder auf Wunsch auch später – in einer geeigneten Amazon EC2-Instanz bereitgestellt werden. Aber die eigentliche Stärke von SMS ist die Fähigkeit, die geordnete Migration von VM-Gruppen zu bewältigen, was es Administratoren ermöglicht, umfassende Infrastrukturmigrationen zu AWS zu organisieren. Dies ist besonders nützlich, wenn Sie Gruppen von verwandten VMs migrieren, die zusammenwirken, um eine übergreifende Anwendung zu erstellen.
Beispielsweise kann SMS eine AWS CloudFormation-Vorlage verwenden, um die AMIs für Gruppen wie Datenbankserver, Dateiserver, Webserver und Anwendungsserver zu starten. Es kann AMIs in jeder Gruppe in der gewünschten Reihenfolge starten und damit sicherstellen, dass die Anwendung wie in AWS erwartet funktioniert.
Kontinuierliche Replikation oder Migration von Azure zu AWS
Die Verwendung von SMS ist nicht unbedingt eine einmalige Aktion. Da es die Quell-VM nicht beeinflusst, kann SMS mehrere Replikationen derselben VM auf AWS AMIs planen und orchestrieren. Dadurch können Änderungen an lokalen oder Azure-VMs regelmäßig in AWS aktualisiert werden. Beispielsweise können Unternehmen Updates lokal – oder in Azure – testen und dann per SMS an AWS replizieren, um sie für die Produktionsbereitstellung zu verwenden. SMS-Benutzer können anfängliche Replikationszeitpläne einrichten, Replikationsintervalle auswählen, den Fortschritt jeder VM-Replikation verfolgen und mithilfe von Skripten den Start jeder VM in AWS anpassen.
SMS hängt von der Verwendung von Konnektoren ab, die dedizierte Dienstprogramme sind, die in der Quellumgebung eingesetzt werden. Diese Konnektoren ermöglichen es AWS SMS, die verfügbaren VMs in der Quellumgebung zu scannen und diese VMs für die Migration zu AWS auszuwählen. Konnektoren sind für VMware, Hyper-V und Azure verfügbar. Abhängig von der Quellumgebung benötigen Administratoren einen spezifischen Konnektor-Download sowie ein vorgefertigtes Skript zur Installation des Konnektors. Der Installationsprozess variiert je nach Quellumgebung und die AWS SMS-Dokumentation enthält detaillierte Anweisungen.
AWS SMS stellt auch zahlreiche Anforderungen und nimmt mehrere programmatische Änderungen an den importierten VMs vor. Zusammengenommen können die Anforderungen und Änderungen, die für die Ausführung von SMS erforderlich sind, die Fähigkeit eines Unternehmens, den Dienst zu nutzen, beeinträchtigen oder die Migration bestimmter VMs verhindern. Es ist wichtig, die geltenden Anforderungen an SMS und ihre Konnektoren in der AWS SMS-Dokumentation zu überprüfen, bevor Sie versuchen, den Dienst zu nutzen. Und selbst dann lohnt es sich, den Migrationsprozess zu testen, bevor man SMS unternehmensweit einsetzt.
Beispielsweise müssen potenzielle SMS-Anwender diese Probleme berücksichtigen: die Auswirkungen von Anti-Malware- und Intrusion-Detection-Tools, Fernzugriffsberechtigungen für Windows- und Linux-VMs, spezifische vSphere-, Hyper-V- und Azure-Konnektoranforderungen, Unterstützung für zugrundeliegende Betriebssysteme, Dateisysteme und Datenträgertypen, die auf jeden SMS-Replikationsauftrag angewandte OS- und AWS-Lizenz und unzählige andere Einschränkungen in Bezug auf Bildformat, Dateisystem oder Boot-up, Netzwerk.
Migration von Azure zu AWS
Eine Anwendungsmigration mit AWS SMS umfasst vier allgemeine Verfahren: Erstellen der Anwendung, Konfigurieren der Starteinstellungen für die Anwendung, Starten der Replikation und dann das tatsächliche Starten der Anwendung. Eine Anwendung ist in diesem Fall eine Reihe von AWS-Ressourcen, die schließlich die migrierten Anwendungskomponenten enthalten würden. Jede AWS SMS-Aufgabe kann über die AWS SMS-API, die AWS Command Line Interface (CLI) oder die AWS SDKs durchgeführt werden.
Anlegen.Administratoren verwenden die AWS SMS-Konsole, um auf die Seite Anwendungen zuzugreifen und eine neue Anwendung zu erstellen. Administratoren legen die Details für die neue Anwendung fest, wählen dann die Quell-VMs aus und ordnen sie zu gewünschten Gruppen an. Hier sind die Konnektoren entscheidend für die Identifizierung der verfügbaren VMs in den lokalen vSphere-, Hyper-V- oder Azure-Cloud-Umgebungen.
Ein Unternehmen kann AWS SMS verwenden, um die Replikation von Windows- und Linux-VMs in die AWS Public Cloud zu automatisieren und zu orchestrieren.
Konfigurieren. Der zweite Schritt besteht darin, die Replikationseinstellungen für die Anwendung zu konfigurieren, so dass Administratoren definieren können, wie Quell-VMs in die AWS-Anwendungsumgebung repliziert werden. Administratoren können den Replikationszeitraum festlegen, den Replikationsstart planen und AMIs löschen. Sie können auch serverspezifische Einstellungen vornehmen, die den Lizenztyp definieren und eine Quell-VM vor der Migration anhalten.
Administratoren können dann die Start-Einstellungen für die migrierte Anwendung festlegen. Sie wählen die Gruppenstartreihenfolge und ein bestimmtes Skript, das zum Startzeitpunkt ausgeführt werden soll, mit dem der Start in AWS weiter angepasst werden kann. Schließlich spezifizieren Administratoren Parameter für das Netzwerk und die Sicherheit und definieren Faktoren wie VPC, Subnetz, Sicherheitsgruppe und öffentliche Zugänglichkeit.
Replizieren. Dies kann typischerweise durch Auswahl der konfigurierten Anwendung und Starten des Replikationsprozesses gestartet werden. Nach dem Start kann die eigentliche Replikation je nach Datenmenge zwischen 30 Minuten und mehreren Tagen dauern. Administratoren können den Fortschritt im Feld „Replication Status Reporting“ verfolgen, und fehlgeschlagene Replikationen werden als Statusmeldungen gekennzeichnet.
Starten Sie. Nach Abschluss der Migration suchen und starten Administratoren die ausgewählte Anwendung. Sie können auch den Status des Starts verfolgen, und fehlgeschlagene Starts werden im Feld Startstatus angezeigt. Nach dem Start der Anwendung können Administratoren die Anwendung mithilfe der regelmäßigen AWS-Überwachung und -Berichterstattung überwachen.
Preise und Verfügbarkeit
Es gibt keine separate Gebühr für die Nutzung von SMS, aber es gibt Kosten zu berücksichtigen. Beispielsweise erstellt SMS bei jeder Replikation einen Elastic Block Store Snapshot. Benutzer bezahlen für die Snapshots und sollten nicht benötigte Snapshots nach der Migration löschen. Es entstehen zusätzliche Kosten für die S3-Speicherung, die für die temporäre Dateiarbeit verwendet wird, was zu kurzfristigen S3-Gebühren führt. Und schließlich müssen die Benutzer für alle EC2-Instanzen und alle zusätzlichen Dienste im Zusammenhang mit der migrierten Anwendung, die in AWS läuft, bezahlen.
SMS ist derzeit auch auf 50 gleichzeitige VM-Migrationen pro Konto sowie 50 gleichzeitige Anwendungsmigrationen pro Konto beschränkt, mit nicht mehr als 10 Gruppen und 50 Servern in jeder Anwendung.
