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.

Bewährte Methoden für die Konfiguration

Dieser Abschnitt enthält eine detaillierte Beschreibung des restriktivsten Szenarios, in dem die gesamte Kommunikation nur über den privaten Kanal erfolgt, sowie eine ausführliche Erläuterung der Anforderungen und der entsprechenden Komponenten, die für jeden Bereich erstellt werden müssen.

In diesem Abschnitt wird die Konfiguration für das restriktivste Szenario (Replikation nur über private Netzwerke) beschrieben, wie im ersten Diagramm dargestellt, und zwar auf der Grundlage der zuvor erörterten Überlegungen. Sie können beide Hybridszenarien konfigurieren, indem Sie Teile der restriktivsten Konfiguration überspringen:

In den folgenden Abschnitten wird davon ausgegangen, dass die anfängliche MGN-Konfiguration bereits abgeschlossen ist (wie in den Blogbeiträgen Accelerate your Migration with AWS Transform MGN und How to Use the New for Migrations) beschrieben. AWS Transform MGN Lift-and-Shift Diese Diskussion konzentriert sich auf Komponenten, die für das restriktive Szenario spezifisch sind, und geht von einem privaten Staging-Subnetz aus, das keine Konnektivität zum Internet hat.

Subnetze und Routingkonfigurationen

Für das restriktive Szenario konfigurieren Sie die erforderlichen AWS Ressourcen im privaten Subnetz einer Staging-VPC. Dieses Subnetz hat keine Verbindung zum Internet (es ist kein Internet-Gateway als Standardroute an die Routingtabelle angeschlossen). Stattdessen verwendet es entweder ein virtuelles Gateway, das einem AWS Site-to-Site VPNGateway zugeordnet ist (das über einen IPSec-Tunnel mit einem lokalen Gateway verbunden ist), oder es ist mit einem Transfer-Gateway oder mit Direct Connect Diensten verbunden, um private Interkonnektivität zu den lokalen Rechenzentren bereitzustellen.

Sie verwenden dieses private Subnetz als Staging-Subnetz für replikationsbezogene Ressourcen, die vom Application Migration Service verwaltet werden, und Sie konfigurieren den gesamten erforderlichen Netzwerkzugriff über dieses Subnetz mithilfe von VPC-Endpunkten, wie im nächsten Abschnitt beschrieben.

Konfiguration der VPC-Endpunkte

Sie müssen jetzt VPC-Endpunkte im Staging-Subnetz erstellen, um Konnektivität für die Replikationsserver und MGN-Agenten aus lokalen Subnetzen bereitzustellen.

Hier ist eine vollständige Liste der VPC-Endpunkte, die Sie benötigen:

In den nächsten Abschnitten wird näher darauf eingegangen, wie VPC-Endpoints funktionieren. In der folgenden Tabelle sind alle Endpunkte aufgeführt, die für das private Staging-Subnetz erstellt wurden. (Beachten Sie, dass für den Amazon S3 S3-Gateway-Endpunkt keine Netzwerkschnittstellen bereitgestellt wurden, sondern dass spezifische Präfixlisten in der Routing-Tabelle des Subnetzes bereitgestellt wurden, wie später in diesem Handbuch beschrieben wird.)

Sie können optionale VPC-Endpoints erstellen, um den Zugriff auf EC2-Instances in privaten isolierten Subnetzen zu ermöglichen AWS Systems Manager, wie unter Erstellen von VPC-Endpunkten in der Systems Manager Manager-Dokumentation beschrieben.

VPC-Schnittstellenendpunkte

Durch das Erstellen eines Schnittstellenendpunkts wird auch eine spezifische elastic network interface für jedes Subnetz erstellt, für das der angegebene Schnittstellenendpunkt bereitgestellt wird. Beispielsweise wird der Application Migration Service-Schnittstellenendpunkt in einem privaten Subnetz in der Staging-VPC mit einer elastic network interface bereitgestellt, die der IP-Adresse innerhalb dieses Subnetzes zugeordnet ist, und er hat auch drei DNS-Namen, die vom Subnetz zu dieser IP-Adresse aufgelöst werden können:

Auf diese Weise kann jede im Subnetz ausgeführte Instanz, die die standardmäßige DHCP-Optionssatzkonfiguration (Dynamic Host Configuration Protocol) in der VPC verwendet und sowohl DNS-Attribute als auch enableDnsSupport aktiviert hat, enableDnsHostnames Folgendes tun:

Dadurch wird die Konnektivität für alle Instances, die im Staging-Subnetz ausgeführt werden (z. B. der MGN-Replikationsserver oder der Konvertierungsserver) AWS-Service , für alle Instanzen behoben, für die Schnittstellenendpunkte im Subnetz bereitgestellt wurden (z. B. Amazon EC2, MGN, Systems Manager usw.). AWS KMS

VPC-Gateway-Endpunkte

Für Dienste wie Amazon S3 kann kein fester DNS-Name bereitgestellt werden, da jeder Bucket seinen eigenen DNS-Namen hat. Für dieses Szenario verwenden Sie VPC-Gateway-Endpunkte. 

Beim Erstellen eines Amazon S3 S3-Gateway-Endpunkts wird auch ein bestimmtes Präfixlistenobjekt mit einer Liste von Subnetzzielen (in CIDR-Notation) erstellt, die der Subnetz-Routentabelle hinzugefügt werden können. Somit wären DNS-Namen von S3-Buckets, die auf die in dieser Liste enthaltenen IP-Adressen aufgelöst wurden, über interne Konnektivität zugänglich. 

