Zusammenfassung

    Dieses Kapitel hat anhand der drei möglichen Integrationsansätze aufgezeigt, daß es durchaus möglich und aussichtsreich ist, Übergänge zwischen Managementarchitekturen im Sinne eines Umbrella Managements zu schaffen. Diese Übergänge können allerdings, auch das hat sich bei unseren Implementierungen gezeigt, wegen der Unterschiedlichkeit der Architekturen zwangsläufig nicht nahtlos sein. Ein charakteristisches Beispiel hierfür ist die Tatsache, daß die im Internet-Management nicht vorhandene Fähigkeit zur automatischen Ermittlung der unterstützten MIBs neuer Ressourcen bedingt, daß die zugehörigen MIBs einem Manager bzw. Gateway immer ,,von Hand`` bekanntgegeben werden müssen.

Während der Darstellung der Interoperabilitätsproblematik von Managementarchitekturen mehrere Veröffentlichungen (z.B. [#!glha96!#], [#!kase94!#]) gewidmet sind, so liegen bis zum heutigen Tage kaum konkrete Betriebserfahrungen mit Implementierungen vor, die eine abschließende Bewertung der Alternativen gestatten. Beispielsweise befaßt sich [#!glha96!#] mit dem auf multiarchitekturellen Agenten (dort als ,,Q-Addition`` bezeichnet) basierenden Ansatz sowie Gateway-basierter Integration (,,Q-Adaptation``), läßt jedoch eine abschließende Bewertung offen.

  

Abbildung: Bewertung der Alternativen für das Umbrella Management

Demgegenüber haben wir anhand unserer Prototyp-Implementierungen den Versuch unternommen, eine solche Bewertung hinsichtlich der von uns zu Beginn dieses Kapitels formulierten Anforderungen vorzunehmen, die in Abbildung dargestellt ist. Es fällt dabei auf, daß der Gateway-basierte Ansatz die meisten positiven Eigenschaften für sich verbuchen kann, da insbesondere die Mechanismen zur Umsetzung der Informations- und Kommunikationsmodelle demnächst standardisiert werden und somit vollständig das Kriterium der Offenheit erfüllen. Der wohl wichtigste Vorteil von Management-Gateways besteht darin, weder Modifikationen an Managern noch an Agenten vornehmen zu müssen, was sich in der Unabhängigkeit von konkreten Produkten und somit in einem breiten Anwendungsspektrum äußert.

Die Durchführung von Leistungsvergleichen gestaltet sich angesichts der stark unterschiedlichen Randbedingungen, denen diese Ansätze unterliegen, als ausgesprochen kompliziert, da die Wahlfreiheit bereits dadurch eingeschränkt wird, ob man von einer Hersteller- (Managementsystem oder Agent), Anwender- oder Systemintegratorenrolle ausgeht. Unzweifelhaft besitzt ein multiarchitektureller Agent sowohl die besten Transparenzeigenschaften für den Netzbetreiber als auch das mit Abstand beste Leistungsprofil, weil hier nicht zwischen Managementarchitekturen vermittelt wird, sondern dieselbe Instrumentierung lediglich um eine weitere Schnittstelle ergänzt wird. Diese Vorteile werden jedoch durch die Tatsache neutralisiert, daß der Zugriff auf die Instrumentierung einer Ressource (und damit die Durchführbarkeit dieses Ansatzes) oft nur dem Ressourcenhersteller vorbehalten ist und folglich weder dem Netzbetreiber (bzw. einem von ihm beauftragten Systemintegrator) noch dem Hersteller eines Managementsystems offensteht.

Unsere Messungen der Antwortzeiten eines Management-Gateways lassen insbesondere erkennen, daß der Preis zur Durchführung komplexer und leistungsfähiger (Scoping und Filtering) Operationen oft durch entsprechend lange Wartezeiten (z.T. mehrere Minuten) erkauft wird, während einfache Zugriffe in Sekundenbruchteilen ablaufen. Der klassische Tradeoff zwischen Komfort bzw. Flexibilität und Komplexität (hinsichtlich Zeit und Platz) bestätigt sich auch an dieser Stelle.

Wir konnten bei der Entwicklung unserer CMIP/SNMP bzw. CORBA/SNMP Gateway-Prototypen ebenfalls feststellen, daß sich mit dem TMN/C++ API die Entwicklung von OSI/TMN-Agenten auf nahezu identische Weise wie die von CORBA-Agenten gestaltet: GDMO-Darstellungen werden von der Werkzeugumgebung durch ein ,,C++ language mapping`` automatisch in entsprechende C++ Klassenrümpfe umgewandelt, welche vom Entwickler um die eigentliche Instrumentierung ergänzt werden müssen. Analog zu CORBA kommt auch hier das Prinzip zum Tragen, den Entwickler von den Spezifika der Kommunikationsinfrastruktur (in diesem Fall: CMIP) vollständig abzuschirmen, was die Komplexität für den Entwickler drastisch senkt. Erkauft wird dieser Komfort jedoch durch den verhältnismäßig großen Umfang eines ausführbaren Agenten, der in unserem Falle (MIB-II und UNIX-MIB) unter Verwendung von shared libraries deutlich über 5 MB betrug und in der standalone-Variante bei knapp 40 MB lag. Es bleibt zu hoffen, daß die weitere Verbesserung der von uns verwendeten relativ jungen Entwicklungsumgebung hier zu signifikanten Effizienzsteigerungen führt.

Auch wenn die Bewertung des multiarchitekturellen Managers diese Ausprägungsform des Umbrella Managements wenig reizvoll erscheinen läßt, so bietet sie für die vorliegende Arbeit einen entscheidenden Mehrwert: Durch die Erweiterung einer SNMP-Managementplattform zu einem multiarchitekturellen CORBA/SNMP-Manager haben wir die Möglichkeit geschaffen, CORBA-basierte Agenten unmittelbar von einer kommerziellen Plattform aus zu administrieren, was wir uns bei der Vorstellung unserer Agentenprototypen in Kapitel zunutze machen werden. Dieser Zusatznutzen wird durch die Tatsache verdeutlicht, daß bis zum heutigen Tage noch keine offene CORBA-Managementplattform auf dem Markt erhältlich ist. Ferner zeigt unser Prototyp auf, wie durch geeignete Modularisierung bisherige monolithische Managementsysteme CORBA-konform und folglich verteilbar gemacht werden können. Wir werden diesen Aspekt am Ende von Kapitel vertiefen.

Zusammenfassend läßt sich sagen, daß wir mit dem Umbrella Management die technische Grundlage zur Etablierung eines vollständig CORBA-basierten Enterprise Managements gelegt haben, da wir durch ersteres in die Lage versetzt werden, die klassischen Managementarchitekturen fast nahtlos zu integrieren. Demzufolge können wir bei der Konzeption des von uns im folgenden Kapitel entworfenen Objektmodells verteilter kooperativer Managementsysteme von einer homogenen, CORBA-basierten Umgebung ausgehen, ohne dadurch die Anwendbarkeit unserer Methodik in heterogener Umgebung zu gefährden.

Eine weitere Erkenntnis aus unseren Erfahrungen bei der Implementierung der CMIP/SNMP- sowie der CORBA/SNMP-Gateways besteht darin, daß auch Management-Gateways überwacht und gesteuert werden müssen. Wir haben dies in Abschnitt anhand der Konfiguration zustandsbehafteter Gateways bezüglich der Polling-Intervalle motiviert. Gateways sind aufgrund ihrer Agent/Manager-Doppelrolle ein Spezialfall verteilter kooperativer Managementsysteme, wie wir es in Abschnitt definiert hatten. Folglich wird das im folgenden Kapitel entwickelte Objektmodell neben gewöhnlichen Managementsystemen insbesondere auch Management-Gateways umfassen.