Was ein Test der Netzwerkgeschwindigkeit über geringe Performance verriet

Während sich eine überlastete Verbindung rasch als Performance-Bremse erweist, erfordert ein Netzwerkgeschwindigkeits-Test eine genauere Analyse.

Ein Kunde kontaktierte uns bezüglich einer schlechten Netzwerk-Performance, die ihm nach einem Test der Netzwerkgeschwindigkeit...

auffiel. Er musste CAD-Dateien (Computer-Aided Design), zwischen 0,5 GByte und 1 GByte groß, von seinem zentralen Storage-System zu Remote-Arbeitsplätzen übertragen, von denen sich einige nicht weniger als 25 Kilometer entfernt befanden.

Bevor der Kunde eine Menge Geld für WAN-Verbindungen mit 1 GBit/s ausgegeben hätte, entschied er sich klugerweise, das Ganze mittels eines WAN-Simulators vorab zu überprüfen. Das File-Storage-System war über eine Ethernet-Verbindung mit 10 GBit/s mit dem Data-Center-Switch verbunden. Bei der Client-Anbindung handelte es sich um eine Ethernet-Leitung mit 1 GBit/s vom Switch zum WAN-Simulator, dann über eine weitere Verbindung mit 1 GBit/s zum Client. Den genauen Aufbau sehen Sie in Abbildung 1.

Ziel des Kunden war eine Datenübertragung mit 800 bis 900 MBit/s, wobei kein anderer nennenswerter Traffic um die Bandbreite der Verbindung konkurrierte. Der WAN-Simulator wurde anfangs mit einer Latenz von 0 Millisekunden (ms) konfiguriert. Bei den Dateitransfers gab es keine Überraschungen, sie erreichten den gewünschten Durchsatz. Als aber die später zu erwartende Latenz von 15 ms eingestellt wurde, reduzierte sich die Performance erheblich. Der beste Durchsatz zum Client lag bei ungefähr 420 MBit/s und betrug häufig lediglich 100 MBit/s. Warum gab es einen solch großen Performance-Unterschied beim Test der Netzwerkgeschwindigkeit?

Abbildung 1: So sah die Konfiguration des Netzwerks aus.

Das zeigten die erfassten Daten

Wir erhielten am File-Storage-System und beim Client aufgezeichnete Pakete und importierten sie in Wireshark. Eine Analyse auf Basis einzelner Pakete wäre aufgrund der schieren Anzahl der Pakete, die bei der Übertragung der 731 MByte großen Datei anfielen, nicht hilfreich gewesen. Stattdessen nutzten wir die Option von Wireshark für die grafische Darstellung des TCP-Sequenzraums. Dazu einfach ein Paket im Datenfluss auswählen, dann in Wireshark das Statistik-Menü Statistics/TCP Stream Graphs/tcptrace aufrufen. Der Graph des Sequenzraums sieht insgesamt unauffällig aus.

Abbildung 2: Die Gesamtübertragung sieht gut aus, nimmt aber zu viel Zeit in Anspruch.

Doch als wir einen genaueren Blick darauf werfen, erkennen wir einen deutlichen Paketverlust wenige Sekunden nach Beginn des Transfers.

Der Transfer beginnt ohne Probleme, aber danach kommt es zu einer Reihe von Paketverlusten. Die Systeme brauchen zirka eine Dreiviertelsekunde, bis sie wieder in der Lage sind, die Übertragung erneut aufzunehmen. Nach dem Paketverlust fällt die Transferrate geringer aus, wie die Neigungsänderung des Sequenznummerngraphen verrät. Unsere Analyse ergab keine weiteren Paketverluste. Die Übertragung von 731,5 MByte benötigte 17,28 Sekunden, das entspricht 42,33 MByte/s oder 338 MBit/s an Nutzerdaten. Wir erwarteten, dass der Transfer in ungefähr sieben Sekunden abgeschlossen sein würde, nicht in 17 Sekunden. Das war einer der besseren Durchsatztests. Gelegentlich zeigten die Tests auch einen Durchsatz von lediglich 70 bis 100 MBit/s.

Der Test der Netzwerkgeschwindigkeit im Detail

