Wie kann ich eine Replikationsverzögerung oder einen Backlog auf meinem Linux-Quellserver für den Application Migration Service beheben?
Ich sehe Verzögerungen oder Backlog auf meinem Linux-Quellserver, wenn ich Daten mit dem AWS Application Migration Service repliziere.
Kurze Beschreibung
Die folgenden Faktoren tragen zu Replikationsverzögerungen und Backlog bei der Replikation von Daten von einem Quellserver auf einen Zielserver bei:
- Netzwerk-Uplink-Geschwindigkeit und Bandbreitenverfügbarkeit: Die Geschwindigkeit der Netzwerkverbindung zwischen dem Quellserver und dem Replikationsserver kann erhebliche Auswirkungen auf die Replikationsleistung haben. Langsame Verbindungen können den Abschluss des Replikationsvorgangs verhindern. Außerdem begrenzt eine begrenzte Bandbreite die Datenmenge, die Sie in einer bestimmten Zeit replizieren können.
- Änderungen an der Festplatte während der Replikation: Während des Replikationsvorgangs schreibt der Quellserver möglicherweise weiterhin neue Daten auf seine Festplatten. Wenn die Menge neuer Daten, die der Quellserver schreibt, stark ansteigt, sammeln sich Daten an und es entsteht ein erheblicher Backlog. Der AWS Replication Agent muss diesen Backlog bei der ersten Synchronisierung senden. Je größer der Backlog, desto länger dauert es, bis die Datenreplikation abgeschlossen ist.
- I/O-Geschwindigkeit der Datenträger: Während des Replikationsvorgangs liest der AWS Replication Agent Speicherblöcke von Festplatten und überträgt Daten an den Replikationsserver. Eine hohe Leselatenz auf den Quellserverfestplatten kann jedoch die Geschwindigkeit und Effizienz der Datenreplikation beeinträchtigen. Langsame Festplatten verursachen Verzögerungen, und schnelle Festplatten verbessern die Replikationsgeschwindigkeit.
- Auf dem Quellserver laden: Ressourcenkonflikte auf dem Quellserver können zu hoher CPU-Auslastung, Speicherverbrauch, I/O-Wartezeiten oder anderen Ressourceneinschränkungen führen. Beispielsweise kann eine hohe CPU-Auslastung zu Replikationsengpässen führen. Dies liegt daran, dass das System Schwierigkeiten hat, CPU-Ressourcen zwischen dem AWS Replication Agent und anderen Prozessen zuzuweisen. Ebenso kann ein hoher Speicherverbrauch dazu führen, dass das System Speicherseiten auf die Festplatte ausladet. Dies führt zu einer längeren I/O-Wartezeit und einer Verlangsamung des Replikationsprozesses.
- Zu wenig bereitgestellte Replikationsressourcen: Das Staging von Amazon Elastic Block Store (Amazon EBS)-Volumes mit geringerem Durchsatz und niedrigerem IOPS kann zu einer hohen Lese- und Schreiblatenz und einer hohen Warteschlangenlänge führen. All diese Probleme wirken sich auf die Replikationsleistung aus. Außerdem führt ein Replikationsserver-Instance-Typ mit geringem Netzwerkdurchsatz und Amazon EBS-Bandbreite zu Problemen mit der Replikationsleistung.
Auflösung
Um den Grund für die Verzögerung zu ermitteln, führen Sie zunächst Überprüfungen auf dem Quellserver durch. Führen Sie dann Kontrollen im Bereitstellungsbereich durch.
Quellserver-Prüfungen
Stellen Sie sicher, dass der Quellserver gebootet ist und läuft
Stellen Sie sicher, dass der Quellserver für die Migration gebootet ist und läuft.
Stellen Sie sicher, dass der Quellserver eine SSL-Verbindung mit dem regionalen Application Migration Service-API-Endpunkt und dem Replikationsserver herstellen kann.
Stellen Sie sicher, dass SSL-Zertifikate zu keinem Zeitpunkt zwischen dem Quellserver und dem API-Endpunkt des Application Migration Service abgefangen und geändert werden. Stellen Sie außerdem sicher, dass die SSL-Zertifikate nicht abgefangen und zwischen dem Quellserver und dem Replikationsserver geändert werden. Führen Sie dazu den folgenden Befehl aus:
# echo -n | openssl s_client -connect mgn.<region>.amazonaws.com:443 # echo -n | openssl s_client -connect <replication server IP>:1500
**Hinweis:**Verwenden Sie den im folgenden Abschnitt Überprüfen Sie aktive TCP-Verbindungen aufgeführten Befehl, um die IP-Adresse des Replikationsservers zu ermitteln.
Stellen Sie sicher, dass alle AWS Replication Agent-Prozesse ausgeführt werden
Führen Sie den folgenden Befehl aus, um die laufenden AWS Replication Agent-Dienste aufzulisten:
# ps -u aws-replication
Die folgende Ausgabe zeigt die AWS Replication Agent-Prozesse, die ausgeführt werden müssen:
PID TTY TIME CMD 30878 ? 00:00:00 update_onprem_v 30879 ? 00:00:00 run_linux_migra 30880 ? 00:00:00 tailer 30881 ? 00:04:45 java 30902 ? 00:00:01 tailer 30904 ? 00:00:00 run_linux_migra 30905 ? 00:00:10 update_onprem_v 31023 ? 00:00:00 tail
Überprüfen Sie aktive TCP-Verbindungen
Führen Sie den folgenden Befehl aus, um zu überprüfen, ob fünf aktive TCP-Verbindungen mit dem Replikationsserver auf TCP-Port 1500 hergestellt wurden.
# sudo netstat -anp | awk '$5 ~ /:1500$/ {print}'
Überprüfen Sie die Befehlsausgabe für die aktiven Verbindungen:
tcp6 0 0 172.31.1.39:54814 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54828 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54832 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54812 172.31.0.82:1500 ESTABLISHED 30881/java tcp6 0 0 172.31.1.39:54800 172.31.0.82:1500 ESTABLISHED 30881/java
Überprüfen Sie die CPU-Auslastung auf dem CPU-Kern, auf dem der AWS Replication Agent ausgeführt wird
Der AWS Replication Agent ist ein Singlethread-Prozess, der auf jeweils einem CPU-Kern ausgeführt wird. Wenn die CPU-Auslastung auf dem Kern, auf dem der AWS Replication Agent ausgeführt wird, hoch ist, verlangsamt sich die Datenreplikation.
1.Führen Sie die folgenden Befehle aus und überprüfen Sie dann die Ausgabe, um Folgendes zu ermitteln:
- Die Prozess-ID des AWS Replication Agents.
- Der CPU-Kern (angezeigt durch psr), auf dem es läuft.
# ps --pid $(pidof /var/lib/aws-replication-agent/jre/bin/java) -o psr,pid,comm # mpstat -P <psr column value> 3
2.Überprüfen Sie dann die CPU-Auslastung des identifizierten CPU-Kerns.
Überprüfen Sie die Festplattenleistung auf dem Quellserver
Bei einem niedrigen Lesedurchsatz (RMB/s) auf den Quellfestplatten werden weniger Daten gelesen und repliziert. Notieren Sie sich jede Erhöhung der Kennzahlen I/O-Tiefe (avgqu-sz) und I/O wait (await). Sie können die Tools sar oder iostat verwenden, um den Festplattenlesedurchsatz zu messen:
# iostat -myx 3 # sar -dp 2
Überprüfen Sie den Quellserver auf einen Anstieg der Schreiboperationen
Ein Anstieg der Schreibvorgänge auf dem Quellserver kann zu einer Zunahme der Replikationsverzögerung führen. Dieses Wachstum setzt sich fort, bis der AWS Replication Agent alle geschriebenen Daten auf den Replikationsserver speichert. Führen Sie denIOSTAT-Test regelmäßig durch, um zu ermitteln, wie hoch die I/O-Last ist, wenn sich die Workload ändert. Wenn der Schreibdurchsatz (WMB/s) den verfügbaren Netzwerkdurchsatz übersteigt, kommt es zu einer Replikationsverzögerung.
**Hinweis:**Informationen zur Berechnung der erforderlichen Bandbreite vom Quellserver zum Replikationsserver finden Sie unter Berechnung der erforderlichen Bandbreite für den TCP-Port 1500.
Überprüfen Sie die Replikationsgeschwindigkeit und die verfügbare Bandbreite vom Quellserver zum Staging Area-Subnetz
1.Starten Sie in Ihrer AWS-Zielregion eine Test-Instance von Amazon Elastic Compute Cloud (Amazon EC2) mithilfe des Veröffentlichungs-AMI CE-SSL-Speedtest. Die EC2-Instance muss den gleichen Instance-Typ wie der Replikationsserver haben.
2.Wählen Sie dasselbe Subnetz aus wie das Subnetz, das in den Replikationseinstellungen Ihres Quellservers verwendet wurde.
3.Stellen Sie sicher, dass die Sicherheitsgruppe den eingehenden TCP-Port 1500-Zugriff zulässt.
4.Konfigurieren Sie auf dem Quellserver die SpeedTest-CLI wie im folgenden Beispiel gezeigt:
# cd /tmp # git clone https://github.com/librespeed/speedtest-cli.git # cd speedtest-cli/ # ls -l # ./build.sh # cat << EOF >> ./servers.json [ { "id": 1, "name": "PHP Backend", "server": "https://<test server private IP>:1500/speedtest/", "dlURL": "/garbage.php", "ulURL": "/empty.php", "pingURL": "/empty.php" } ] EOF
**Hinweis:**Stellen Sie im vorherigen Beispiel sicher, dass Sie die IP-Adresse des Testservers ersetzen. Wenn Sie die öffentliche IP des Testservers für einen Geschwindigkeitstest verwenden, fügen Sie „getipURL“: „/getIP.php“ hinter der Zeile „PingURL“ ein.
5.Führen Sie die LibreSpeed CLI wie im folgenden Beispiel gezeigt aus, um die Replikationsgeschwindigkeit zu testen:
# ./out/librespeed-cli-linux-amd64 —local-json ./servers.json —server 1 —no-icmp —skip-cert-verify —simple Ping: 11.00 ms Jitter: 0.00 ms Download rate: 503.84 Mbps Upload rate: 493.56 Mbps
Suchen Sie nach einem Quellserver, der versehentlich heruntergefahren wurde
Wenn ein Quellserver versehentlich heruntergefahren wird, scannt der AWS Replication Agent nach dem Serverneustart alle Festplatten erneut. Der AWS Replication Agent liest die Festplatten erneut, und die Verzögerung nimmt kontinuierlich zu, bis das erneute Scannen abgeschlossen ist. Weitere Informationen finden Sie unter Welche Windows- und Linux-Betriebssysteme unterstützen No-Rescan beim Neustart?
Suchen Sie nach einem Kernel-Upgrade
Wenn der Kernel auf dem Quellserver aktualisiert und der Server neu gestartet wird, kann der AWS Replication Agent nicht ausgeführt werden. Die laufende Kernelversion entspricht der Kernelversion, für die der AWS Replication Agent-Treiber während der Agenteninstallation kompiliert wurde.
Führen Sie die folgenden Befehle aus, um zu überprüfen, ob die laufende Kernelversion mit der Kernelversion übereinstimmt, für die der AWS Replication Agent-Treiber kompiliert wurde:
$ uname -r $ modinfo -F vermagic /var/lib/aws-replication-agent/aws-replication-driver.ko
Hinweis: Vermagic wird verwendet, um zu überprüfen, in welcher Kernelversion der Kerneltreiber kompiliert ist.
Stellen Sie sicher, dass der TCP-Port 1500 nicht ausgehend blockiert ist
Stellen Sie sicher, dass der TCP-Port 1500 die ausgehenden Verbindungen vom Quellserver zum Replikationsserver nicht blockiert.
Überprüfen Sie die MGN Agent-Protokolle
Überprüfen Sie die MGN-Agent-Protokolle auf Verbindungsprobleme mit dem Replikationsserver auf TCP-Port 1500. Achten Sie auch auf Unregelmäßigkeiten bei der Replikation, die auf einen häufigen Verbindungsverlust hindeuten. Nachdem Sie diese Probleme identifiziert haben, überprüfen Sie die Netzwerktopologie, um weitere Untersuchungen durchzuführen.
Stellen Sie sicher, dass Zwischengeräte keine niedrigere MTU haben
Stellen Sie sicher, dass keines der Zwischengeräte im Replikationspfad eine niedrigere MTU hat. Eine niedrigere MTU reduziert die Replikationsgeschwindigkeit und führt zu Verzögerungen im Prozess. Es hat sich bewährt, im gesamten Replikationspfad eine konsistente MTU-Größe beizubehalten. Wenn ein Gerät im Pfad eine niedrigere MTU hat, aktualisieren oder ersetzen Sie es durch ein höheres MTU-Gerät.
**Hinweis:**Wenn Sie über das öffentliche Internet replizieren, stellen Sie sicher, dass die MTU 1500 ist. 1500 ist die größte, die Internet-Gateways, Peering und VPN unterstützen. Jumbo-Rahmen funktionieren nur in Amazon Virtual Private Cloud (Amazon VPC) oder AWS Direct Connect und haben ihre eigenen Einschränkungen. Weitere Informationen finden Sie im Folgenden:
Stellen Sie sicher, dass die Netzwerkbandbreitenbeschränkung in den Replikationseinstellungen auf dem Quellserver deaktiviert ist.
Die Bandbreitenbeschränkung muss in den Replikationseinstellungen des Quellservers deaktiviert sein.
Wenn die Bandbreitendrosselung im Quellserver aktiviert wird, wird die Datenübertragungsrate des AWS Replication Agents gedrosselt. Dies kann zu einem konstanten oder stagnierenden Verzögerungswachstum führen, wenn auf dem Quellserver ein Backlog besteht. Um eine konstante und begrenzte Bandbreite für die Datenübertragung aufrechtzuerhalten, aktivieren Sie die Netzwerkbandbreitendrosselung.
Gehen Sie wie folgt vor, um zu überprüfen, ob die Bandbreite gedrosselt ist:
1. Öffnen Sie die Application Migration Service-Konsole.
2. Wählen Sie die Quellserver und dann den Quellserver aus.
3. Wählen Sie den Tab Replikationseinstellungen aus.
3. Wenn die Option Netzwerkbandbreite drosseln aktiviert ist, stellen Sie sicher, dass der gedrosselte Wert der für die Datenreplikation erforderlichen Bandbreite entspricht oder größer ist. Weitere Informationen finden Sie im Hinweis im vorherigen Abschnitt, Überprüfen Sie den Quellserver auf einen Anstieg der Schreiboperationen.
Ressourcenprüfungen im Staging-Bereich
Stellen Sie sicher, dass der TCP-Port 1500 nicht eingehend blockiert ist
Stellen Sie sicher, dass der TCP-Port 1500 in den Sicherheitsgruppen des Replikationsservers keine eingehenden Nachrichten blockiert.
**Hinweis:**Sie müssen die folgenden Schritte in der Amazon Elastic Compute Cloud (Amazon EC2)-Konsole ausführen.
1. Öffnen Sie die Amazon EC2-Konsole.
2. Wählen Sie die Sicherheitsgruppe aus, die an die Replikator Instance angehängt ist.
3. Stellen Sie sicher, dass der eingehende TCP-Port 1500 für die angehängte Sicherheitsgruppe zulässig ist.
Überprüfen Sie die NetworkIn CloudWatch-Metrik
Wenn sich die NetworkIn Amazon CloudWatch-Metrik für den Replikationsserver dem Bandbreitenlimit nähert, kann es zu einer Drosselung kommen. Die Drosselung führt zu einer langsameren Replikationsgeschwindigkeit und einer erhöhten Verzögerung. Erwägen Sie ein Upgrade auf einen größeren Instance-Typ, der die erforderliche Bandbreite bewältigen kann.
Überprüfen Sie den aggregierten Durchsatz und die IOPS der EBS-Volumes des Replikationsservers
Die Leistung des Replikationsservers kann gedrosselt werden, wenn der aggregierte Durchsatz und die IOPS der Amazon Elastic Block Store (Amazon EBS)-Volumes die Grenzwerte überschreiten. Wenn eine Drosselung auftritt, wechseln Sie zu einem Replikationsserver-Instance-Typ, der Ihren Replikationsanforderungen entspricht, und halten Sie die Leistung ohne Drosselung aufrecht. Es hat sich bewährt, einen EBS-optimierten Instance-Typ der aktuellen Generation für Replikationsserver zu verwenden. Bei Instances ohne Unterstützung für EBS-optimierten Durchsatz kämpft der Netzwerkverkehr mit dem Datenverkehr zwischen Ihrer Instance und Ihren EBS-Volumes. Auf EBS-optimierten Instances werden die beiden Datenverkehrstypen getrennt gehalten. Überwachen Sie das Netzwerk des Replikationsservers und die EBS CloudWatch-Metriken. Weitere Informationen finden Sie im Folgenden:
Überwachen Sie die Metriken für alle EBS-Replikationsvolumes
Verzögerungen und Backlog häufen sich an, wenn die Volume-Schreibgeschwindigkeit des Replikationsservers nicht mit der Änderungsrate auf dem Quellserver mithalten kann. Verwenden Sie einen schnelleren Volume-Typ mit höherer IOPS und Bandbreite, um Replikationsverzögerungen zu vermeiden. Für eine optimale Leistung des EBS-Volumes empfiehlt es sich, die CloudWatch-Metriken für jedes EBS-Replikationsvolume zu überwachen.
Suchen Sie nach EBS-Volumes, die aus einem Snapshot erstellt wurden
Bei Replikationsservern, deren EBS-Volumes aus einem Snapshot erstellt wurden, kann es beim ersten Zugriff auf jeden Block zu einer erhöhten I/O-Betriebslatenz kommen. Diese Latenz kann zu einer Zunahme oder Stagnation der Verzögerung führen, bis der erneute Scanvorgang abgeschlossen ist. Weitere Informationen finden Sie unter Beachten Sie die Leistungseinbußen beim Initialisieren von Volumes aus Snapshots.
Überprüfen Sie das Snapshot-Kontingent in der Zielregion
Stellen Sie sicher, dass Ihr AWS-Konto die Snapshot-Kontingentgrenzen in der AWS-Region, in der Sie Quellserver replizieren, nicht erreicht hat. Verwenden Sie die folgenden Befehle des AWS Command Line Interface (AWS CLI), um zu überprüfen, ob Sie das Snapshot-Kontingent in der Region erreicht haben. Ersetzen Sie im folgenden Beispiel die Region durch Ihre AWS-Region:
# aws service-quotas get-service-quota --service-code ebs --quota-code L-309BACF6 --region region --query "Quota.Value" # aws ec2 describe-snapshots --owner-ids self --region region --query "length(Snapshots)"
**Hinweis:**Wenn Sie beim Ausführen der AWS-CLI-Befehle Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der AWS-CLI verwenden.
Verwandte Informationen
Identifizierung von Replikationsengpässen bei der Verwendung von AWS Application Migration Service
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr