Performance-Probleme im WAN
QoS-Qualität auf dem Prüfstand
Unternehmen, die QoS bei ihren Providern beauftragen, fühlen sich auf der sicheren Seite: Nun ist die Übertragungsqualität von wichtigen Anwendungen gewährleistet. Entsprechend groß ist die Enttäuschung, wenn dann doch Performance-Probleme auftreten. Ein professioneller Abnahmetest sowie kontinuierliche Kontrollen können hier Abhilfe schaffen.
TCP-basierte Business-Anwendungen provozieren heute automatisch eine Überlast im Netzwerk. Besonders auf WAN-Leitungen entsteht so häufig das Potenzial für Paketverlust, was wiederum erhebliche Performance-Probleme verursacht. Oftmals sind sich die Netzwerkadministratoren jedoch gar nicht des eigentlichen Problems bewusst. Der Hintergrund: Das Monitoring eines Netzwerks ist in den meisten Fällen gleichbedeutend mit einer reinen Lastmessung, die jedoch nicht immer aussagekräftig ist. Schließlich lassen sich nicht alle Performance-Probleme auf eine zu große Last im Netzwerk zurückführen.
Denn auch ein reguläres SNMP-Monitoring ist nicht frei von Fehlerquellen (siehe auch Link). Die Crux liegt - kurz gesagt - darin, dass ein SNMP-Monitoring im Bestfall eine Auflösung von 60 Sekunden hat, die auftretenden Probleme aber im Bereich von Millisekunden liegen. Somit zeigt das Monitoring grünes Licht - und dennoch klagen die Anwender über eine mangelnde Netzwerk-Performance.
Fakt ist: Überlastszenarien sind heutzutage völlig normal. Viele Unternehmen arbeiten mit zahlreichen Business-Applikationen, VoIP-Telefonie und Video-Streaming - und alles läuft über eine einzige WAN-Leitung. Ganz selbstverständlich wird es da irgendwann einmal eng. Dazu muss man wissen, dass Business-kritische Applikationen wie Terminal-Services oder Host-3270-Applikationen wenig Last verursachen, aber stark von Latenz und Verlust abhängig sind. Citrix HDX extra ist "chatty" - das heißt, bei der Nutzung schickt es viele kleine Datenpakete hin und her. Schwierig wird das bei einer hohen Latenz zum Beispiel durch ein Überlastszenario. Wenn ein Kollege gerade parallel eine Datei herunterlädt oder eine Datenbank öffnet, ist die Leitung plötzlich dicht, weil die jeweilige Anwendung die verfügbare Bandbreite zu 100 Prozent nutzt. Auch wenn das nur über einen Zeitraum von einigen 100 ms der Fall ist, zieht es die Citrix-Nutzer in Mitleidenschaft. Vermeiden lässt sich dies, in dem man diese Applikation priorisiert - und hier kommt Quality of Service (QoS) ins Spiel.
QoS-Abnahmetest ist Pflicht
Bei Überlastszenarien im WAN ist QoS eigentlich zwingend erforderlich, um eine verlustfreie Übertragung und somit auch beste Performance für Anwendungen zu gewährleisten. QoS reserviert für wichtige Anwendungen Bandbreite und behandelt diese bevorzugt. Besonders wichtig ist das bei VoIP- oder Video-Anwendungen, aber eben auch bei Business-Applikationen wie Citrix. Entsprechend gibt es bei vielen Providern vier QoS-Service-Klassen, die für die meisten Unternehmen auch völlig ausreichen: Voice, Video und Business Traffic sowie die am niedrigsten priorisierte Klasse Best Effort. In letztere fallen zum Beispiel Anwendungen, die nicht geschäftskritisch sind oder die Kriterien für eine Reservierung nicht erfüllen. So ist beispielsweise Microsoft Exchange zwar Business-kritisch; durch die mögliche Verwendung von sehr großen Dateien (Anhängen) ist eine Reservierung von Bandbreite jedoch nicht hilfreich. Typischerweise liegt die Best-Effort-Klasse bei 40 bis 50 Prozent der Gesamtkapazität.
So lautet zumindest die Theorie. In der Praxis funktioniert dies aber nicht immer und überall. Das Problem ist, dass viele neue QoS-Kunden ihren Providern blind vertrauen und keinen eigenen Abnahmetest durchführen. Zwar prüfen manche Provider eigenständig neu geschaltete QoS-Leitungen - in der Regel jedoch nur auf Layer-2-Basis. Optimal wäre jedoch Layer 4: also ein umfassender Test bezüglich Qualität, Laufzeit, Paketverlust, verfügbarer Bandbreite und funktionierender QoS.
In vielen Fällen erfolgt jedoch weder der eine noch der andere Test - was nicht optimal ist. Bei einem Maurer ist es selbstverständlich, dass am Ende des Tages noch einmal die Wasserwaage zum Einsatz kommt - warum sollte es bei Netzwerken anders sein? Die Antwort darauf lautet: Weil die nötigen Software-Tools noch nicht vorhanden sind. Oder, noch grundlegender: Weil das Bewusstsein fehlt, dass sich QoS überhaupt messen lässt. Dabei ist das sogar relativ einfach: Man versendet Daten im Bereich für priorisierte Anwendungen und versucht parallel, diese mit Daten im Bereich Best Effort zu überbuchen. Ist die Qualität in der priorisierten Anwendung nicht beeinträchtigt, funktioniert QoS korrekt.
Problem erkannt, Problem gebannt
Mit speziellen Tools lassen sich solche Belastungsmessungen bei einem bewussten Überbuchen der Best-Effort-Klasse realisieren. Vorgefertigte oder kundeneigene Vorlagen für unterschiedliche Bandbreiten helfen dabei, QoS auf die korrekte Funktion hin zu überprüfen. Die Anwender können alle verfügbaren QoS-Klassen definieren und testen, wobei innerhalb einer kurzen Wartezeit von wenigen Minuten Ergebnisse vorliegen sollten. Die Bilder 1 und 2 zeigen als Beispiel eine fest definierte Datenübertragung in der Best-Effort-Klasse mit sich überlappenden Lastwechseln in Sende- und Empfangsrichtung. Bei der priorisierten Klasse - in diesem Fall EF - sollte es keine Auswirkungen auf die Lastwechsel geben. In diesem Beispiel funktioniert QoS wie geplant, und der MOS-Wert bleibt konstant - trotz der provozierten Überlastwechsel in der Best-Effort-Klasse.
Neben Belastungsmessungen sollte man auch eine permanente Überwachung der Qualität vornehmen. Dabei wird parallel zu den Anwenderdaten im gleichen Übertragungskanal ein kontinuierlicher Datenstrom erzeugt; dies geschieht mittels sehr kleiner Referenzlasten (typisch sind 30 kBit/s). Bild 3 zeigt ein Beispiel für eine solche Messung: Hier lässt sich gegen 21 Uhr ein Paketverlust-Event feststellen, das alle drei QoS-Klassen gleichermaßen betraf. Die priorisierten Klassen verlieren genau wie die Best-Effort-Klasse Pakete, was natürlich nicht passieren sollte. Auch tagsüber ist der gleiche Verlust in allen QoS-Klassen zu sehen. Typisch wäre, dass die Best-Effort-Klasse ein paar Pakete verliert, weil TCP-Anwendungen dies einfach immer wieder provozieren. Aber die priorisierten Klassen sollten dank QoS eigentlich keine Paketverluste aufweisen.
Zusätzlich lassen sich gegebenenfalls auch die DSCP-Werte im IP-Header auf der Empfängerseite auslesen und mit denen auf der Senderseite vergleichen. Weichen diese ab, können Administratoren zeitnah ungewollte Änderungen sichtbar machen und schnell darauf reagieren.
Lesen Sie mehr zum Thema
