Warum bleibt mein Application-Migration-Service- oder Elastic-Disaster/Recovery-Replikationsprozess bei 100 % hängen und die Meldung „Finalizing Initial Sync“ wird angezeigt?

Kurzbeschreibung

Wenn der Replikationsprozess während der Synchronisierungen für Application Migration Service oder Elastic Disaster Recovery bei 100 % hängen bleibt, werden die folgenden Fehler angezeigt:

• „Finalizing Initial Sync - Flushing Backlog“
• „Finalizing Initial Sync - Creating First Launchable Snapshot“

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Fehler „Finalizing Initial Sync - Flushing Backlog“ beheben

Warte, bis das Backlog vollständig gelöscht ist, damit die Synchronisierung initialisiert werden kann.

Wenn der Quellcomputer schreibintensiv ist, kann das Backlog an Größe zunehmen. Wenn der Computer im Status „Finalizing Initial Sync“ feststeckt, teste die Replikationsgeschwindigkeit für Application Migration Service oder Elastic Disaster Recovery (Notfallwiederherstellung). Berechne außerdem die erforderliche Bandbreite für alle replizierenden Quellcomputer. Stelle sicher, dass der Netzwerkdurchsatz der Replikations-Instance ausreichend ist.

Gehe wie folgt vor, um deine Replikationseinstellungen zu überprüfen:

1. Öffne die Application-Migration-Service- oder die Elastic-Disaster-Recovery-Konsole.
2. Wähle im Navigationsbereich Quellserver aus.
3. Wähle Replikationseinstellungen bearbeiten aus.
4. Prüfe, ob die Drosselung der Netzwerkbandbreite auf Bandbreite drosseln eingestellt ist. Wenn eine Drosselung der Bandbreite nicht erforderlich ist, wähle Bandbreite nicht drosseln aus. Wenn eine Drosselung der Bandbreite erforderlich ist, stelle sicher, dass du den Wert auf die minimal erforderliche Bandbreite festlegst. Weitere Informationen findest du unter Datenrouting und -drosselung für Application Migration Service oder Netzwerk-Bandbreite drosseln für Elastic Disaster Recovery.

Verwende Amazon-CloudWatch-Metriken, um die Netzwerk- und Festplattenauslastung des Replikationsservers zu überprüfen. Wenn eine Ressource den Server drosselt, verwende einen dedizierten Replikationsserver oder einen größeren Replikationsservertyp. Oder wähle SSD-basierten Speicher aus. Weitere Informationen findest du unter Bewährte Methoden für AWS Application Migration Service oder unter Ändern des Staging-Datenträgertyps.

Um den Replikationsserver zu überprüfen, den ein bestimmter Quellcomputer verwendet, führe je nach Betriebssystem den folgenden Befehl auf dem Quellcomputer aus.

Linux:

netstat -anp | grep ":1500"

Windows:

netstat -ano | findstr ":1500"

Notiere dir die Remote-IP-Adresse, mit der das Gerät über Port 1500 eine Verbindung herstellt.

Oder führe je nach Betriebssystem den folgenden Befehl aus, um die Datei agent.log.0 auf dem Quellcomputer zu überprüfen und den genauen verwendeten Replikationsserver zu ermitteln.

Linux:

sudo cat /var/lib/aws-replication-agent/agent.log.0 | grep :1500 | tail -n 1

Windows:

findstr /L ":1500" "C:\Program Files (x86)\AWS Replication Agent\agent.log.0"

Den Fehler „Finalizing Initial Sync - Creating First Launchable Snapshot“ beheben

Die IAM-Richtlinienberechtigungen von Benutzern überprüfen

Stelle sicher, dass die AWS-Richtlinie für Identity and Access Management (IAM) des Benutzers über Berechtigungen zum Ausführen der Amazon Elastic Compute Cloud (Amazon EC2)-APIs verfügt.

Überprüfe die Anmeldeinformationen von Benutzern für Application Migration Service oder Elastic Disaster Recovery. Oder überprüfe den AWS-CloudTrail-Ereignisverlauf, um API-Fehler zu finden, die beim/bei der Benutzer:in aufgetreten sind.

Deine Amazon-EC2-Endpunkte überprüfen

