next up previous contents index
Next: Analyse der Anforderungen Up: Einleitung Previous: Aufgabenstellung

Vorgehensmodell und Ergebnisse dieser Arbeit

  Der Aufbau und die Vorgehensweise dieser Arbeit folgen einem Top-down-Ansatz, der in Abbildung [*] am Ende dieses Kapitels dargestellt ist:


  
Abbildung: Vorgehensmodell dieser Arbeit

Kapitel 2 stellt neben der Definition relevanter Begriffe anhand mehrerer realer Szenarien charakteristische Teilaspekte der Fragestellung der vorliegenden Arbeit vor, die die derzeitige Situation beim Betrieb großer Kommunikationssysteme widerspiegeln. Hieraus werden Anforderungen an das Management verteilter kooperativer Managementsysteme abgeleitet. Diese grundlegenden Anforderungen haben nicht nur Auswirkungen auf das Kooperationsmodell und die Bildung von Managementdomänen sowie die Repräsentation der Managementinformation, sondern auch Konsequenzen für die Bereitstellung bzw. die Granularität der benötigten Managementfunktionalität.

Kapitel 3 analysiert bestehende Konzepte, standardisierte Architekturen und am Markt erhältliche Technologien und grenzt diese Arbeit gegen bereits bekannte Ansätze ab. Es werden diejenigen Möglichkeiten vorgestellt, die gegenwärtige, zum Teil in der Entwicklung befindliche, Architekturen für das Management verteilter kooperativer Managementsysteme bieten. Hierbei wird insbesondere die Common Object Request Broker Architecture (CORBA) einer genauen Betrachtung unterzogen, da sie sich bei unseren Untersuchungen als besonders geeignet für das Enterprise Management herausgestellt hat. Ebenso werden aktuelle Forschungsprojekte mit verwandter Themenstellung sowie kommerziell erhältliche Lösungen und Werkzeuge im Hinblick auf die zentralen Fragestellungen dieser Arbeit kritisch untersucht und bewertet.

Während bisher häufig davon ausgegangen wurde, daß die Unterteilung der zu administrierenden Ressourcen in Domänen hauptsächlich durch organisatorische oder geographische Gegebenheiten festgelegt wird, führt das vierte Kapitel ein weiteres, technisches, Kriterium zur Festlegung von Domänen ein. Es behandelt diejenigen Aspekte, die sich aus der Einführung einer neuen Architektur für das System- und Anwendungsmanagement in das heterogene Managementumfeld eines Netzbetreibers ergeben: Schließlich impliziert der Einsatz einer neuen Managementarchitektur häufig nicht, bestehende etablierte Architekturen vollständig zu ersetzen, da dies in der Praxis aus Gründen der Sicherung bestehender Investitionen nicht machbar ist; es müssen vielmehr Wege geschaffen werden, welche die Koexistenz und Kooperation von Systemen erlauben, die auf unterschiedliche Weise administriert werden. Kapitel 4 untersucht daher die technischen Konzepte der Kooperation von Managementarchitekturen (Umbrella Management), die die Basis bilden, um Enterprise Management überhaupt erst zu ermöglichen. Wir werden dabei anhand von uns implementierter Prototypen aufzeigen, welche Ansätze hierfür besonders geeignet sind. Es wird ebenfalls aufgezeigt werden, wie Managementdienste, die lediglich in einer Architektur vorhanden sind, auch auf Systeme angewandt werden können, deren zugrundeliegende Architekturen ursprünglich keine solche Funktionalität vorsehen. Dies ist wichtig, da der Umfang bereitgestellter Managementdienste zwischen einzelnen Architekturen erheblich variiert. Insgesamt müssen also zusätzlich zu den betreiberspezifischen Anforderungen auch technische Gegebenheiten in die Modellierung einfließen, um ein Objektmodell zu erhalten, das den Ansprüchen integrierten Managements genügt.

