Monitoring von Lastspitzen
Bursts erkennen und vermeiden
Fortsetzung des Artikels von Teil 1
Analyse im Millisekundenbereich
Eine solche Burstanalyse ist in vielen Fällen die lösungsorientierteste Analysemöglichkeit. Sei es z.B. der Telekommunikationsanbieter, der seinem Kunden ein bestimmtes Bandbreitenpaket verkauft und entsprechend zur Verfügung stellt. Klagt der Kunde nun über Bandbreitenengpässe, hilft eine Burst-Analyse, genaue Angaben über deren Traffic-Aufkommen zu treffen. In solch einem Bereich ist wünschenswert, eine Detailtiefe dargestellt zu bekommen, die über das übliche Minuten- bzw. 30-Sekunden-Intervall hinausgeht.
Ein anderer Fall ist die Voice-Telefonie. Die Datenübertragung per SIP/RTP erfolgt mit einer Rate von einem Paket alle 20, 25 oder 30 Millisekunden. Empfangen werden die Daten aber nicht ganz regelmäßig, sondern mit Abweichungen. Schon Abweichungen von 20 Millisekunden verursachen bereits akustische Schwierigkeiten auf der Gegenstelle, z.B. verschluckte Buchstaben. Um diesen Abweichungen, dem sogenannten Jitter, auf die Spur zu kommen, bedarf es folglich einer Burst-Analyse im Millisekundenbereich. Erst diese zeigt, ob die Leitung tatsächlich für einige Millisekunden überlastet war. Halten die Abweichungen über eine längere Zeit an, wird der Audiopuffer sehr voll, der Jitter passt sich an. Alternativ wird ein Teil des Puffers entfernt, Pakete gehen verloren. Liegen die Analyse-Ergebnisse lediglich im Minutenbereich vor, würden diese Fehler nicht erkannt und somit auch nicht behoben werden können. Erst eine höhere Taktung gewährt Einsichten, wo die Probleme liegen.
Ein weiterer Anwendungsfall, bei dem eine Qualitätsauswertung im Millisekundenbereich notwendig wird, sind kritische Dienste. Während manche Anwendungen nach dem Prinzip des Best-Effort funktionieren, also so schnell wie möglich, sind andere Dienste extrem zeitkritisch. Der Vergleich zwischen E-Mail und Voice-Telefonie erläutert dies anschaulich: Beim Versenden einer E-Mail ist es in den meisten Fällen kaum von Belang, ob sie dafür eine oder drei Sekunden benötigt. Beim VoIP-Telefonat ist dies im Gegensatz sehr kritisch. Wie erläutert sollen hier die Pakete möglichst alle im konstanten, kurzen Zeitintervall ankommen.
Um auf das Bild mit der Straße zurückzukommen: Bei einem Teil der Waren ist es weniger wichtig, ob sie exakt zur vorbestimmten Zeit ihren Bestimmungsort erreichen. Bei anderen Waren hingegen ist es extrem kritisch, wann sie ankommen, z.B. aufgrund einer einzuhaltenden Kühlkette.
Egal ob Logistiker oder Systemadministrator, dies sind die Planer, die für die eingehaltene Kühlkette oder die störungsfreie Voice-Telefonie verantwortlich sind. Gerade bei der Voice-Telefonie, aber auch bei allen anderen zeitkritischen Anwendungen, kommt es wesentlich darauf an, das Netzwerk millisekundengenau debuggen zu können. Inzwischen sind Monitoring-Tools auf dem Markt erhältlich, die dem Systemadministrator diese Qualitätsmerkmale liefern.
Vorgehensweisen bei Lastspitzen
Hat eine Fehleranalyse der Netzwerkprobleme dann tatsächlich Bursts als Ursache ans Tageslicht gebracht, besteht für den Admin Handlungsbedarf. Doch welche Strategie ist die Richtige? Gilt es, einfach die Bandbreite des Links zu erhöhen und alle Probleme sind ausgemerzt? Wie verhält sich z.B. ein System mit 10G-Netzwerkanschluss, wenn das dahinterliegende 1G-Netzwerk auf 10G erhöht wird?
Folgendes Beispiel soll den Fall erläutern: Zwei mit 10G angeschlossene Server waren so konfiguriert, dass die Backups neu starten, sobald sie das letzte vervollständigt haben. Um die volle Auslastung des Links zu entschärfen, wurde daraufhin der Link zwischen den beiden Rechenzentren auf 40G aufgerüstet. Dies war mit großem Aufwand und hohen Kosten verbunden. Als nun das Projekt endlich abgeschlossen war, zeigte sich zum Frust aller Beteiligten, dass der Link ebenso ausgelastet war wie vorab. Wie konnte das passieren? Eine neuerliche Analyse brachte nun ans Tageslicht, dass das Problem an den dahinter liegenden Clustern lag. Diese waren mehrfach mit 10G angeschlossen. Der Link, der vorab mit 10 Gbit/s voll ausgelastet war, erzeugte nach dem Upgrade so viel Traffic, dass auch der 40G-Link keine Kapazitäten mehr hatte. Die Backups liefen in vierfacher Geschwindigkeit.
Das teure Upgrade wäre also nicht notwendig gewesen. Eine dezidierte Burst-Analyse hätte dies im Vorfeld erkannt. Denn neben der Dauer der Peaks stellt sie unter anderem auch dar, welche Netzwerkteilnehmer die Bursts eigentlich verursachen. Sie erkennt, welche Dienste den Link sättigen, sei es der Windows-Update-Server, ein File-Transfer oder Backups. Statt eines Link-Upgrades hätte es genügt, die Geschwindigkeiten dieser Dienste zu drosseln.
Leidet eine Netzwerkarchitektur unter Bursts, ist ein Upgrade also nicht immer die richtige Verfahrensweise. Mitunter ist es ratsam, stattdessen das System auf das Prinzip Quality of Service umzustellen. So kann den einzelnen Diensten eine entsprechende Bandbreite zugeordnet werden. Eine weitere Alternative stellt eine logische oder physische Trennung der Dienste dar. So kann z.B. dem Telefonnetz eine hohe Priorität oder eine gänzlich eigene Leitung zugeordnet werden.
Wer also nach einer Universallösung sucht, wie ein Netzwerk bei voller Auslastung zu behandeln ist, wird leider enttäuscht. Sind die Ursachen der Bursts aber hinlänglich bekannt, ist die Entscheidung über den Lösungsweg wesentlich vereinfacht.
Klaus Degner ist Geschäftsführer von Allegro Packets
- Bursts erkennen und vermeiden
- Analyse im Millisekundenbereich
Lesen Sie mehr zum Thema