Das Storage-System fing mit der Datenübertragung an und ging dabei von einer Verbindung mit 10 GBit/s zum Client aus, allerdings mit einer Latenz von 15 ms. Das ist ein Verzögerungs-Bandbreiten-Produkt von annähernd 18 MByte. Wenn sich die Puffer der Netzwerkkomponenten immer weiter füllen, werden sehr viele Pakete verworfen. Das Storage-System benötigte zirka 700 ms, um die verloren gegangenen Daten erneut zu senden. Es sollte dann die Datenübertragung mittels Slow Start und anschließender Ramp-up-Phase wieder aufnehmen. Eine weitere Untersuchung war notwendig.

Wir ließen den Storage-Anbieter einen Blick auf das System werfen, während wir einen weiteren Test durchführten. Es stellte sich heraus, dass der Parameter des Congestion Window im TCP-Code des Storage-Systems als Folge des Paketverlusts auf den Wert 1 reduziert war. Zudem wies der Check darauf hin, dass der TCP-Stack im Storage-System auf dem TCP-Reno-Code basierte, einer sehr alten Implementierung. Das interne Congestion Window wird immer dann auf den Wert 1 gesetzt, wenn ein erheblicher Paketverlust auftritt. Das Congestion Window wird nicht als Teil eines Pakets übertragen. Infolgedessen musste das Innere des Storage-Systems während eines Transfers überwacht werden, um diesen Sachverhalt zu verifizieren. TCP-Reno verwendet einen zusätzlichen Slow-Start-Algorithmus, um das Congestion Window zu vergrößern, so dass das Transmit Window für jede Round-Trip-Zeit um ein Paket größer wurde.

Abbildung 3: Nach Beginn der Übertragung lässt sich ein beträchtlicher Paketverlust erkennen.

Bei der 731 MByte großen Datei stieß das Storage-System nie wieder auf ein Problem hinsichtlich Überlastung, einfach deshalb, weil die verbleibende Zeit für den Dateitransfer zu kurz war, um das Transmit Window bis zu dem Punkt wachsen zu lassen, an dem es einen weiteren Paketverlust verursachen würde. In Abbildung 3 lässt sich ein Unterschied beim geometrischen Ramp-up vor dem Paketverlust und der zusätzlichen Ramp-up-Phase nach dem Paketverlust feststellen.

Das Storage-System geht beim Ramp-up von einer Verbindung mit 10 GBit/s aus. Dann verwirft der Switch etliche Pakete, weil sich seine internen Puffer füllen. Der TCP-Stack des Storage-Systems verkleinert das Congestion Window wieder auf ein Paket. Es dauert zirka 700 ms, bis der Storage-Server die verworfenen Pakete erkennt und erneut überträgt. Der Slow-Start-Mechanismus zur Vergrößerung des Transmit Window nutzt den zusätzlichen Mechanismus, bei dem für jeden erfolgreichen Round Trip dem Transmit Window ein Paket hinzugefügt wird – zum Beispiel wächst so das Fenster an. Bei 700 MByte großen Dateien kommt es nie zu einem Paketverlust aufgrund von Überlastung. Nachforschungen zum Reno-TCP-Stack förderten zahlreiche Hinweise auf Probleme bei Netzwerken mit hoher Latenz zutage.

Es liegt nicht am Netzwerk

In diesem Fall handelte es sich bei den Schwierigkeiten, die beim Test der Netzwerkgeschwindigkeit auffielen, nicht um Netzwerkprobleme. Vielmehr entpuppte sich der alte TCP-Code im Controller für das Storage-System als wahrer Schuldiger. Dieses Problem lässt sich auf eine einfache Überlastung einer Verbindung mit geringer Geschwindigkeit – die Leitung mit 1 GBit/s zum Remote-Client – durch eine Hochgeschwindigkeitsquelle – die Schnittstelle mit 10 GBit/s zwischen dem Storage-System und dem Switch – zurückführen.

Als Schuldiger entpuppte sich der alte TCP-Code im Controller für das Storage-System.

