Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

29.01.1993

Netz-Management: Plattformen erfuellen die Anforderungen nicht

Angesichts der Produkt- und Komponentenvielfalt heute vorherrschender heterogener Netzwerke ist deren Management zu einem komplexen und unuebersichtlichen Aufgabenbereich geworden. Um so verstaendlicher ist der Wunsch der Netzadministratoren nach einem Management-Tool, das die Arbeit so weit wie moeglich erleichtert. Organisatorische und technische Rahmenbedingungen sind dabei mit den funktionalen Aufgaben des Netzwerk-Managements sowie mit den jeweiligen Lebensphasen eines Netzwerkes (Planung, Inbetriebnahme, Wartung, Erweiterung etc.) in Einklang zu bringen und der Einsatz des Personals sowie des Tools fuer ein integriertes Management zu koordinieren. Das beschriebene Umfeld muss fuer die Auswahl und Integration eines gegebenenfalls zentralen Netzwerk-Management-Systems (NMS) beruecksichtigt werden - idealerweise wird es von einem geeigneten Plattformsystem kuenftig integriert verwaltet.

Leider sind die heute verfuegbaren Management-Plattformsysteme weit von der Idealvorstellung entfernt, und so bleibt der Alptraum von fuenf bis zehn Management-Konsolen am Arbeitsplatz des Netzbetreuers weiterhin lebendig. Gerade deshalb ist es notwendig, in der Planungsphase oder auch bei einer nachtraeglichen Ueberpruefung der eingesetzten Tools klare Anforderungen an ein integratives NMS zu stellen, die entsprechend den spezifischen Randbedingungen eines Netzwerkes unterschiedlich zu gewichten sind.

Systeme mit Plattform werden sich durchsetzen

Als eine der wichtigsten Funktionen des NMS ist zu nennen, dass es moeglichst alle Komponenten und Kommunikationswege des Unternehmensnetzes verwalten kann. Dies beinhaltet saemtliche Funktionen der eingesetzten Netzkomponenten, insbesondere Statusabfragen, Konfigurierung und Steuerung sowie die geeignete Darstellung einer Netzkomponente und aller Parameter fuer den Benutzer.

Die zugrundeliegende Architektur eines NMS ist sowohl fuer die Einsetzbarkeit der erreichten Management-Funktionalitaet als auch fuer die zukunftsorientierte Weiterentwicklung des Systems entscheidend. Dies betrifft sowohl die Benutzer-Schnittstelle als auch notwendigwerdende

funktionale Konsequenzen neu eingesetzter Management-Protokolle - zum Beispiel Migration von SNMP auf CMIP - als auch den Umfang der Komponentenverwaltung (Steuerungsfunktionen und Anzahl der verwalteten Komponenten).

Hierbei setzen sich zunehmend Systeme durch, deren Architektur plattformartig aufgebaut ist. Sie sind aus unterschiedlichen, funktional und operational voneinander getrennten Modulen wie Benutzer-Schnittstelle, Datenablage, Funktionsmodulen zum Komponentenzugang sowie zur Netz- und Komponentendarstellung, Programmier-Schnittstellen, Management-Protokollen zum Netzzugang und NMS-Kernanwendung aufgebaut. Als eine offengelegte Architektur zum verteilten Management sei hier das DME-Modell der OSF genannt.

Je mehr Hersteller von den Anwendern aufgefordert werden, ein weitgehend offenes System zu realisieren, um so mehr wird es moeglich sein, zusaetzliche Weiterentwicklungen ueber externe System- und Entwicklungshaeuser einzubringen und somit das System in Richtung Heterogenitaet zu erweitern. Solche Zusatzentwicklungen koennen sowohl von unabhaengigen Systemhaeusern als auch von Herstellern entsprechender Netzkomponenten (Sternkoppler, Bruecken, Router, Terminal-Server, Steuereinheiten, Gateways etc.) verfuegbar gemacht werden. Hierzu ist jedoch eine einfach zu bedienende Programmier-Schnittstelle (API) Voraussetzung.

