Warum überschreitet meine Amazon-Elastic-Compute-Cloud-Instance (Amazon EC2) ihre Netzwerkgrenzen, wenn die durchschnittliche Auslastung gering ist?

Kurzbeschreibung

Sie können Netzwerkleistungsmetriken in Echtzeit auf Instances abfragen, die Enhanced Networking über den Elastic Network Adapter (ENA) unterstützen. Diese Metriken liefern eine kumulierte Anzahl von Paketen, die seit dem letzten Treiber-Reset auf jeder Netzwerkschnittstelle in die Warteschlange gestellt oder verworfen wurden. Im Folgenden sind einige der ENA-Metriken aufgeführt:

• bw_in_allowance_exceeded: Die Anzahl der Pakete, die in die Warteschlange gestellt oder verworfen wurden, weil die eingehende Gesamtbandbreite das Maximum für die Instance überschritten hat.
• bw_out_allowance_exceeded: Die Anzahl der Pakete, die in die Warteschlange gestellt oder verworfen wurden, weil die ausgehende Gesamtbandbreite das Maximum für die Instance überschritten hat.
• pps_allowance_exceeded: Die Anzahl der Pakete, die in die Warteschlange gestellt oder verworfen wurden, weil die bidirektionalen Pakete pro Sekunde (PPS) das Maximum für die Instance überschritten haben.

Die Spezifikationen für die Netzwerkleistung variieren je nach Instance-Typ. Informationen zu Spezifikationen finden Sie unter Instances der aktuellen Generation. In einigen Fällen kann es zu Warteschlangen oder zu Einbrüchen kommen, obwohl Ihre durchschnittliche Bandbreite oder PPS, wie in Amazon CloudWatch zu sehen ist, gering ist. Beispielsweise können die Metriken NetworkIn, NetworkOut, NetworkPacketsIn oder NetworkPacketsOut in CloudWatch Beträge anzeigen, die nicht darauf hindeuten, dass ein Limit erreicht wird.

Auflösung

Microbursts sind die häufigste Ursache für die vorangegangenen Symptome. Microbursts sind kurze Spitzen, gefolgt von Zeiträumen geringer oder keiner Aktivität. Diese Bursts dauern nur Sekunden, Millisekunden oder sogar Mikrosekunden. Im Fall von Microbursts sind die im vorherigen Abschnitt aufgeführten CloudWatch-Metriken nicht detailliert genug, um sie widerzuspiegeln.

So werden Durchschnittswerte berechnet

Die im vorherigen Abschnitt aufgeführten EC2-Metriken in CloudWatch werden alle 1 Minute abgetastet. Diese Metriken erfassen die Gesamtzahl der Byte oder Pakete, die in diesem Zeitraum übertragen wurden. Diese Beispiele werden dann aggregiert und in 5-Minuten-Zeiträumen auf CloudWatch veröffentlicht. Jede Statistik im Zeitraum gibt einen anderen Beispielwert zurück:

• Summe ist die Summe aller Stichprobenwerte.
• SampleCount ist die Anzahl der aggregierten Proben (in diesem Fall 5).
• Minimum ist der Beispielwert mit der niedrigsten Byte-/Paketzahl.
• Durchschnitt ist der durchschnittliche Stichprobenwert, berechnet durch Division von Summe durch SampleCount.
• Maximum ist der Beispielwert mit der höchsten Byte-/Paketzahl.

Der durchschnittliche Durchsatz oder PPS kann auf zwei Arten berechnet werden:

• Teilen Sie die Summe durch einen Zeitraum (z. B. 300 Sekunden) für einen einfachen 5-Minuten-Durchschnitt.
• Teilen Sie Maximum durch 60 Sekunden für den Durchschnitt in der Minute mit der höchsten Aktivität.

Wie sich Microbursts in CloudWatch-Metriken widerspiegeln

Das Folgende ist ein Beispiel für Microbursts und wie sie sich in CloudWatch widerspiegeln:

• Die Instance hat eine Netzwerkbandbreitenleistung von 10 Gbit/s (1,25 GB/s).
• In einem bestimmten Beispiel (60 Sekunden) verbraucht eine ausgehende Datenübertragung von 20 GB die gesamte verfügbare Bandbreite, wodurch bw_out_allowance_exceeded inkrementiert wird. Die Übertragung ist in etwa 20 Sekunden abgeschlossen, und danach werden keine weiteren Daten gesendet.
• Die Instance bleibt für die verbleibenden 4 Samples inaktiv (240 Sekunden).

In diesem Beispiel ist der durchschnittliche Durchsatz in einem Zeitraum von 5 Minuten viel niedriger als der während des Microbursts:

SUM(NetworkOut) / PERIOD = ((20 GB * 1 sample) + (0 GB * 4 samples)) / 300 seconds = ~0.066 GB/s * 8 bits = ~0.533 Gbps

Selbst wenn Sie den Durchsatz auf der Grundlage der höchsten Probe berechnen, spiegelt der Durchschnitt immer noch nicht den Durchsatz wider:

MAXIMUM(NetworkOut) / 60 = 20 GB / 60 seconds = ~0.333 GB/s * 8 bits = ~2.667 Gbps

Microbursts überwachen

Verwenden Sie Betriebssystem-Tools (OS) zur Überwachung von Netzwerkstatistiken, um Durchsatz und PPS auf einer detaillierteren Ebene zu messen. Überwachen Sie Ihre Netzwerkstatistiken häufiger in Phasen der Formgebung oder hoher Aktivität.

Im Folgenden finden Sie Beispiele für OS-Tools:

Linux

• sar
• nload
• iftop
• iptraf-ng

Windows

• Leistungsüberwachung

Der CloudWatch-Agent kann sowohl unter Linux als auch unter Windows verwendet werden, um diese Netzwerkmetriken auf Betriebssystemebene als benutzerdefinierte Metriken in CloudWatch zu veröffentlichen. Diese Metriken können in Intervallen von nur einer Sekunde veröffentlicht werden. Beachten Sie, dass hochauflösende Metriken (solche mit einem Zeitraum von weniger als 60 Sekunden) zu höheren Gebühren führen. Weitere Informationen zur Preisgestaltung von CloudWatch finden Sie unter Amazon CloudWatch – Preise.

Es ist eine bewährte Methode für Sie, die von ENA bereitgestellten Netzwerkleistungsmetriken zu überwachen. Die Treiberversion muss größer oder gleich 2.2.10 (Linux) und 2.2.2 (Windows) sein, damit Sie die Metriken anzeigen können. Weitere Informationen finden Sie auf den entsprechenden Seiten für Linux und Windows.

CloudWatch Agent kann auch ENA-Metriken veröffentlichen. Anweisungen zum Veröffentlichen von ENA-Metriken für Linux finden Sie unter Erfassen von Netzwerkleistungsmetriken. Für Windows sind ENA-Metriken im Performance Monitor verfügbar, und der CloudWatch Agent kann alle dort verfügbaren Metriken veröffentlichen.

Microbursts verhindern

Um Microbursts zu vermeiden, muss der Datenverkehr an die Absender gerichtet werden, damit er einen maximalen Durchsatz oder eine maximale Paketrate nicht überschreitet. Dadurch sind Microbursts schwer zu vermeiden. Das Tempo des Datenverkehrs beim Absender erfordert normalerweise Änderungen auf Anwendungsebene. Je nachdem, wie diese Änderung implementiert wird, muss die Betriebssystemunterstützung für Traffic-Pacing möglicherweise beim Absender verfügbar und aktiviert sein. Das ist vielleicht nicht immer möglich oder praktisch. Microbursting kann auch auftreten, weil zu viele Verbindungen Pakete in kurzer Zeit senden. In diesem Fall hilft es nicht, einzelne Absender auf Tempo zu setzen.

Aus diesen Gründen empfiehlt es sich, die ENA-Metriken, wie bereits erwähnt, zu überwachen. Wenn Grenzwerte häufig erreicht werden oder es Hinweise darauf gibt, dass sich dies auf Ihre Anwendungen auswirkt, gehen Sie wie folgt vor:

• Hochskalieren: Wechseln Sie zu einer größeren Instance-Größe. Größere Instances haben in der Regel höhere Zulagen. Netzwerkoptimierte Instances (z. B. Instances mit einem „n“, wie in C5n) haben höhere Zulagen als ihre jeweiligen nicht netzwerkoptimierten Gegenstücke.
• Aufskalieren: Verteilen Sie den Datenverkehr auf mehrere Instances, um Datenverkehr und Konflikte bei einzelnen Instances zu reduzieren.

Unter Linux gibt es zusätzlich zu den oben genannten Optionen potenzielle Risikominderungsoptionen für fortgeschrittene Benutzer: Sie können diese Optionen alleine oder in Kombination implementieren. Es ist eine bewährte Methode, Risikominderungen in einer Testumgebung zu bewerten, um sicherzustellen, dass sie die Traffic-Formung reduzieren oder eliminieren, ohne Ihre Arbeitslast zu beeinträchtigen.

• SO_MAX_PACING_RATE: Diese Socket-Option kann von einer Anwendung an setsockopt übergeben werden, um eine maximale Pacing-Rate (Byte pro Sekunde) anzugeben. Der Linux-Kernel leitet dann den Datenverkehr von diesem Socket so ab, dass er das Limit nicht überschreitet. Für diese Option ist Folgendes erforderlich:

• Änderungen auf Codeebene der Anwendung.
• Unterstützung vom Kernel.
• Die Verwendung von Fair-Queue-Warteschlangendisziplin (FQ) oder die Unterstützung des Kernels für das Tempo auf TCP-Ebene (gilt nur für TCP).

• Queuing-Disziplinen (qdiscs): qdiscs sind für die Paketplanung und optionale Formung verantwortlich. Einige qdiscs, wie fq, helfen dabei, Traffic-Bursts aus einzelnen Flows auszugleichen. Weitere Informationen finden Sie auf der Handbuchseite Traffic Control (TC).
• Warteschlangen für flache Übertragung (Tx): In einigen Szenarien tragen flache Tx-Warteschlangen dazu bei, die PPS-Drosselung zu reduzieren. Dies kann auf zwei Arten erreicht werden:

• Byte Queue Limits (BQL): BQL begrenzt dynamisch die Anzahl der während der Ausführung in Tx-Warteschlangen befindlichen Bytes. BQL ist standardmäßig in ENA-Treiberversionen aktiviert, die mit dem Linux-Kernel ausgeliefert werden (solche, die mit einem „K“ enden). Für ENA-Treiberversionen von GitHub (solche, die mit einem „g“ enden) ist BQL ab v2.6.1g verfügbar und standardmäßig deaktiviert. Sie können BQL mithilfe des enable_bql ENA-Modulparameters aktivieren.
• Reduzierte Tx-Warteschlangenlänge Reduzieren Sie die Tx-Warteschlangenlänge von der Standardeinstellung von 1.024 Paketen auf einen niedrigeren Betrag (mindestens 256). Sie können diese Länge mit dem Ethtool ändern.

---

Relevante Informationen

• Netzwerkbandbreite der Amazon EC2-Instance
• Überwachen Sie die Netzwerkleistung für Ihre EC2-Instance (Linux)
• Überwachen Sie die Netzwerkleistung für Ihre EC2-Instance (Windows)