Ueber die Plattformprodukte fuer das System- und Netzwerk-Management (SNM) ist schon viel geschrieben worden. Doch eine Plattform allein ergibt noch lange kein integriertes Management-System. Dazu sind verschiedene Applikationen erforderlich. Helmut Duerr* versucht in seinem Beitrag, einen Ueberblick ueber die am Markt erhaeltlichen Produkte zu geben, erhebt aber keinen Anspruch auf Vollstaendigkeit. Die Produktangaben sind ohne Gewaehr, kurzfristige Aenderungen konnten nicht mehr beruecksichtigt werden.

Beim Aufbau eines integrierten Management-Systems geht es darum, eine Management-Plattform mit verschiedenen Applikationen zur Verwaltung so zu kombinieren, dass eine durchgaengige Loesung entsteht. Eine Plattform sollte deshalb zusammen mit den wichtigsten Applikationen ausgewaehlt werden. Interessante Integrationsaspekte ergeben sich durch folgende Fragen:

- Welche Datenbanken koennen verwendet werden?

- Welche (offengelegten) Schnittstellen haben die Produkte?

- Fuer welche Produkte gibt es schon Integrationsloesungen, und wie hoch ist der jeweilige Integrationsgrad (zum Beispiel nur Oberflaechenintegration)?

Darueber hinaus sollten Entscheider vor der Auswahl eines integrierten Management-Systems noch folgende Fragen klaeren:

- Welche Komponenten sollen mit dem Management-System verwaltet werden beziehungsweise wie heterogen ist die Systemlandschaft?

- Auf welcher Systembasis (Hard- und Software) soll das Management-System laufen?

Um die Euphorie von vornherein auf ein realistisches Mass zu daempfen, sei folgendes gleich bemerkt: Je heterogener die Systemlandschaft ist, desto weniger uebergreifend einsetzbare Produkte gibt es und desto schwieriger gestaltet sich die Suche nach einer passenden Loesung (beispielsweise OS/2-, DOS- und Windows-PCs an den Arbeitsplaetzen, LAN Server und Netware als Netzwerk-Betriebssysteme, einige Server mit Windows-NT, Hubs, Bridges und Router von mehreren Herstellern).

Die Norm CMIP konnte sich bislang nicht durchsetzen

Soll die Administration heterogener System- und Netzlandschaften heute vereinheitlicht werden, bietet ein SNMP-Ansatz (Simple Network Management Protocol) nach wie vor die besten Erfolgsaussichten. Die Verwendung einer OSI-Architektur mit dem Common Management Information Protocol (CMIP) setzt sich, wenn ueberhaupt, nur im Bereich oeffentlicher Netze durch.

Als die vier fuehrenden Plattformen fuer SNMP-basierende Umgebungen haben sich der "Openview Network Node Manager" von Hewlett- Packard, "Netview for AIX" von IBM, "Spectrum" von Cabletron Systems sowie der "Solstice Sunnet Manager" von Sun Microsystems herauskristallisiert. Dabei haelt Sun den Marktforschern der Gartner Group zufolge bislang mit rund 30 Prozent den groessten Marktanteil. Alle vier Plattformen sind Unix-basierend.

Mit den Plattformen verhaelt es sich wie mit bestimmten Arzneien. Der Anwender muss nicht immer zum Original greifen. So gibt es Netview/6000 auch als "Polycenter/Netview" von DEC. Eine erste Polycenter/Netview-Version ist auch auf Windows NT verfuegbar. "One Vision" heisst die Openview-Portierung in AT&T-GIS-Umgebungen, eine Windows-NT-Version ist angekuendigt. Selbst SNI bietet den "Openview Node Manager" als Teil der Transview-Produktlinie an. Weitere Unix-basierte Plattformprodukte gibt es zum Beispiel von SNI ("Transview/SNMP"), Tivoli ("TME"), Netlabs ("Dimons") oder von Multinet ("Lance+"). SNI Transview/SNMP sowie Teile von Openview und der "Solstice Enterprise Manager" von Sun nutzen uebrigens Netlabs Technologie.

Ist die zu verwaltende Umgebung PC-orientiert, koennen Administratoren auch zu Openview beziehungsweise Netview for Windows (geeignet fuer das Management von Workgroups), SMS von Microsoft, NMS von Novell

(Novell kooperiert hier mit Intel, und die Intel Landesk-Produkte sind in NMS eingebunden), "NMC Vision" ("NMC 1000" fuer Windows, "NMC 3000" fuer Unix, "NMC 4000" fuer Windows-NT) von Network Managers oder zu den SNM-Produkten von Frye/ Seagate greifen. In OS/2-orientierten Umgebungen sollte der Einsatz der IBM- Systemview-Produkte (LAN-Management-Utilities: "LMU for AIX" oder "LMU for OS/2") ernsthaft in Erwaegung gezogen werden.

