ESPRIT-Projekt MAScOTTE

   

Im Zuge des vierten europäischen Rahmenprogramms zur Förderung der Forschung in informationsverarbeitenden Disziplinen (ESPRIT) begann im November 1995 ein Projekt mit zweijähriger Laufzeit, das den Titel MAnagement Services for Object-oriented disTributed sysTEms (MAScOTTE) trägt und folgende Teilnehmer umfaßt: Bull (Frankreich, Hersteller), CSELT (Italien, Anwender), ESA/ESRIN (Italien, Anwender), Fraunhofer IITB (Deutschland, Forschung - Systemintegrator), Iona (Irland, Hersteller) und MARI (Großbritannien, Systemintegrator).

Das Ziel von MAScOTTE [#!mascwp!#] liegt in der Definition, Spezifikation und Implementierung von Managementdiensten für verteilte objektorientierte Systeme. Als Architektur zur Anwendung dieser Managementdienste ist CORBA vorgesehen. Das dem Projekt zugrundegelegte Szenario besteht aus den Anforderungen, die Anwender CORBA-basierter Systeme an das Management haben sowie der Definition hierfür geeigneter Dienste. Folglich konzentrieren sich die Untersuchungen weniger auf die Administration von Netzen und Systemen, sondern auf das Management der Middleware (also der CORBA-Infrastruktur selbst) und die darauf aufbauenden (CORBA-konformen) Anwendungen. Hierzu wurde in MAScOTTE eine von den Objektklassen der X/Open Managed Set Facility (vgl. die Ausführungen zum CORBA-Funktionsmodell in Abschnitt ) abgeleitete sogenannte CORBA-MIB  definiert, die u.a. in [#!usbr97!#] genauer erläutert wird. Folgende Komponenten eines CORBA-konformen Systems sind potentielle Managementobjekte: Object Request Broker, Client-Objekte, Application Objects, CORBAservices, CORBAfacilities. Beispiele für relevante Managementattribute sind: Interface-Name, Anzahl und Referenzen von Instanzen pro Objektklasse, Aktivierungsmodus und Typinformationen zu Instanzen, Rechenzeitverbrauch und aktive Verbindungen pro Instanz. Die Intention des Projekts besteht darin, eine für alle ORBs einheitliche Menge an Instrumentierung bereitzustellen, die durch Vererbung produktspezifisch verfeinert werden kann.

Das MAScOTTE-Konsortium favorisiert CORBA-basiertes Management (CORBA-konforme Agenten und Manager), schließt jedoch ausdrücklich Managementsysteme, die auf anderen Managementarchitekturen basieren (hier: das OSI-Management), mit ein. Diese Form von Outband Management  ist notwendig, da einige der oben angeführten MO-Kandidaten weitreichende Eingriffsmöglichkeiten in die Funktionsweise eines Object Request Brokers gestatten. So soll es beispielsweise möglich sein, die Ursachen für den Zusammenbruch eines ORBs aufzuspüren und zu beseitigen. Dies ist mit ausschließlich CORBA-basiertem (d.h. Inband-) Management nicht möglich.

Um Managementoperationen durchführen zu können, setzt MAScOTTE voraus, daß Entwickler sowohl eines ORBs, als auch einer verteilten Anwendung entsprechende Managementinformation in OMG IDL bereitstellen. Die Summe dieser Managementinformation bezeichnet MAScOTTE als CORBA-MIB; ihre Struktur erhält sie durch die Verwendung von Vererbungs- und Enthaltenseinsbeziehungen. Solcherart definierte Managementinformation wird von Diensten ausgewertet, die ihrerseits von Managementapplikationen aus unterschiedlichen Architekturwelten genutzt werden können. Solche universell nutzbaren Managementdienste werden im Kontext von MAScOTTE als Management Facilities bezeichnet und werden in zwei Klassen eingeteilt:

1.

CORBA Framework Management Facilities beinhalten Dienste für das Management des ORB-Kernsystems.

2.

Facilities for managing object aggregates können wiederum in zwei Kategorien eingeteilt werden:

(a)

Generic Object Management Facilities sind auf alle (Client- und Server-) Objekte anwendbar.

(b)

Specific Service Management Facilities beziehen sich auf das Management von CORBA-Diensten. Im Gegensatz zu den anderen Ausprägungsformen von Management Facilities sind diese nicht Gegenstand von MAScOTTE.

Beispiele für im Rahmen von MAScOTTE entstandene Management Facilities sind:

• CORBA Agent Facility: Generisches (d.h. nicht auf konkrete Produkte zugeschnittenes) Management der CORBA-Infrastruktur.
• Notification Facility: Monitoring von Kommunikationsbeziehungen mit Filter- und Loggingmöglichkeiten.
• Application Definition Facility: Bereitstellung einer Managementsicht auf vollständige Applikationen, d.h. Definition von Gruppen zusammengehöriger Objekte.
• Connectivity Test Facility: Prüfen von Kommunikationsverbindungen zwischen Objekten.
• CORBA Discovery Facility: Ermitteln der Enthaltenseinshierarchie eines gegebenen CORBA-Agenten.

Bei den beiden letzteren handelt es sich um Hilfsdienste (,,Experimental Facilities``) für die drei erstgenannten Dienste; ihre Spezifikation beschränkt sich daher auf den im Rahmen des Projekts notwendigen Umfang, d.h. es werden nur diejenigen Teilaspekte von Diensten spezifiziert und implementiert, die unmittelbar für die Funktionsweise des in diesem Projekt entwickelten Systems erforderlich sind.

Ein weiterer Teil von MAScOTTE befaßt sich mit der Nutzung der CORBA-basierten Managementdienste von einer kommerziellen - also nicht CORBA-konformen - Managementplattform aus (hier: ISM/OpenMaster von Bull). Hierzu ist es notwendig, die Dienstbeschreibungen in die Darstellungsweise der Plattform (hier: OSI SMI) zu überführen und die Dienstaufrufe der Plattform (hier: M-GET, M-SET, M-ACTION, M-EVENT-REPORT) auf die entsprechenden Objektdienste abzubilden. Auf der Plattform laufen Managementapplikationen, die zu einem Teil generisch (Monitor, Alarm, Event, Performance) und zum anderen Teil auf die CORBA-konforme Dienstumgebung zugeschnitten sind (Connectivity Analysis, Monitoring Policies, Reporting Policies, Routing Policies).

Aus den Ergebnissen von MAScOTTE ist neben einem CORBA MIB-Browser [#!corbaass!#] ein Produkt zur Administration eines kommerziellen Object Request Brokers hervorgegangen. Es handelt sich dabei um den OrbixManager [#!orbixmgrwp!#] der Firma Iona, der Dienste für das Management von Orbix bereitstellt, einem weit verbreiteten CORBA-2.0-konformen ORB derselben Firma. Das Ziel von OrbixManager besteht darin, die managementrelevanten Parameter von Orbix in Form von IDL-Schnittstellen zu beschreiben, um sie einem Managementsystem in Form einer offengelegten Management Library  zur Verfügung zu stellen. Sie besteht einerseits aus passiven Informationen wie zum Beispiel Monitoring-Parametern des ORB-Kerns zur Definition von Schwellwerten und zur Erstellung von Meßverfahren. Andererseits stehen sämtliche Konfigurationsparameter des ORBs, die ansonsten in zwei Konfigurationsdateien abgelegt sind, über IDL-Schnittstellen dem (aktiven) Management zur Verfügung. Im Idealfall ist jeder ORB in einem verteilten Rechenverbund mit einer solchen Managementschnittstelle ausgestattet. Auf diese CORBA-Objekte können nun Managementdienste, wie z.B. allgemeine, von der OMG standardisierte Dienste (vgl. hierzu Abschnitt ) oder spezialisierte, auf dieses Produkt abgestimmte Dienste (z.B. Verteilung der Konfigurationsparameter auf alle ORBs eines Verbundes, Entdeckung eines Absturzes von ORB-Applikationen, Schwellwertüberwachungen) angewendet werden. [#!cros97!#] führt dies genauer aus.

Für die Administration des OrbixManager stehen eine graphische Benutzerschnittstelle sowie Kommandozeilenwerkzeuge zur Verfügung. Da die meisten gegenwärtigen Managementsysteme bislang keine CORBA-Schnittstellen besitzen, gehört ebenfalls ein SNMP Proxy zum Umfang von OrbixManager, der eine Konvertierung der CORBA-requests in SNMP-PDUs vornimmt. Diese Umsetzung beschränkt sich jedoch auf diejenigen MIB-Variablen, die unmittelbar Bestandteil von OrbixManager sind; es ist nicht möglich, diesen Proxy um andere MIBs zu erweitern.