Beim Entwurf eines solchen Objektmodells treten zwei wichtige Aspekte auf: Es ist einerseits die Frage zu klären, welche Managementobjekte sowie die dazugehörigen Attribute und Operationen relevant sind. Dies wird im folgenden als der Informationsaspekt  bezeichnet, da sich diese Angaben im wesentlichen auf das Informationsmodell des Systems beziehen. Von ebenso großer Wichtigkeit ist die Fragestellung, welche Dienste für das Management des betrachteten Systems erforderlich sind, also der Funktionsaspekt .

Ziel des fünften Kapitels ist die Bereitstellung aller wichtigen Parameter sowohl des Informationsaspektes als auch des Funktionsaspektes verteilter kooperativer Managementsysteme. Hierbei wird auf anerkannte und verbreitete objektorientierte Analyse- und Designtechniken wie OMT zurückgegriffen. Wir werden in diesem Zusammenhang zunächst eine werkzeugunterstützte, konstruktive Methodik vorstellen, die es uns erlaubt, nahezu automatisch bereits bestehende Managementinformationsbeschreibungen in unsere Zielarchitektur zu überführen. Das zugrundeliegende Vorgehensmodell wird dabei anhand eines einfachen Beispiels aus dem Systemmanagement erläutert: Einem Agenten für das Management von UNIX-Workstations, der am Lehrstuhl entworfen und implementiert wurde. Da die Funktionsfähigkeit der verteilten Anwendung ,,Management`` maßgeblich von der Zuverlässigkeit der darunterliegenden Systeme abhängt, bildet das Systemmanagement die Grundlage für das Management verteilter kooperativer Managementsysteme. Anschließend stellen wir unsere auf einem standardisierten Referenzmodell für offene verteilte Verarbeitung basierende Entwurfsmethodik vor, anhand der die Managementinstrumentierung für verteilte kooperative Managementsysteme entwickelt wurde.

Gegenwärtige objektorientierte Management Information Bases (MIBs) (und damit auch Objektmodelle) sind häufig zwei substanziellen Kritikpunkten ausgesetzt:

1.
Ihnen geht nahezu ausschließlich eine Bottom-up-Analyse voraus; sie beinhalten daher lediglich eine unabstrahierte 1:1-Abbildung von konkreten Ressourcenparametern wie Zählern, Pegeln und Bezeichnern in das jeweilige Informationsmodell. Eine Verdichtung mehrerer Ressourcenparameter zu aussagekräftigen Kennzahlen geschieht nicht. Die von den MIBs zur Verfügung gestellten Parameter decken sich daher häufig nicht mit den Daten, die von den Anwendern bzw. Netzbetreibern gewünscht werden.
2.
Die Vererbungshierarchie in den MIBs ist generell ziemlich flach; dies bedeutet, daß der Grad an Wiederverwendbarkeit von Managementinformation sehr gering ist, da der überwiegende Teil dieser Information in ressourcenspezifischen Klassen definiert wird. Die generischen Basisklassen der Vererbungshierarchie enthalten daher nur äußerst wenige verwertbare Informationen.

Das in dieser Arbeit entworfene Objektmodell vermeidet diese beiden Nachteile, da zuerst konkrete Managementszenarien, die beim Betrieb verteilter kooperativer Managementsysteme auftreten, aufgestellt und klassifiziert werden. Die aus ihnen resultierenden Anforderungen an Managementparameter werden aus den Szenarien gewonnen und in die Modellierung aufgenommen. Diese Top-down-Analyse wird anschließend durch eine Analyse der vorhandenen Eingriffsmöglichkeiten (bottom-up) ergänzt, die gegenwärtige Systeme bieten. Sie ist notwendig, um einen hinreichenden Informationsgehalt der in der Top-down-Analyse identifizierten Objekte zu garantieren. Dem zweiten Kritikpunkt wird durch die Optimierung des Objektmodells begegnet, die unter anderem darauf abzielt, einen möglichst hohen Anteil an Managementinstrumentierung bereits in die Basisklassen der Vererbungshierarchie zu integrieren. Hierdurch wird erreicht, daß der Anteil ressourcenspezifischer Managementinformation zugunsten generischer und damit für eine große Ressourcenmenge gültiger Parameter sinkt; der Zugriff auf eine gewisse Anzahl von Informationen über eine neue Ressource ist somit möglich, ohne daß diese Daten einem Managementsystem vorher explizit bekanntgegeben werden müssen[*].

