Nach wie vor bereitet das vernünftige Aufsetzen von Netzwerk- und System-Management-Konzepten sowie das Doing im Betrieb Kopfzerbrechen. Das gilt auch, obwohl gewisse Kreise etablierter Hersteller derzeit auf einer Management-Wolke schweben und die Kunden glauben machen wollen, daß Netzwerk-Management heute völlig beherrschbar sei.
Um eine maximale Tool- und Betriebseffizienz zu erreichen, muß ein NSM-Konzept mehrere Elemente enthalten: Dazu gehören ein oder mehrere NSM-Systeme, die über offene Schnittstellen (Object Request Broker) an eine zentrale Objekt- und Verbindungsdatenbank gekoppelt sind. Die erforderliche Anzahl dieser Systeme ist durch den Einsatz eines geschickt gewählten Plattformsystems erheblich zu reduzieren. Die Objektdatenbank kann auf einem zentralen DB-System oder verteilt gehalten werden, die Informationen sind jedoch immer über verteilte Agenten einzuspeisen. Technologieübergreifende und weiterverarbeitende Management-Funktionen wie Trouble-Ticket-Systeme (TTS), User-Helpdesk (UHD), Report-Generierung etc. werden über Interfaces (APIs) und separate Tools integriert, da Management-Plattformen im Schwerpunkt für aktuell erforderliche Überwachung, Fehlerdiagnose und Konfigurationstätigkeiten ausgelegt sind.
Wer die nicht unerhebliche Investition in ein NSM-Plattformsystem plant, muß sowohl über Maschinenausstattung und Funktionsumfang (direkte Investkosten) als auch über die Bedienbarkeit und mittelfristige Betreibbarkeit eines solchen Systems nachdenken, um einen Überblick über die Folgekosten zu bekommen. Wesentliche Aspekte sind dabei unterstützte Hardware und Grundfunktionen, Design und Ergonomie der Benutzeroberfläche, Darstellung hinsichtlich Netzwerk und verwalteter Objekte sowie die zentralen Funktionsbereiche Konfigurations-, Fehler- und Performance-Management.
Ab einer Größe von mehreren hundert Netzknoten läßt sich ein angemessen dimensioniertes Management-Werkzeug im Regelfall nur bei Einsatz einer Unix-Plattform - künftig möglicherweise auch NT-Plattform - implementieren.
Allein das Schlagwort Unix-Plattform reicht jedoch nicht aus. Es muß auch geprüft werden, welche konkreten Systeme als Server-Plattform einsetzbar sind (Hewlett-Packard, IBM, Sun ...) und in welchem Umfang bei Bedarf verteilter Zugriff möglich ist, das heißt, welche Systeme als Management-Stationen an verschiedenen Standorten für unterschiedliche Netzbetreuer installiert werden können. Informationen und Planungsunterstützung für die Hardware-Auslegung des NMS sind eine wichtige Installationsvoraussetzung, teilweise geben die Hersteller jedoch nur sehr ungern Informationen über Referenzkonfigurationen heraus.
Bei einer Aufteilung des Netzes in mehrere Management-Domänen ist jedoch nicht nur verteilter Zugriff durch Netzbetreiber erforderlich, sondern auch die Einrichtung dedizierter Netz-Management-Server (NMS) kann sinnvoll sein. Hierfür gibt es proprietäre Konzepte mit Manager-Manager-Kommunikation (Cabletron, Sunsoft) oder verteilten Überwachungskonsolen (Hewlett-Packard, Sunsoft). Standardkonforme Manager-Manager-Kommunikation wird sich erst mit breiterer Unterstützung von Simple Network Management Protocol II (SNMP II) etablieren, da das Common Management Information Protocol (CMIP) im LAN kaum größeren Zuspruch finden wird.
Backup oft zu wenig beachtet
Für das Plattformsystem als zentrale Komponente stellt sich sofort die Frage nach einem Backup-NMS, die leider nicht bei allen Herstellern positiv beantwortet werden kann. Es ist zwar möglich, ein zweites NMS parallel zu betreiben und alle Meldungen von verwalteten Objekten an beide Systeme zu senden. Der resultierende Overhead ist dann jedoch doppelt so hoch. Overhead-Reduzierung wird auch bei der Vorverarbeitung von Status- und Alarmmeldungen in sogenannten Mid- level-Manager-(MLM-)Lösungen erreicht (HP oder IBM).
Je nach betriebenen Schwerpunkt-Protokollen wird nicht nur die automatische Darstellung von IP-Knoten, sondern auch von IPX/SNA- oder MAC-Knoten benötigt, zukünftig im Zusammenhang mit ATM auch OSI-Knoten, da ATM-Geräte als physikalische Adresse bemerkenswerterweise OSI-NSAP-Adressen verwenden. SNMP Discovery ist erforderlich, um verschiedene IP-Knotentypen (Host, Terminal, Hub, Brücke, Router) unterscheiden zu können. Mit wachsender Knotenzahl muß auch die Hardware nachgerüstet werden. Das IBM-System benötigt mehr RAM und weniger Swap-Platz, das HP-System weniger RAM und mehr Swap-Platz, Cabletron erheblichen RAM-Speicherplatz, da jeweils komplette Objektmodelle anstelle spezifischer Objekt-Teilinformationen geladen werden. Nachdem in einer Startphase alle verschiedenen Netzknoten vom NMS gefunden wurden und in einer riesigen Netzkarte untergegangen sind, benötigt der Netz-Manager im laufenden Betrieb Suchfunktionen, um bestimmte Objekte wiederzufinden oder darzustellen, zum Beispiel anhand ihrer MAC-Adresse, IP-oder IPX-Adresse, des IP-Host-Namens, oder des vergebenen organisatorisch-logischen Namens.
Bei einem NMS muß, abgesehen vom selbstverständlichen Paßwort, auch ein sicherer und effizienter Zugang bewertet werden, der nur gegeben ist, wenn über Login-Prozedere verschiedene Benutzerprofile definierbar sind, das heißt, nicht jeder Administrator darf alles sehen, lesen und schon gar nicht verändern. Bei der Implementierung wird meist schnell deutlich, daß ein NSM allein nicht ausreicht, sondern die Kopplungen zu weiterreichenden Dokumentationssystemen und TTS erforderlich sind.
Sowohl Kommandomodus als auch grafische Bedienbarkeit und sogar kontextsensitive Online-Hilfe sind bei allen bekannten Plattformsystemen inzwischen etabliert. Mit der Übersichtlichkeit bei Größe, Zoomfunktion und insbesondere Anordnung der Fenster hapert es noch. Spätestens nach Öffnen des zwanzigsten Fensters kann die Sache sehr unübersichtlich werden - und das ist bei vier Hierarchie-Ebenen leicht möglich. Eine systematische Fensteranordnung, Darstellung eines Navigationsbaums (Map-Hierarchie) und ähnliches (IBM, Cabletron) sowie die Möglichkeit, häufig benutzte Applikationen auf einen frei definierbaren Tool-Bar zu legen, sind hier sehr nützlich.
Ein sternförmig verlegtes Ethernet muß als Stern angezeigt werden und nicht, wie es in einigen Testfällen geschah, als Bus, ein Token Ring als Token Ring und ein FDDI-Ring als FDDI-Ring. Dies ist immer noch nicht selbstverständlich, insbesondere wenn ein einzelnes logisches IP-Netz aus verschiedenen LAN-Segmenten besteht. Auch das Zoomen von Objekten in allen Ebenen und Ansichten (geografisch, topologisch oder organisatorisch) ist noch nicht für alle Systeme die Regel.
Virtuelle LANs bereiten Probleme
Schwierig wird es bei der Implementierung von virtuellen LANs. Hier bieten die Plattformsysteme eher Hindernisse als Hilfen. Da ihre Grundfunktionen vor allem auf klassische, physikalisch zusammenhängende IP-Subnetze ausgerichtet sind, erfolgen diverse Fehlermeldungen, wenn die logischen IP-Subnetze physikalisch getrennt werden. Hat zum Beispiel ein LAN-Switch auf allen Ports unterschiedliche Hardware-MAC-Adressen, jedoch auf mehreren Ports dieselbe IP-Adresse (so wird ein Subnetz über mehrere LAN-Switch-Ports gespannt), meldet das NMS permanent "duplicate IP-Adress" als Fehlersituation. Im Normalfall wäre das auch korrekt, wird jedoch durch die Implementierung von VLANs zur "falschen Fehlermeldung", da hier die nicht standardgemäße Doppelbelegung gewollt ist. Lediglich über herstellerspezifische Zusatz-Tools, die auf die jeweilige Produktlinie beschränkt sind und eigene Netzdarstellungen generieren, erhält der Administrator hier Unterstützung. Grundsätzlich kann ein Netz-Manager bei der aktuellen Standardfunktionalität erwarten, daß bei Ausfall von aktiven Netzkomponenten ein Alarm erzeugt wird.
Wenn die generierten Events und Alarme nicht vernünftig sortiert und selektiert werden oder keine angepaßten Event-Kategorien festgelegt werden können, fällt es schwer, die eingehenden Informationen effizient auszuwerten. Weiterführendes Fehler-Management wie Fehlerverfolgung und -Dokumentation sind noch schwach ausgeprägt und erfordern im Regelfall den Einsatz von Zusatz-Tools.
Die Ausrichtung verschiedener Plattformsysteme ist nach wie vor unterschiedlich geprägt. IBM betont aktuell die System- und IT-Management-Seite.
Die Integration zwischen System- und Netz-Management läßt nach dem Kauf von Tivoli noch zu wünschen übrig. HP legt mit seinen neuen IT/O und IT/ Admin-Tools den Schwerpunkt auf die Synthese von beiden Bereichen. Bei Cabletron dominiert nach wie vor die netztechnische Seite mit Stärken in weiterverarbeitenden Funktionen wie TTS oder Fehlerkorrelation. Sun vermarktet den Solstice Sunnet Manager nunmehr als Einstiegswerkzeug, der neue Solstice Enterprise Manager muß in der Version 2.x erst noch Profil gewinnen.
Die Tabelle zeigt einen Auszug unserer Bewertungen für die zwei Plattformsysteme Openview und Netview. In die angegebenen Marktanteile sind eigene Auswertungen sowie Studien von IDC und Forrester Research (1995 und 1996) einbezogen.
Bei der Implementierung eines Netzwerk- und System-Management-Konzepts sowie der Auswahl des zugehörigen NSM-Systems sollte der Anwender vier Kriterien berücksichtigen:
- Die eingesetzten Technologien müssen beherrschbar werden und bleiben. Entsprechend muß der Netz- und Systemadministrator alle Betriebszustände einsehen, kennen und auch beeinflussen können. Das hierfür notwendige Know-how muß gezielt gepflegt und weiterentwickelt werden.
- Die Servicefähigkeit gegenüber dem Anwender muß erhalten bleiben und gesteigert werden. Dies bedeutet die Festlegung von Service-Level-Agreements hinsichtlich Reaktionszeiten und Verfügbarkeiten, auf deren Basis dann das Personal mit dem notwendigen Know-how-Stand geplant und angemessen eingesetzt werden kann.
- Der Netzbetrieb muß wirtschaftlich sein. Da über 80 Prozent des Netzbetriebs Personalkosten sind, ist hier der Hebel anzusetzen und über klare Definition von Zuständigkeiten (zum Beispiel ISO-9000-Prozesse, Checklisten, Prüfprozeduren) Effizienz zu schaffen.
- Die Sicherheit der Unternehmensdaten und -prozesse muß garantiert sein. Dies betrifft sowohl Server-Autorisierung als auch Client-Authentifizierung. Insbesondere im Zusammenhang mit der Internet- und Intranet-Thematik wird diese Vorgabe in den nächsten Jahren wichtig werden.
Angeklickt
Die Entscheidung für ein Netzwerk- und Management-System sollte an vorhandenen Plattformen und Umgebungen ausgerichtet werden. Die angebotenen Management-Lösungen haben Stärken und Schwächen beim System-Management oder bei der Verwaltung von Netzinstallationen. Ziel sollte es schließlich aber sein, Service, Sicherheit und Wirtschaftlichkeit der vorhandenen IT-Umgebung zu verbessern.
Nachtrag
Korrekturanmerkungen zum Beitrag "Ist ATM ein Bahnbrecher oder eine Mogelpackung?" von Petra Borowka im Schwerpunkt "High-speed im LAN" in der CW Nr. 32 vom 9. August 1996, Seite 35:
- Zur Definition der LAN-Emulation muß es richtig heißen: "Allerdings beschränkt sich die Definition auf einen MAC-Dienst für Ethernet und Token Ring. Außerdem läßt sich durch die Vorgabe von AAL 5 eine Steuerung der Dienstgüte durch QoS-Parameter nicht nutzen."
- Bei der Gegenüberstellung von MPOA und IPNNI muß es lauten: "IPNNI ist ein OSPF-ähnliches Protokoll zur Durchschaltung von Paketen der Ebene 3. (...) Ohne IPNNI könnte in MPOA nur ein einziger Route-Server benutzt werden. MPOA definiert nicht, wie mehrere Route-Server miteinander reden."
- Der erwähnte Test mit Windows NT und PC-Servern bezieht sich auf das "PC Magazine", April 1996.
- Beim Thema "native ATM-Anwendungen" muß es heißen: "Etablierte Protokoll-Stacks wie TCP/IP, Netware oder NT Advanced Server können die von ATM angebotene Steuerung der Verbindungsqualität (QoS) nicht nutzen."
*Diplominformatikerin Petra Borowka ist unabhängige Beraterin für Netzwerke in Aachen.