Projekte

Retrospektive Netzwerk-Analyse mit GigaStor

Selbst ein partieller Ausfall des Netzwerks für einen nur kurzen Zeitraum kann in Kosten von mehreren Tausend Euro resultieren.Das GigaStor-System von Network Instruments ermöglicht eine Retrospektive Netzwerk-Analyse (RNA) und verkürzt Fehlersuche, Ursachen-Ermittlung und Fehlerbehebung erheblich.

Von Oliver Lindlar und Mirco Jakuszeit, GORDION.


Die Netzwerk-Kommunikation und damit der Zugriff auf Server, Daten und Applikationen muss heutzutage reibungslos funktionieren. Optimalerweise ohne Störungen und am besten hochverfügbar. Ein performantes und hochverfügbares Daten-Netzwerk ist branchenübergreifend die Basis für moderne Geschäftsprozesse und -Kommunikationen sowie deren Applikationen. Die Mehrheit der Dienste und Applikationen, darunter auch VoIP / Audio / Video, nutzt mittlerweile das (Ethernet-) Netzwerk als Kommunikations-Infrastruktur. Während es noch vor einigen Jahren in Unternehmen und Organisationen durchaus denkbar war, dass z.B. der Email-Dienst für einen Tag ausfällt oder eine Applikation für Mitarbeiter nicht erreichbar ist, wirken sich solche Szenarien heute meist sehr empfindlich auf die Geschäftsprozesse aus und verursachen signifikante Kosten.Aus diesem Grund verfügen moderne Netzwerke u.a. über ein redundantes Core- und Server-Switch-System, welches im Störungsfall einer zentralen Komponente weiterhin den Zugriff auf die Server / Daten / Applikationen ermöglicht (no single point of failure, gleiches gilt analog für Firewalls u.a. unternehmenskritische Komponenten).Darüber hinaus ermöglichen Netzwerk-Management-Lösungen einen Gesamtüberblick und melden Störungen von Komponenten und Systemen umgehend an die verantwortlichen Administratoren.

Neben den meist eindeutigen Störungsmeldungen aus dem Netzwerk-Management-System gibt es leider auch eine Vielfalt an „schwammigen“ Störungsmeldungen. Oft kommuniziert durch die User, wie z.B. der Klassiker: „Das Netz ist langsam.“ Oder „Mein Programm ABC reagiert nicht mehr“. Noch ungünstiger sind Meldungen wie „Das Netz war gestern langsam“ oder „Heute morgen reagierte mein Programm ABC nicht mehr“. Der Ausfall von Voice over IP (VoIP), eine nicht erreichbare Serverfarm / Datenbank oder eine stehende Produktion aufgrund einer Netzwerkanomalie sind dagegen durchaus konkrete, unternehmenskritische Störungen und verursachen sofort Ausfallkosten.Zeigt in solchen Fällen das Netzwerk-Management-System keine korrelierende Anomalie, kann die Fehlerbehebung erheblich Zeit beanspruchen. Wie geht man dann der Ursache für kritische Störungsmeldungen auf den Grund? Wie ermittelt man ad hoc mit ein paar Mausklicks die Ursache und behebt in kürzester Zeit das Problem? Wie hoch steigern sich die Kosten für den Fall, dass eine komplette Abteilung, Produktionshalle oder Aussenstelle von einer Störung / Downtime betroffen ist?

Zur schnellen Problemlösung ist meist eine Netzwerk-Analyse erforderlich, mit Fokus auf die detaillierte Datenkommunikation. Vorzugsweise retrospektiv, also mit „Blick in die Vergangenheit“. Wir beleuchten daher nachfolgend das Potential einer Retrospektiven Netzwerk-Analyse (RNA) und zeigen die Möglichkeiten einer schnellstmöglichen Aufdeckung und Lösung von Netzwerk- / Server- / Applikations-Problemen. Ein entsprechendes System zur RNA bietet der Hersteller Network Instruments mit der GigaStor-Technologie. Die GigaStor ermöglicht mittels Zeitnavigation und per Drill-Down-Mausklicks die schnelle Ermittlung eines Fehlers und unterstützt durch ihre Langzeit-Datenerfassung eine proaktive Lösung von Problemen, insbesondere bei sporadischen Fehlerbildern.