Ferner befaßt sich Kapitel [*] mit dem Funktionsaspekt verteilter kooperativer Managementsysteme. Hierunter versteht man die Identifikation, Spezifikation, Modellierung und Implementierung derjenigen Dienste, die für das Management dieses spezifischen Anwendungsbereiches notwendig sind. Dabei kommt es darauf an, in heutigen standardisierten Managementarchitekturen bereits vorhandene Dienste zu nutzen und - auf diesen aufbauend - weitergehende Funktionalität zu definieren. Zu diesem Zweck werden die für unseren Anwendungsbereich relevanten Dienste aus unterschiedlichen Managementarchitekturen identifiziert und miteinander verglichen. Es wird gezeigt, wie Dienste, die in einer Managementarchitektur vorhanden sind, von einer anderen Architektur genutzt werden können. Dies ist notwendig, um die neu zu entwickelnde Menge der für das Management verteilter kooperativer Managementsysteme notwendigen Managementfunktionalität in akzeptablen Grenzen zu halten. Die Identifikation dieser Dienste geschieht anhand der in den Kapiteln [*] und [*] herausgearbeiteten anwendungsspezifischen bzw. technischen Anforderungen. Die Spezifikation und Modellierung dieser Dienste erfolgt analog zu dem bei der Konzeption des Objektmodells erfolgreich angewandten Verfahren. Hieraus ergibt sich insbesondere, daß die Vorteile der Verwendung einer vollständig objektorientierten Realisierungsarchitektur wie CORBA insbesondere darin liegen, daß sowohl der Informationsaspekt als auch der Funktionsaspekt einheitlich behandelt werden können, da sowohl die Managementobjekte, als auch die zu ihrem Management notwendigen Dienste in Form von Objektklassen modelliert und implementiert werden können.

Kapitel [*] stellt unsere Implementierung des in Kapitel [*] entworfenen Objektmodells sowie die dazugehörigen Managementdienste für das Management verteilter kooperativer Managementsysteme vor. Eine für die Skalierbarkeit einer Managementlösung unabdingbare Voraussetzung ist die Delegierbarkeit von Managementfunktionalität von Managementsystemen an untergeordnete Managementsysteme bzw. Agenten. Folglich wird aufgezeigt, wie Managementfunktionalität in einer CORBA-Umgebung delegiert werden kann; auch hier kommen die Vorteile der Nutzung von CORBA für das Management zum Tragen, da diese Architektur gute Mechanismen zur Delegierung allgemeiner Dienste bereitstellt. Diese werden in der vorliegenden Arbeit auf den Problembereich Management angewandt. Das Kapitel schließt mit einer Schilderung unserer Erfahrungen mit am Markt erhältlichen CORBA-Entwicklungssystemen.

Das Ziel dieser Arbeit ist es also, die Fragestellung zu beantworten, welche Managementinformation und Managementdienste vorhanden sein müssen, um Managementsysteme in heterogener Umgebung effektiv und effizient überwachen und steuern zu können.

Die wichtigsten Ergebnisse der vorliegenden Arbeit lauten wie folgt:

