Startseite > Datacenter & Verkabelung > Qos: Qualität oder Schrott

Kommentar: Quality of Service

Qos: Qualität oder Schrott

11. März 2013, 16:15 Uhr | Mathias Hein, freier Consultant in Neuburg an der Donau

Fortsetzung des Artikels von Teil 1

Das Netzwerkmanagement zeigt keine Überlastung an

Natürlich überwachen die Netzwerker die Datenaktivitäten und untersuchen das Netz auf Anomalitäten. In der Regel zeigen die Messungen nur eine geringe Auslastung der Netzverbindungen. Daraus schließt der Netzwerker: Auf meinen Infrastrukturkomponenten ist alles in Ordnung und es gibt keine Probleme mit Staus.

Das Problem besteht jedoch darin, dass das Polling der Netzmanagementstation relativ langsam abläuft. Dadurch bleiben die momentanen Maximalwerte auf der Strecke. Wird die Polling-Rate erhöht beziehungsweise der Polling-Zeitraum reduziert (beispielsweise von 10 Minuten auf 1 Minute) verbessert sich die Qualität der Messdaten. Diese Reduzierung führt jedoch zwangsläufig zu einer Erhöhung des Datenverkehrs und liefert noch immer ungenaue Messergebnisse. Ergo werden noch immer nicht momentane Pufferüberlastungen erkannt. Bei einem meiner Kunden traten in der Praxis immer wieder kurzzeitige Staus auf einer 1 GBit/s schnellen Verbindung auf. Das Netzmanagement zeigte, bedingt durch den eingestellten 10-minütigen Abfrageintervall, jedoch nur eine Auslastung von 30 bis 40 Prozent.

Zur Erkennung von Staus und Überlastungen muss der Augenmerk des Monitoring-Systems auf die auftretenden Paketverluste gerichtet werden. Paketverluste passieren immer dann, wenn eine Netzschnittstelle überlastet ist oder deren Puffer voll sind.

Bei realen Produkten werden den Interfaces typischerweise eine kleine Anzahl von Puffern (meist 64 Puffer) zugeordnet. Befinden sich 64 Pakete in der Warteschlange dann ist der Puffer und somit die Warteschlange voll. Alle nachfolgenden Pakete werden so lange verworfen, bis mindestens ein Paket aus dem Puffer in Richtung Zielrechner übertragen wurde.

Auf der Suche nach Staus müssen die Netzschnittstelle mit Paketverlusten identifiziert werden. Hierbei muss man sich von den geringen Auslastungs- und Leistungszahlen des Netzmanagements befreien. Man muss jedoch vorsichtig sein, denn das TCP-Protokoll nutzt die Paketverluste als Mechanismus zur Geschwindigkeitsregulierung. Um Probleme im Netzwerk zu finden muss man sich auf die Suche nach den Schnittstellen machen, die Tausende Paketverluste pro Stunde erzeugen. Eine Liste der von Paketverlusten betroffenen Schnittstellen (in absteigender Reihenfolge der Paketverluste) zeigt den Weg auf die Überlastungen im Netz zu identifizieren beziehungsweise zu beheben.

Bei einem meiner Kunden traten erhebliche Paketverluste im Netzwerk auf. Aus diesem Grund wurden auf den zentralen Koppelkomponenten die Schnittstellenpuffer erhöht. Eine Erhöhung der Anzahl an verfügbaren Puffern auf den Schnittstellen ist jedoch der falsche Lösungsansatz. Durch die zusätzlichen Puffer wird die Verzögerung während der Übermittlung von Datenbursts zu einem großen Problem. Bei Echtzeit-Anwendungen (VoIP) führt die Puffererhöhung zu dem Effekt, dass die Pakete zu lange im Netz verzögert werden und daher zu spät beim Empfänger eintreffen. Der Jitter-Puffer des Empfängers verwirft daher die verspäteten Pakete. Bei TCP-Verbindungen werden die im vergrößerten Puffer feststeckenden Pakete, unter Umständen als verloren gegangen bewertet und nach Ablauf des Retransmission-Timers vom Sender erneut übermittelt. Dies führt zwangsläufig zur weiteren Verstopfung der Verbindung und die doppelt übermittelten Pakete konsumieren Netzwerkbandbreite ohne Nutzen. Diesen Effekt kann man sehr gut mit einem Trace nachweisen, wenn in den aufgezeichneten Daten eine große Zahl von doppelten TCP-ACKs zu finden sind.

Anstatt sehr viele Pakete in den Puffern zwischen zu speichern, wäre es tatsächlich besser die Bandbreite des betreffenden Links zu erhöhen. Hierbei handelt es sich jedoch nur um eine kurzfristige Lösung, damit die Anzahl der Puffer verringert werden kann. Langfristig kommt man nicht an einer umfassenden Lösung des Problems vorbei und muss sich mit dem Thema „QoS“ intensiv auseinander setzen.