Die GigaStor erfasst und speichert jedes übertragene Paket von geeigneten Messpunkten im Netz (vgl. Übersicht zu nTAPs und Matrix-Switch) und ermöglicht so ein einfaches „Zurückspulen“ der Datenkommunikation im Rahmen der Retrospektiven Netzwerk-Analyse (RNA) zur Ermittlung von Netz-, Applikations- oder Security-Problemen. Die RNA ist vergleichbar mit einer 24/7 Kameraüberwachung für das Netzwerk. Die RNA erlaubt ein „Zurückspulen“ in problematische Szenarien und zeigt auf, was vor, während und nach einer Netzwerk-Anomalie vorgefallen ist.

Die GigaStor-Technologie unterstützt Ethernet-Schnittstellen bis 40Gbps auf Basis einer eigenentwickelten Gen2-Erfassungskarte und ermöglicht eine Aufzeichnungskapazität von bis zu 576 TB. In Kombination mit der GigaStor-Zeitnavigation kann unmittelbar nach einer Problemmeldung mit der Fehler-Analyse begonnen werden. Eine zeitaufwändige Nachstellung von Problemen entfällt (vgl. auch Übersicht zur GigaStor).

In dem folgenden Beispiel wird exemplarisch beschrieben, wie mittels GigaStor und RNA innerhalb von nur neun Schritten eine typische Störung identifiziert und lokalisiert werden kann. Im folgenden Beispiel erhält der Netzwerk-Verantwortliche an einem Nachmittag die „schwammige“ Fehler-Meldung eines Users: „Meine Web-Anwendung ist seit ca. 12:30 Uhr langsam“. Das Unternehmen verfügt über das o.g. GigaStor Analyse-System von Network Instruments, welches die Netzwerkdaten an vorab definierten Messpunkten permanent aufzeichnet.


Da eine langsame Web-Anwendung gemeldet wurde, prüft der Netzwerk-Verantwortliche im ersten Schritt in der GigaStor-Weboberfläche die Performance der Applikationsprotokolle (u.a. FTP, SMTP, CIFS/SMB, HTTP). Das System zeigt für den Zeitbereich von 12:00 bis 13:00 Uhr eine rot markierte Anomalie im Übertragunsprotokoll HTTP (vgl. nachfolgende Abbildung zu Schritt-1).

Der Administrator möchte im zweiten Schritt die gezeigte Anomalie mit der Baseline vergleichen. Die GigaStor ermöglicht mittels Baselining einen Vergleich der aktuellen Werte mit den Werten der gespeicherten Ergebnisse aus der Vergangenheit (Tage / Wochen / Monate). Die Baseline dient hierbei zur Orientierung im Sinne von „Vergleich mit dem normalen Verhalten der Applikationen im Netz“. Der Drill-Down-Report „Application Response Time Baseline“ zeigt per Mausklick die Baseline (grün) sowie einen signifikanten Anstieg der HTTP-Antwortzeiten ab 12:00 Uhr (blau), welche deutlich über dem Baseline-Wert liegen (vgl. Abb. zu Schritt-2). Die gemeldete langsame Web-Anwendung ist demnach definitiv eine akute Störung im Netz- oder im Serverbereich.

Schritt-3 soll klären, ob die Ursache der Störung im Netz- oder im Serverbereich liegt. Hierzu vergleicht der Administrator die Verzögerungszeiten des Netzwerks (Network Delay) mit den Antwortzeiten der HTTP-Server (Server Response Time). Dies ermöglicht die GigaStor ebenfalls per Drill-Down-Report, welcher zu hohe Server-Antwortzeiten zeigt. Die HTTP-Applikation antwortet offenbar zu langsam. Ursache des Fehlers ist also nicht der Netzwerk-, sondern der Serverbereich. Die nachfolgende Abbildung zu Schritt-3 verdeutlicht dies. Der blaue Bereich zeigt die durchschnittliche Verzögerung durch das Netzwerk (Delay). Diese ist nahezu unverändert und unauffällig. Der grüne Bereich zeigt einen signifikanten Anstieg der HTTP-Server-Antwortzeiten. Die Ursache der Störung liegt also im Serverbereich. Mit ein paar weiteren Klicks geht man der Sache auf den Grund.

Die ersten drei Schritte haben gezeigt, dass der Fehler im Serverbereich liegt und es stellt sich die Frage, welcher Server genau langsam ist. Der Admin nutzt hierzu, ausgehend vom Report „Application Performance Summary” aus Schritt-1, den Drill-Down-Report „Application Servers by Response Time“, welcher einen auffälligen Server mit der IP „172.30.234.61“ anzeigt. Dieser Server beinhaltet das Web-Frontend der auffälligen Anwendung. Der Report zeigt eine durchschnittliche Server-Antwortzeit (Response Time Server Average, vgl. Abb. zu Schritt 4) von 2.685,182ms. Eine solche Antwortzeit, über zwei Sekunden, ist allerdings sehr hoch.

