next up previous contents index
Next: Multiarchitektureller Manager Up: Umbrella Management als Basis Previous: Umbrella Management als Basis

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!#]):


  
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.


next up previous contents index
Next: Multiarchitektureller Manager Up: Umbrella Management als Basis Previous: Umbrella Management als Basis
Copyright Munich Network Management Team