Allerdings sollten die neuen Ansätze, wie die CW- Schwesterpublikation "Network World" warnt, weniger als komplette Plug-and-play-Lösungen, sondern vielmehr als Tools angesehen werden, die es dem Netzspezialisten erlauben, einen relativ genauen Überblick über die Vorgänge im Netz zu bekommen. Ein mehrmonatiger Anpassungsprozeß ist jedoch einzukalkulieren, bis die Vorteile einer Distributed-Management-Plattform in der Praxis nutzbar sind.
Ein grundsätzlicher Vorteil gegenüber dem zentralisierten Management ist die Skalierbarkeit. Diese hat Auswirkungen auf mehrere Bereiche: So reduziert sie beispielsweise die benötigte Bandbreite für den Verwaltungsverkehr. Allerdings setzt dies ein entsprechendes Fein-Tuning voraus, damit der Großteil des Verkehrs wirklich im LAN bleibt und nur die unbedingt notwendigen Nachrichten über das WAN-Backbone transportiert werden. Beim zentralisierten Management fließt dagegen der gesamte Verkehr über das komplette Netz.
Ein weiterer Unterschied besteht in der Behandlung der gewonnenen Verwaltungsdaten. Während beim zentralen Management alle Daten auf einem Rechner gespeichert sind und dort möglicherweise zu Engpässen führen, kann der Anwender in einer verteilten Umgebung die Daten auf verschiedenen Stationen speichern und so mögliche Flaschenhälse der Maschinen hinsichtlich Speicherausbau und Rechnerleistung umgehen.
Besonderes Augenmerk sollte auch der Art der Management-Daten geschenkt werden: Welche Informationen sind wirklich notwendig? Ein größeres US-Unternehmen stellte beispielsweise bei der Untersuchung des eigenen Netz-Managements fest, daß der im globalen Backbone generierte Verkehr von über zwanzig verschiedenen Verwaltungsprotokollen stammte, die zum Teil zur Administration des Netzes gar nicht mehr genutzt wurden. Eine andere Stolperfalle verbirgt sich hinter dem weitverbreiteten SNMP-Protokoll (siehe Lexiko- thek auf Seite 24). Bis vor kurzem gehörte es bei den Herstellern von SNMP-fähigen Netzgeräten nämlich zum guten Ton, diese mit eingeschalteter Trap-Funktion auszuliefern. Beim Erreichen gewisser vordefinierter Zustände sendeten die Devices Messages an die Management-Konsole, unabhängig davon, ob sie dort auch wirklich verarbeitet wurden.
Eine andere Gefahr, Bandbreite zu verschwenden, bergen in verteilten Management-Umgebungen doppelt ausgeführte Verwaltungsaufgaben.
An der Frage, welche Daten die wichtigsten sind, scheiden sich die Geister. Während die einen Trap-Messages bevorzugen, schwören andere auf eine Polling-basierte Administration. Hierbei sendet die Management-Station in voreinstellbaren Zeitabständen Anfragen an die verwalteten Geräte. Aufgrund des bidirektionalen Verkehrs benötigt dieses Verfahren zwar mehr Bandbreite, bietet aber den Vorteil, daß der Systemverwalter auch über den Totalausfall eines Gerätes informiert wird. Ein Service, den die Trap-Methode nicht bietet.
Um in verteilten Architekturen das Bandbreitenproblem in den Griff zu bekommen, bietet sich ein weiteres Verfahren an: Management- Stationen werden möglichst nahe an den Devices installiert, die den meisten Verkehr erzeugen. Auf diese Weise soll das Datenaufkommen auf das lokale Netz beschränkt bleiben. An die zentrale Management-Station werden dann nur die gesammelten Daten geschickt, die für eine Trendanalyse erforderlich sind.
Die Positionierung von Daten-Repositories wirkt sich ebenfalls auf die Leistung des Management-Systems aus. Je nach verwendeter Plattform können die Daten der Polling-Aktionen unterschiedlich gespeichert werden. Eine einfache Faustregel besagt, daß dies möglichst nahe bei den Anwendern, die die Daten benötigen, geschehen sollte. Zudem hat sich gezeigt, daß eine einzige Datenbank, die alle Netzdaten enthält, schnell zu Performance- Problemen führt. In der Praxis hat es sich deshalb bewährt, die Daten verteilt im Netz zu speichern und nur bei Bedarf die zentrale Datenbank upzudaten, wenn neuere Daten für eine Analyse benötigt werden.
Management-Plattformen
Die vier wichtigsten Hersteller in Sachen Distributed-Management- Plattformen sind IBM, HP, Sunsoft und Cabletron. Nach den Erfahrungen der CW-Schwester- publikation "Network World" eignen sich die Produkte von IBM und HP besonders gut für das Monitoring großer Netze in Echtzeit. Am einfachsten zu installieren war dagegen die Sunsoft-Plattform.
Cabletron
Cabletron trennt die Funktionen der "Spectrum"-Plattform in zwei Teile. Der Client "Spectrograph" umfaßt die Anzeigekonsole sowie die Konsolenformulare. Der "Spectroserver" dagegen verwaltet die Datenbank und ist für die Polling- und Trapping-Abläufe zuständig. Dahinter steckt die Idee, daß die Konsolen sich nur mit den Servern unterhalten. Diese sammeln wiederum die Daten der verwalteten Geräte. Allerdings zeigte sich in der Praxis laut "Network World" das Problem, daß weder die Datenbanken verschiedener Server miteinander verschmolzen werden konnten, noch eine Synchronisation über ein Message-basiertes Update zu realisieren war. Ein weiterer Nachteil des Systems ist die modellorientierte Struktur. Der Anwender muß nämlich alle Eigenschaften eines Gerätes selbst eingeben, bevor Spectrum das neue Device im Netz erkennt.
Hewlett-Packard
Mit der aktuellen Version des "Openview Network Node Manager" hat auch bei HP die verteilte Netzverwaltung Einzug gehalten. Verteilte Stationen sammeln die Daten der zugeordneten Netzdomänen und reichen diese an eine zentrale Management-Station weiter. Zudem können die Informationen der lokalen Rechner vor Ort in eine zentrale Datenbank integriert werden. Danach senden die Stationen nur noch dann Nachrichten an die Zentrale, wenn sich etwas an den verwalteten Geräten ändert. Was auf den ersten Blick vorteilhaft aussieht, hat in der Praxis aber einen Nachteil: Der schonende Umgang mit der Netzbandbreite funktioniert nur so lange, wie das Netz passiv überwacht wird. Sobald der User das Netz aktiv kontrolliert, überträgt die HP-Lösung genausoviel Daten wie andere Systeme. Ein anderes Feature, das den amerikanischen Kollegen positiv auffiel, ist, daß dem gleichen Node im Netz zwei verschiedene Namen zugewiesen werden können: einer für die zentrale Konsole und einer für die Management-Station vor Ort.
IBMs Ansatz bietet eine gut durchdachte, flexible und effektive Lösung, wobei der Anwender allerdings über eine RS/6000 und IBMs Unix verfügen muß, da das System nur auf dieser Plattform läuft. Big Blues Architektur basiert auf dem Softwarepaket "Systems Monitor Mid-Level Manager 2.3" (MLM). Im Gegensatz zu den anderen Systemen kann der MLM remote installiert werden. Auch wenn der Produktname suggeriert, daß es der Anwender hier mit einer eigenständigen Applikation zu tun hat, ist MLM auf die Netview- Datenbank angewiesen. Primäre Aufgabe des Managers ist es, das System von Aufgaben wie dem Status-Polling zu entlasten. Mit nur einer zentralen Datenbank unterscheidet sich die IBM-Lösung von den drei Wettbewerbern. Um die Sicherheit zu erhöhen, läßt sich die Datenbank allerdings auf einem Netview Node spiegeln.
Sunsoft
Sunsoft schickt als Distributed-Management-Plattform den "Solstice Domain Manager" ins Rennen, der nun in der Version 2.3 über eine entsprechende Funktionalität verfügt. Nachdem zwei oder mehr Domain Manager die Netztopologie oder Teile davon untersucht haben, können die Datenbanken der Stationen miteinander verbunden werden. Eine Methode, die Sun als "Cooperative Consoles" bezeichnet. Auf diese Weise kann ein Domain Manager seine Datenbank mit einer anderen synchronisieren. Allerdings hat das kooperative Verfahren einen Nachteil: Entdecken zwei Manager den gleichen Node, so fügen sie ihn beide ihrer Datenbank hinzu und fragen ihn ab. Um dies zu verhindern, muß der Anwender das Netzgerät selbst aus einer der Datenbanken entfernen. Verglichen mit dem HP-Ansatz, läßt sich Suns Architektur leichter verwalten, und Netzdaten sind einfacher zu sharen als mit Openview. Ein unangenehme Überraschung erwartet den Netzadministrator aber in Sachen Benutzeroberfläche. Statt des Motif-Standards verwendet Sun das hauseigene proprietäre Openlook/Openwindows.
Alle vier Produkte haben ihre Ecken und Kanten, an denen die Hersteller noch feilen müssen. Gemessen an den anderen beschriebenen Plattformen, bietet aber Cabletrons Spectrum nicht den gleichen Grad an Skalierbarkeit. Allerdings scheint hier mit dem "Enterprise Alarm View" Abhilfe in Sicht.