Ausserdem bieten mehrere Hersteller, die originaer aus dem Mainframe-Bereich kommen, wie Computer Associates mit Unicenter, Legent mit "XPE" (Legent wurde von CA gekauft, die Produkte sollen zusammengefuehrt werden), Candle mit dem "Command Center" und Amdahl mit "A+EMS" (Enterprise Management Solutions) Plattformen fuer das System-Management von Client-Server-Umgebungen an.

Microsoft geht eigene Wege im Netz-Management

Fuer einige dieser Produkte gibt es Integrationsloesungen in SNMP- Plattformen (etwa Unicenter in Openview oder A+ in Solstice) beziehungsweise entsprechende Kooperationen der Hersteller (zum Beispiel CA und Microsoft). Auf Mainframe-basierte Produkte und Loesungen wie "IBM Netview/Systemview for MVS/ESA" soll hier nicht naeher eingegangen werden.

Gegenstand dieses Beitrags werden vielmehr folgende Management- Applikationen sein:

- Desktop- und Server-Management,

- Trouble-Ticketing sowie

- Netz- und Systemdokumentation fuer das Asset- und Inventory- Management.

Das Desktop- und Server-Management (DTM) verwaltet intelligente Clients wie PCs und Workstations sowie Server und Enterprise Server, sofern diese Geraete ueber ein Netz erreicht werden koennen. Dabei wird DTM in vier Bereiche unterteilt:

- das Hardware- und Software-Inventory. Damit erfolgt eine Identifizierung, Zusammenstellung und Bereinigung von technischen Daten ueber Hard- und Softwarekomponenten.

- die Electronic Software Distribution (ESD). Sie beinhaltet zentrales Software-Management (zum Beispiel Repository) und zentralisierte Softwareverteilung, Installation (zum Beispiel Installationssteuerung, Recovery und Deinstallation).

- Licence Management und Software-Metering. Hier handelt es sich um die Kontrolle und Dokumentation der Nutzung lizenzpflichtiger Software sowie den Schutz vor unberechtigter Nutzung. Oft laesst sich auch eine Optimierung des Lizenzeinsatzes im Unternehmen erreichen.

- Remote Control. Fernbedienung von Arbeitsstationen, Fernstart, Fernausfuehrung von Programmen auf Arbeitsstationen, Mitverfolgen der Ablaeufe sowie Kontrolle von Bildschirm, Tastatur und Maus von einer abgesetzten Station aus.

Um das DTM durch die Definition eines standardisierten Ansatzes zu vereinfachen, haben sich 1992 verschiedene Hersteller (Microsoft, IBM, DEC, HP, Sun, Synoptics etc.) in der Desktop Management Task Force (DMTF) zusammengeschlossen und das Desktop Management Interface (DMI) definiert. Mittlerweile hat sich Microsoft aus dieser Initiative zurueckgezogen und geht wieder einmal eigene Wege.

Bei der Auswahl eines Produkts fuer das Desktop-Management ist unter anderem darauf zu achten, dass Domaenen- beziehungsweise Zellenkonzepte verwirklicht sind und sich lokale Server oder lokale Depots definieren lassen. Alle Desktop-Typen (PC mit DOS, Windows oder OS/2, MAC etc.) sind mit dem gleichen Funktionsumfang in ihrer jeweiligen Netzumgebung zu unterstuetzen. Die mit den DTM- Funktionen erfassten Daten sollten im Rahmen der System- und Netzwerkdokumentation sichtbar gemacht werden koennen. So erfolgt bei einem Anklicken oder Zoom ein Aufblenden von DTM-Daten in der Etagendarstellung.

Fuer das DTM sind einige Produkte am Markt verfuegbar. Beispiele fuer solche Erzeugnisse und ihre moegliche Integration sind Tabelle 1 zu entnehmen. Mit zunehmender Heterogenitaet, insbesondere wenn gemischte Microsoft-Novell- (Windows NT und Netware) sowie IBM- Umgebungen (OS/2 und LAN Server) zu verwalten sind, duennt sich die Produktpalette allerdings zunehmend aus.

Eine weitere wichtige Applikation ist das sogenannte Trouble- Ticketing (TT). Auf gut deutsch wuerde man hierzu Stoerzettelverwaltung sagen. Vier Arten der Eingabe von Problem- oder Stoerungsmeldungen in ein Trouble-Ticket-System sollten moeglich sein:

- Von den Anwendern (telefonisch) gemeldete Stoerungen werden vom Benutzerservice manuell erfasst.

- Entsprechende Client-Software ermoeglicht dem Anwender das Erstellen der Trouble-Tickets, ausgefuellte Trouble-Tickets werden per E-Mail oder File-Transfer zum Server uebertragen.

