Praxis der Performance-Analyse im Netzwerk
Applikationsprobleme zuverlässig lösen
Wenn geschäftswichtige Anwendungen zäh reagieren, nervt dies nicht nur die Anwender, sondern beeinträchtigt die Leistung des gesamten Unternehmens. Die Suche nach den Ursachen ist häufig nicht trivial - aber mit der richtigen Strategie und Expertise sowie ausgesuchten Tools zuverlässig realisierbar.
Anwender wollen es, Anbieter propagieren es: das "ultimative" Werkzeug für Performance-Analyse und Troubleshooting in Netzwerken. Leicht bedienbar, erkennt es die Ursachen von Problemen selbstständig und behebt diese sofort. Idealerweise warnt es auch noch proaktiv vor potenziellen Performance-Schwachstellen und schlägt Lösungen vor - gleichsam die eierlegende Wollmilchsau unter den Netzwerk-Tools.
Doch in dieser Hinsicht treffen Wunsch und Wirklichkeit hart aufeinander, denn die Realität sieht leider anders aus. Dies liegt zunächst ganz grundlegend an der außerordentlichen Vielfalt und Heterogenität realer Netzwerke. Keines gleicht dem anderen, alle basieren auf unterschiedlicher Hard- und Software und sind verschieden groß. Zum Teil kommen proprietäre Lösungen zum Einsatz. Ein breites Spektrum installierter Betriebssysteme und geschäftlich genutzter Applikationen sowie die Nutzung Java- und Web-basierender Programme runden das komplexe Gemenge ab.
Die zunehmende Virtualisierung von Netzwerk- und Rechnerressourcen verschärft die Problematik. Moderne Lösungen wie VMware ESX oder Microsoft Hyper-V sind mittlerweile so leistungsfähig, dass sich die Software-Server dynamisch initiieren und während des Betriebs über Hardwaregrenzen hinweg verschieben lassen. Die Folge dieser Flexibilität: Die Darstellung und Analyse der Anwendungs-Performance innerhalb von virtualisierten Umgebungen hat sich bei Beschwerden über schlechte IT-Performance zu einem zentralen Thema entwickelt.
Das erwähnte "Ideal-Tool", das für alle Eventualitäten gerüstet ist, wäre nur mit extremem technischen Aufwand zu realisieren - wenn überhaupt. Zudem wäre es sehr teuer. Damit nicht genug: Diese Lösung müsste permanent und netzwerkweit Prüfvorgänge mit hoher Detailtiefe und entsprechend hohem Datenaufkommen durchführen, um ihrer Aufgabe gerecht zu werden. Server und Infrastruktur müssten diese zusätzliche Last schultern - was unter Umständen selbst Performance-Probleme provozieren würde.
Hinzu kommt: Je mehr Aufgaben Mess- und Analyse-Tools in hoher Detailtiefe verrichten, desto komplizierter sind sie zu bedienen. Jedes Werkzeug muss der Administrator mithilfe von Voreinstellungen, Regeln und Richtlinien zunächst an die zu überwachende Infrastruktur anpassen - sonst verschwendet es Ressourcen für das Messen von Kriterien, die bei der Fehlersuche letztlich gar nicht helfen. Dies setzt eine weitreichende Expertise voraus. Letztlich bewahrheitet sich in dieser Hinsicht die alte Messtechniker-Weisheit: Wer (zu) viel misst, misst oft Mist. Einen wichtigen Aspekt stellt zudem die Handhabung dar: Ist die Bedienung zu kompliziert, bleibt das teuer eingekaufte Analyse-Equipment ungenutzte Schrankware.
Überblick verschaffen und genau zuhören
Tauchen Schwierigkeiten mit Applikationen auf, ist die Problembeschreibung der Anwender oft sehr unspezifisch. "Das Netzwerk ist heute wieder zu langsam", oder "Programm ABC reagiert manchmal sehr zäh", sind Klagen, die häufig am Helpdesk eingehen. Daher ist es entscheidend, in einem ersten Schritt, noch bevor der Koffer mit den Analyse-Tools geöffnet wird, die Betroffenen zu befragen und genau zuzuhören. Nur so hat der Administrator eine Chance, die Umstände richtig zu verstehen. Dabei stellt sich häufig heraus, dass nicht ein einziges großes Problem besteht, sondern viele kleine. Diese können in ihrer Gesamtheit durchaus zu spürbaren Beeinträchtigungen des IT-Betriebs führen. Daher ist es erforderlich, jede einzelne problematische Transaktion separat zu untersuchen. Verallgemeinerungen oder Zusammenfassungen sind nicht zielführend.
Troubleshooting ist keine Langzeitmessung
Eine IT-Infrastruktur besteht in der Regel aus drei Hauptbereichen: Clients, Netzwerk und Server ("CNS"). In diesem Dreigestirn ist der Punkt "Netzwerk" besonders komplex. Für viele Anwender und oft auch Systemverantwortliche ist daher klar: Wenn es Probleme gibt, zum Beispiel eine Applikation nur schleppend reagiert, dann ist das Netzwerk schuld. Anstatt nun aber zu versuchen, ein Performance-Problem mit einem teuren All-in-one-Tool sofort in seiner Gänze zu erfassen und vollständig lösen zu wollen, ist es meist wesentlich effizienter und letztlich auch kostensparender, eine strukturierte, schrittweise Fehlersuche durchzuführen. Zumal sich meist schnell und mit wenig Aufwand nachweisen lässt, dass das Netzwerk einwandfrei funktioniert.
Natürlich wäre es theoretisch möglich, eine Langzeitmessung in höchster Detailtiefe netzwerkweit durchzuführen und 24 Stunden am Tag und sieben Tage pro Woche den gesamten Datenverkehr im Netzwerk mitzuschneiden. Mit vertretbarem Aufwand und Budget ist es jedoch nicht möglich, die Unmengen an gesammelten Informationen rasch auszuwerten und schnell die eine Ursache für ein Performance-Problem zu finden und zu isolieren. Dafür sind die in modernen Netzwerken übertragenen Datenmengen - Stichwort 10G oder 40G - viel zu groß.
In der Praxis bedeutet dies, dass nach wie vor ein gut bestückter Werkzeugkoffer an Tools nötigt ist, um schnell und effizient Ursachen für eine schlechte Netzwerk-Performance zu erkennen, zuzuordnen und zu beseitigen. Dabei sollte die strukturierte Herangehensweise die Auswahl der Werkzeuge bestimmen - und nicht die verfügbaren Tools die Vorgehensweise.
Reproduzierbare Probleme beheben
Wenn feststeht, welche Transaktion von reproduzierbaren Problemen beeinträchtigt ist, erweist sich das Troubleshooting als relativ einfach. Meist reicht es, die betroffene Transaktion auszuführen, einen Paket-Trace in hoher Detailgenauigkeit mitzuschneiden und zu analysieren. Wichtig ist dabei: Der Anwender darf nicht willkürlich agieren, sondern muss sich strikt an Vorgaben halten, welche Aktion er wann und wo ausführen soll. So ist es möglich, diese Aktion zeitlich mit den aufgezeichneten Ereignissen der Infrastruktur zu korrelieren. Dabei zählt sehr akkurates Vorgehen.
Nach dem Separieren der betroffenen Kommunikation erfolgt dann beispielsweise die Prüfung auf typische Fehler über das Analysieren von Werten wie Retransmission, Zero Window, Timeouts auf den OSI-Layern 3 und 4. Treten dort keine Auffälligkeiten zutage, erfolgt eine weitere Analyse höherer Schichten, etwa ein Vergleich der guten und schlechten Traces, die Analyse der Anwendungsprotokolle und das Auswerten der Statistiken für die Service-Antwortzeiten. Wichtig ist dabei, die aufgezeichneten Messdaten immer wieder auf Plausibilität zu überprüfen. Finden sich beispielsweise Pakete in der Aufzeichnung, die durch die ACK-Pakete nicht bestätigt werden, ist der Trace vermutlich fehlerhaft, und der Administrator sollte ihn wiederholen.
Ausschlussverfahren bei sporadischen Problemen
Treten Probleme nur hin und wieder auf, muss der Performance-Profi schon etwas tiefer in seine Werkzeugkiste greifen. Trotzdem gilt es, die verfügbare Zeit und die vorhandenen Ressourcen so effektiv wie möglich einzusetzen. Dabei bewährt sich einmal mehr die "80/20-Regel": mit möglichst geringem Aufwand versuchen, einen Großteil möglicher Fehlerquellen auszuschließen. In der Praxis lässt sich dieser Nachweis oft mit geringem Aufwand führen, indem der Administrator mithilfe spezieller Tools die gesamte Übertragungsstrecke vom Client zum Server strukturiert über einen längeren Zeitraum vermisst. Anhand von Werten wie Laufzeiten und Paketverlusten - beides sind Kernkriterien für die Netzwerkqualität - lässt sich die Qualität des Transportkanals beurteilen.
Im weiteren Verlauf versucht der Verantwortliche, das sporadisch auftretende Problem auf eine bestimmte Transaktion herunterzubrechen. Dabei können die im Ausschlussverfahren gewonnenen Informationen eine wichtige Stütze sein. In diesem Umfeld kann sich der Einsatz eines Softwareroboters lohnen, der beispielsweise hundertmal eine bestimmte Aktion ausführt. Taucht das Problem auf, vollzieht man analog zum Troubleshooting genau diese eine Transaktion noch einmal nach und zeichnet einen Paket-Trace in bestmöglicher Detailtiefe auf. Über die genaue Analyse lässt sich das Problem oft auf einen bestimmten Teilbereich der Infrastruktur eingrenzen. Häufig ist ab diesem Punkt die Zusammenarbeit mit einem Systemspezialisten erforderlich.
Fazit
Ein schrittweises, strukturiertes Vorgehen nach dem Ausschlussverfahren verspricht den schnellsten Erfolg beim Beheben von Performance-Problemen. Dafür sind nach wie vor ein breites Arsenal an Werkzeugen und umfassende Expertise notwendig. Erfahrene Performance-Spezialisten beherrschen die Klaviatur der unterschiedlichen Mess- und Analyse-Tools und setzen situationsabhängig die richtigen Werkzeuge ein. Mithilfe gezielter Langzeitmessungen und Troubleshooting-Analysen lassen sich nicht nur permanente, sondern auch sporadische Performance-Probleme sicher beheben.
Lesen Sie mehr zum Thema