Das Hinzufügen von Puffern zum Switch im Pfad würde nur die Zeit verzögern, zu der der Paketverlust auftreten würde. Zum gleichen Problem kann es kommen, wenn mehrere Quellen eine einzelne Verbindung überlasten. Es empfiehlt sich, Quality of Service (QoS) zu verwenden, um den Traffic zu priorisieren und weniger wichtige Pakete zu verwerfen. Falls dies nicht möglich ist, nutzen Sie Weighted Random Early Detection, um mit dem Verwerfen zu beginnen, sobald sich eine Überlastung andeutet, wodurch die Quellen eine negative Rückmeldung erhalten.

Ein interessanter Aspekt bei dem Problem ist, dass Übertragungen mit 800 MBit/s laufen, wenn die Verbindung mit 10 GBit/s durch eine mit 1 GBit/s ersetzt wird. Das Storage-System stößt auf keinen wesentlichen Paketverlust und reduziert folglich nicht das Congestion Window. Es kommt zu einem geringfügigen Paketverlust, wenn die Systeme die Verbindungskapazität erreichen, der aber nicht ausreicht, damit der Reno-basierte Code des Storage-Systems das Congestion Window schließt und zu einem zusätzlichen Slow Start wechselt.

Wie sieht es mit Workarounds aus? Wir haben mehrere verschiedene Problemumgehungen für die Diskrepanz bei der Geschwindigkeit postuliert:

  • Verwenden Sie QoS, um eine Begrenzung auf 1 GBit/s zu erreichen und so einen Pfad mit 1 GBit/s zu emulieren;
  • Nutzen Sie bei der Ethernet-Verbindung mit 10 GBit/s die Pausen-Frames, um das Storage-System anzuweisen, das Senden zu verzögern;
  • Konfigurieren Sie eine Schnittstelle mit 1 GBit/s, und nutzen Sie Policy Routing, Domain Name System (DNS) und Network Address Translation (NAT), um den Traffic des Remote-Clients dazu zu zwingen, die Verbindung mit 1 GBit/s zu verwenden.

Einer der Anbieter setzte seine eigenen Tests ein, die überprüften, was wir sahen. Er berichtete, dass die Pausen-Frames und QoS nicht funktionierten. (Dieses Ergebnis kam überraschend, da wir sicher waren, dass die Drosselung per Policing auf 1 GBit/s funktionieren würde. Wir würden gerne Paketmitschnitte von QoS-Policing-Tests erhalten, um zu verstehen, warum das nicht geklappt hat.) Unser Vorschlag, zwischen dem Storage-System und dem Switch eine Schnittstelle mit 1 GBit/s einzusetzen, scheint die einzig praktikable Möglichkeit zu sein.

Wie sehen die nächsten Schritte aus?

Dieses Problem lieferte bei der Analyse einige Überraschungen. Nun entscheidet der Kunde, wie es weitergeht. Wir kümmern uns weiter um das Problem und werden die QoS-Paketflüsse untersuchen, falls wir einen Paketmitschnitt bekommen können.

Kurz nachdem wir unseren Analysebericht abgeliefert hatten, wurden wir interessanterweise auf ein anderes Technikunternehmen aufmerksam, das ein ähnliches Problem hatte. Die Lösung dieser Firma bestand darin, ihre Daten von Storage-Systemen vor Ort zu einem Cloud-basierten Storage-Anbieter zu verschieben. Dabei kamen an jedem Remote-Standort Caching-Systeme von Panzura zum Einsatz. Das Unternehmen konnte zu preisgünstigeren Internetverbindungen mit breitbandigeren VPNs wechseln. Das half, den Durchsatz zu erhöhen. Wir meinen, das ist eine kreative Lösung, erforderte jedoch eine Anpassung der Geschäftsprozesse und der Infrastruktur. Bis die Änderung implementiert war, vergingen mehrere Monate.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Kostenloses E-Handbook: Besser arbeiten mit Wireshark.

Das können Tools für das Netzwerk-Performance-Monitoring.

Netzwerkanalyse für die schnelle Lösung von Serviceproblemen einsetzen.

Tests von Unternehmensnetzwerken effizient planen.

Artikel wurde zuletzt im Dezember 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Netzwerk-Performance-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close