Nach der Identifizierung des problematischen Servers möchte der Administrator wissen, welche Clients von der Störung betroffen sind. Der Drill-Down-Report „Server/Client Connections by Performance“ zeigt ihm sämtliche Clients, die im gemeldeten Fehlerzeitraum mit dem Server kommuniziert haben. Der Report meldet nur einen betroffenen Client für den Zeitraum, welcher auch die Störung gemeldet hatte (IP „172.30.43.51“, vgl. Abbildung zu Schritt 5).

Die genaue Überprüfung der Kommunikations-Beziehung zwischen Webfrontend und Fileserver erfordert eine Detail-Analyse der aufgezeichneten Datenpakete (Traces). Hierzu grenzt man in der GigaStor-Oberfläche den zu untersuchenden Zeitbereich ein (vgl. Abb. zu Schritt-6, rot markierter Bereich) und wählt das gewünschte Kommunikations-Paar per Vorab-Filter aus (Datamining).

Der Verbindungsaufbau (TCP - Three-Way-Handshake) erfolgt normal. Das generelle Antwortzeit-Verhalten ist unauffällig (deutlich unter 1ms, vgl. Abbildung zu Schritt-7A). Auffällig dagegen sind CIFS-Anfragen seitens des Webfrontends mit negativer Beantwortung durch den Fileserver (Object Name not Found, Access Denied, vgl. Abbildung zu Schritt-7B).

Einen Überblick zu allen Anfragen / Antworten der CIFS-Kommandos gibt die Analyse-Metrik respektive Auswerte-Schablone „Application Transaction Analysis“ im Rahmen der integrierten Applikations-Analyse. Diese zeigt die Anzahl von CIFS-Anfragen und CIFS-Antworten (für den ausgewählten Zeitbereich) an den Fileserver. Einige dieser Anfragen werden mit den Status-Codes „Access_Denied“ (≡ Zugriff verweigert) und „Object_Name_Not_Found“ (≡ Objekt-Name nicht gefunden) quittiert (vgl. Abb. zu Schritt-8).

Was genau wird angefragt im CIFS-Dialog ?

Im Packet Decode ist im Detail zu erkennen, dass das Webfrontend sämtliche Archiv-Ordner für die Anwendung per CIFS abfragt. Einige Anfragen erfolgen dabei mit falschen Zugriffsrechten. Teilweise erfolgen die Anfragen mit Datei- oder Ordner-Namen, welche nicht (mehr) existieren (vgl. Abbildungen zu Schritt-9A und Schritt-9B). Das CIFS-Protokoll arbeitet normal, jedoch wird das Webfrontend aufgrund der vielen (unnötigen) Anfragen langsam. Eine Korrektur der Konfiguration sollte das Problem beheben.


Zusammenfassung

Heutzutage ist es allgemein nachvollziehbar, dass das Netzwerk und die Kommunikation darüber in Unternehmen und Organisationen stabil und ohne Störungen funktionieren muss. Zuviele unternehmenskritische Prozesse, Anwendungen und Kommunikationen sind davon abhängig. Ebenso ist es nachvollziehbar, dass Störungen de facto nicht komplett ausgeschlossen werden können, und dass Anomalien im Netzwerk durchaus empfindliche Kosten zur Folge haben. Dies gilt mittlerweile branchenunabhängig. Es empfiehlt sich, optimalerweise sowohl Werkzeug als auch eine Vorgehensweise zur Hand zu haben, um im Ernstfall schnell eine Lösung zu finden.

Neben einem modernen und belastbaren Netzwerk-Design (inkl. Redundanzen, no single point of failure, etc.) ist es empfehlenswert, auch strategische Messpunkte im Netzwerk zu definieren und vorzubereiten (z.B. per TAP), um so jederzeit den Datenstrom einsehen und mögliche Anomalien analysieren zu können. Optimalerweise wird eine Retrospektive Netzwerk-Analyse (RNA) ermöglicht, vergleichbar mit einer 24/7 Kameraüberwachung im Netz, welche ein „Zurückspulen“ der Datenkommunikation in kritische Szenarien unterstützt und in wenigen Schritten aufzeigt, was vor, während und nach einer Netz-Anomalie vorgefallen ist.

Die beschriebene GigaStor-Technologie ermöglicht die Retrospektive Netzwerk-Analyse und verkürzt mit wenigen Analyse-Schritten Fehlersuche, Ursachen-Ermittlung und Fehlerbehebung erheblich.