1.
Die Eignung zahlreicher (Management-) Architekturen für ein betriebszielorientiertes Enterprise Management wurde eingehend analysiert und bewertet. Dabei konnte gezeigt werden, daß CORBA hierfür die gegenwärtig besten Voraussetzungen bietet.
2.
Es wurde ein Rahmenwerk für das Umbrella Management definiert, das Mechanismen zur Sicherstellung der Interoperabilität in heterogenen Umgebungen beinhaltet. Die unterschiedlichen Varianten solcher Mechanismen (multiarchitektureller Manager, Management-Gateway, multiarchitektureller Agent) wurden von uns implementiert und auf ihre Einsetzbarkeit hin überprüft und entsprechend bewertet. Hierbei konnten wichtige Erkenntnisse hinsichtlich ihrer praktischen Anwendbarkeit, Effizienz und Skalierbarkeit gewonnen werden.
3.
Anhand unserer prototypischen Implementierungen konnte ebenfalls nachgewiesen werden, daß es aussichtsreich und mit heutigen technischen Mitteln machbar ist, nahtlose Übergänge zwischen unterschiedlichen Managementarchitekturen zu schaffen. Die weitverbreitete Annahme, wonach die Interoperabilität von Managementarchitekturen stets nach dem Prinzip des ,,kleinsten gemeinsamen Nenners`` erfolgt, konnte widerlegt werden.
4.
Es wurde ein werkzeugunterstützter, universell anwendbarer Ansatz entwickelt, der die nahezu vollständig automatisierte Gewinnung CORBA-konformer Managementagenten aus bestehenden modularen Implementierungen gestattet, denen andere Managementarchitekturen zugrundeliegen.
5.
Wir haben eine neue Methodik entwickelt, die es erlaubt, sowohl die Managementsysteme als auch die zu ihrem Management erforderlichen Dienste auf einheitliche Weise mit Hilfe objektorientierter Analyse- und Designmethoden zu spezifizieren. Durch die Verwendung standardisierter Konzepte für offene verteilte Anwendungen wurde erreicht, daß ein Maximum an generischer Managementinformation bereits nahe an der Wurzel der Vererbungshierarchie definiert wird.
6.
Die Erkenntnis, daß CORBA nachweislich (d.h. durch unsere Prototypen) ein solides Fundament für integriertes Enterprise Management bietet; um im realen Betrieb eingesetzt werden zu können, müssen jedoch noch einige spezifische Managementdienste standardisiert werden. Hierfür wurden dem Problembereich dieser Arbeit entsprechende Dienste spezifiziert und implementiert, die ein umfassendes Management verteilter kooperativer Managementsysteme gewährleisten.
7.
Diese spezifischen Managementdienste bestehen zu einem gewissen Teil bereits in anderen Architekturen; folglich wurde in dieser Arbeit ein Verfahren entwickelt, um diese ,,fremden`` Dienste in die OMG-Referenzarchitektur einzubetten.
8.
Es konnte nachgewiesen werden, daß durch die Verwendung von ,,Inband Management`` und eines vollständig objektorientierten Entwicklungsprozesses die Notwendigkeit spezieller Managementprotokolle und -modelle entfällt. Hieraus ergeben sich Vereinfachungen bei der Implementierung von Managementlösungen, da allgemein verfügbare Designmethoden (wie OMT und UML) und Technologien (wie z.B. CASE-Tools) erfolgreich für das Management genutzt werden können.
9.
Bisher ist trotz der Standardisierung einer Vielzahl von MIB-Modulen für unterschiedlichste Ressourcenklassen noch kein Vorschlag für eine Managementschnittstelle von Managementsystemen erfolgt. Die vorliegende Arbeit leistet dies, indem Vorgaben für den notwendigen Umfang an von Managementsystemen bereitzustellender Managementinstrumentierung gemacht werden. Dem mit der Abhängigkeit der Managementapplikationen von konkreten Managementplattformen einhergehenden Verlust der Offenheit und Portabilität kann so gezielt begegnet werden.
10.
Schließlich haben wir uns mit den Aspekten dynamischer Delegierung von Managementdiensten befaßt mit dem Ziel, verteilte kooperative Managementsysteme nach Bedarf mit geeigneter Managementfunktionalität auszustatten.

next up previous contents index
Next: Analyse der Anforderungen Up: Einleitung Previous: Aufgabenstellung
Copyright Munich Network Management Team