Warum treten in meiner Anwendung Latenz- und Leistungsprobleme auf, wenn ich AWS Site-to-Site VPN verwende?

Lösung

Wenn Sie AWS Site-to-Site VPN für den Zugriff auf Ressourcen verwenden und Leistungs- oder Latenzprobleme auftreten, gehen Sie wie folgt vor:

• Isolieren Sie die Quell- und Zielsysteme nacheinander.
• Überprüfen Sie den Netzwerkpfad auf Probleme, die zu Latenz führen könnten.
• Überprüfen Sie Ihre Anwendung auf häufige Fehler, die zu Latenzproblemen führen.

Isolieren Sie Ihre Quell- und Zielsysteme

Um Leistungsprobleme zwischen Ihrer lokalen Anwendung und AWS zu minimieren, isolieren Sie zunächst die Quell- und das Zielsysteme. Suchen Sie dann mithilfe von Netzwerk-Tools nach Verlusten und Latenzen außerhalb der Anwendung, die sich direkt auf die Leistung auswirken könnten.

1.    Ändern Sie die Quelle und das Ziel. Verwenden Sie eine andere Quelle und dann ein anderes Ziel und überprüfen Sie, ob das Problem nach jeder Änderung weiterhin besteht. Überprüfen Sie dann das Gerät, um festzustellen, ob ein Problem mit der Konfiguration des Betriebssystems (BS) oder ein anderes Problem vorliegt.

2.    Führen Sie einen UDP-Bandbreitenfunktionstest durch. Leistungsprobleme können auf Durchsatzprobleme hinweisen. Verwenden Sie daher das iperf3-Tool, um Ihre bereitgestellte Bandbreite zu überprüfen. Führen Sie diesen Test bidirektional durch. Im folgenden Beispiel für einen UDP-Test wird das iperf3-Tool verwendet.

Hinweis: -i bezieht sich auf Intervall,-u bezieht sich auf UDP,-b bezieht sich auf Bandbreite (entsprechend anpassen),-p bezieht sich auf den UDP-Port und -v bezieht sich auf verbose.

Server: sudo iperf -s -u [-p 5001]
client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V

Hinweis: Vergewissern Sie sich, dass Ihr Bandbreiten-Guthaben für die Amazon Elastic Compute Cloud (Amazon EC2)-Instance verfügbar ist, die Sie verwenden. Oder versuchen Sie, eine größere Instance-Größe zu verwenden, und testen Sie dann erneut.

3.    Verwenden Sie iperf3, um einen TCP-Durchsatztest in Ihrem AWS Site-to-Site-VPN durchzuführen. Führen Sie diesen Test bidirektional durch. Siehe folgendes Beispiel:

Hinweis: Um eine optimale Leistung zu erzielen, probieren Sie verschiedene TCP-Empfangsfenstergrößen aus, um die Quell- und Zielspeicherpuffer zu testen, wenn Sie die Instance vergrößern.

Server : iperf3 -s [-p 5001]
Client:
sudo iperf3 -c <Private IP> -P 10 -w 128K -V
sudo iperf3 -c <Private IP> -P 10 -w 512K -V
sudo iperf3 -c <Private IP> -P 10 -w 1024K -V  

Überprüfen Sie den Netzwerkpfad auf Probleme

Überprüfen den Netzwerkpfad, um den spezifischen Hop oder das Gerät zu identifizieren, das Probleme im Netzwerk verursacht:

• Suchen Sie nach Paketverlusten im Pfad zwischen den Site-to-Site-VPN-Peers.
• Überprüfen Sie den Durchsatz des Site-to-Site-VPN-Tunnels.
• Überprüfen Sie die Konfiguration des Kunden-Gateway-Routers.
• Überprüfen Sie die niedrigste MTU des Pfads.

Suchen Sie nach Paketverlusten im Pfad zwischen Site-to-Site-VPN-Peers

Ihr Site-to-Site-VPN-Tunnel ist eine verschlüsselte Kommunikation zwischen Peers. Im zugrunde liegende Netzwerk gibt es jedoch möglicherweise Verluste, die sich auf die Qualität der verschlüsselten Kommunikation auswirken. Der Paketverlust erhöht die Latenz und wirkt sich direkt auf den Durchsatz aus.

Sehen Sie sich die folgende Gleichung und das folgende Beispiel an:

Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):

Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})=  (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)

Das Maß für den Durchsatz ist [TCP-Fenstergröße in Bits] / [Latenz (RTT) in Sekunden]. Siehe folgendes Beispiel:

Eg.  64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput

Verwenden Sie einen ICMP-Test, z. B. MTR, um im öffentlichen Pfad zwischen Site-to-Site-VPN-Peers nach Paketverlusten zu suchen. Weitere Informationen zum Installieren und Verwenden von MTR finden Sie unter Wie behebe ich Probleme mit der Netzwerkleistung zwischen EC2-Linux- oder Windows-Instances in einer VPC und einem On-Premises-Host über das Internet-Gateway?

Siehe folgendes Beispiel:

Hinweis: Die MTR-Ausgabe in diesem Beispiel enthält Werte ohne Daten oder ohne 100-prozentigen Verlust. Das bedeutet, dass das Gerät das Paket mit einer TTL von 0 verworfen hat, aber nicht mit der Meldung vom Typ „ICMP-Zeit überschritten“ (Typ 11, Code 0) geantwortet hat. Diese Werte deuten also nicht auf ein Problem hin.

 [ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss%   Snt   Last   Avg  Best  Wrst StDev  1.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  3.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  4.|-- 241.0.12.14                0.0%    20    0.4   0.4   0.3   0.8   0.1  5.|-- 240.0.204.2                0.0%    20    0.4   0.4   0.3   0.5   0.0  6.|-- 240.0.204.17               0.0%    20    0.4   0.4   0.3   0.5   0.0  7.|-- 240.0.204.5                0.0%    20    0.4   0.4   0.4   0.5   0.0  8.|-- 242.2.74.145               0.0%    20    1.2   4.0   0.4  23.9   5.7  9.|-- 52.93.29.71                0.0%    20    0.8   2.3   0.7   9.2   2.8 10.|-- 100.100.8.66               0.0%    20   10.8   2.5   0.7  12.8   4.0 11.|-- 100.92.53.85               0.0%    20   26.0  13.3  11.0  26.0   4.4 12.|-- 52.93.239.5                0.0%    20   11.6  12.8  11.4  23.7   2.7 13.|-- 52.95.1.159                0.0%    20   11.0  12.0  11.0  18.3   1.7 14.|-- 52.95.1.186                0.0%    20   11.5  14.1  11.2  32.6   5.9 15.|-- 15.230.39.135              0.0%    20   11.6  11.9  11.1  15.5   1.1 16.|-- 15.230.39.124              0.0%    20   11.7  12.8  11.2  27.2   3.6 17.|-- 108.166.252.38             0.0%    20   11.2  11.2  11.1  11.3   0.0 18.|-- 242.0.102.17               0.0%    20   12.1  12.4  11.2  23.9   2.8 19.|-- 108.166.252.35             0.0%    20   11.3  11.3  11.2  12.3   0.2 20.|-- 241.0.12.207               0.0%    20   11.2  11.3  11.1  13.2   0.5 21.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 22.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 23.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 24.|-- 100.65.30.129              0.0%    20   57.2  24.9  11.6  76.4  17.9 25.|-- 18.189.121.166             0.0%    20   11.3  11.8  11.2  17.6   1.6[ec2-user@ip-10-7-10-67 ~]$

Überprüfen Sie den Durchsatz des Site-to-Site-VPN-Tunnels

Prüfen Sie, ob Ihr Durchsatz das Limit von 1,2 Gbit/s überschreitet:

1.    Öffnen Sie die Amazon-CloudWatch-Konsole, um die Site-to-Site-VPN-Metriken einzusehen.

2.    Wählen Sie die Metriken für TunnelDataIn und TunnelDataOut aus.

3.    Wählen Sie für Statistik die Option Summe und dann für Zeitraum die Option 5 Minuten aus.

4.    Wenden Sie die folgende Berechnung auf die Datenpunkte an, wenn diese Spitzenwerte haben. In dieser Gleichung gilt m1 = TunnelDataIn und m2 = TunnelDataOut.

Hinweis: Wenn der Durchsatz über einen längeren Zeitraum mehr als 1,2 Gbit/s beträgt, implementieren Sie zwei BGP-Tunnel mit ECMP und Transit-Gateway.

(((m1+m2)/300)*8)/1000000

Überprüfen Sie die Konfiguration Ihres Kunden-Gateway-Routers

Überprüfen Sie Ihr Kunden-Gateway-Gerät auf die folgenden Konfigurationen:

• Stellen Sie sicher, dass keine kontrollierenden oder gestalterischen Richtlinien den Durchsatz einschränken.
• Setzen Sie das Don't-Fragment-Flag (DF) in den IP-Paketen zurück.
• Stellen Sie sicher, dass Sie die IPSec-Pakete fragmentieren, bevor Sie sie verschlüsseln.
• Stellen Sie sicher, dass das Kunden-Gateway über eine MSS-Konfiguration verfügt, sodass IP-, TCP-, UDP- oder ESP-Header und Datennutzlast 1.500 nicht überschreiten. Folgen Sie den MTU-Richtlinien für den Verschlüsselungsalgorithmus, den Sie verwenden. Weitere Informationen finden Sie unter Bewährte Methoden für Ihr Kunden-Gateway-Gerät.

Überprüfen Sie die niedrigste MTU des Pfads

Testen Sie den Pfad, um sicherzustellen, dass die niedrigste MTU des Pfads den Erwartungen entspricht:

Verwenden Sie hierzu den Befehl „ping“ für -s 1460 <DESTINATION> -M do:

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms

 Wenn ein Gerät entlang des Pfads die Nutzlast nicht transportieren kann, gibt es eine Meldung aus, die besagt, dass MTU für den ICMP-Pfad überschritten wurde:

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500

Überprüfen Sie Ihre Anwendung auf häufig auftretende Fehler

Überprüfen Sie Ihre On-Premises-Anwendung auf die häufigsten Probleme:

• Probleme mit der Anwendungskonfiguration.
• Verwendung paralleler Threads bei der Datenübertragung. Wenn Sie beobachten, dass der Site-to-Site-VPN-Durchsatz langsamer als erwartet zu sein scheint, verwenden Sie parallele Threads, um den Durchsatz unabhängig von der Anwendung zu bestätigen.
• Implementierung des Wiederholungsalgorithmus mit exponentiellem Backoff. Wenn beim Aufrufen von AWS-Services Timeouts auftreten, verwenden Sie den Wiederholungsalgorithmus mit exponentiellem Backoff.

Ähnliche Informationen

Verbessertes Networking unter Linux

Häufig gestellte Fragen zu AWS VPN