Genaue Analysen verhindern mögliche Fehlentscheidungen

Kommunikationsprobleme

Der Datentransfer zwischen Zürich und Bern wurde im Hinblick auf Zeitpunkt (Freitag 14 Uhr) und benötigte Bandbreite mit den Netzwerkern abgesprochen und geplant. Trotzdem tauchen neuerdings Freitagnachmittags Kommunikationsprobleme auf, weil der Vertrieb des Unternehmens freitags von 14 bis 16 Uhr seine Mitarbeiter per Business-TV schult. Die Schulung, die zudem in einer unnötig hohen Übertragungsqualität läuft, ist zwar mit den Applikations-Administratoren abgesprochen, jedoch nicht mit den Netzwerkern. Der geplante Datenbankabgleich und ein zum gleichen Zeitpunkt für den Netzwerker ungeplantes Business-TV führen zum einen zu einer Bandbreitenüberschreitung. Zum anderen entsteht eine Vielzahl weiterer Fehler – mit der Folge, dass in der Kommunikation eine grössere Verzögerung eintritt, die wiederum auch andere Dienste in Mitleidenschaft zieht. So treten beispielsweise Packet Drops auf: Bereits gesendete Pakete müssen komplett noch einmal verschickt werden. Dadurch wiederum vervielfacht sich die Bandbreite, die nötig ist, um ein einzelnes Paket zu transportieren.

Ursache unbekannt

Der Datenbank-Administrator, der den Datenbankabgleich zwischen Zürich und Bern mit drei Stunden geplant hat, muss jetzt mit sechs statt drei Stunden rechnen. Auch für die Endanwender verschlechtert sich die Kommunikation. Voice over Internet Protocol (VoIP) ist stark eingeschränkt, ebenso wie das Instant Messaging. Vom freitäglichen Bandbreitenproblem ist aber immer nur die Strecke Berlin-München betroffen. Es ist deswegen schwer herauszufinden, warum dieser Transfer so langsam ist. Weil diese Störungen aber regelmässig auftreten, überlegt das Unternehmen, eventuell einen neuen Vertrag mit seinem Service Provider abzuschliessen. Es weiss, dass am Ende der Woche zu wenig Bandbreite vorhanden ist, kennt aber nicht die Ursache des Problems.

Ohne Performance Management

Ein Netz-Administrator bekommt einen Anruf vom Help Desk, dass sich Anwender über das langsame Netzwerk beschwert haben. Er schaltet sich per Telnet auf einen Router, um die Bandbreitenauslastung abzufragen. Wie der Zufall es will, ist zu diesem Zeitpunkt die verfügbare Bandbreite punktuell wieder kurze Zeit angestiegen. Die Mitarbeiter haben sich über die schlechte Bild- und Tonqualität beschwert und der Fehler wird im Moment in der möglichen falschen Paket-Priorisierung gesucht. Es findet in diesem Augenblick keine Übertragung statt. Beim nächsten Router trifft der Netzwerker dann einen Peak (die Applikationsverantwortlichen führen einen Testlauf mit neuer Priorisierung durch) und sieht, dass die Auslastung bei 90 Prozent liegt. Er kann die Fehlerursache jedoch nicht lokalisieren. Mit Telnet erhält er immer nur einen Schnappschuss der Netzbelastung. Er bekommt keine grafische Auswertung, die ihm auf einen Blick zeigt, wie sich die Bandbreite über den Tag oder über eine Woche entwickelt hat.

Der Administrator schlägt deshalb vor, beim Service Provider mehr Bandbreite einzukaufen, um die Auslastungsspitzen abzufangen. Der Zukauf von Bandbreite würde die Kosten jedoch unnötig in die Höhe treiben, während bereits eine einfache zeitliche Entzerrung von Business-TV und Datenbanksynchronisation die Fehler beheben würde.

Mit Performance Management

Mit einem Tool für das Performance Management (beim vorliegenden Beispiel wird CA eHealth eingesetzt) würde der Administrator sehen, dass freitags um 14 Uhr die Bandbreitenauslastung für zwei Stunden von 10 Prozent auf 90 Prozent steigt. Zudem zeigt ihm die Lösung an, dass eine um 14 Uhr geplante Datenbanksynchronisation läuft. Er erhält auch Informationen über bereits vergangene ähnliche Ereignisse, beispielsweise ob die Datenbanksynchronisation immer die gleiche Zeit benötigt, ob immer die gleiche Datenmenge transferiert wird und immer die gleiche Bandbreite zur Verfügung steht. Der Netzwerk-Administrator überprüft regelmässig über Kapazitätsplanungsreports den zukünftigen Bandbreitenbedarf.

Im hier genannten Beispiel bekommt der Netzwerk-Administrator automatisch einen Hinweis, dass erstens auf einem Serverinterface und zweitens auf dem Link Zürich – Bern eine zu diesem Zeitpunkt abnormal hohe Bandbreite genutzt wird. Damit ist es möglich, den Verursacher direkt nach dem Erscheinen zu lokalisieren. Diese Informationen (hier: abnormales Verhalten auf dem Server Port und Link Zürich – Bern im Abschnitt xyz) leitet das Tool dann automatisch an CA Spectrum zur RootCause-Analyse weiter. Spectrum ermittelt den Fehler und zeigt diesen in einer topologischen Darstellung an. Spectrum verbindet dabei alle Fehlermeldungen mit dem ursächlichen Problem. Die Lösung informiert darüber, dass Bandbreitenprobleme, «packet losts», «packet collisions» und Probleme mit DNS und DHCP auf eine Ursache zurückgehen und nur auf dem Link Zürich – Bern auftreten.

Ohne Toolunterstützung würde Fehlermeldung über Fehlermeldung auf dem Bildschirm des Netz-Administrators einlaufen. Spectrum dagegen fasst diese Meldungen automatisch zusammen und stellt sie grafisch dar. Der Administrator erkennt, dass die vielen Fehlermeldungen nur eine Fehlerursache haben, an deren Behebung er dann konkret und vom Tool unterstützt arbeiten kann.

Konkrete Vorschläge

Mithilfe der gewonnenen Informationen kann er verschiedene Massnahmen zur Fehlerbehebung vorschlagen:

• Der Administrator sieht, dass freitags um 14 Uhr regelmässig ein neuer, ungeplanter Datentransfer gestartet wird. Er erkennt, von welchem Server der Transfer ausgeht, und kann den verantwortlichen Server-Administrator gezielt ansprechen.
• Er schlägt vor, entweder Business-TV oder Datenbanktransfer nach Absprache mit den Prozess-Verantwortlichen auf einen anderen Zeitpunkt zu setzen.
• Er empfiehlt eine engere Synchronisation zwischen Server- und Netz-Administratoren: Server-Administratoren sollten gravierende Änderungen des Netzwerkverkehrs schon im Vorfeld per Change Request ankündigen. Kunden, die grosse Datenmengen übertragen wollen, wenden sich an einen Netzwerker, der ihnen dann einen Zeit­slot für den Transfer nennt.