Verteilte Anwendungen sind noch nicht die Regel im DV-Alltag. Ein Grund dafür dürfte darin liegen, daß das Management solcher Anwendungen nicht gerade trivial ist. Heinz-Gert Hegering* vermittelt im folgenden Beitrag Optimismus: "Wir sind nicht nur auf einem Weg zu offenen Netzwerk-Managementstrukturen, sondern auf dem richtigen Weg." Ein integriertes Management heterogener Rechnernetze setzt Modellbildungen als Basis einer Managementarchitektur voraus. Was ist Netzmanagement? Netzmanagement umfaßt die Gesamtheit der Vorkehrungen und Aktivitäten zur Sicherstellung des effektiven und effizienten Einsatzes eines Kommunikationssystems. Netzmanagement ist also betriebszielorientiert, betrifft Personal, Verfahren, Programme und technische Systeme und umfaßt die Aspekte Planung, Betrieb, Kontrolle sowie Berücksichtigung von Organisationsformen.

Welches sind die Einflußfaktoren für die Ausprägung eines konkreten Managementkonzeptes?

Zunächst ist die Zielsetzung des Netzes zu nennen, die gegeben ist durch Netzanwendungen, die eine bestimmte Dienstgüte erwarten. Die Einhaltung der Dienstgüte muß durch das Management garantiert werden.

Ihre Bewertung erfolgt aufgrund der angebotenen Netzdienste, bestimmter quantitativer Güteindikatoren (zum Beispiel Verfügbarkeit, Antwortzeit, Auslastung) oder qualitativer Indikatoren (zum Beispiel Änderungsflexibilität, Datenschutzklassen, Oberflächen).

Vielzahl der zu verwaltenden Komponenten

Weitere Einflußfaktoren sind die Einbettung des Netzes in DV-Versorgungsstrukturen (man denke an die verschiedenen Netzebenen in einem CIM-Konzept), die physische Netzstruktur (Topologieformen und Komponenten), die logische Netzstruktur (Protokollhierarchien), die Struktur der Netzbenutzer und ihre Kommunikationscharakteristiken und schließlich die Aufbauorganisation des Netzbetreibers.

Was macht die Komplexität des Management aus?

Da ist zunächst die Vielfalt und die Vielzahl der zu verwaltenden Komponenten wie Hosts, PCs, Workstations, Terminals, Übertragungseinrichtungen, Vermittlungseinrichtungen, Medien und Teilnetze. Es ist ferner die Heterogenität von HW-Schnittstellen, Protokollprofilen und Systemsoftware. Als nächstes ist eine räumliche weite Verteilung zu nennen und schließlich oft noch die Tatsache verschiedener Verantwortungsbereiche und Zuständigkeiten.

Die ganze Bandbreite berücksichtigen

Es verwundert also zunächst nicht, daß noch so gut wie keine integrierten Netzmanagement-Werkzeuge existieren.

Integrierte Werkzeuge und damit auch die zugrunde liegenden Management-Architekturen müßten berücksichtigen:

a) die ganze Bandbreite der Management-Funktionsbereiche. Funktionsbereiche sind

Gruppierungen von Management-Aktivitäten, zum Beispiel Fehlermanagement,

Leistungsmanagement, Konfigurationsmanagement. Die Festlegung von Funktionsbereichen gestattet nicht nur eine modulare Entwicklung der entsprechenden Werkzeuge, sondern erhöht auch die Auswahlmöglichkeiten von Managementfunktionen für den Netzbetreiber.

Problematisch bei der Definition der Teilbereiche ist jedoch die Tatsache, daß viele Wechselwirkungen zwischen den Bereichen denkbar sind und eine Abgrenzung oft nicht exakt formulierbar ist. Beispiele für Wechselwirkungen sind:

- Aufrufhierarchien: Das Fehlermanagement lokalisiert Fehler und muß das Konfigurationsmanagement veranlassen, durch Neukonfiguration das fehlerhafte Objekt zu ersetzen

- Gemeinsam benutzte Objekte: Leistungs- und Abrechnungsmanagement benutzen identische Zähler in Meß- und Abrechnungsvorgängen

