Aufgrund der Entwicklung hin zu größeren und schnelleren Netzen wurden nicht nur Milliarden für ein Redesign und neue Netzkomponenten ausgegeben. Den Marktforschern von IDC zufolge wuchsen 1996 auch die Investitionen für System- und Netzwerk-Management um 30 Prozent - Zugpferd waren Management-Plattformen mit einem Wachstum von 60 Prozent im US-Markt. Zwar fällt die Prognose für 1997 mit 46 Prozent etwas geringer aus, bis jedoch etablierte Plattformen auf SNMP-Basis in smarten Web-Browsern ernsthafte Konkurrenz bekommen, werden mit Sicherheit noch Jahre ins Land gehen.
Um eine maximale Tool- und Betriebseffizienz zu erreichen, muß ein Netzwerk- und System-Management-Konzept (NSM) mehrere Elemente enthalten können. Dazu gehören ein oder mehrere Netz- und System-Management-Lösungen, die über offene Schnittstellen-Kopplung (Object Request Broker) an eine zentrale Objekt- und Verbindungsdatenbank gekoppelt sind. Die erforderliche Anzahl läßt sich durch den Einsatz eines geschickt gewählten Plattformsystems, das selbst in mehreren Stufen skalierbar und somit den ersten Management-Erweiterungsstufen gewachsen ist, erheblich reduzieren. Technologieübergreifende und weiterverarbeitende Management-Funktionen wie Trouble-Ticket-System, User-Helpdesk oder Reportgenerierung werden in der Regel über Programmier-Interfaces (APIs) und separate Tools eingebunden, da Management-Plattformen schwerpunktmäßig für Überwachung, Fehlerdiagnose und Konfigurationstätigkeiten ausgelegt sind.
Die Verfügbarkeit verteilter Lösungen zum Management mittlerer bis großer Netze ist für die Netzwerk- und Management-Performance, für die effiziente Datenhaltung sowie aus organisatorischen Gründen wichtig: Mit steigendem Umfang der überwachten Komponenten und Parameter entsteht eine Netzlast, die von einem zentralen Management-System und an einem zentralen Netzknotenpunkt nicht mehr zu bewältigen ist. Daher ist die Aufteilung eines Netzes in Management-Domänen erforderlich, um notwendige Performance-Restriktionen einzuhalten.
Gleiches gilt für die Speicherung und Verarbeitung der einlaufenden Management-Daten: Ein einzelnes Unix-System ist als Datenbank-Server für alle Management-Informationen überfordert. Organisatorisch entsteht eine Betriebssituation, in der ein LAN-WAN-Verbund von einem zentralen Betreuungspunkt aus gesteuert wird und somit in den Außenstandorten wenig bis gar kein Know-how für den Betrieb komplexerer Management-Systeme vorhanden ist. Für alle genannten Aspekte ist die Verteilung der Management-Funktionalität auf eine Hierarchie von Verwaltungskomponenten erforderlich. Erfreulicherweise haben Hersteller etablierter Plattformsysteme dieser Anforderung in den letzten Jahren Rechnung getragen.
Die Ansätze zur Funktions- und Datenverteilung sind verschieden: Eine erste Stufe ist die Auslagerung der grafischen Darstellungsbearbeitung in "selbständige" Konsolen, teilweise Management-Clients genannt. Dies trennt die grafische Aufbereitung von der Bearbeitung einlaufender Polling-Antworten und Traps. Eine weitergehende Funktionstrennung erfolgt durch den Einsatz sogenannter Midlevel-Manager, teilselbständige Management-Komponenten, die Funktionen wie Polling oder Schwellwertüberwachung dezentral durchführen und die resultierenden Daten teilweise vorverarbeiten. Dadurch wird das zentrale Management-System hinsichtlich Prozessorleistung und Speicherkapazität entlastet. Die am weitesten gehende Funktionstrennung ist die Unterstützung gesteuerter Manager-Manager-Kommunikation und Synchronisation verteilter Management-Datenbestände. Dadurch lassen sich selbständige Management-Domänen mit beliebiger Management-Funktionalität frei definieren, übergreifende Informationen können jedoch bedarfsgerecht weitergeleitet werden und mehreren Management-Systemen zur Verfügung stehen. Das Aachener Unternehmen Comconsult Kommunikationstechnik hat die Systeme von Cabletron, Hewlett-Packard, IBM und Sunsoft hinsichtlich ihren Möglichkeiten zur Funktionsverteilung untersucht und in einem Technologiereport zusammengefaßt. Nachfolgend eine Zusammenfassung
Cabletron Spectrum
Enterprise Manager 4.0
Das Plattformsystem arbeitet mit einer mehrfach verteilten Architektur: Grafische Benutzeroberfläche und Management- beziehungsweise Datenbank-Server lassen sich via Client-Server-Konzept auf separaten Maschinen betreiben, darüber hinaus können mehrere Management-Server mit verteilten Datenbanken eingesetzt werden. Über vordefinierte und an das Netzwerk angepaßte Modelle wird das Gesamtnetzwerk abgebildet. Jeder Server stellt eine Virtual Network Machine (VNM) dar, die Management-Grundfunktionen wie Datenbank, Modellierungsfunktion, Elementzugriff oder Protokoll-Schnittstellen für den Zugriff auf verwaltete Ressourcen bereitstellt.
Ein Client ist eine NM-Applikation, die auf Server-Daten zugreift und diese über eine grafische Oberfläche (Spectrograf) darstellt. Hierdurch wird die Datenverarbeitung und grafische Verarbeitung auf verschiedene Maschinen verteilt (ähnlich dem GUI-Offload bei HP Openview). Verteilte Spectroserver (DSS) lassen sich so konfigurieren, daß das Gesamtnetz in Management-Domänen partitioniert wird (keine Überschneidung) oder daß überlappende Management-Teilnetze entstehen. Dadurch ergibt sich eine variable Konfigurierungsmöglichkeit der Server-Zuständigkeit für verschiedene Netzbereiche.
Der Management-Sektor eines Servers heißt Landscape. Zu beachten ist, daß alle Landscapes identische Modelle beinhalten müssen, sonst können Management-Inkonsistenzen auftreten (zum Beispiel bei Discovery und Korrelation). Eine verteilte Konfiguration mit einem Spectrograf und mehreren Spectroservern zeigt Abbildung 1. "Teilselbständigkeit" in Form von remote Polling oder Midlevel Managern ist nicht realisiert: Jeder Spectroserver arbeitet völlig selbständig.
HP Openview Network Node Manager 4.1 (NNM)
Der NNM verfolgt mehrere Verteilansätze. Neben der Möglichkeit, per X-Terminal oder X-Emulation auf die Konsole der Management-Station zuzugreifen, werden Management Consoles unterstützt, die lokale Openview-Maps verwalten. Gegenüber der X-Terminal-Lösung entfällt hier die Netzbelastung für die Übertragung der Grafikdaten (GUI-Offload). Seit NNM 4.1 lassen sich Collection Stations einsetzen, die die Discovery-Funktion, die Überwachung, Datensammlung und das Event-Handling für Teilnetze übernehmen. Die notwendigen Informationen legen sie in lokalen Datenbanken ab und melden Statusänderungen an eine übergeordnete zentrale Management-Station (siehe Abbildung 3). Auf diese Weise kann eine Management-Hierarchie aufgebaut werden, an deren Spitze die Informationen für das gesamte Netz zusammenfließen.
Im Gegensatz zu den Management Consoles wird hier eine echte Funktionsteilung realisiert und der Einsatz in größeren Netzen mit WAN-Verbindungen überhaupt erst praktikabel - ideale Voraussetzungen für ein Backup-Konzept und die Definition eines redundanten Management-Systems. Die Collection Stations überwachen das ihnen zugeteilte Netzsegment, wobei Redundanzen durch Überlappung von Bereichen möglich sind. Sie leiten Ereignismeldungen und Traps gefiltert oder ungefiltert an ihnen übergeordnete Manager-Stationen weiter. Über Peer-to-peer-Verbindungen können sie auch in die Datenbanken anderer Manager beziehungsweise Kollektoren gelangen. Dieser Informationsaustausch kann zeitlich gesteuert werden.
IBM TME 10 Netview
TME 10 Netview ist die funktionale Integration von "Netview for AIX 4.1" in die TME-10-Produktlinie und ersetzt das letztgenannte. Neben der Möglichkeit, per X-Terminal oder X-Emulation auf die Konsole der Management-Station zuzugreifen, lassen sich analog zu den Management Consoles von Openview Netview-Clients einsetzen. Die zentral durchgeführten Poll-Aktionen, die von zentralen Management-Station durchgeführt werden müssen, sind weiterhin auf das gesamte Netz ausgerichtet und erzeugen eine entsprechende Netzbelastung auch im WAN.
Eine weitergehende Funktionsverteilung ist durch den Einsatz von Midlevel-Managern (MLM) erreichbar. Diese sind auf eine bestimmte Management-Aufgabe optimiert und führen sie auf ihrem zuständigen Teilnetz durch. Ein Beispiel ist der Systems Monitor, der Netz- und System-Management-Aufgaben für seine Managed Nodes realisiert. Dazu gehören unter anderem die Statuskontrolle, die Schwellwertüberwachung, Event-Behandlung und die Autodiscovery-Funktionalität. Außerdem ist der Systems Monitor für verschiedene Betriebssysteme erhältlich und kann so zur Überwachung seiner eigenen Systemparameter wie Platten- und Speicherauslastung verwendet werden. Der Midlevel-Manager ist jedoch keine vollwertige Management-Station, die zum Beispiel beim Ausfall des zentralen Managers die Kontrolle des gesamten Netzes und die Administration des Netview-Systems übernehmen könnte. Insbesondere ist keine grafische Benutzeroberfläche für die MLM vorgesehen. Diese läßt sich jedoch durch einen Netview Client oder ein Web-Interface für MLMs zur Verfügung stellen.
Bei einem Einsatz mehrerer Netview-Manager unterstützt Netview ein Backup-Konzept, das eine Übernahme von Überwachungsregionen eines Managers durch einen oder mehrere andere Manager ermöglicht. Der zugeteilte Backup-Manager NV2 überprüft regelmäßig (Polling) die Management-Station NV1 (siehe Abbildung 4). Falls diese ausfällt, beginnt er automatisch mit der Überwachung ihres Management-Bereichs und trägt die gefundenen Knoten und ihre Topologieinformationen in seine Datenbank ein. Im Unterschied zu "Hot-standby"-Lösungen wie sie etwa Spectrum realisiert, wird kein permanenter Abgleich (Replikation) der beiden Daten- bestände durchgeführt, sondern erst nach dem Ausfall einer Ma- nagement-Station mit der Aufnahme der notwendigen Daten begonnen.
Sunsoft Solstice Domain - Manager 2.3
Innerhalb der Solstice Produktlinie sind der "Domain Manager" und "Cooperative Consoles" die empfohlenen Produkte für LAN-Management. Ein Integrationsansatz hinsichtlich des WAN- und Enterprise-Management-Produkts "Solstice Enterprise Manager" erfolgt über Cooperative Consoles, über die ein Domain-Manager-System Informationen an ein Enterprise-Manager-System (ab Version 2.0) weiterleitet. Die Kommunikationsmöglichkeiten zwischen Enterprise Manager, Domain Manager und "Site Manager" zeigt Abbildung 2.
Mehrere Domain-Manager-Systeme oder Domain Manager und die Einstiegsversion Site Manager können über die Cooperative Consoles Informationen miteinander austauschen. Mit Solstice sind daher zwei Verteilungs-Ansätze realisierbar: das frei konfigurierbare Weiterleiten von Informationen (Topologie und Events) über Cooperative Consoles sowie die Installation von Midlevel-Managern für Statusabfragen und Event-Vorverarbeitung (Site Manager, Domain Manager oder Proxy-Stationen). Wird der Enterprise Manager in ein Konzept eingebunden, so stellt er den "Manager of Managers" dar. Es lassen sich jedoch nur Events/ Traps weiterleiten, keine Topologieinformationen. Leider wird bei jedem konfigurierenden Zugriff auf Cooperative Consoles ein neuer CPU-belastender Prozeß (S/R-Prozeß) gestartet.
Der Console-Prozeß realisiert die Benutzer-Schnittstelle, über die die grafische Darstellung der Netzkarte und Netzstatistiken erfolgt und Kommandos eingegeben werden. Multiuser-Zugriff wird über X.11 und mehrere separate Console-Prozesse unterstützt. Jeder Console-Prozeß läuft über eine eigene Runtime-Datenbank, so daß verschiedene Anwender, die über unterschiedliche Console-Prozesse (X-Windows) arbeiten, nicht auf eine gemeinsame synchronisierte Datenbankumgebung zugreifen können. Der Console-Prozeß eines Users arbeitet wiederum mit benutzergebundenen Prozessen weiterer Tools.
Wird der Domain Manager aufgrund von Bedienfehlern nicht korrekt heruntergefahren, ist die Datenbank unter dem letzten Benutzernamen gesperrt. Die entsprechenden Prozesse müssen dann auf Systemebene manuell deaktiviert werden, um einen Neustart zu ermöglichen. Echte Multiuser-Unterstützung mit gleichzeitigem Zugriff auf konsistente Datenbestände ist derzeit nur mit dem Enterprise Manager möglich. Eine Funktionstrennung nach Grafikkonsole und Manager-System wie bei Cabletron, HP und IBM gibt es nicht.
Fazit: Von den untersuchten Systemen sind der Network Node Manager und Spectrum für sehr große Netze am besten geeignet, da hier zusätzlich zur Funktionsverteilung eine Datenverteilung stattfindet. Der Domain Manager zeigt deutliche Schwächen bei Mehrbenutzerfähigkeit und Datenhaltung, wenn es auch der Einsatz von Cooperative Consoles ermöglicht, mittlere, nicht zu heterogene Netze zu verwalten.
Angeklickt
Zur Verwaltung großer Netze, die sich auch über WANs erstrecken, sind verteilte Lösungen erforderlich. Zentrale Systeme wären aufgrund der zunehmenden Daten- und Verarbeitungslast überfordert. Zu den Ansätzen der Daten- und Funktionverteilung zählen die Trennung der grafischen Darstellung von der Berarbeitung einlaufernder Polling-Antworten und Traps, der Einsatz von Midlevel-Managern und die Definition von Management-Domänen. Nicht alle Plattformen genügen diesen Anforderungen.
*Diplominformatikerin Petra Borowka ist Gesellschafterin der Comconsult Kommunikationstechnik in Aachen und leitet dort den Bereich Engineering und Beratung