Wenn Netzwerke aufgrund der Anzahl und Vielfalt angebundener Endgeraete und genutzter Protokolle mit fliessenden LAN-WAN- Uebergaengen zwischen lokalen und standortuebergreifenden Bereichen staendig wachsen, ist das Management von einer zentralen Stelle aus nicht mehr als ausreichend zu betrachten. Daher steht mittelfristig ein verteiltes Management mit entsprechender Domaenenbildung ins Haus, die an die Unternehmensstruktur anzupassen ist.

Derzeit unterstuetzt noch kein Produkt ein solches verteiltes Management heterogener Netze mit wahlweise disjunkten oder sich ueberschneidenden Domaenen. Die erste Huerde besteht darin, dass unter SNMP - darauf basieren die meisten Plattformsysteme und insbesondere Komponentenagenten - noch keine Kommunikation unter verschiedenen NMS definiert und spezifiziert ist. SNMP II weckt hier jedoch Hoffnungen.

Zum geordneten Datenaustausch zwischen NMS und den zu verwaltenden Komponenten (Managed Nodes, Management Agents) werden sogenannte Management-Protokolle verwendet. Dies sind eigens spezifizierte Protokoll-Stacks bis zur Ebene 7 des ISO-Modells, die in der Regel in den unteren Schichten offene oder genormte Transportprotokolle wie UDP, TCP, OSI-TP4 oder auch nur die Datensicherungsschicht (LLC) nutzen. Neben den weiterhin eingesetzten herstellereigenen Loesungen (NICE von Digital, NMVT von IBM etc.) haben sich fuer das heterogene Management zwei Protokolle etabliert, die in diesem Jahrzehnt dominieren werden: SNMP und CMIP. SNMP entstand aus dem dringenden Bedarf an uebergreifender Netzwerk-Management-Funktionalitaet innerhalb der Internet-Gemeinde, CMIP ging aus den Standardisierungs-Arbeiten fuer offene Systeme (OSI) innerhalb der ISO hervor.

CMIP fuehrt derzeit noch ein Schattendasein

Waehrend sich SNMP bereits mit einer Vielzahl von Implementierungen sowohl fuer Management-Systeme als auch fuer die zu verwaltenden Netzkomponenten wie Router, Bruecken und Hubs im Markt etabliert hat, fuehrt CMIP derzeit noch ein Schattendasein, das sich im wesentlichen auf Absichtserklaerungen und abgespeckte Implementierungen des Management-Protokolls in IBM-Produkten wie dem LAN Netzwerk Manager beschraenkt.

Waehrend die SNMP-Implementierungen aktuell ueber die Standards MIB (MIB II) hinaus von IETF-Arbeitsgruppen staendig erweitert werden (RMON MIB fuer Ethernet und Token Ring, FDDI MIB, Hub MIB, Bridge MIB, Router MIB etc.), ist die Entwicklung im OSI-Management noch nicht so weit fortgeschritten. Da noch nicht einmal alle wichtigen funktionalen Teilstandards in endgueltiger Form verabschiedet sind, halten sich die Hersteller mit Implementierungen und Entwicklungen bisher sehr zurueck.

Die aktuelle Situation wird zusaetzlich durch Bestrebungen verschleiert, nicht zu OSI konforme Protokolle als Transportprotokolle oder einen reduzierten Stack fuer CMIP zu verwenden. Als Beispiel seien hier CMOT (CMIP ueber TCP) und CMOL (CMIP ueber LLC) aufgefuehrt. Natuerlich gibt es auch andere Derivate wie SNMP ueber IPX von Novell, denen zugunsten eines tatsaechlich offenen Managements hier keine weitere Beachtung eingeraeumt werden soll.

Unter Beruecksichtigung von Machbarkeit und Optimum heisst die Management-Richtung derzeit SNMP, zukuenftig ist jedoch wegen des breiteren Funktionsumfangs und der groesseren Flexibilitaet ein OSI- Management anzustreben - es sei denn, die SNMP-Funktionalitaet wuerde in zukuenftigen Standards dem OSI-Pendant so weitgehend angenaehert, dass die kostenintensive Implementierung von OSI ohnehin obsolet wird. Hierzu muesste SNMP jedoch noch manche Schwierigkeit ueberwinden.