b) die verschiedenen Management-Zeitbereiche. Je nach Betrachtungszeitraum von Managementaktivitäten kann man drei Klassen unterscheiden: operationales (short-term) Management mit einem Zeitrahmen für Reaktionen in Sekunden bis Minuten, taktisches (medium-term) Management mit Reaktionen innerhalb von Stunden bis Tagen und strategisches Management, das in Analyse und Planung übergeht.

Den Zuständigkeiten flexibel zuordnen

Die Zuordnung einer Managementfunktion zu einem Zeitbereich hat Auswirkungen darauf, wie und wo die Funktion erbracht wird, wann und wie oft etwas getan wird und wie lange es dauert. Dies hat Auswirkungen auf Zähl- und Puffergrößen, Meßhäufigkeit und Meßgenauigkeit, Auswerteverfahren, Verteilungs- und Kommunikationsaspekte. Ein integriertes Managementsystem sieht vor, daß Daten und Ergebnisse des short-term-Managements Eingabeinformationen für das medium-term-Management sind, und letzteres in das long-term-Management einfließt.

c) Einbettung in verschiedene Organisationsformen. Managementsysteme unterscheiden sich bezüglich der räumlichen Anordnungsflexibilität von Netzmanagementkomponenten und der Flexibilität der Zuordnung von Betriebsmitteln zu Zuständigkeitsbereichen. Je nach Ausprägung ergibt sich dadurch eine Einschränkung der für ein Netzmanagement möglichen Organisationsformen. Dies wirkt sich aus auf die Anpassungsmöglichkeit des Netzmanagements an die Aufbaubeziehungsweise Ablauforganisation des Netzbetreibers. Für die Modellierung von Teilbereichen ist der Begriff der Domäne von großer Bedeutung. Unter Domäne kann man eine Menge von Objekten eines Netzes verstehen, die gemeinsame Eigenschaften besitzen und/oder von einer übergeordneten Instanz verwaltet werden. So lassen sich unterschiedliche Konfigurationsdomänen, Abrechnungsdomänen, Sicherheitsdomänen, Steuerungsdomänen, Routingdomänen etc. über ein und demselben Netz bilden, die nicht deckungsgleich zu sein brauchen, was die betroffenen Netzkomponenten angeht: Für das Netzmanagement muß natürlich entsprechend der organisatorischen Domänenbildung eine Verteilung der Managementfunktionen auf die einzelnen Netzkomponenten vorgenommen werden.

d) die Modellierung der zu verwaltenden Betriebsmittel (managed objects) durch entsprechende Objektmodelle.

Zum Entwurf der Objekt-Modelle gehören folgende Schritte:

- Festlegung der "managed objects", abhängig von den gewünschten Managementfunktionen und den unterstützten Funktionsbereichen.

- Festlegung der Beschreibung von Objekten durch Benennung und Spezifikation von management-relevanten Attributen.

- Spezifikation von Operationen auf den Objekten (Generierungs-Zugriffs- und Manipulationsfunktionen). Dies beinhaltet zum Beispiel die Festlegung von Zustandsmodellen für Objekte.

- Eingliederung der Objekte in die Protokollschichtung, die Funktionsbereiche, das Domänenkonzept, die Zeithorizonte.

- Festlegung der zulässigen Relationen zwischen "managed objects".

e) Konventionen zum Austausch von Management-Informationen durch Festlegen von Kommunikationsdiensten und Protokollen.

Schwerpunkt ist die

OSI-Standardisierung

Die Standardisierung innerhalb des Bereichs Netzmanagement bildet seit einigen Jahren einen Schwerpunkt innerhalb der Arbeiten der ISO auf dem Gebiet "Open Systems Interconnection". Kernstück ist das .,Management Framework" (ISO DIS 7498-4), ein Zusatz zum OSI Referenzmodell, in dem grundlegende Konzepte und Begriffe des OSI-Netzmanagements festgelegt werden. Diese Grundkonzepte können an folgenden Bildern erläutert werden.

