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.
Schritt 8: Testen Sie die Lösung mithilfe der Automatisierungsskripte
Importieren Sie Migrationsmetadaten in die Fabrik
Um den Migrationsprozess zu starten, laden Sie die server-list.csv
server-list.csv
Datei ist ein Beispiel für ein Eingabeformular für die AWS MGN Servicemigration zum Import der Attribute für die Quellserver im Geltungsbereich.
Anmerkung
Die CSV-Datei und die Beispiel-Automatisierungsskripts waren Teil des Pakets aus demselben GitHub Repository.
Sie können das Formular für Ihre Migration anpassen, indem Sie die Beispieldaten durch Ihre spezifischen Server- und Anwendungsdaten ersetzen. In der folgenden Tabelle sind die Daten aufgeführt, die ersetzt werden müssen, um diese Lösung an Ihre Migrationsanforderungen anzupassen.
Feldname | Erforderlich? | Beschreibung |
---|---|---|
wave_name | Ja | Der Wellenname basiert auf der Priorität und den Abhängigkeiten der Anwendungsserver. Beziehen Sie diese Kennung aus Ihrem Migrationsplan. |
app_name | Ja | Die Namen der Anwendungen, die für die Migration gelten. Vergewissern Sie sich, dass Ihre Anwendungsgruppierung alle Anwendungen umfasst, die sich dieselben Server teilen. |
aws_accountid | Ja | Eine 12-stellige Kennung für Sie, die AWS-Konto sich in Ihrem Kontoprofil befindet. Um darauf zuzugreifen, wählen Sie Ihr Kontoprofil in der oberen rechten Ecke von AWS Management Console und wählen Sie im Drop-down-Menü Mein Konto aus. |
aws_region | Ja | AWS-Region Code. Beispiel, us-east-1 . Weitere Informationen finden Sie in der vollständigen Liste der Regionalcodes. |
Servername | Ja | Der Name der lokalen Server, für die eine Migration vorgesehen ist. |
server_os_family | Ja | Das Betriebssystem (OS), das auf den Quellservern im Geltungsbereich ausgeführt wird. Verwenden Sie entweder Windows oder Linux, da diese Lösung nur diese Betriebssysteme unterstützt. |
server_os_version | Ja |
Die Version des Betriebssystems, das auf den Quellservern im Geltungsbereich ausgeführt wird. AnmerkungVerwenden Sie die Betriebssystemversion, nicht die Kernel-Version, verwenden Sie beispielsweise RHEL 7.1, Windows Server 2012 R2 oder CentOS 7.5, 7.6. Verwenden Sie nicht Linux 3.xx, 4.xx oder Windows 8.1.x. |
server_fqdn | Ja | Der vollqualifizierte Domänenname des Quellservers, bei dem es sich um den Servernamen, gefolgt vom Domänennamen, handelt. Zum Beispiel server123.company.com. |
server_tier | Ja | Eine Bezeichnung zur Identifizierung, ob es sich bei dem Quellserver um einen Web -, App - oder Datenbankserver handelt. Wir empfehlen, den Quellserver als App zu kennzeichnen, wenn der Server als mehr als eine Ebene fungiert, z. B. wenn auf dem Server Web-, App- und Datenbankebenen zusammen ausgeführt werden. |
server_environment | Ja | Ein Label zur Identifizierung der Serverumgebung. Zum Beispiel dev, test, prod, QA oder pre-prod. |
r_type | Ja | Ein Label zur Identifizierung der Migrationsstrategie. Zum Beispiel „Ausscheiden“, „Beibehalten“, „Umziehen“, „Umstellen“, „Umstellen“, „Umbauen“, „Umgestalten“,. TBC |
subnet_ IDs | Ja | Die Subnetz-ID für die EC2 Amazon-Zielinstanz für die Migration nach der Umstellung. |
Sicherheitsgruppe_ IDs | Ja | Die Sicherheitsgruppen-ID für die EC2 Amazon-Zielinstanz für die Migration nach der Umstellung. |
subnet_ _test IDs | Ja | Die Zielsubnetz-ID für den Quellserver, der getestet werden soll. |
securitygroup_ _test IDs | Ja | Die Zielsicherheitsgruppen-ID für den Quellserver, der getestet werden soll. |
instanceType | Ja | Der EC2 Amazon-Instance-Typ, der im Ermittlungs- und Planungsaufwand identifiziert wurde. Informationen zu EC2 Instance-Typen finden Sie unter EC2Amazon-Instance-Typen |
tenancy | Ja | Der Tenancetyp, der bei der Ermittlung und Planung ermittelt wird. Verwenden Sie einen der folgenden Werte, um den Mandanten zu identifizieren: Shared, Dedicated oder Dedicated Host. Sie können Shared als Standardwert verwenden, es sei denn, für die Lizenz einer Anwendung ist ein bestimmter Typ erforderlich. |
Tags | Nein | Die Tags für die Serverressourcen, z. B. CostCenter =123; BU=IT; Location=US |
private_ip | Nein | Die private IP für die Zielinstanz. Falls nicht enthalten, erhält die Instanz eine IP vonDHCP. |
iamRole | Nein | IAMRolle für die Zielinstanz. Wenn nicht enthalten, wird der Zielinstanz keine IAM Rolle zugewiesen. |
-
Melden Sie sich bei der Cloud Migration Factory-Webkonsole an.
-
Wählen Sie unter Migration Management die Option Import und dann Datei auswählen aus. Wählen Sie das zuvor ausgefüllte Aufnahmeformular aus und klicken Sie auf Weiter.
-
Überprüfen Sie die Änderungen und stellen Sie sicher, dass Sie keine Fehler sehen (eine Informationsmeldung ist normal), und wählen Sie Weiter.
-
Wählen Sie Hochladen, um Server hochzuladen.
Greifen Sie auf die Domains zu
Die in dieser Lösung enthaltenen Beispiel-Automatisierungsskripts stellen eine Verbindung zu den Quellservern her, um Migrationsaufgaben wie die Installation des Replikationsagenten und das Herunterfahren der Quellserver zu automatisieren. Um einen Testlauf der Lösung durchzuführen, ist bei Windows- und Linux-Servern (Sudo-Berechtigungen) ein Domänenbenutzer mit lokalen Administratorberechtigungen für die Quellserver erforderlich. Wenn Linux nicht in der Domäne ist, können andere Benutzer verwendet werden, z. B. ein LDAP Benutzer mit Sudo-Berechtigungen oder ein lokaler Sudo-Benutzer. Weitere Informationen zu automatisierten Migrationsaufgaben finden Sie unter Automatisierte Migrationsaktivitäten mit der Migration Factory-Webkonsole und Automatisierte Migrationsaktivitäten mit der Befehlszeile.
Führen Sie einen Testlauf der Migrationsautomatisierung durch
Mit dieser Lösung können Sie einen Testlauf der Migrationsautomatisierung durchführen. Mithilfe von Automatisierungsskripten importiert der Migrationsprozess die Daten aus der CSV Migrationsdatei in die Lösung. Für die Quellserver werden Prüfungen der Voraussetzungen durchgeführt, der Replikationsagent wird auf die Quellserver übertragen, der Replikationsstatus wird überprüft und der Zielserver wird über die Migration Factory-Weboberfläche gestartet. step-by-step Anweisungen zur Durchführung eines Tests finden Sie unter Automatisierte Migrationsaktivitäten mit der Migration Factory-Webkonsole und Automatisierte Migrationsaktivitäten mit der Befehlszeile.