Von: Dr. Klaus Plessner
Ein Problem kommt nie allein. Jedenfalls nicht in einem Computernetz, das Tausende Geräte enthält, die nach verschiedenen Übertragungsstandards kommunizieren, auf verschiedenen Betriebssystemen beruhen und Hunderten von Anwendungen als Plattform dienen. Fällt eine der zahlreichen Komponenten eines Netzwerks aus, egal ob Hard- oder Software, zieht sie eine Reihe von Störungen nach sich. Der Netzadministrator erhält dann auf seiner Überwachungskonsole nicht nur eine Meldung, sondern eine Flut von Hinweisen. Was ihn aber vor allem interessiert, ist der Auslöser der Kette von Problemen, die Ursache oder auf englisch "Root Cause".
Fast alle Hersteller von Programmen für das Netzmanagement bieten Lösungen für die Root-Cause-Analyse: sowohl die Framework-Produzenten BMC Software, Computer Associates, Hewlett-Packard und IBM Tivoli als auch Anbieter von Speziallösungen. Die Firmen Aprisma, Micromuse, Riversoft und Smarts widmen sich hauptsächlich der Fehlersuche in Unternehmens- und Providernetzen und haben Software entwickelt, die die Aufgabe weitgehend automatisch erledigt.
Kontrolle auf allen Ebenen
Die Root Cause kann verschiedene Ebenen eines Netzes betreffen. Fehler der "Layer 2" liegen an einem defekten Switch oder einem ausgefallenen Port. Probleme der dritten und vierten Netzwerkschicht treten auf, wenn eine TCP/IP-Verbindung nicht zustande kommt oder wenn die Performance einer Übertragung einbricht und einen definierten Grenzwert unterschreitet. Schließlich können auch Server und darauf installierte Programme durch Störungen beeinträchtigt werden. In der Sprache des OSI-Netzmodells (Open System Interconnection) verbirgt sich die Ursache dann auf einer der Anwendungsebenen, die mit 5, 6 und 7 nummeriert sind.
Um die erste Ursache zu finden, muss die Netzmanagementsoft-ware Fehlermeldungen aus verschiedenen Quellen zueinander in Beziehung setzen. Einer der wichtigsten Lieferanten von Informationen sind SNMP-Agenten (Simple Network Management Protocol). Diese schicken im Fehlerfall eine "Trap Message", zu deutsch Ereignismeldung an das Managementprogramm. Einige Hersteller haben ihre eigenen "Agenten" entwickelt, die den Server bei Problemen verständigen, zum Beispiel BMC Software, Computer Associ-ates, Micromuse und Riversoft. Firmen wie Aprisma, Hewlett-Pa-ckard und Smarts haben sich da-rauf spezialisiert, neben den Standardquellen wie SNMP und "Remote Monitoring" möglichst viele Netzproben anderer Anbieter auszuwerten.
Was die Verfahren anbelangt, nach denen die Managementplattformen Ereignisse zueinander in Beziehung setzen, unterscheidet man zwei Ansätze:
- Herkömmliche regelgestützte Methoden kombinieren die Events nach den Vorgaben des Anwenders oder des Herstellers. In vielen Fällen lassen verletzte Service-Level-Bestimmungen und Angaben über die Performance auf ein überlastetes Netz schließen, falls keine Übertragungsfehler auftauchen. Die Regeln enthalten logische Verknüpfungen wie "Und", "Oder" und "Nicht".
- Modellgestützte Techniken funktionieren objektorientiert. Sie beziehen die Ereignisse auf ein internes Modell, das die Topologie oder den Aufbau eines Netzes widerspiegelt. Auch hier gibt es Regeln. Allerdings sind diese vom Aufbau des Netzes unabhängig, weil sie sich auf Klassen von Geräten beziehen. Während das Modell von einem Discovery-Mechanismus selbstständig konstruiert wird, legt die Software für jede Netzkomponente ein Objekt aus einer entsprechenden Klasse an. Das Modell repräsentiert sowohl die geografischen Zusammenhänge eines Netzes in Form von physikalischen Verbindungen zwischen Geräten, als auch logische Beziehungen von virtuellen VLAN-Segmenten oder Anwendungen.
Regelgestützte Verfahren sind mit ihrem einfachen Konzept leicht zu verstehen. Davon abgesehen haben sie aber viele Nachteile. Erstens wächst die Zahl der Regeln mit der Menge der Geräte und Anwendungen im Netz sehr schnell. Die Fülle der Bestimmungen wird unübersichtlich und das Bearbeiten der Rules schluckt Rechenzeit. Zweitens erfordert jede Erweiterung des Inventars das Anpassen und Neuformulieren von Regeln. Drittens hängt die Qualität der Ursachen-analyse von den Vorgaben des Anwenders ab.
Nach Regeln oder Modellen
Demgegenüber haben die modellgestützten Techniken viele Vorteile. Sie "skalieren", was bedeutet, dass die zum Bearbeiten der Regeln benötigte CPU-Zeit mit der Größe des Netzes vergleichsweise langsam zunimmt. Weil die Analyse unmittelbar auf einem automatisch angelegten Modell beruht, entfällt das aufwändige Rule-Management. Neue Geräte und Anwendungen benötigen keine Regelkorrekturen. Außerdem erhält der Benutzer aufgrund des Modells einen guten Überblick über die Netzstruktur. Physikalische, logische und serviceorientierte "Views" stellen die Fehler auf übersichtlichen Karten dar.
Die Güte der Vorhersagen eines modellgestützten Tools hängt nicht vom Anwender sondern von der "Correlation Engine" ab. Das bedeutet aber auch einen Nachteil. Der Benutzer hat keine Möglichkeit, auf das Verfahren einzuwirken und die Analyse durch eigene Erfahrungen zu verfeinern. Hier gehen Computer Associates und Riversoft einen Schritt weiter und kombinieren die Modellanalyse mit einer vom Anwender gepflegten Regelbasis.
Welches Verfahren der Root-Cause-Analyse das beste ist, lässt sich nicht beurteilen, solange die Hersteller keine Details zu den Techniken preisgeben. Das ändert sich erst, wenn eine der Methoden zum "offenen Standard" gekürt wird.