Zusammenfassung

  Während die im vorigen Abschnitt anhand einer Top-down-Vorgehensweise identifizierte Managementinformation und -funktionalität naturgemäß technischer Art ist, fließen in der Praxis bei der Auswahl geeigneter Managementsysteme weitere Kriterien in den Analyseprozeß ein, die im wesentlichen auf die Betreiberanforderungen abzielen. Wir haben dies in einem von uns entwickelten Kriterienkatalog dokumentiert, dessen Ziel darin besteht, Netzbetreiber bei der Evaluierung existierender Managementsysteme zu unterstützen. Im einzelnen haben wir folgende vier Hauptkategorien identifiziert, die in insgesamt 23 Unterkategorien verfeinert wurden. Wir werden im folgenden anhand einiger Beispiele die vier Hauptkategorien skizzieren; der vollständige Kriterienkatalog ist in [#!domb97!#] aufgeführt:

• Unternehmensbezogene Kriterien  umfassen Anforderungen an betriebswirtschaftliche Aspekte eines Managementsystems wie z.B. Preise und Lizenzgebühren, Support und Zuverlässigkeit des Herstellers, Möglichkeiten einer Teststellung, Schulungsaufwand usw.
• Informationsbezogene Kriterien  fokussieren auf die Anforderungen des Informationsaustauschs sowie die Arten, auf Managementinformation zuzugreifen, also Aspekte wie die Art der Speicherung (Dateien, relational, objektorientiert), die Schnittstellen und Abfragesprachen zum externen Zugriff auf Managementinformation und die unterstützten Objektkataloge.
• Funktionsbezogene Kriterien  beziehen sich auf den von einem System bereitgestellten Funktionsumfang, d.h. sie beurteilen aus Benutzersicht die Qualität von MIB-Browsern sowie Autodiscovery- und Autotopologyfunktionen oder die Möglichkeiten zur automatisierten Generierung von Statusberichten.
• Systembezogene Kriterien  zielen auf die Anforderungen eines Managementsystems an die Ablaufumgebung ab wie z.B. die Möglichkeit der Kopplung von Managementsystemen mit Trouble-Ticket-Systemen oder Inventardatenbanken des Betreibers oder die Mechanismen, um im Fehlerfalle Meldungen über E-Mail, Telefon oder Pager an das Wartungspersonal abzusetzen.

Dieser insgesamt über 250 Einzelparameter umfassende Kriterienkatalog konnte bereits mehrfach erfolgreich in der Praxis eingesetzt werden. Während eine solche Aufstellung für den Betreiber von Managementsystemen ein wichtiges Hilfsmittel darstellt, sind wir im Rahmen der vorliegenden Arbeit jedoch an der technischen Instrumentierung verteilter kooperativer Managementsysteme interessiert. Wir werden uns daher ausschließlich auf die in Abschnitt identifizierten technischen Anforderungen stützen.

Diese verdeutlichen die logische Schichtung verteilter Ablaufumgebungen und Managementarchitekturen sowie der darauf aufbauenden spezifischen Managementinformation und -dienste (siehe Abbildung ): Anforderungen wie z.B. Offenheit, Flexibilität und Verteilungstransparenz sind nicht nur notwendige Charakteristiken einer Managementarchitektur, sondern insbesondere Eigenschaften der Middleware , also des Rahmenwerkes für verteilte Verarbeitung, mit dem diese implementiert wird.

  

Abbildung: Wiederverwendbarkeit und Erweiterung von (Management-) Diensten

Wie in Abbildung dargestellt, impliziert die logische Schichtung der Middleware- und Managementarchitekturen, daß eine so implementierte Managementarchitektur eine Vielzahl wichtiger Dienste bereits von der Middleware übernehmen kann und nicht mehr neu definieren muß: Beispiele hierfür sind Dienste zur Zustellung asynchroner Ereignismeldungen und zur Ermittlung von Metainformation (wie die Signatur einer Komponente oder die Zahl der Instanzen). Ist ein Ereignisdienst bereits Bestandteil der Middleware, kann ein davon abgeleiteter Management-Ereignisdienst wesentliche Teile des Funktionsumfangs erben und gegebenenfalls anpassen. Dies ist jedoch für den überwiegenden Teil der in Abschnitt vorgestellten Managementarchitekturen nicht gegeben; somit müssen die dort notwendigen Managementdienste von Grund auf neu implementiert werden. Im Sinne der Einsparung von Entwicklungskosten ist jedoch ein hoher Grad an Wiederverwendbarkeit durch geeignete Abstützung des Managements auf vorhandene Middleware wünschenswert.

Auch in den darüberliegenden logischen Ebenen ist die Wiederverwendbarkeit von Diensten gegeben: Managementinformation und -dienste für ein spezifisches Szenario (hier: das Management von Managementsystemen) stützen sich auf bereits in den darunterliegenden Schichten vorhandene Dienste ab und verfeinern diese gegebenenfalls.

Voraussetzung ist hierfür allerdings, daß entweder die Notationen zur Definition von Information und Diensten sowie die Mechanismen zum Zugriff auf Komponenten einheitlich sind oder geeignete Mittel zur Sicherstellung der Interoperabilität vorhanden sind. Kapitel stellt einige Ansätze vor, die dieses leisten.

Folglich reicht es nicht aus, unsere Betrachtungen auf reine Managementarchitekturen zu beschränken; vielmehr ist es notwendig, im weiteren Verlauf auch Rahmenwerke für verteilte Umgebungen in unsere Überlegungen mit einzubeziehen.

Die in Abschnitt analysierten Managementszenarien sowie die daraus (in Abschnitt abgeleiteten Anforderungen haben ebenfalls verdeutlicht, daß nicht nur ein enger Zusammenhang zwischen Managementinformation und Managementdiensten besteht, sondern der Übergang zwischen diesen beiden Ausprägungsformen von Managementinstrumentierung fließend ist. Ein Beleg hierfür sind die oben besprochenen Möglichkeiten zur Realisierung zustandsbehafteter und abgeleiteter Managementinformation: Diese können entweder in Form von Managementdiensten implementiert sein, die aus der von den Ressourcen zur Verfügung gestellten Basisinformation betreibergerechte Managementdaten generieren oder bereits Teil der Basisinformation sein. Letzteres ist, wie wir in Abschnitt begründet haben, aufgrund der vielfältigen Ausprägungsformen nicht sinnvoll.

Eine weitere Implikation ist die Notwendigkeit einer einheitlichen Notation zur Definition sowohl von Managementinformation als auch von Managementdiensten. Sie wird uns im weiteren Verlauf dieser Arbeit gestatten, dieselben Verfahren zur Modellierung, Spezifikation und Implementierung sowohl von Managementinformation als auch von Managementdiensten anzuwenden.

Wir haben in diesem Kapitel ebenfalls festgestellt, daß Sicherheitsdienste aufgrund ihrer essentiellen Bedeutung bereits auf unterster Ebene eines verteilten Managementsystems vorhanden sein müssen und folglich oft bereits durch die verteilte Ablaufumgebung erbracht und durch die darauf aufbauende Managementarchitektur verfeinert werden. Die anwendungsspezifische Ausgestaltung dieser Dienste des Sicherheitsmanagements besteht daher oft nur in einer geeigneten Wertebelegung der Signatur elementarer Sicherheitsfunktionen.

Dienste, die den Management-Funktionsbereichen Abrechnung und Leistung zuzuordnen sind, sind zu großen Teilen ebenfalls generisch, wie beispielweise die Berechnungsvorschriften für gewichtete Durchschnittswerte oder die Bildung von Analysen über begrenzte Zeiträume. Auch hier können bereits in den Schichten der Ablaufumgebung sowie der Managementarchitektur einige solcher Dienste realisiert werden, die von höheren, problemspezifischeren Diensten geeignet instrumentiert werden. Die Qualität solcher Managementdienste in Bezug auf Betreiberanforderungen hängt jedoch maßgeblich von denjenigen Managementdaten ab, die durch die individuelle, problemspezifische Instrumentierung erbracht werden.

Auf einen speziellen Anwendungsfall individuell zugeschnittene Managementinformation findet man insbesondere in den Bereichen des Konfigurations- und Fehlermanagements, da hier die Spezifizität einer Anwendung am deutlichsten sichtbar wird. Sie bietet uns somit die vielversprechendsten Möglichkeiten zur Abgrenzung dieser Arbeit von verwandten Problemklassen. Daher werden wir uns in Kapitel dieser Arbeit hauptsächlich auf die Modellierung, Spezifikation und Implementierung von Managementinformation und Managementdiensten für diese beiden Management-Funktionsbereiche abstützen.