- Unter Mitwirkung der System- und Netzwerkoperatoren werden Alarme und Events aus dem Client-Server-Management-System manuell uebernommen.

- Alarme und Events werden automatisch von der Management- Plattform ins Trouble-Ticket-System uebertragen.

Bei der automatischen Uebermittlung von Alarmen und Events ist darauf zu achten, dass die Menge der zu uebertragenden Meldungen durch den Einsatz von Filtern (zum Beispiel Mindestdauer von Stoerungen) und Alarmkorrelation (zum Beispiel Folgefehler) relativ gering gehalten wird. Ist dies nicht der Fall, verhindert eine zu grosse Anzahl an Trouble-Tickets die Bearbeitung. Trouble-Ticketing ist als eine besondere Art der Vorgangsbearbeitung zu sehen und sollte auch in das im Unternehmen genutzte Workflow-Management integriert werden.

Das Trouble-Ticket-System muss zumindest folgende Funktionen unterstuetzen: Definition von Funktionen und Funktionstraegern, Verantwortlichkeiten, Laufwege, Time-out-Kriterien sowie Benachrichtigungs- und Eskalationsprozeduren (wer wird benachrichtigt?). Im Trouble-Ticket-System sind somit wichtige betriebliche Ablaeufe und Prozeduren hinterlegt und dokumentiert. Bei einer richtigen Vergabe von Kennzahlen und Problem-

identifikatoren sowie einer entsprechenden statistischen Auswertung ist das System auch als ein wichtiges Instrument fuer Kontrolle und Reports zu sehen. Trouble-Tickets sollten per E-Mail versendet werden koennen (zum Beispiel an Operatoren der naechsten Schicht oder an externe Wartungsunternehmen).

Fuer das Trouble-Ticketing sind einige Produkte und ihre moegliche Integration in Management-Plattformen Tabelle 2 zu entnehmen. Als wichtigste Vertreter koennen hier das Action Request System (ARS) von Remedy (ARS ist auch Ausgangsprodukt fuer den "Calltracker" von Sun) und "Paradigm" von Legent (IBM TT/6000 basiert auf Paradigm) erwaehnt werden. Einige der TT-Tools werden zusammen mit einem System- und Netzdokumentationsprodukt angeboten (zum Beispiel "CCM" von Comconsult oder "DEC ATEM").

Produkte fuer die System- und Netzdokumentation (SND) werden unter den verschiedensten Oberbegriffen wie Facility Management, Kabelverwaltung, Netzdokumentation, Verbindungs-Management oder Infrastrukturverwaltung angeboten. Die von den Herstellern verwendeten Begriffe geben meist Aufschluss ueber die Historie der jeweiligen Produkte. So gibt es welche, die aus der PABX-Ecke (Kabelverwaltung), vom Kabel- und Trassen-Management in der Leittechnik (Verbindungs-Management) oder aus der DV-Welt (Infrastruktur- und Facility-Management) kommen. Je nach Herkunft haben die verschiedenen Produkte ihre Staerken beziehungsweise Schwaechen. Es sind relativ viele SND-Produkte auf dem Markt verfuegbar (vgl. Tabelle 3).

Spezifische Umgebungen sind selbst zu erarbeiten

Das SND sollte folgende Grunddaten fuer System- und Netz- Management-Aufgaben verwalten:

- Beschreibung der Unternehmensorganisation (Einheiten, Lokationen etc.);

- Gebaeudedokumentationen mit Lage- und Bauplaenen sowie unter Umstaenden Beschreibungen der Raumausstattung - eine generelle dreidimensionale Darstellung ist eher als Spielerei zu sehen;

- eine Dokumentation von Geraeten wie Desktops, Server und Hosts, TK-Anlagen, Modems mit ihren Standorten, Konfiguration etc.;

- eine Dokumentation von physikalischen Netzen wie Trassen- und Kabelfuehrung, Kabeltypen, Anschlussdosen, Verbindungen, Verzweigungen, Verstaerkern etc. sowie

- eine Dokumentation von logischen Netzen (Netzelemente, Uebertragungswege etc.).

Im Rahmen dieses Artikels konnten fuer einige wenige Problembereiche des System- und Netz-Managements einige Anforderungen aufgezaehlt und eine kurze, natuerlich nur unvollstaendige Produktuebersicht gegeben werden. Zusammenfassend ist festzuhalten, dass es heute Teilloesungen fuer integrierte Netzwerk-Management-Systeme gibt. Der potentielle Betreiber beziehungsweise Nutzer muss sich die Erstellung eines integrierten Management-Systems fuer seine spezifische Umgebung aber meist selbst erarbeiten.

*Helmut Duerr ist Berater fuer Netze und Telekommunikation in Muenchen.