Allein die erforderliche IP-Adressierung bereitet derzeit vielen TCP-Anwendern Kopfzerbrechen und stoesst bei der Einfuehrung eines uebergreifenden Managements noch deutlicher an ihre Grenzen. Dennoch erscheint SNMP derzeit mangels Alternative als das kleinere Uebel.

Funktionale Komponenten des Management-Systems

Zur naeheren Beschreibung der NMS-Funktionsmodule wird die allgemein uebliche Gliederung entsprechend den fuenf funktionalen Bereichen des OSI-NM gewaehlt.

Das Konfigurations-Management umfasst die Verwaltung aller Komponenten (Objekte) inklusive Statusabfragen sowie Status- und Konfigurationsveraenderung (aktive Konfigurierung). Verbindungen und Relationen zwischen verschiedenen Netzwerk-Objekten muessen fuer den Netzbetreuer ebenfalls erkennbar sein. Verwaltete Objekte sind zum Beispiel Netzkomponenten wie Hubs, Bruecken,

Router, Terminal-Server, Steuereinheiten, vernetzte Rechner etc., Softwarekomponenten wie

Netzwerk-Anwendungen, ueber Netz zugreifbare Dateien und Dateisysteme sowie Benutzer mit jeweils spezifischen Zugangsrechten und Benutzerprofilen.

Aus Gruenden der Uebersichtlichkeit und Reaktionsschnelligkeit ist eine hierarchisch strukturierbare grafische Netzkarte inklusive Zoom-Funktion und farblicher Statusanzeige unverzichtbar.

Das Konfigurations-Management basiert im wesentlichen auf einer Management-Datenbank mit den entsprechenden Konfigurationsdaten aller aktiven und passiven Netzkomponenten und Benutzer. Hierzu gehoeren auch Aufbau und Pflege der Konfigurations- und Benutzerdatenbank. Das Konfigurations-Management bildet somit die Grundlage fuer alle anderen funktionalen Bereiche.

Zweite Funktion: Fehler-Management

Das Fehler-Management als weiterer funktionaler Bereich schliesst alle Aktivitaeten ein, die mit offensichtlichen oder verdeckten Stoerungen im Netzwerk beziehungsweise an vernetzten Komponenten zusammenhaengen. Dazu gehoeren einerseits Hilfsmittel wie Anwendungen, Funktionen, Routinen etc. zur Fehlererkennung, - diagnose und -behebung, andererseits auch Konzepte zur Fehlerbehandlung, soweit diese nicht automatisch von Tools geleistet werden kann.

Netzfehler meldet ein NMS in der Regel in Form von Alarmen. Ob eine Stoerung jedoch tatsaechlich bemerkt wird und wie klar sich die wahrscheinliche Ursache dem Netzadministrator darstellt, ist abhaengig von den Moeglichkeiten des jeweils verwendeten Management- Systems. Als Beispiel sei hier die farbige Statusdarstellung genannt: Allein die Anzahl unterstuetzter Farbstufen variiert zwischen drei und acht, ganz zu schweigen von zusaetzlichen Funktionen wie Logfiles, Trouble Tickets und akustischen Alarmen.

Zur Generierung von Alarmen verwendet das OSI-NM ein ereignisgesteuertes Modell (Alarme werden unaufgefordert an das NMS gesendet), waehrend SNMP im wesentlichen mit Polling arbeitet. Soll ein Netz mit Tausenden von verwalteten Komponenten nicht voellig unter der erzeugten Polling-Last zusammenbrechen (und nicht jeder Netzbetreiber kann sich ein separates Hochgeschwindigkeitsnetz fuer Management-Kommunikation leisten), so ist die Polling-Rate wohlueberlegt anhand vorher gebildeter Gefahrenklassen fuer Netzkomponenten einzustellen.

