Neue Wege in der Netzwerk-Diagnose

Mit der zunehmenden Komplexitaet der Netzwerke wachsen auch die Anforderungen bei der Wartung und Pflege der Installation. Die Diagnose auftretender Probleme setzt auf neue Methoden und Programme, die den Systemverwalter zum "Netz-Supermann" befoerdern.

Von Detlef Borchers

Die Diagnose und die Behebung von Fehlern in Netzwerken ist fuer das Gros der Benutzer eine Mischung aus schwarzer Magie und simplen Tricks. Fuer die Netzverwalter mit ihren Kabelscannern, Protokolldecodern, Inventurprogrammen und Datenbanken sieht die Sache natuerlich ganz anders aus: Sie ist eine Mischung aus schwarzer Magie und simplen Tricks. Dennoch tauchen mehr und mehr Programme auf, die selbst ein bisschen Zauberei betreiben und mit zeitgemaessen Oberflaechen alte Tools ersetzen, deren Arbeit und Ausgaben selbst erst einmal dekodiert werden mussten.

Bei diesen neuen Programmen kuemmern sich die Entwickler nicht nur um die Darstellung der moeglichen Problemdaten, sondern sie integrieren Datenbanken, KI-Module oder sonstige regelorientierte Verfahren, um dem Netzwerkadministrator zu helfen. Denn sein Aufgabenbereich dehnt sich zunehmend aus, womit der richtige Ueberblick ueber das Netz, ueber Router, Drucker und Workstations, ueber all die Protokolle, die jetzt in den Netzen gefahren werden, immer schwieriger wird. Der alleinige Hinweis auf die zunehmende Standardisierung durch Management-Programme, die auf SNMP aufsetzen, ist dabei allzu billig. Gerade in PC-Netzen ist das SNMP-Management eher randstaendig und kaempft zudem mit weissen Flecken auf der Netzwerk-Landkarte, die gerade erst gefuellt werden.

So ist die einheitliche Druckerwartung via SNMP nach etlichen Anlaeufen erst auf der Fruehjahr-Comdex in Atlanta von Hewlett- Packard, Microsoft, Novell und IBM festgeschrieben worden. Gegenueber diesen langatmigen Definitionsprozeduren greifen neue Trends eher aktuelle Probleme auf; sie moegen auf einer hoeheren Ebene spaeter einmal vereinheitlich werden, bieten aber schon jetzt fuer viele Situationen dem Netzwerwalter echte Hilfen an.

Der neue Trend erfasst ganz unterschiedliche Diagnosehilfen und beginnt bereits bei den Kabelscannern und TDR-Pruefern (Time Domain Reflectometer zur Pruefung von Kabelfehlern) wie dem "Lanscat" der kanadischen Firma Digicom, dessen Bedienung ueber eine Drehscheibe aehnlich wie bei den Voltmetern erfolgt und der seine Ergebnisse nicht allein auf dem Mini-Display zeigt, sondern zum Download in ein Windows-Programm speichert. Dieses Programm wiederum enthaelt eine Reihe von Situationsbeschreibungen und Grenzwerten, aus denen der Administrator seine Schluesse ziehen kann.

Deutlich wird der Trend bei der neuesten Version des "Lanalyzer 2.0" von Novell. Waehrend Novell die grosse Version des Lanalyzer verkaufte und sich ein weiteres Stueck aus der Hardware-Produktion zurueckzog, wurde die Software-Variante erheblich verbessert. Sie enthaelt nicht nur eine Oberflaeche im Stil eines Armaturenbretts, sondern erstellt Statistiken ueber Fehlerzustaende sowie Alarme und gibt vor allem Hinweise ueber die Ursache der aufgetretenen Stoerungen oder Bedrohungen. Neben der eigentlichen Aufgabe eines Decoders - dem Mitschneiden der Datenkommunikation und der Entschluesselung der Protokolle - wird damit beim Lanalyzer eine Ebene eingezogen, auf der auch der weniger kundige Administrator mit der Software umgehen kann. Entweder helfen ihm die Hinweise des Lanalyzer auf die Spruenge oder er kann durch Anleitung des Programms einen Mitschnitt erstellen, der im Netz zum "grossen" Lanalyzer, aber auch per Modem zum Support des Haendlers geschickt werden kann.