Die OSI-Standardisierung sieht das Netzmanagement vornehmlich als verteilte Anwendung zwischen kooperierenden Systemen und faßt das Gesamtmanagement-Verhalten unter dem Begriff "systems management" zusammen. Es äußert sich in verteilten Management-Anwendungen (Systemmanagement Application, SMA), die auf die Kooperation verteilter Anwendungsprozesse (System Management Application Processes, SMAP) aufbaut. Die Kommunikationsinstanz (Entity) eines SMAP ist die SMAE; diese benutzt Management-Protokolle, die über Dienste der System Management Application Service Entity (SMASE) abgewickelt werden. Die SMASE ihrerseits benutzt allgemein Dienste der OSI-Anwendungsschicht, oder spezielle für Managementzwecke definierte Dienste, wie die Common Management Informations Services (CMIS), und die zugehörigen Protokolle (CMIP). Es sind dies Dienste zur Verwaltung von Assoziationen (M-lnitialize, Terminate, Abort), Dienste zur Mitteilung von Ereignissen (M-Event-Report) und Dienste zum Anstoßen von Operationen (M-Get, Set, Action, Create, Delete). Diese Dienste können auf ganze Objekte oder Teilobjekte, die durch Teilbäume (scoping) oder Filter auswählbar sind, angewendet werden.

Die Standardisierung legt also unter Berücksichtigung der Funktionsbereiche (configuration, fault, performance, accounting, security) die Syntax und Semantik von Managementinformationen sowie Dienste und Protokolle zu deren Austausch zwischen Systemen fest. Ein solcher Austausch erfolgt mit dem Ziel, fremde Systeme zu steuern, Ereignisse mitzuteilen oder sich zu informieren.

Die Management-Kommunikation über SMAEs setzt im Normalfall volle OSI-Funktionalität, das heißt, Vorhandensein der sieben Schichten, voraus. Falls nur eine beschränkte Funktionalität vorhanden ist (wie zum Beispiel bei Bridges, Router, fehlerhaften Komponenten), sollen layerspezifische Eingriffe (Schleifentests, Fernladen, Routinginformation) über das N-Layer-Management direkt erfolgen können, wobei Layer Management Entities (LME) zweier Systeme miteinander kommunizieren. Das Rahmenmodell nimmt auch zur Kenntnis, daß gewisse Managementinformationen (zum Beispiel Timereinstellungen, Fenstergrößen) bereits beim normalen Protokollablauf durch die Protokoll-Instanzen (PE) ausgetauscht werden.

Alle Instanzen haben Zugriff auf die Basis

Alle Instanzen des Managements haben Zugriff auf die Management Information Base (MIB), die die Gesamtheit von Management-Informationen eines offenen Systems über die OSI-relevanten Ressourcen, die Managed Objects (MO) darstellt. Die MIB ist ein konzeptioneller Behälter, Festlegungen zur konkreten Datenhaltung existieren nicht.

Die Managed Objects stellen innerhalb der Standardisierung einen zentralen Begriff dar. Was grundsätzlich festzulegen ist, wurde am Ende des ersten Kapitels schon gesagt. Die ISO faßt ihre Festlegungen hierzu in einem Dokument "Structure of Management Information" zusammen.

Dieses umfaßt

- die Definition allgemeiner Begriffe, wie managed object, object class, attribute, operation;

- Regeln und Prinzipien zur Namensgebung, wobei wegen der hierarchischen Enthaltenseins-Beziehungen der Objekte eines Systems eine Baumstruktur vorgeschlagen wird;

- Möglichkeiten zur Gruppierung von Objekten zu abstrakten Objektklassen mit gleichen Eigenschaften bezüglich Attributmengen, Operationen etc. (Generic Definition of Management Information, GDMI);

- Festlegung von einfachen Attributen (Name, Timerwerte, Fenstergrößen) und komplexen Attributen (Informationselemente), die eine gewisse Eigendynamik aufweisen, zum Beispiel Aktionen auslösen beziehungsweise Werte ändern können. Beispiele der letzteren sind current status, counter, gauge, threshold, event, log. Für jedes Element sind Struktur und Operationen festgelegt.

- Mechanismen, um Beziehungen (relations) zwischen MOs festzulegen;

- Definitionen von Zustandsmodellen (organisatorisch bedingte und ablauforientierte Zustände) mit Übergangsfestlegungen.

Die MOs lassen sich manipulieren über Dienste, die die Komponente SMASE bereitstellt.

Die Standardisierungsarbeiten laufen in allen Teilbereichen. Höchste Priorität haben die Arbeiten zur Structure of Management Information.

Eine politische und eine subjektive Bewertung

