Die Notwendigkeit eines Umbrella Managements

  Wir haben aufgrund der von uns in Kapitel durchgeführten Analyse existierender Managementarchitekturen CORBA als Enterprise Management Architektur  ausgewählt. Diese Architektur bildet somit nicht nur das Rahmenwerk für die in Kapitel vorgestellten Objektmodelle und Managementdienste, sondern agiert insbesondere in der Rolle als ,,Management-Backbone``, in den andere Managementarchitekturen integriert werden müssen. CORBA agiert somit in der Rolle einer Architektur für das Enterprise Management; die Integration anderer Architekturen erfolgt anhand definierter Übergänge. Abbildung stellt dies graphisch dar.

Der naheliegende Weg zur Implementierung einer vollständig und ausschließlich auf CORBA basierenden Managementlösung besteht darin, sowohl das Managementsystem als auch die Agenten vollständig in Form verteilter CORBA-Objekte zu implementieren, die über einen ORB interagieren. Um dies sicherzustellen, müssen mindestens folgende drei Voraussetzungen erfüllt sein:

1.

Grundsätzlich muß die Interoperabilität zwischen ORBs gewährleistet sein, d.h. Objekte auf unterschiedlichen Systemen innerhalb des Rechnernetzes müssen in der Lage sein, Daten über die ORBs auszutauschen. Obwohl die bereits im Dezember 1995 verabschiedete CORBA 2.0 Spezifikation dies explizit vorschreibt, ist es bis zum heutigen Tage keinesfalls selbstverständlich, daß zwischen ORB-Produkten unterschiedlicher Hersteller Daten ausgetauscht werden können. Dies bedeutet, daß die Kommunikation zwischen verteilten Komponenten eines Managementsystems derzeit noch nicht in jedem Fall möglich ist.

2.

Eine weitere Voraussetzung ist das Vorhandensein von Managementplattformen, die über CORBA-konforme Schnittstellen sowohl für Managementapplikationen als auch zu den Agentensystemen verfügen. Da das Management hohe Anforderungen an die Sicherheit stellt, bedeutet dies, daß weitreichende Mechanismen für die Autorisierung und Authentifizierung vorhanden sein müssen. Die relativ späte (im zweiten Quartal 1996 erfolgte) Standardisierung des CORBA Security Service hat bisher noch zu keinen tragfähigen Ergebnissen in Form kommerziell erhältlicher Produkte geführt. Folglich ist es zwar möglich, daß einzelne Plattformbestandteile wie Kernsystem, Zustandsmonitor oder Topologiemanager über einen (CORBA 1.2 konformen, d.h. lokalen) ORB kommunizieren; der Austausch von Daten mit Agentensystemen verbietet sich jedoch. Ein Beispiel für eine solche Implementierung ist die Produktlinie IBM Tivoli TME 10, die in Abschnitt besprochen wurde.

3.

Ferner ist schließlich die Verfügbarkeit einer gewissen Mindestanzahl von Managementdiensten notwendig, die beispielsweise das Erzeugen, Gruppieren und Löschen von Managementobjekten sowie die Überwachung von Schwellwerten gestatten oder die Definition von Managementdomänen sowie die Durchsetzung von Zielvorgaben ermöglichen. Hier liegen weitere Defizite: Obwohl gegenwärtig mehr als 18 verschiedene CORBAservices (siehe dazu auch Anhang ) spezifiziert sind, die allgemein verwendbare Grundfunktionalität bereitstellen, verfügen gegenwärtige CORBA-Entwicklungswerkzeuge lediglich über einen kleinen Teil dieser Dienste: Eine CORBA-Implementierung, die über mehr als ein Viertel dieser Dienste verfügt, gilt gegenwärtig als ausgesprochen fortgeschritten. In der Tat ist es schwierig, ORBs zu finden, deren Dienstumfang über essentiell notwendige Basisdienste hinausgeht. Die in Abschnitt angesprochenen Managementdienste von CORBA sind bisher nicht in Form konkreter Implementierungen am Markt erhältlich; im Rahmen der in Kapitel behandelten Dienste für das Management verteilter kooperativer Managementsysteme stellen wir einige Dienste vor, die sich auf das Management verteilter kooperativer Managementsysteme beziehen.

  

Abbildung: CORBA als Management-Backbone

