Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Migration mit dem AWS Application Migration Service
Die meisten großen lift-and-shift Migrationen, die verwendet werden können. AWS AWS Application Migration Service
Diese Replikationsmethode auf Blockebene unterstützt keine NAS (Network Attached Storage), gemeinsam genutzte Laufwerke wie Network File System (NFS) -Shares oder Common Internet File System (CIFS) /Server Message Block (SMB) -Shares. Sie unterstützt nur Speicher auf Blockebene, der zum Zeitpunkt der Migration direkt mit dem migrierten System verbunden ist. (Weitere Informationen finden Sie in den häufig gestellten Fragen zum Application Migration Service zur SAN/NAS-Unterstützung.) Dies schränkt die Anwendbarkeit der Replikation über den Application Migration Service für die meisten Clustersysteme ein, da die meisten Cluster auf gemeinsam genutzten Speicher verschiedener Implementierungen angewiesen sind. Weitere Informationen finden Sie in den Abschnitten Vor- und Nachteile auf dieser Seite.
Bei der Replikationsmethode auf Blockebene müssen Sie einen AWS Replication Agent auf Betriebssystemebene (OS) installieren. Dieser Agent unterstützt nur x86-Plattformen, die auf dem Windows- oder Linux-Betriebssystem basieren (siehe Vom Application Migration Service unterstützte Betriebssysteme). Plattformen, die nicht x86-Plattformen sind, fallen nicht in den Anwendungsbereich dieser Migrationsmethode. Dazu gehören ARM, RISC/CISC Systeme, PowerPC-Varianten, IBM-Systeme wie PSeries, iSeries, zSeries und ihre jeweiligen Betriebssysteme wie AIX, HP-UX, Solaris, Linux für PowerPC, zLinux auf Mainframes und andere Nicht-x86-Architekturen.
Der AWS Replication Agent arbeitet auf der Ebene eines virtuellen Dateisystem-Gerätetreibers* im Betriebssystemstapel und erfasst alle Datenblöcke, die auf die zugrunde liegenden Geräte auf Blockebene geschrieben werden sollen (einschließlich Laufwerke, Festplatten und direkt angeschlossene SAN-Geräte), wie auf der FAQ-Seite des Application Migration Service unter den folgenden Fragen erklärt:
* Die Definitionen von Dateisystem
Vorteile
Für lift-and-shift Migrationen jeder Größenordnung bietet der Application Migration Service viele Vorteile:
-
Die Replikation ist einfach einzurichten (sie erfordert keine steile Lernkurve).
-
Sie lässt sich schnell skalieren, indem Agenten auf den Quellcomputern bereitgestellt werden.
-
Sie können die Cloud Migration Factory
verwenden, um die meisten manuellen Aufgaben zu automatisieren, mehrere Maschinen zu verwalten und Migrationswellen zu orchestrieren. -
Sie unterstützt eine breite Palette von x86-Betriebssystemarchitekturen.
-
Es unterstützt jede Art von Quellumgebung (lokales Rechenzentrum, jede andere Cloud oder eine andere AWS-Region).
-
Es ist anwendungsunabhängig und unterstützt daher jede Anwendung, die auf den Quellservern ausgeführt wird.
-
Es ist weder eine Lizenz noch ein Kauf erforderlich. AWS bietet pay-as-you-go Preisgestaltung, sodass Sie nur für den Service zahlen, solange Sie ihn nutzen, ohne langfristige Verträge oder komplexe Lizenzierung. Der Application Migration Service bietet einen kostenlosen Zeitraum von 90 Tagen pro Server, was für die meisten Migrationen ausreichend ist. Einzelheiten finden Sie auf der Website unter AWS Application Migration Service Preise
. AWS
Nachteile
Wenn Sie Replikationstools auf Blockebene wie den Application Migration Service verwenden, stoßen Sie möglicherweise auf die folgenden Einzelfälle und Faktoren, die es zu berücksichtigen gilt:
-
Der Application Migration Service unterstützt keine bereitgestellten gemeinsam genutzten Dateisysteme oder gemeinsam genutzte Speichergeräte wie NAS- CIFS/SMB und NFS-Dateisysteme. Weitere Informationen zu Replikationsmethoden für NAS oder gemeinsam genutzte Dateisysteme finden Sie unter MGN Replication Agent to Migration NFS Share
(AWS Re:POST-Artikel) und Migrieren gemeinsam genutzter Dateisysteme bei einer AWS großen Migration (AWS Prescriptive Guidance Pattern). -
Der Application Migration Service unterstützt die meisten Cluster-Dateiserver- oder Datenbankcluster-Konfigurationen mit gemeinsam genutztem Speicher nicht, da dieser gemeinsam genutzte Speicher auf Betriebssystemebene über die Gerätetreiberschichten nur eingeschränkt dargestellt wird. Beispielsweise werden Microsoft SQL Server-Cluster mit der Option Storage Space Direct (S2D) nicht unterstützt. Sie können den Application Migration Service jedoch weiterhin verwenden, um andere Typen von Clustersystemen mit gemeinsam genutztem Blockspeicher zu replizieren, z. B. gemeinsam genutzten Speicher in Failover Cluster Instance (FCI) -Konfigurationen in Windows Server Failover Cluster (WSFC), wie im Blogbeitrag Migration Ihrer Microsoft Windows-Cluster auf AWS Using CloudEndure Migration
beschrieben, Speicher, der von externen SAN-Arrays (iSCSI-Verbindungen) bereitgestellt wird, und einige Microsoft SQL Server Always On Availability Group (AAG) -Cluster in bestimmten Eckfällen. Im Allgemeinen unterstützt der Application Migration Service die Replikation eines Geräts auf Blockebene von einem Server aus, bei dem das Speichergerät während der Migration vollständig auf dem Server vorhanden ist. (Der AWS Replication Agent muss auf dem Server installiert sein, und das Gerät muss für den Replikationsagenten sichtbar sein.) All diese Szenarien erfordern jedoch sehr spezifische Verfahren und führen zu längeren Umstellungsfenstern. -
Systeme mit einer hohen Rate an Datenänderungen (wie OLTP-Datenbanken) haben möglicherweise höhere Leistungs- oder Netzwerkanforderungen, was die Migration erschwert.
-
Die Netzwerkbandbreite muss ausreichend sein, damit die Datenmenge innerhalb des geplanten Zeitfensters für Migration und Cutover übertragen werden kann. Dies liegt daran, dass der Application Migration Service im Gegensatz zu anderen AWS Snowball
keine Offline-Versandoption bietet. -
Die Migration erfordert ein kleines Ausfallzeitfenster innerhalb eines RTO-Zeitraums von Minuten. Der Application Migration Service verwendet EBS-Snapshots als Teil des Migrationsprozesses, und neue EBS-Festplatten, die aus solchen Snapshots erstellt werden, weisen zunächst eine schlechtere Leistung auf. Bei einigen Datenbanklesemustern kann dies das effektive Zeitfenster für den Cutover verlängern, bis die migrierte Datenbank die volle Leistung erreicht hat.
Am besten geeignete Szenarien
Der Application Migration Service deckt fast jede lift-and-shift Migration vollständig ab, mit wenigen Nachteilen, wie in den beiden vorherigen Abschnitten beschrieben. Dieses Tool eignet sich für die meisten Sonderfälle, wie z. B. Datenbankcluster, sofern das für diese Systeme erforderliche längere Cutover-Fenster Ihren Migrationsanforderungen entspricht.
In den folgenden Abschnitten werden zwei Szenarien eingehender behandelt:
-
Migration in großem Maßstab mit mehreren Migrationswellen
-
Migration einer einzelnen Anwendung, die nur minimale Ausfallzeit erfordert
Migration in großem Maßstab mit mehreren Migrationswellen
Ein Beispiel für eine groß angelegte Migration ist ein Ausgang eines Rechenzentrums, der durch Größen- und Geschwindigkeitsanforderungen gekennzeichnet ist. Sie beinhaltet in der Regel auch eine bestimmte Zeitbeschränkung, z. B. das Ende des Leasingvertrags für das Rechenzentrum. In diesem Fall diktiert der Maßstab den Ansatz. Die Migrationswellen werden nach Anwendungen, einschließlich Datenbanken, bestimmt und gruppiert. Jede Welle hat eine geplante Vorbereitungs-, Migrations- und endgültige Cutover-Phase mit spezifischen Ausfallzeiten.
Innerhalb jeder Migrationswelle sollten die Datenbankserver am besten skaliert werden, indem die Replikation auf Blockebene von Application Migration Service verwendet wird, mit Ausnahme einiger Ausnahmen für die folgenden Sonderfälle, die möglicherweise einen separaten Migrationsansatz erfordern:
-
Die meisten geclusterten Datenbanksysteme
-
Datenbanksysteme, bei denen die Änderungsrate den verfügbaren Netzwerkdurchsatz übersteigt (was zu einer Verzögerung bei der Replikation führen kann)
Berücksichtigen Sie für jeden speziellen Fall den Kompromiss zwischen Ihren Ausfallzeiten und dem Aufwand, der mit der Verwendung eines anderen Migrationstools verbunden ist. In einigen Fällen ist es viel einfacher, denselben Migrationsansatz für alle Systeme zu verwenden, anstatt separate Tools zu verwenden und unterschiedliche Prozesse für bestimmte Systeme zu erstellen. Wenn der Application Migration Service die Ausfallzeitanforderungen für ein bestimmtes System nicht unterstützt, empfehlen wir, stattdessen eine der im Abschnitt Migration mit systemeigenen Datenbanktools beschriebenen Methoden zu verwenden.
Einzelanwendungsmigration
Das Szenario mit einer einzigen Anwendung stellt einen detaillierten Ansatz für die Migration einer einzelnen geschäftskritischen Anwendung dar, für die während der Migration nur minimale oder nahezu keine Ausfallzeiten erforderlich sind, oder für einige wenige solcher Anwendungen. Im Gegensatz zu den Geschwindigkeits- und Skalierungsanforderungen des vorherigen Szenarios (groß angelegte Migration) kann der Umfang der Migration je nach geschäftlicher Wichtigkeit und Ausfallzeiten variieren. Wenn die Anwendung Ausfallzeiten innerhalb des RTO von Application Migration Service zulässt, sollte diese genauso behandelt werden wie jede zuvor beschriebene groß angelegte Migration.
In Fällen, in denen die Umstellungszeit so kurz wie möglich sein muss, z. B. wenn die migrierte Datenbank Lesemuster aufweist, die viel Zeit benötigen, um mit voller Leistung zu arbeiten, und die Umstellungsfenster klein bleiben müssen, sollten Sie einen detaillierteren und detaillierteren Ansatz in Betracht ziehen. Im Allgemeinen beinhaltet dieser Ansatz zusätzliche Schritte und Anforderungen, die mehr Aufwand und Zeit erfordern. Einer der Schritte besteht darin, die Datenbankmigration von der Anwendungsservermigration zu trennen und die Datenbankmigrationstools zu verwenden, die im nächsten Abschnitt beschrieben werden, um die Quell- und Zieldatenbanken synchron zu halten. Sie können verschiedene Methoden verwenden, um die Synchronisierung zu erreichen. Jede Methode hat Vor- und Nachteile und beinhaltet unterschiedliche Kompromisse zwischen dem Umfang der Ausfallzeit und der Komplexität der Synchronisation. Wenn Sie jedoch die Datenbank zwischen der Quell- und der Zielumgebung synchron halten, können Sie die Verbindung zwischen der Datenbankschicht und der Anwendungsebene trennen. Unter der Annahme, dass Anwendungsserver persistente Daten nicht lokal speichern, sondern alles an die Datenbankschicht weiterleiten, entfernt die Synchronisation auch die Einschränkungen der Ausfallzeiten auf der Anwendungsebene.
Durch die Entkopplung der Datenbank- und Anwendungsebene können Sie Anwendungsserver wie im vorherigen Szenario mithilfe des Application Migration Service migrieren. Zielanwendungsserver können in der Zielumgebung gestartet werden, während die Quellsysteme noch arbeiten, die Daten verarbeiten und in der Datenbankschicht speichern. Da die Datenbankschicht bereits mit dem Ziel synchronisiert ist, ist die Umstellungszeit minimal. Sie müssen lediglich das Netzwerk wechseln und Kundenanfragen vom alten Quellsystem in die Zielumgebung umleiten. Sie können hierfür mehrere Methoden verwenden. Folgen Sie dabei der Anleitung für Blau/Grün-Bereitstellungen, in der Regel durch den Wechsel von DNS-Endpunkten, unter Verwendung gewichteter DNS-Zonen, Verwendung von AWS Global Accelerator
