Warum überschreitet meine Amazon EC2-Instance ihre Netzwerklimits, wenn meine durchschnittliche Auslastung niedrig ist?

Kurzbeschreibung

Die Elastic Network Adapter (ENA)-Netzwerkleistungsmetriken bw_in_allowance_exceeded, bw_out_allowance_exceeded oder pps_allowance_exceeded können ansteigen, selbst wenn die durchschnittliche Auslastung niedrig ist. Die häufigste Ursache für dieses Problem sind kurze Spitzen bei der Nachfrage nach Netzwerkressourcen, sogenannte Microbursts. Microbursts dauern in der Regel nur Sekunden, Millisekunden oder sogar Mikrosekunden. Amazon CloudWatch-Metriken sind nicht detailliert genug, um sie widerzuspiegeln. Du kannst beispielsweise die Instance-Metriken in CloudWatch, NetworkIn und NetworkOut verwenden, um den durchschnittlichen Durchsatz pro Sekunde zu berechnen. Die berechneten Raten können jedoch aufgrund von Microbursts niedriger sein als die verfügbare Instance-Bandbreite für den Instance-Typ.

Ein Anstieg der Metriken bw_in_allowance_exceeded und bw_out_allowance_exceeded tritt auch bei kleineren Instances auf, die eine Bandbreite von „bis zu“ haben, z. B. „bis zu 10 Gigabit pro Sekunde (Gbit/s)“. Die kleineren Instances verwenden Netzwerk-E/A-Guthaben, um für eine begrenzte Zeit ihre Basisbandbreite zu überschreiten. Wenn das Guthaben aufgebraucht ist, passt sich der Datenverkehr der Basisbandbreite an, und die Metriken steigen an. Da der Instance-Burst auf der Grundlage bestmöglichen Bemühens erfolgt, können die Metriken auch dann ansteigen, wenn die Instance verfügbares E/A-Guthaben hat.

Ein Anstieg der Metrik pps_allowance_exceeded tritt auch auf, wenn nicht optimale Datenverkehrsmuster zum Verwerfen von Paketen bei niedrigeren PPS-Raten führen. Asymmetrisches Routing, veraltete Treiber, kleine Pakete, Fragmente und Verbindungsverfolgung beeinträchtigen die PPS-Leistung bei einer Workload.

Lösung

Durchschnittsberechnung

CloudWatch erfasst alle 60 Sekunden Amazon EC2-Metriken, um die Gesamtzahl der Bytes oder Pakete zu erfassen, die in 1 Minute übertragen werden. Amazon EC2 aggregiert die Beispiele und veröffentlicht sie in Zeiträumen von 5 Minuten auf CloudWatch. Jede Statistik im Zeitraum zeigt einen anderen Wert.

Wenn du eine detaillierte Überwachung verwendest, veröffentlicht CloudWatch die Metriken NetworkIn und NetworkOut ohne Aggregation in Zeiträumen von 1 Minute. Die Werte für Summe, Minimum, Durchschnitt und Maximum sind identisch, und der Wert für SampleCount ist 1. CloudWatch aggregiert und veröffentlicht immer die Metriken NetworkPacketsIn und NetworkPacketsOut für Zeiträume von 5 Minuten.

Verwende die folgenden Methoden, um den durchschnittlichen Durchsatz in Byte pro Sekunde (B/s) oder PPS in einem Zeitraum zu berechnen:

• Um den einfachen Durchschnitt in einem angegebenen Zeitraum zu ermitteln, dividiere die Summe durch den Zeitraum oder durch die Zeitstempeldifferenz zwischen den Werten (DIFF_TIME).
• Um den Durchschnitt in der Minute mit der höchsten Aktivität zu ermitteln, dividiere Maximum durch 60 Sekunden.

Um B/s in Gbit/s umzurechnen, dividiere die Berechnungsergebnisse durch 1.000.000.000 Byte und multipliziere sie dann mit 8 Bit.

Microbursts in CloudWatch-Metriken

Das folgende Beispiel zeigt, wie ein Microburst in CloudWatch angezeigt wird. Die Instance hat eine zulässige Netzwerkbandbreite von 10 Gbit/s und verwendet eine grundlegende Überwachung.

In einer Stichprobe von 60 Sekunden nutzt eine ausgehende Datenübertragung von etwa 24 GB die gesamte verfügbare Bandbreite. Die Datenübertragung erhöht den Wert bw_out_allowance_exceeded und wird in etwa 20 Sekunden mit einer Durchschnittsgeschwindigkeit von 9,6 Gbit/s abgeschlossen. Amazon EC2 sendet keine anderen Daten, und die Instance bleibt für die verbleibenden 4 Stichproben von 240 Sekunden inaktiv.

Der durchschnittliche Durchsatz in Gbit/s in einem Zeitraum von 5 Minuten ist viel niedriger als der während des Microbursts:

Formel: AVERAGE_Gbps = SUM(NetworkOut) / PERIOD(NetworkOut) / 1.000.000.000 Bytes * 8 Bits

SUM(NetworkOut) = (~24 GB * 1 Stichprobe) + (~0 GB * 4 Stichproben) = ~24 GB

PERIOD(NetworkOut) = 300 Sekunden (5 Minuten)

AVERAGE_Gbps = ~24 / 300 / 1.000.000.000 * 8 = ~0,64 Gbit/s

Selbst wenn du den durchschnittlichen Durchsatz auf der Grundlage der höchsten Stichprobe berechnest, spiegelt der Betrag immer noch nicht den Durchsatz während des Microbursts wider:

Formel: AVERAGE_Gbps = MAXIMUM(NetworkOut) / 60 Sekunden / 1.000.000.000 Bytes / 8 Bits

MAXIMUM(NetworkOut) = ~24 GB

AVERAGE_Gbps = ~24 GB / 60 / 1.000.000.000 * 8 = ~3,2 Gbit/s

Wenn hochauflösende Daten verfügbar sind, kannst du genauere Durchschnittswerte erhalten. Wenn du Metriken zur Netzwerknutzung des Betriebssystems (OS) in Intervallen von 1 Sekunde erfasst, erreicht der durchschnittliche Durchsatz kurzzeitig etwa 9,6 Gbit/s.

Überwachen der Microbursts

Du kannst den CloudWatch-Agent unter Linux und Windows verwenden, um Netzwerkmetriken auf Betriebssystemebene in Intervallen von bis zu 1 Sekunde auf CloudWatch zu veröffentlichen. Der Agent kann auch ENA-Netzwerkleistungsmetriken veröffentlichen.

Hinweis: Hochauflösende Metriken haben höhere Preise.

Du kannst auch Betriebssystemtools verwenden, um Netzwerkstatistiken in Intervallen von bis zu 1 Sekunde zu überwachen. Verwende für Windows-Instances den Performance Monitor. Verwende für Linux sar, nload, iftop, iptraf-ng oder netqtop.

Um Microbursts eindeutig zu identifizieren, führe eine Paketerfassung des Betriebssystems durch und verwende dann Wireshark, um ein E/A-Diagramm in Intervallen von 1 Millisekunde zu zeichnen. Weitere Informationen findest du unter Download Wireshark (Wireshark herunterladen) und 8.8. The „I/O Graphs“ window (8.8 Das Fenster „E/A-Diagramme“) auf der Wireshark-Website.

Diese Methode hat die folgenden Einschränkungen:

• Die Netzwerkzulagen sind im Mikrosekundenbereich ungefähr proportional. Beispielsweise kann ein Instance-Typ mit einer Bandbreitenleistung von 10 Gbit/s in 1 Millisekunde etwa 10 Megabit (Mb) senden und empfangen.
• Paketerfassungen verursachen eine zusätzliche Systemlast und können den Gesamtdurchsatz und die PPS-Raten reduzieren.
• Paketerfassungen umfassen aufgrund von Paketenverlusten, die von einem vollen Puffer verursacht wurden, möglicherweise nicht alle Pakete.
• Zeitstempel geben nicht genau wieder, wann ein Netzwerk Pakete gesendet hat oder wann der ENA sie empfangen hat.
• Die E/A-Diagramme zeigen möglicherweise eine geringere Aktivität für eingehenden Datenverkehr, da Amazon EC2 den Datenverkehr formt, der sein Kontingent überschreitet, bevor er die Instance erreicht.

Warteschlangen und Verwerfen von Paketen

Wenn das Netzwerk ein Paket in die Warteschlange stellt, wird die daraus resultierende Latenz in Millisekunden gemessen. TCP-Verbindungen können ihren Durchsatz skalieren und die Kontingente eines EC2-Instance-Typs überschreiten. Daher werden einige Paketwarteschlangen auch dann erwartet, wenn du Engpass-Bandbreite and Roundtrip (Bottleneck Bandwidth and Round Trip, BBR) oder andere Algorithmen zur Überlastungskontrolle verwendest, die Latenz als Signal verwenden. Wenn ein Netzwerk ein Paket verwirft, überträgt das TCP verlorene Segmente automatisch erneut. Sowohl Paketwarteschlangen als auch Paketverluste können zu einer höheren Latenz und einem geringeren Durchsatz führen. Du kannst jedoch keine Wiederherstellungsaktionen anzeigen. In der Regel sind die einzigen Fehler, die du sehen kannst, wenn die Anwendung niedrige Timeouts verwendet oder wenn das Netzwerk ausreichend Pakete verwirft, dass die Verbindung zwangsweise geschlossen wird.

Die ENA-Netzwerkleistungsmetriken unterscheiden nicht zwischen Paketen in der Warteschlange oder verworfenen Paketen. Verwende die Befehle ss oder tcprtt, um die TCP-Latenz auf Verbindungsebene unter Linux zu messen. Um TCP-Neuübertragungen zu messen, verwende die Befehle ss oder tcpretrans für Statistiken auf Verbindungsebene und nstat für systemweite Statistiken. Informationen zum Herunterladen der Tools tcprtt und tcpretrans, die Teil der BPF Compiler Collection (BCC) sind, findest du unter bcc auf der GitHub-Website. Du kannst Paketerfassungen auch verwenden, um Latenz und Neuübertragungen zu messen.

Hinweis: Pakete, die das Netzwerk aufgrund der Überschreitung der Instance-Kontingente verworfen hat, erscheinen nicht in den Ablagezählern für ip oder ifconfig.

Microbursts verhindern

Vergleiche zunächst die ENA-Netzwerkleistungsmetriken mit den Key Performance Indicators (KPIs) deiner Anwendung, um die Auswirkungen von Paketwarteschlangen oder verworfenen Paketen zu ermitteln.

Wenn die KPIs unter einem erforderlichen Schwellenwert liegen oder du Anwendungsprotokollfehler erhältst, ergreife die folgenden Maßnahmen, um Paketwarteschlangen und Paketverluste zu reduzieren:

• Hochskalieren: Erhöhe die Instance-Größe auf eine Instance, die eine höhere Netzwerkzulage hat. Instance-Typen mit einem „n“, wie C7gn, haben höhere Netzwerkzulagen.
• Aufskalieren: Verteile den Datenverkehr auf mehrere Instances, um den Datenverkehr und Konflikte auf einzelnen Instances zu reduzieren.

Bei Linux-basierten Operationen kannst du auch die folgenden Strategien implementieren, um Microbursts zu vermeiden. Es hat sich bewährt, die Strategien in einer Testumgebung zu testen, um sicherzustellen, dass sie die Datenverkehrsformung reduzieren, ohne negative Auswirkungen auf die Workload zu haben.

Hinweis: Die folgenden Strategien gelten nur für ausgehenden Datenverkehr.

SO_MAX_PACING_RATE

Verwende die Socket-Option SO_MAX_PACING_RATE, um eine maximale Taktrate in B/s für eine Verbindung anzugeben. Der Linux-Kernel führt dann Verzögerungen zwischen Paketen aus dem Socket ein, sodass der Durchsatz das von dir angegebene Kontingent nicht überschreitet.

Um diese Methode verwenden zu können, musst du die folgenden Änderungen implementieren:

• Der Anwendungscode ändert sich.
• Unterstützung durch den Kernel. Weitere Informationen findest du unter net: introduce SO_MAX_PACING_RATE auf der GitHub-Website.
• Faire Warteschlangendisziplin (Fair queue, FQ) oder die Unterstützung des Kernels für die Taktung auf der TCP-Schicht (nur für TCP).

Weitere Informationen findest du unter getsockopt(2) – Linux manual page (getsockopt(2) – Linux-Handbuchseite) und tc-fq(8) – Linux manual page auf der man7-Website. Siehe auch tcp: internal implementation for pacing (interne Implementierung für die Taktung) auf der GitHub-Website.

qdiscs

Linux verwendet die Standardkonfiguration einer Warteschlangendisziplin (Queuing Discipline, qdisc) pfifo_fast für jede ENA-Warteschlange, um Pakete zu planen. Verwende die fq qdisc, um die durch einzelne Datenflüsse verursachten Datenverkehrsstöße zu reduzieren und deren Durchsatz zu regulieren. Oder verwendefq_codel und cake, um Funktionen für aktives Warteschlangenmanagement (Active Queue Management, AQM) bereitzustellen, die Netzwerküberlastungen reduzieren und die Latenz verbessern. Weitere Informationen findest du unter tc(8) – Linux manual page (tc(8) – Linux-Handbuchseite) auf der man7-Website.

Aktiviere für TCP die Explicit Congestion Notification (ECN) auf Clients und Servern. Kombiniere dann ECN mit einer qdisc, die die ECN Congestion Experienced (CE)-Kennzeichnung durchführen kann. CE-Kennzeichnungen führen dazu, dass das Betriebssystem den Durchsatz für eine Verbindung senkt, um Latenz und Paketverluste zu reduzieren, die durch eine Überschreitung des Instance-Kontingents verursacht wurden. Um diese Lösung verwenden zu können, musst du die qdisc mit einem niedrigen CE-Schwellenwert konfigurieren, der auf der durchschnittlichen Roundtrip-Zeit (RTT) deiner Verbindungen basiert. Es hat sich bewährt, diese Lösung nur zu verwenden, wenn die durchschnittliche RTT zwischen den Verbindungen nicht stark variiert. Die Instance verwaltet beispielsweise den Datenverkehr nur in einer Availability Zone.

Aufgrund von Leistungsproblemen ist es keine bewährte Methode, eine aggregierte Bandbreitenformung auf Instance-Ebene einzurichten.

Warteschlangen für flache Übertragungen (Tx)

Verwende flache Tx-Warteschlangen, um die PPS-Formung zu reduzieren. Byte-Warteschlangenlimits (Byte Queue Limits, BQL) begrenzen dynamisch die Anzahl der In-Flight-Bytes in Tx-Warteschlangen. Um BQL zu aktivieren, füge ena.enable_bql=1 zu deiner Kernel-Befehlszeile in GRUB hinzu.

Hinweis: Du benötigst den ENA-Treiber der Version 2.6.1g oder höher, um diese Lösung verwenden zu können. BQL ist bereits auf ENA-Treibern mit Linux-Kernelversionen aktiviert, die auf K enden.

Weitere Informationen findest du unter bql: Byte Queue Limits (bql: Byte-Warteschlangenlimits) auf der LWN.net-Website.

Wenn du ENA Express verwendest, musst du BQL deaktivieren, um die Bandbreite zu maximieren.

Du kannst ethtool auch verwenden, um die Länge der Tx-Warteschlange von ihrer Standardeinstellung von 1024 Paketen zu reduzieren. Weitere Informationen findest du unter ethtool (8) –Linux manual page (ethtool (8) –Linux-Handbuchseite) auf der man7-Website.

Ähnliche Informationen

Netzwerkbandbreite der Amazon-EC2-Instance