Die Bewertung setzt sich aus zwei Teilen zusammen, einer technischen Kritik und einer politischen Würdigung. Natürlich hat diese Bewertung subjektiven Charakter.

Zur technischen Bewertung: Zunächst muß festgestellt werden, daß die bisherige Festlegung von Diensten, Protokollen und der MIB-Struktur im wesentlichen ohne eine Untersuchung der Anforderungen aus den einzelnen Management-Funktionsbereichen erfolgte. Die Erfordernis von Nachbesserungen am Festgelegten ist abzusehen.

- Die Festlegungen erfolgten rein aus der Betrachtungsweise der Kommunikation, die auch bei der Entwicklung des OSI-Referenzmodells und der OSI-Protokolle angewendet wurde. Während diese Sicht dort angemessen war, scheint sie mir als ausschließliche Sicht im Zusammenhang mit Netzmanagement problematisch, da der Netz-Betreiber nicht nur Einzelsysteme sieht, sondern ein Netz aus OSI-Systemen betreiben soll.

- Der konkrete Einbezug von "OSI related objects" fehlt noch, obwohl im Management die Abbildbarkeit von OSI-Konzepten auf zugrunde liegende reale Systeme eine nicht zu vernachlässigende Rolle spielt.

- Die Behandlung unvollständiger (im Sinne der vollen OSI-7-Schichten-Funktionalität) beziehungsweise fehlerhafter Systeme ist noch nicht erfolgt.

- Die Rückwirkung der OSI-Netzmanagement-Arbeiten auf andere Normungsaktivitäten (zum Beispiel Rückwirkung auf Quality-of-Service-Parameter bei Protokollen, Einbezug der Directoy-Normen) ist noch nicht untersucht.

- Eine ernsthafte und systematische Bearbeitung der Funktionsbereiche hat erst begonnen. Nur im Bereich Konfigurationsmanagement liegen mehr Ergebnisse vor.

- Die MIB ein Dreh- und Angelpunkt für weitere Untersuchungen. Die Festlegung von Objektkatalogen sowie Objektauswahl steht noch aus.

- Domainkonzepte zur Berücksichtigung von Organisationsaspekten im Modell sind erst andiskutiert.

Viele Probleme sind noch zu lösen

Die technische Bewertung zeigt, daß noch viele Probleme zu lösen sind. Die einhellige Meinung vieler Teilnehmer am 1. Internationalen IFIP-Kongreß zum Thema Netzmanagement in Boston im Mai dieses Jahres ist aber, daß wir nicht nur auf einem Weg zu offenen Netzmanagement-Architekturen sind, sondern auf dem richtigen Weg. Das OSI-NM-Framework mit CMIP/CMIS gilt unumstritten als der beste Ansatz für eine Management-Architektur in heterogenen Netzen. Dies wird auch unterstrichen dadurch, daß manche Hersteller in ihre Management-Produkte gezielt bisher bereits gesicherte OSI-NM-Erkenntnisse einbringen. Dies gilt zum Beispiel für die Umstellung im TCP/IP-Protokoll-Stack von SNMP auf CMOT. Netview/Netview-PC verliert für heterogene Netzumgebung an relativer Bedeutung, das OSI-basierte Net/Master von Cincom hingegen gewinnt an Gewicht.

Für die Entwicklung von NM-Werkzeugen ist der zunehmende Trend zu grafischen Bedienschnittstellen deutlich, sowie die Erkenntnis der Notwenigkeit, Managementaktivitäten im Netz zu automatisieren, zum Beispiel mit Hilfe von Expertensystemen. Diese Entwicklung wird durch die OSI-Standardisierung zusätzlich gefördert.

Interessant ist die häufiger geäußerte Meinung, daß eine Anwendung der Konzepte von OSI-NM auch unabhängig von der Benutzung der OSI-Protokoll-Hierarchien Bedeutung .habe. Die Arbeiten zu OSI-NM gelten auch als gute Basis für das Management allgemeiner verteilter Anwendungen.

Nimmt man noch die gewichtige Promotor-Rolle des OSI-Network Management Forums hinzu, dann kann man zusammenfassend feststellen: wir sind auf einem zwar etwas steinigen und langen, aber doch dem richtigen Weg zu einer wohl tragfähigen Netzmanagement-Architektur für offene Kommunikation.