Einführung und Motivation

  Die zunehmende Komplexität und Heterogenität verteilter Systeme stellt für ihre Betreiber eine große Herausforderung dar. Heutige umfangreiche DV-Infrastrukturen können nur noch dann mit vertretbarem Aufwand administriert werden, wenn man integrierte Managementlösungen einsetzt. Solche Lösungen auf der Basis standardisierter Managementarchitekturen ([3,14]) sollen die Betreiber dabei unterstützen, eine optimale Versorgung der Benutzer mit akzeptablem Aufwand sicherzustellen.

In letzter Zeit trat auf dem Weg zum integrierten Management allerdings eine zusätzliche Komplikation auf: neben proprietären Ansätzen wurden mehrere Managementarchitekturen standardisiert, die teilweise in Konkurrenz zueinander stehen. So ist das bekannte Internet-Management (SNMP-Management) im Bereich des LAN-Managements weit verbreitet, während im Bereich der Telekommunikationsnetze vor allem auf das OSI-Management gesetzt wird. Mit dem Desktop Management Interface (DMI) der DMTF wird derzeit versucht, für das Management von Endsystemen wie PCs oder Workstations einen weiteren Standard zu etablieren. Neuerdings werden auch die Arbeiten der OMG (Object Management Architecture - OMA, CORBA) für die Bereiche des Endsystem- und Anwendungsmanagements zunehmend beachtet. Dem OMG-Ansatz werden heute gute Chancen auf große Verbreitung für die Entwicklung verteilter Anwendungen eingeräumt. Bewahrheitet sich dies, wird er auch für integriertes Management sehr wichtig werden, obwohl er nicht wie die anderen Architekturen speziell auf das Management einer DV-Infrastruktur ausgerichtet, sondern prinzipiell für alle verteilten Anwendungen gedacht ist.

In verteilten und heterogenen Systemumgebungen ist das Management natürlich eine verteilte Anwendung, deren Komponenten von verschiedenen Herstellern stammen. Zentraler Bestandteil einer Managementarchitektur ist damit die Definition eines Beschreibungsrahmens für die zu Managementzwecken ausgetauschte Information. Diese Information wird heute meist objektorientiert modelliert. Der Informationsaustausch findet also z.B. durch Lesen oder Setzen von Attributen sogenannter Managementobjekte oder durch Anwendung von Methoden auf diesen Objekten statt. Je detaillierter diese Information festgelegt ist, desto effizienter ist Management auf der Basis der jeweiligen Architektur möglich. Weiterhin ist offensichtlich ein Kommunikationsprotokoll für diesen Austausch - ein sogenanntes Managementprotokoll - festzulegen.

Vermutlich wird sich nicht eine einzige Managementarchitektur durchsetzen; es wird wohl zu einem Nebeneinander von verschiedenen Architekturen kommen. Wirklich integriertes Management setzt also voraus, daß Übergänge geschaffen werden, die eine nahtlose Kombination der Architekturen erlauben (siehe auch [1,9]). Prinzipiell gibt es hier 3 Alternativen:

• ,,Management-Gateway``: Der Übergang wird durch ein Zwischensystem realisiert, das sowohl eine Übersetzung der Managementinformation als auch die Umsetzung der Managementprotokolle vornimmt. Zuerst müssen also die verschiedenen Spezifikationssprachen, in denen die Managementobjekte beschrieben sind, algorithmisch ineinander überführt werden. Besonders interessant ist die Abbildung der Sprachen des OSI- und des Internet-Managements auf den OMG-Ansatz, da in den beiden erstgenannten Fällen umfangreiche Objektspezifikationen speziell für Managementzwecke existieren, die für CORBA-basiertes Management übernommen werden können. Dieser statische Aspekt der Kooperation von Managementarchitekturen, die sogenannte Specification Translation, wird mit Hilfe von Spezifikations-Compilern behandelt. Zur Laufzeit müssen dann noch die Protokolle bzw. deren Elemente umgesetzt werden, was als Interaction Translation bezeichnet wird. Abb. 1 zeigt ein mögliches Szenario.
• ,,Multiarchitekturelle Plattform``: Hier erfolgt der Übergang innerhalb der Managementplattform, also 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 der Plattform. Häufig findet die Übersetzung der Managementinformation nicht in der Infrastruktur der Plattform statt, sondern muß in den Anwendungen durchgeführt werden. Damit schlagen dann die Unterschiede der Architekturen bis in die Anwendungen durch; es bleibt häufig bei einem bloßen Nebeneinander der Architekturen unter einer gemeinsamen Oberfläche.
• ,,Multiarchitektureller Agent``: In diesem Fall erfolgen die notwendigen Abbildungen im Agenten, also im zu administrierenden System; hier ,,spricht`` der Agent mehrere oder alle ,,Management-Sprachen`` (siehe auch [11,6]). Bei dieser Alternative fällt allerdings der höchste (Implementierungs-)Aufwand an, da naturgemäß die Anzahl an Agenten die der Managementsysteme bei weitem übersteigt. Insbesondere für einfache Komponenten ist eine solche Mehrsprachigkeit nicht sinnvoll realisierbar. Für den Betreiber einer DV-Infrastruktur ist dieser Ansatz irrelevant, da der Quelltext des Agenten vorliegen muß. Dies ist jedoch in der Regel nicht der Fall. Das Papier wird sich deshalb im folgenden auf die ersten beiden Alternativen beschränken.

  

Abbildung: Interoperabilitätsszenario für Managementarchitekturen

Ziel ist bei allen Varianten, die Existenz verschiedener Managementarchitekturen für Benutzer, also die Betreiber einer DV-Infrastruktur, und die Managementanwendungen möglichst weitgehend zu verschatten. Man möchte dem Benutzer eine möglichst einheitliche Sicht auf alle zu administrierenden Systeme bieten und die Implementierung der Anwendungen effizient gestalten.

Im weiteren werden in Abschnitt 2 skizzenhaft die Managementarchitekturen verglichen und die grundsätzlichen Möglichkeiten für Übergänge gezeigt. Anschließend werden konkrete Projekte vorgestellt, die zum einen prototypisch Teile einer multiarchitekturellen Plattform implementiert (Abschnitt 3) und zum anderen Gateways zwischen CORBA und SNMP bzw. zwischen CMIP und SNMP (Abschnitt 4) realisiert haben.