Nach einer ersten Fehlererkennung sollte ein NMS weitergehende Funktionen zur Diagnose bieten. Es sollte vordefinierte Testroutinen aktivieren und darueber hinaus auch eigene Routinen zur Fehlerbehandlung definieren koennen. Ferner ist die automatisierte Aktivierung von Ersatzkomponenten (Backup- Leitungen, Backup-Server etc.) wuenschenswert; die Fehlerbeseitigung via NMS-Automatik ist bisher meist ein frommer Wunsch.

Fehler und Stoerungen muessen kurz- und langfristig verwaltet, das heisst aufgezeichnet werden. In diesen Bereich fallen Fehlerberichte und Auswertung von Fehler-Logbuchdaten.

Fehlerverfolgung sollte in Form sogenannter Trouble Tickets dokumentiert werden, die Zeitpunkt, Ursache, Diagnose- sowie Stationen festhalten.

Dritte NMS-Funktion: Leistungs-Management

Das Leistungs-Management beinhaltet ausserdem die Erfassung, Auswertung und aufbereitete Ausgabe der Leistungsdaten wie Durchsatz, Verfuegbarkeit, Auslastung, Antwortzeiten etc. Dazu ist in vielen Faellen zusaetzlich zum Einsatz eines NM-Plattformsystems die Einbindung von externen Messgeraeten noetig. Leistungs-Management realisiert nicht nur eine Analyse der aktuellen Leistungssituation des Netzes, sondern auch eine mittel- und langfristige Kapazitaetsplanung hinsichtlich Strukturierung, Tuning und Erweiterung des Unternehmensnetzes.

Der NMS-Benutzer sollte auf die Bearbeitung der Daten Einfluss nehmen, und zwar durch die Definition von Schwellwerten, Abtastintervallen und gaengigen Leistungsparametern. Die Leistungsdaten muessen in lesbaren Reports aufbereitet werden koennen.

Vierte NMS-Funktion: Accounting Management

Das Accounting Management dient dagegen einerseits der benutzerbezogenen Kostenabrechnung innerhalb eines Kommunikationssystems, andererseits der Zuteilung von Ressourcen. Es bietet im wesentlichen Informationen ueber Art und Umfang der in Anspruch genommenen Ressourcen beziehungsweise Netzdienste sowie entsprechende Regelungen des Zugriffs.