Stelle sicher, dass der Replikationsserver mit den Amazon-EC2-Endpunkten für Application Migration Service oder Elastic Disaster Recovery in deiner AWS-Region kommunizieren kann.

Gehe wie folgt vor, um die Konnektivität zu deinen Service-Endpunkten zu testen:

1. Starte eine neue Linux-Instance im selben Subnetz wie dein Staging-Bereich.
2. Melde dich bei der neuen Instance an und führe dann die folgenden Befehle aus:

   dig ec2.us-east-1.amazonaws.com  
   telnet ec2.us-east-1.amazonaws.com 443  
   wget https://ec2.us-east-1.amazonaws.com

   Hinweis: Ersetze us-east-1 durch deine Region. Wenn einer der vorherigen Befehle fehlschlägt, fahre mit dem folgenden Abschnitt fort, um Probleme mit der Netzwerkkonnektivität zu beheben. Vergewissere dich, dass die Einstellungen der Virtual Private Cloud (VPC), des Subnetzes, der Sicherheitsgruppe, der Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) und der Routing-Tabelle mit deinen Replikationseinstellungen übereinstimmen. Eine Fehlkonfiguration kann die Kommunikation von den Replikationsservern zu Amazon-EC2-Endpunkten blockieren.

Identifiziere Netzwerkverbindungsblocker für einen Replikationsserver, den du in einem öffentlichen Subnetz gestartet hast

Stelle sicher, dass die Sicherheitsgruppe, die Netzwerk-ACLs und die Routing-Tabelle die Kommunikation mit Amazon-EC2-Endpunkten auf TCP-Port 443 ermöglichen.

Stelle sicher, dass die Attribute enableDnsHostnames und enableDnsSupport auf VPC-Ebene auf true gesetzt sind. Führe den folgenden AWS-CLI-Befehl describe-vpc-attribute aus, um das Attribut enableDnsHostnames zu überprüfen:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames   

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID.

Beispielausgabe:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames  
{   
 "VpcId": "vpc-a01106c2",  
 "EnableDnsHostnames": {   
 "Value": true  
 }   
}

Führe den folgenden Befehl describe-vpc-attribute aus, um das enableDnsSupport-Attribut zu überprüfen:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID.

Beispielausgabe:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport     
{  
 "VpcId": "vpc-a01106c2",   
 "EnableDnsSupport": {  
 "Value": true   
 }  
}

Wenn die Attribute nicht auf „true“ gesetzt sind, führe den folgenden modify-vpc-attribute-Befehl aus, um sie zu aktivieren:

aws ec2 modify-vpc-attribute --vpc-id vpc-abdcef --enable-dns-hostnames "{\"Value\":true}"

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID und enable-dns-hostnames durch das Attribut, das nicht auf true gesetzt ist.

Identifiziere Netzwerkverbindungsblocker für einen Replikationsserver, den du in einem privaten Subnetz gestartet hast

Stelle sicher, dass die Sicherheitsgruppe, die Netzwerk-ACLs und die Routing-Tabelle die Kommunikation mit privaten Amazon-EC2-Endpunkten auf TCP-Port 443 ermöglichen. Wenn du in der Routing-Tabelle ein NAT-Gateway oder eine NAT-Instance konfiguriert hast, stelle sicher, dass der ausgehende Datenverkehr zum Amazon-EC2-Endpunkt auf TCP-Port 443 funktioniert.

Prüfe, ob ausgehender Datenverkehr über ein Transit-Gateway oder ein virtuelles privates Gateway geleitet wird. Stelle in diesem Fall sicher, dass die Routing-Tabelle Datenverkehr zu Amazon-EC2-Endpunkten auf TCP-Port 443 zulässt. Prüfe außerdem, ob die Firewall die Kommunikation blockiert.

Wenn die VPC über VPC-Schnittstellen-Endpunkte verfügt, stelle sicher, dass die Kommunikation zwischen Amazon-EC2-Endpunkten am TCP-Port 443 über ein privates Netzwerk erfolgt. Stelle sicher, dass du enableDnsHostnames und enableDnsSupport auf VPC-Ebene auf true und PrivateDnsEnabled auf den VPC-Schnittstellenendpunkten auf true setzt.