Neu ist auch der paedagogische Ansatz: Das Programm gibt sich alle Muehe, mit einem Lernprogramm, einem einfuehrenden Video und weiterfuehrender Fachliteratur die Technik der Protokollanalyse dem Laien zu erklaeren. Dank dieser Komponenten eignet sich der Lanalyzer hervorragend zum Einsatz von "Teilzeitadministratoren" in Teilnetzen, die der zentralen Netzverwaltung ein gutes Stueck Arbeit abnehmen. Diese Ausrichtung wird deutlich, wenn man sieht, welche Komponenten im Lanalyzer fehlen: die Benchmarks zur Bestimmung der Nutzlastgrenzen im Netzwerk, die der grosse Lanalyzer, der "Sniffer" oder der "Spider2 bieten. Sie sind nach Novell offenbar nicht fuer den laienhaften Einsatz gedacht.

Insgesamt schlaegt der Lanalyzer damit einen Weg ein, wie ihn der Sniffer mit dem Expert Sniffer und vor allem Hewlett-Packard mit "Openview" vorgedacht haben. Der grosse Unterschied zu diesen Profitools besteht in der moeglichen Bedienung durch Laien. Technisch gesprochen wird so in der Netzwerkverwaltung eine Zwischenschicht eingezogen, in der "Unterverwalter" als intelligente Hilfsmittel bei der Problemdiagnose eingesetzt werden. Dem Vorteil dieser Methode steht zumindest beim Lanalyzer der Nachteil gegenueber, trotz der Unterstuetzung von vielfaeltigen Protokollen (IPX, Appletalk und TCP/IPmit den Informationen allein auf Novell-Umgebungen zentriert zu sein - Sun-Server werden beispielsweise ueberhaupt nicht erkannt.

Aehnlich wie der Lanalyzer operiert die neue Klasse der anwendungsorientierten Diagnoseprogramme, die sogenannte Agents als Zwischenschicht einsetzen. Die Agents sitzen dabei in den Workstations der Benutzer und schneiden gewissermassen den Nachrichtenverkehr zwischen den drei Grundkomponenten Anwendungssoftware, Betriebssystem und Netzwerk-Betriebssystem mit. Das israelische "Alertview" von Shany ist die bislang ueberzeugendste Realisierung dieser interessanten Gattung. Der Alertview-Agent sendet seine Warnungen an einen Ereignismonitor auf dem Fileserver, der sie nicht nur in eine Logdatei eintraegt, sondern ueber ein ganzes Arsenal an Triggern laufen laesst, die mitunter auch automatische Fehlerkorrekturen veranlassen koennen. Tritt beispielsweise ein Fehler beim Drucken einer Datei auf, so sammelt Alertview neben den lokalen Informationen auch die Statusmeldungen der Netzdrucker ein, um dem Administrator ein vollstaendiges Bild der Lage zu geben.

Damit schlaegt Alertview einen Mittelweg zwischen den kargen Meldungen der Netware und den ueppigen Hinweisen von druckerspezifischen Programmen wie HPs "Jetadmin" ein, die ueber die Soundkarte fortlaufend ausplappern, was mit den Druckern los ist. Verlangt eine Anwendung eine groessere Zahl geoeffneter Dateien als in der Config.sys-Datei definiert, so ist Alertview in der Lage, nach der Dateisicherung die Files-Angabe selbststaendig zu erhoehen und danach die Workstation neu zu starten. In diesem Fall sendet der Verwalter eine Nachricht an den Benutzer, in dem der Vorgang erklaert wird, damit keine Panik auftritt. Die automatischen Prozeduren decken dabei nach Angaben von Shany mehr als 50 Prozent der haeufigen Problemfaelle ab, die vom Programm unbeaufsichtigt behoben werden koennen - die Zeit moeglicher Netzausfaelle soll somit drastisch reduziert werden.

Fuer den Netzwerkverwalter stellt das Managermodul von Alertview noch weitere Hilfsmittel bereit. So gibt es eine Benutzer- Datenbank, in der alle aufgetretenen Problemfaelle samt Loesungsvorschlaegen oder tatsaechlichen Loesungswegen gespeichert werden. Wiederholt auftretende Probleme mit Programmen wie Dbase oder Excel finden hier ihren Niederschlag, da hier Fehlermeldungen aehnlich der kleinen Fehlerdatei der Norton Utilities gespeichert sind. Mit der Zeit kann der Adminstrator eine Wissensbasis aufbauen, in der auch die Rettungsprozeduren verzeichnet sind, die getriggert werden koennen.

Der grosse Unterschied von Alertview liegt indes beim Workstation- Agenten, der bislang fuer DOS, Windows und OS/2 als Zwischenschicht verfuegbar ist. Das Abfangen der Fehlermeldungen ist wesentlich effektiver als die Arbeit mit Remote-Control-Programmen, ueber die sich der Verwalter den Bildschirm des Benutzers auf die eigene Console holt, um dann erst mitzuverfolgen, wie das Problem entsteht. Der groesste Nachteil von Produkten wie Alertview ruehrt in der prinzipiellen Unmoeglichkeit, fuer alle Fehler gleich die Loesungen parat zu haben.

Speziell bei Alertview ist durch die Entwicklungsgeschichte des Programmpakets ein weiterer Nachteil gegeben: Das Programm wurde urspruenglich allein fuer IBMs LAN Server und fuer Token-Ring- Topologien entwickelt und enthaelt verhaeltnismaessig wenige Informationen zu Netware. Dies mag der kundige Netzverwalter selbst aendern, der auf der Protokollseite Hilfestellungen fuer IPX- , Netbios und HDLC/SDLC-Meldungen angeboten bekommt.

Die naechste Stufe der neuen Diagnosemoeglichkeiten liegt im Vergleich zum Lanalyzer oder Alertview noch in den ersten Zuegen: Die einheitliche Sammlung und Auswertung aller Fehler aller Netzwerksegmente sowie der Zugriff aller Benutzer auf diese Bestaende befindet sich erst am Anfang der Entwicklung. Am Ziel steht ein System, in dem in heterogenen Netzwerken alle Benutzer ungeachtet des/der Betriebssystems(e) der verschiedenen Server Hilfe bei Problemfaellen abrufen koennen. Zur Entlastung der Verwalter sollen diese ihre Erfahrungen und Hinweise selbst in die universale Hilfsdatenbank einbringen koennen.

Das wichtigste Werzeug zur universalen und bruederlichen Hilfe ist die Einrichtung eines systemuebergreifenden "Hilfefonds", der von allen Plattformen aus erreichbar ist. SGML, die "Structured Markup Language" der DTP-Spezialisten feiert hier in einer gaenzlich anderen Umgebung ihr Debuet. Mit SGML strukturierte Hilfen koennen ueber einen SGML-Leser von jeder Plattform aus erreicht werden - die Hilfe, von einem PC unter Windows aufgerufen, unterscheidet sich nicht von der Hilfe, die eine Sun-Workstation unter Solaris bekommt. Wichtiger noch: Zu den haeufiger auftretenden Problemen in der Firma koennen die Netzwerkverwalter ihre eigenen Datenbanken oder Texte als SGML-Dateien formatieren und allgemein zur Verfuegung stellen.

Fuer solche Zwecke bieten bereits die Textverarbeiter wie Wordperfect mit Intelli/Tags die noetigen Konverter an. Auch bei den gemeinhin benutzten CD-ROM-Datenbanken zeichnet sich die Unterstuetzung dieser Methoden ab, wenngleich sie erst voll zum Zuge kommen koennen, wenn alle Soft- und Hardware-Firmen ihre internen Support-Datenbanken ebenfalls ueber SGML aufbereiten. Derzeit ist dies eher die Ausnahme: Ein Netzwerkverwalter, der einen Teil des Anwendungssupports ueber CD-ROMs wie "Support on Site" von Computer Library oder "CD-Help" von EZ-Technologies abwickelt, muesste heute noch selbst die noetige SGML-Konvertierung vornehmen. Hat er diese Umstellung dann hinter sich, so duerfte der Vorwurf der Ueberfuetterung mit Informationen seitens der Benutzer nicht lange auf sich warten lassen. Schliesslich sind sie es, die mit ihrem Unwillen und Unvermoegen, einmal genauer die Handbuecher zu studieren, das Gros der Fehler produzieren, die muehsamm diagnostiziert werden wollen.

Vor diesem Hintergrund ist es sicherlich verstaendlich, dass viele Netzwerkverwalter das beruechtigte "RTFM" in die diversen Screen- Saver der Anwender einblenden und dies noch als letzten Schrei der Netzwerk-Diagnose betrachten. (RTFM ; Read The Fucking Manual)