Wenn Sie einen Amazon S3 S3-Gateway-Endpunkt bereitstellen, können Sie die Subnetze in den Routing-Tabellen angeben, die diese Präfixlisten-ID (PL-<id>) enthalten sollen. Die resultierende Routing-Tabelle für das private Staging-Subnetz muss diese Präfixlisten-ID enthalten, wie in dieser Beispiel-Routentabelle:

Eingehende Endpunkte mit DNS-Resolver

Die im vorherigen Abschnitt beschriebene Konfiguration ist ausreichend für Instances, die innerhalb der AWS Subnetze ausgeführt werden, da sie bereits für die Verwendung interner Amazon Route 53-DNS-Server konfiguriert sind. Für lokale Quellserver sind jedoch zusätzliche Schritte erforderlich, um mit AWS-Services privaten Servern kommunizieren zu können. Insbesondere muss MGN Agent das Installationsprogramm von Amazon S3 herunterladen und dann über die in der Dokumentation angegebenen DNS-Namen mit MGN kommunizieren. On-premises Server verwenden ihre Standard-DNS-Server, um diese DNS-Namen aufzulösen, was zu öffentlichen IP-Adressen führt. Die Kommunikation mit diesen Adressen über HTTPS/TCP Port 443 wird schließlich durch Unternehmens-Firewalls blockiert.

Um dies zu verhindern, müssen Sie Quellserver oder deren Standard-DNS-Server so konfigurieren, dass sie Amazon Route 53 Resolverfür die Auflösung dieser spezifischen DNS-Namen oder eine Subdomänenzone (d. h. die vollständige *.<region>.amazonaws.com Zone) verwendet werden. Dies kann konfiguriert werden, indem ein eingehender Route 53 Resolver-Endpunkt erstellt wird, der wie ein VPC-Schnittstellenendpunkt über eine dedizierte elastic network interface verfügt, die im dedizierten privaten Subnetz erstellt wurde AWS, und der somit DNS-Anfragen weiterleiten kann. Amazon Route 53 Resolver 

Sicherheitsgruppen für elastische Netzwerkschnittstellen

Jeder Elastic Network-Schnittstelle ist eine eigene Sicherheitsgruppe zugeordnet, die den für diese elastic network interface und den entsprechenden Endpunkt erwarteten Datenverkehr zulassen muss. Daher sollte die Sicherheitsgruppe des DNS-Resolver-Endpunkts eingehenden UDP-Port 53 (und manchmal TCP-Port 53) für DNS-Anfragen zulassen, und für die Endpunktsicherheitsgruppen für die meisten anderen Dienste (MGN, Amazon EC2, Systems Manager usw.) muss der eingehende HTTPS/TCP Port 443 aktiviert sein.

MGN Agent auf den Quellservern installieren

Um MGN Agent auf Quellservern zu installieren, müssen Sie die DNS-Namen der MGN- und Amazon S3 S3-Schnittstellenendpunkte in die Befehlszeilenparameter des Agenten eingeben (siehe Installation des Agenten in einem sicheren Netzwerk in der MGN-Dokumentation). 

Für den MGN-Endpunkt können Sie jeden der damit verknüpften DNS-Namen verwenden — ein privates DNS-Feld (mgn.<region>.amazonaws.com) oder einen VPC-specific DNS-Namen (vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com) — und ein Argument angeben:. --endpoint <FQDN> Wenn Sie dieses Argument überspringen, verwendet der Agent den angegebenen, um den Standard-DNS-FQDN (mgn.<region>.amazonaws.com) AWS-Region zu rekonstruieren, und verwendet den FQDN, um auf die Steuerebene des Application Migration Service zuzugreifen. In den meisten Fällen sollte dieses Standardverhalten ausreichen, sofern dieser FQDN vom Quellserver korrekt in die private IP-Adresse der elastic network interface für den MGN VPC-Endpunkt aufgelöst wird, der im Staging-Subnetz erstellt wurde. 

Der Endpunkt der Amazon S3 S3-Schnittstelle wird keinen einzigen privaten DNS-Namen haben (da jeder S3-Bucket seinen eigenen hat), sodass diese Option nicht unterstützt wird. Einem Amazon S3 S3-Schnittstellenendpunkt ist jedoch immer noch eine elastic network interface zugeordnet. Es hat auch eine bestimmte private IP und DNS-Wildcard-Namen (im Format .vpce-<VPC-ID>-<suffix>.s3.<region>.vpce.amazonaws.com oder Region-specific). vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com), die in diese private IP aufgelöst werden können.

Dieser DNS-Wildcard-Name kann wie folgt für das --s3-endpoint Argument verwendet werden:

aws-replication-installer-init.py --region <region> --aws-access-key-id <MGN_IAM_ACCESS_KEY>  --aws-secret-access-key <MGN_IAM_SECRET> --no-prompt \
   --endpoint vpce-<VPC-id>-<suffix>.mgn.<region>.vpce.amazonaws.com --s3-endpoint vpce-<VPC-ID>-<suffix>-<region>.s3.<region>.vpce.amazonaws.com

Der nächste Abschnitt enthält ein Beispiel für die Konfiguration von MGN, einschließlich aller erforderlichen VPC-Endpunkte, und die Bereitstellung der Agents mithilfe von VPC-Endpunkten auf Windows- und Linux-Quellservern. Der Abschnitt behandelt sowohl die manuelle als auch die automatisierte Bereitstellung.