Führe den folgenden Befehl describe-vpc-attribute aus, um das Attribut enableDnsHostnames zu überprüfen:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsHostnames --query 'EnableDnsHostnames'

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID.

Beispielausgabe:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsHostnames --query 'EnableDnsHostnames'  

{   
 "Value": true  
}

Führe den folgenden Befehl describe-vpc-attribute aus, um das enableDnsSupport-Attribut zu überprüfen:

aws ec2 describe-vpc-attribute --vpc-id vpc-abcdef --attribute enableDnsSupport --query 'EnableDnsSupport'

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID.

Beispielausgabe:

$ aws ec2 describe-vpc-attribute --vpc-id vpc-a01106c2 --attribute enableDnsSupport --query 'EnableDnsSupport'  

{   
 "Value": true  
}

Führe den folgenden Befehl describe-vpc-attribute aus, um das PrivateDnsEnabled-Attribut zu überprüfen:

aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-12345abcde --query 'VpcEndpoints[0].PrivateDnsEnabled'  

Hinweis: Ersetze vpce-12345abcde durch deinen VPC-Endpunkt.

Beispielausgabe:

true

Wenn die Attribute nicht auf „true“ gesetzt sind, führe den folgenden modify-vpc-attribute-Befehl aus, um sie zu ändern:

aws ec2 modify-vpc-attribute --vpc-id vpc-abdcef --enable-dns-hostnames "{\"Value\":true}"

Hinweis: Ersetze vpc-abcdef durch deine VPC-ID und enable-dns-hostnames durch das Attribut, das nicht auf true gesetzt ist.

Suche nach aktuellen Änderungen in den Replikationseinstellungen

Suche nach aktuellen Änderungen in den Replikationseinstellungen für Application Migration Service oder Elastic Disaster Recovery. Suche in deinem CloudTrail-Ereignisverlauf nach dem API-Aufruf UpdateReplicationConfiguration, um Änderungen zu identifizieren. Verwende den Quellserver, um den Ressourcennamen zu filtern. Überprüfe beispielsweise, ob im Feld Replikationsressourcen-Tags ein ungültiges Tag eingefügt ist. Eine Liste der zulässigen Zeichen findest du unter Tag-Einschränkungen.

Stelle sicher, dass du die richtigen Proxyeinstellungen verwendest

Wenn deine Replikationsserver einen Proxyserver verwenden, vergewissere dich, dass die Proxyeinstellungen die Kommunikation mit regionalen Amazon-EC2-Endpunkten auf TCP-Port 443 ermöglichen.

Stelle sicher, dass die Zulassungsliste für SSL-Abfangen und Authentifizierung mgn.region.amazonaws.com für Application Service Migration und drs.region.amazonaws.com für Elastic Disaster Recovery enthält.

Hinweis: Ersetze region durch deine Region.

Weitere Informationen findest du unter Kann ein Proxyserver zwischen dem Quellserver und der AWS-Application-Migration-Service-Konsole verwendet werden? Weitere Informationen findest du auch unter Kann ein Proxyserver zwischen dem Quellserver und der Elastic-Disaster-Recovery-Konsole verwendet werden?

Überprüfe den AWS Replication Agent

Vergewissere dich, dass der AWS Replication Agent auf dem Quellcomputer ordnungsgemäß funktioniert. Um Probleme zu lokalisieren, überprüfe die AWS-Replication-Agent-Protokolle auf Fehler. Du findest die AWS-Replication-Agent-Protokolle an den folgenden Speicherorten:

• Die Linux-Replication-Agent-Protokolle findest du unter /var/lib/aws-replication-agent/agent.log.0
• Überprüfe für Windows-Replication-Agent-Protokolle C:\Programme (x86)\ AWS Replication Agent\agent.log.0

Suche nach Problemen mit dem Amazon-EC2-Servicekontingent

Wenn du ein Servicekontingent für Application Migration Service oder Elastic Disaster Recovery überschreitest, können die Services keinen startbaren Wiederherstellungs-Snapshot erstellen. Möglicherweise treten auch Probleme mit der API-Drosselung oder der Überschreitung der Rate auf. Überprüfe den CloudTrail-Ereignisverlauf, um Probleme mit dem Servicekontingent oder der Drosselung der Bandbreite zu ermitteln. Fordere bei Bedarf eine Kontingenterhöhung an.