Die Analyse von CORBA in Abschnitt hat jedoch auch verdeutlicht, daß deren gegenwärtiger Entwicklungsstand aufgrund der Insuffizienzen heutiger Werkzeuge sowie des Mangels an geeigneten Implementierungen standardisierter Managementdienste die Entwicklung ausschließlich auf CORBA basierender Managementlösungen noch nicht gestattet. Mechanismen zur Sicherstellung der Interoperabilität von Managementarchitekturen sind daher auch im Hinblick auf die Wiederverwendung anderweitig standardisierter Dienste für integriertes CORBA-basiertes Enterprise Management erforderlich. Die Nutzung von Diensten einer Managementarchitektur durch Systeme, denen ein anderes Rahmenwerk zugrundeliegt, bietet neben der Sicherung bereits getätigter Investitionen insbesondere die Perspektive, Dienste architekturübergreifend zu vererben. So könnten beispielsweise CORBA-basierte Systeme, die derzeit noch nicht über geeignete Managementdienste verfügen, mit Hilfe von OSI-Managementdiensten administriert werden. Abschnitt geht auf diesen Punkt detailliert ein.

Mit dem zukünftigen Aufkommen weiterer neuer Architekturen, die für Managementzwecke verwendet werden können (siehe die Analyse in Abschnitt ) wird offensichtlich die Problematik der Koexistenz und Kooperation von Managementsystemen über die Grenzen heterogener Managementarchitekturen hinweg immer weiter zunehmen. Wirklich integriertes Management impliziert also, daß Übergänge geschaffen werden, die eine nahtlose Kombination der Architekturen erlauben. Prinzipiell gibt es hier drei Alternativen, die sich dahingehend unterscheiden, welches System die Abbildung letztendlich vornimmt. Diese sind in Abbildung dargestellt (siehe auch [#!kene97ac!#], [#!kase94!#]):

• Multiarchitektureller Manager : Die Umsetzung zwischen unterschiedlichen Architekturen erfolgt innerhalb des managenden Systems, das damit mehrere oder alle ,,Management-Sprachen spricht``. Damit ist auch keine direkte Umsetzung der Protokolle notwendig, sondern jeweils nur eine Abbildung auf das entsprechende Kommunikations-API des Managers. Häufig findet die Übersetzung der Managementinformation allerdings nicht in der Infrastruktur des Managers statt, die gegenwärtig durch sogenannte Managementplattformen bereitgestellt wird (vgl. hierzu [#!hean99a!#]), sondern muß in den darauf aufbauenden Managementanwendungen durchgeführt werden. Hinsichtlich der Unterscheidung zwischen den Begriffen ,,Manager`` und ,,Managementplattform`` sei bereits an dieser Stelle angemerkt, daß in Zusammenhang mit Interoperabilitätsuntersuchungen die Rollenbezeichnung ,,Manager`` häufig als Synonym für ihre Implementierungsausprägung ,,Managementplattform`` verwendet wird. Wenn in den folgenden Ausführungen die Rolle eines überwachenden und steuernden Systems gemeint ist, werden wir die Begriffswelt des Organisationsmodells verwenden und von einem ,,multiarchitekturellen Manager`` sprechen; ist hingegen seine technische Realisierung gemeint, verwenden wir den Begriff ,,multiarchitekturelle (Management-) Plattform``. Abschnitt stellt anhand eines von uns entwickelten und implementierten Prototypen die Verfahren zur Entwicklung multiarchitektureller Manager detailliert vor und bewertet diese.
• Multiarchitektureller Agent : Die notwendigen Abbildungen erfolgen bereits im Agenten, also im zu administrierenden System oder werden durch entsprechende Vorgaben an dessen Realisierung überflüssig gemacht. Abschnitt führt dies genauer aus.
• Management-Gateway : Der Übergang wird durch ein Zwischensystem realisiert, das sowohl eine Übersetzung der Managementinformation als auch die Umsetzung der Managementprotokolle vornimmt. Dies geschieht in zwei Schritten: Zuerst müssen die verschiedenen Spezifikationssprachen, in denen die Managementobjekte beschrieben sind, algorithmisch ineinander überführt werden. Im zweiten Schritt müssen zur Laufzeit die Protokolle bzw. deren Elemente ineinander überführt werden. Abschnitt beschreibt die hierzu notwendigen Verfahren und unsere prototypischen Implementierungen im Detail.

  

Abbildung: Übergänge zwischen Managementarchitekturen

Die genannten alternativen Ansätze werden in den folgenden Abschnitten bis anhand der von uns entworfenen und implementierten Prototypen detailliert vorgestellt. Unsere Implementierungserfahrungen bilden das Fundament, um in Abschnitt die drei Realisierungsalternativen für das Umbrella Management gegenüberzustellen und hinsichtlich ihrer Komplexität sowie ihrer praktischen Anwendbarkeit zu bewerten.