Mit Hilfe der Nutzungsinformationen kann eine adaequate Kostenrechnung erfolgen. Die entstandenen Kosten lassen sich auf vielfaeltige Weise aufteilen: Zwischen den Extremen "Bei uns kommt die Kommunikation aus der Datensteckdose" (voellig globale Umlage aller Kostenund "Bei uns bezahlt jeder Benutzer jede genutzte Netz-CPU-Sekunde und jede Netz-Druckerseite" (Strategie eines grossen deutschen Konzerns) ist eine Myriade von Accounting- Strategien denkbar, etwa auch die Kostenumlage nach verschiedenen Benutzergruppen oder nach Kostenstellen.

Das Accounting Management sollte den Zugriff auf einzelne Ressourcen (Server-Zugriff, Druckernutzung) gesteuert nach Zeit und Anwender erlauben oder beschraenken. Es sollte dazu insbesondere die Definition von Obergrenzen fuer die Nutzung von Ressourcen unterstuetzen.

Fuenfte NMS-Funktion: Sicherheits-Management

Das Sicherheits-Management realisiert schliesslich als letzter funktionaler Bereich die Datensicherheit im Sinne einer gesicherten Uebertragung und des Zugriffsschutzes. Es bezieht sich auf alle Komponenten, die zur Kommunikation erforderlich oder an der Kommunikation beteiligt sind. Moegliche Eingriffe und Stoerungen, denen das Sicherheits-Management vorbeugen soll, sind:

- Abhoeren von Nachrichten (passiv),

- aktives Veraendern von Nachrichten,

- aktive Stoerung einer Verbindung,

- passive Stoerung einer Verbindung (Hardware-Defekte) sowie

- nicht autorisierter Zugriff auf Ressourcen und Daten.

Vor den aufgefuehrten Gefahren koennen verschiedene Massnahmen schuetzen. So verhindert zum Beispiel ein Zugangskontrollmechanismus (in der Regel verschluesselt uebertragene Passworte) den unerlaubten Zugriff auf einen Server. Verschluesselung kann Datenuebertragung abhoersicher machen. Abgestufte Zugangsberechtigungen zur Verwaltung von Netzkomponenten mittels NMS sind erforderlich, um einerseits den berechtigten Personen notwendige Aktivitaeten wie Wartung und Routineaenderungen zu ermoeglichen, andererseits jedoch zu verhindern, dass nicht autorisierte Personen an verwalteten Komponenten oder dem NMS Stoerungen produzieren.

Management-Systeme und Management-Aktivitaeten an einzelnen Netzkomponenten sind besonders zu schuetzen, da vom NMS aus Aktionen hinsichtlich der Kommunikationsfaehigkeit eines Netzwerkes moeglich sind, die den Nerv der Datenkommunikation betreffen (Deaktivierung von Koppelelementen und Servern, Veraenderung der Adresstabellen bei Bruecken und Routern, Veraenderung von Konfigurationsdateien und Benutzerprofilen etc.). Vor allem bei SNMP sind die Sicherheitsmassnahmen bisher noch relativ schwach entwickelt, was dazu fuehrte, dass eine Reihe von Implementierungen (mit allerdings abnehmender Tendenzkeinen SET-Mechanismus zur Verfuegung stellen.

Management-System muss Datenbank beinhalten

Eine zentrale Funktion des NMS ist die konsistente Speicherung und Aktualisierung von Daten aller bisher beschriebenen Bereiche. Dazu ist die Verwendung einer Datenbank unverzichtbar. Sie sollte einen offenen Zugang (auch von ausserhalb des NMS) bieten, damit weitergehende Programmsysteme sowie Benutzer, die keine Netzbetreuer sind, zum Beispiel zur Netzplanung, zu Accounting- oder Controlling-Zwecken darauf zugreifen koennen. Zu fordern ist die Unterstuetzung eines von verschiedenen, am Markt relevanten Datenbanksystemen, die auf Defacto-Standards basieren. Audem sollte die eingesetzte Datenbank entsprechende Tools zum Anlegen, Verwalten und Erweitern der DB zur Verfuegung stellen.

Viele NMS sind nur fuer bestimmte Kombinationen von Rechner und Betriebssystem verfuegbar. Diese Einengung auf den Einsatz explizit einer Hardware und Software ist grundsaetzlich nicht akzeptabel. Hat sich als strategische Linie der Einsatz von Unix auf der Basis von HP oder Sun Workstations durchgesetzt, so ist der zwangsweise Aufbau von Know-how im Bereich AIX und RS/6000 oder OS/2 und PS/2 ausgesprochen laestig, abgesehen von den zusaetzlich entstehenden Hard- und Softwarekosten.

Ebenso wichtig ist die Erweiterbarkeit des NMS (Skalierbarkeit) innerhalb oder sogar ausserhalb der anfangs eingesetzten Systemfamilie. Natuerlich sollten zur Netzanbindung die gaengigen LAN-Standards Ethernet, Token Ring und FDDI unterstuetzt werden (siehe Abbildung).

Die Benutzeroberflaeche des NMS ist die Schnittstelle zum Anwender. Sie muss uebersichtlich und leicht bedienbar sein. Gaengige Standards sind hier X.11, OSF Motif, Presentation Manager - letzterer nur unter OS/2 fuer Einstiegsversionen von NMS. Netz- Manager, die haeufig mit dem System arbeiten, brauchen einen Expertenmodus (Kurzbefehle).

Analog zur Sicherheit der Datenkommunikation ist ebenfalls der Zugang zum NMS besonders abzusichern und sind Zugriffe mittels Logbuch festzuhalten.

Anwender sollten beim Kauf auf Support achten

Unternehmen mit mehreren Standorten benoetigen Zugang zum NMS von entfernten Standorten aus. Bei Netzausfall ist es wichtig, NMS und Komponenten dennoch durch das Management-System ansprechen zu koennen. Das bedingt die Unterstuetzung eines separaten Zugriffs (Outband Management).

Als zentrale Anforderungen an das Management-System und seine Einsetzbarkeit lassen sich zusammenfassen:

- Einsetzbarkeit auf verschiedenen Hard- und Software-Plattformen,

- moeglicher Uebergang auf leistungsfaehigere Systeme,

- Unterstuetzung der gaengigen LAN-Interfaces,

- grafische Benutzer-Oberflaeche,

- Online-Hilfefunktion,

- Unterstuetzung eines Expertenmodus,

- abgestufte Zugangskontrolle zum NMS,

- Logbuch fuer erlaubte und unerlaubte NMS-Zugriffe,

- farbige Netzdarstellung mit grafischen Symbolen (Icons),

- Lieferung und staendiges Update von Standardsymbolen,

- grafischer Editor zum Anlegen eigener Icons,

- Unterstuetzung des Remote-Zugriffs auf das NMS (zum Beispiel Telnet, Dialup-Modem etc.) sowie

- Unterstuetzung von Outband-Management.

Viele Anwender gewichten die Moeglichkeiten, nach einer Kaufentscheidung Unterstuetzung von seiten des Herstellers oder Anbieters zu erhalten, nicht ausreichend. Solche Hilfen koennen jedoch eine Menge Aerger verhindern. Die Verfuegbarkeit einer qualifizierten Hotline und ebenso das Angebot einer Fernwartung des NMS beziehungsweise des gesamten Netzes lassen Rueckschluesse ueber Kompetenz und Erfahrung des Anbieters zu.

Abschliessend seien einige Plattformsysteme als Produktbeispiele naeher betrachtet, die fuer sich in Anspruch nehmen, integrierende Management-Plattformsysteme im erlaeuterten Sinne zu sein: "NMC Vision" (frueher NMC 3000) von Network Managers, "Openview" von Hewlett Packard, "Spectrum" von Cabletron und "Starsentry" von NCR/AT&T. Wie die Uebersichtstabelle, die sich auf Ergebnisse der Benutzergruppe Netzwerke stuetzt, hinsichtlich einiger ausgewaehlter Funktionen zeigt, gibt es durchaus produktspezifische Unterschiede.

"NMC Vision" von Network Managers

Kern des Systems NMC Vision sind Net Map (grafische Netzdarstellung), Fault Handler und Performance Handler zur Fehleranzeige, Leistungs- und Funktionsueberwachung (zum Beispiel Einstellung von Polling-Intervallen, Alarmstufen etc.).

Staerken des Systems liegen in der beliebigen Hierarchiebildung durch frei definierbare Netzkarten und in den Moeglichkeiten zur Alarmfilterung. Die vollstaendige grafische Integration von Netzkomponenten ueber Product Specific Modules (PSM) ist zwar bestechend, aber es bleibt fraglich, ob Network Managers bei einer Vielzahl integrierter Komponenten und dem immer schnelleren Produktneuerungszyklus den Aufwand, neue Features in ein existierendes PSM zu integrieren, auf Dauer leisten kann.

Nachteilig ist die zugrundeliegende proprietaere und nicht SQL- basierte Datenbank. Auch die Einbringung von IPX als Management- Protokoll zusaetzlich zu SNMP macht deutlich, dass NMC Vision auf Spezialloesungen abzielt.

MAP/TOP als Management-Protokoll ist historisch bedingt verfuegbar, da einige Retix-Bruecken nur ueber diesen Protokoll-Stack managebar sind und noch kein SNMP realisieren. Positiv faellt ins Gewicht, dass das System nicht nur auf Sun Workstations, sondern auch auf RS/6000-Systemen laeuft.

"Openview" von Hewlett Packard

Openview (Version 3.x) ist grundsaetzlich in zwei Versionen erhaeltlich, einem abgespeckten, ueberwiegend auf IP-Netze und entsprechende Anwendungen ausgelegten SNMP-Release, und der umfassenderen Distributed Management Platform, die CMIP- und OSI- Ansaetze einschliesst und zukuenftig auch die volle Kompatibilitaet zu OSF DME anstrebt. Der Openview

Postmaster als zentrales Dispatching-Element wird als wesentlicher Baustein der vorgeschlagenen Architektur verwendet, hier ist schon jetzt eine Teilkompatibilitaet gegeben. In der Architektur der Distributed Management Platform ist auch schon die Kommunikation zwischen NMS auf CMIP-Basis vorgesehen - allerdings gibt es noch keine Anwendung, die dieses Feature auch nutzen kann.

Sowohl die SNMP-Version als auch die Distributed Management Platform sind als reines Produkt lediglich implementierte Basisarchitekturen, auf denen entsprechende Netz-Management- Anwendungen aufsetzen koennen, zum Beispiel der Openview Node Manager von HP als bekannteste derzeit verfuegbare Applikation. Fuer die Distributed Management Platform respektive fuer CMIP, das hier als Option erhaeltlich ist, muessen entsprechende Anwendungen jedoch erst noch zur Produktreife gelangen. Das Plattformsystem als solches ist allerdings aufgrund seiner Modularitaet sehr flexibel. Nicht umsonst hat die OSF Teile der Openview-Architektur adaptiert.

Die Staerken des Systems sind in der ausgepraegten Modularitaet zu sehen, naemlich der vollstaendigen Trennung von GUI, Applikationen, Management-Datenhaltung und eingesetzten Protokollen, wobei insbesondere die Separation von Benutzeroberflaeche und Anwendung bemerkenswert ist.

Auch die Vielfalt der angebotenen Programmier-Schnittstellen und -Bibliotheken geht ueber den Durchschnitt hinaus. Mit dem optionalen Einsatz von Ingres statt der proprietaeren Openview- Datenbank ist auch hier ein Schritt in Richtung Offenheit erfolgt.

Zwar hat HP mit der Portierung von Openview auf Sun Workstations einen Fuss in viele halboffene Tueren der Sun-Anwender bekommen, weitere Portierungsplaene sind jedoch nicht erkennbar. Das handfeste Verkaufsinteresse, mit dem Management auch gleich eigene Workstations zu lancieren, hat bisher noch die Oberhand, obwohl es nicht allzu schwer sein duerfte, Openview auch auf die RS/6000 zu portieren, da hier in Form von Netview/6000 schon ein Openview auf OEM-Basis existiert.

Zur voellig wahlfreien Netzdarstellung in beliebigen Hierarchien fehlen allerdings noch Anwendungsmodule. Der aktuelle, stark TCP/IP-orientierte Node Manager hat noch Probleme, Strukturen innerhalb eines Segments aufzubrechen oder zwei verschiedene LANs (Ethernet und Token Ring) in einer Darstellung zu praesentieren.

Gut ausgepraegt sind dagegen die Moeglichkeiten, verfuegbare MIBs zu benutzen: Einzelne MIBs koennen explizit geladen und wieder ausgelagert werden, und zusaetzlich zu dem in allen gaengigen Systemen irgendwie implementierten MIB Browser und Compiler gibt es einen MIB Data Collector, der statistische Datensammlungen fuer einzelne MIB-Variablen anlegen kann, die nach einiger Zeit eine Interpretation erlauben, welche Werte einer bestimmten MIB- Variable in einem speziellen Anwendernetz ueberhaupt als gut, normal, kritisch oder katastrophal anzusehen sind. Benutzer, die selbst Management-Anwendungen schreiben wollen, erhalten mit dem Application Builder ein Tool.

"Spectrum" von Cabletron

Spectrum ist ein Management-System, das die Firma Cabletron seit mehreren Jahren anbietet. Urspruenglich vorzugsweise fuer die Verwaltung eigener Netzkomponenten konzipiert, hat Cabletron relativ schnell den Weg beschritten, auch Netzkomponenten anderer Hersteller zu integrieren und damit Netzwerk-Management per se statt Management als Add-on zu eigenen Produkten zu betreiben.

Die Kernanwendung von Spectrum besteht aus einem relativ komplexen Modellierungs-Tool, mit dem das gesamte Netzwerk in Form von Modellen nach geografischer, topologischer und organisatorischer Sicht jeweils rekursiv nachmodelliert werden kann. Die Verknuepfung der Modelldefinitionen mit realiter zu verwaltenden Netzkomponenten erfolgt ueber den Device Communication Manager. Zur Erstellung von Modellen oder tiefergehenden Management-Erweiterungen wie der Integration neuer Management- Protokolle stehen verschiedene Tools (Level I, Level II) zur Verfuegung. Fuer die Entwicklung zusaetzlicher Anwendungen wie Trouble Tickets oder Report- Generierung wurden Partnerschaften geschlossen (SAS, Remedy).

Positiv ist die Strategie von Cabletron zu werten, die Spectrum- Software 1993 auf verschiedenste Hardware-Plattformen wie IBM?s RS/6000, Silicon Graphics und Digital zu portieren. Wer sich mit ASN.1 auskennt, kann mit dem Model Type Editor und Level I Toolkit auch Applikationen zur Integration von Komponenten schreiben.

Leider ist die Datenbank zwar objektorientiert, aber voellig proprietaer, die sich zu Wiegenzeiten von Spectrum SQL noch nicht etabliert hatte. Ferner gibt es noch keine Alarmfilterung. Verbesserungswuerdig in der Netzdarstellung ist die Icon- Praesentation: Komponentensymbole koennen nicht vergroessert oder verkleinert werden, was die Anzahl darstellbarer Komponenten auf einem einzelnen Bildschirm stark eingrenzt.

"Starsentry" von NCR/AT&T

Starsentry von NCR/AT&T ist derzeit noch nicht so etabliert wie die drei genannten Systeme. Abgesehen von der Verwaltbarkeit der Netzkomponenten von AT&T hat das System beziehungsweise seine Anwendungsmodule einen deutlichen Schwerpunkt im Bereich PC- Netzwerke.

Zwei wesentliche Anwendungspakete sind derzeit einsetzbar: der SNMP-basierte System-Manager (zum Beispiel fuer Starlan- Hubs, Starlan-Bruecken und -Router, Starlan-FDDI-Concentratoren von NCR/AT&T) und der Computer-Manager zum PC-Netzwerk-Management (Funktionalitaet einer LAN Manager/UX- oder Vines-Konsole, 1993 auch einer Netware-Konsole). Computer-Manager und System-Manager sind auf derselben Management-Station ablauffaehig. Leider setzt der Computer-Manager SNMP auf der Basis von TCP (nicht UDP, wie laut RFC spezifiziertein.

Die erforderliche Systembasis ist schnell beschrieben: Die Software laeuft nur auf einem NCR-System. Auch eine saubere modulare Trennung von Benutzeroberflaeche, Anwendungen, Kernsystem und eingesetzten Protokollen ist nicht erkennbar. Eine Unterstuetzung von Trouble Ticketing ist nicht gegeben. Ebenso fehlen Tools zum Generieren eigener Management-Anwendungen.

Positiv zu werten sind der Einsatz der SQL-Datenbank Informix (noch dazu derselben DB, die der AT&T Accumaster Integrator als uebergeordnetes Monitoring Tool benutzt), die detaillierte Alarmabstufung und entsprechende Filtermoeglichkeiten. Ueberdies ist Starsentry das einzige der betrachteten Systeme, das ueber den Computer-Manager eine Ressourcen-Beschraenkung bei der Server- Nutzung erlaubt, zum Beispiel in bezug auf den nutzbaren Plattenplatz.

*Petra Borowka ist unaebhaengige Unternehmensberaterin mit Sitz in Stolberg.