Verteiltes kooperatives Management

      Aus dem erfolgreichen Einsatz von Managementplattformen zur Überwachung und Steuerung von Netzkomponenten folgt die Überlegung, dieselben Verfahren ebenfalls zum Management von Endsystemen (PCs, Workstations, Server) und den darauf laufenden Anwendungen einzusetzen. Hierbei kommen zwei Aspekte ins Spiel, die maßgeblichen Einfluß auf die Organisation des Managements haben:

1.

Während die Zahl an Netzkomponenten in großen Netzen wenige tausend Stück kaum überschreitet, liegt die Zahl der angeschlossenen Endsysteme häufig im fünf- und, unter Umständen, im sechsstelligen Bereich. Die jeweils darauf laufende Anwendungsanzahl ergibt, multipliziert mit der Zahl der Endsysteme, eine in der Regel siebenstellige Menge an Managementobjekten. Folglich scheidet ein zentralistischer, plattformbasierter Ansatz aus Skalierbarkeitsgründen von vornherein aus.

2.

Die für das Management nutzbare Menge an Betriebsmitteln ist bei Endsystemen naturgemäß höher als bei einfachen Netzkomponenten. Demzufolge kann das Management eine wesentlich höhere Menge an Verarbeitungsleistung beanspruchen, was die Entwicklung komplexer Agentensysteme zuläßt.

Die aufgrund Punkt 1 zwingend notwendige Vorverarbeitung bzw. Verdichtung von Managementinformation durch Agenten und die damit verbundene Erhöhung der Verarbeitungslast kann aufgrund der vorhandenen Systemleistung toleriert werden, was einerseits die Managementsysteme entlastet und andererseits eine Verringerung des Kommunikationsaufwandes zwischen Manager und Agenten bewirkt. Außerdem bieten Endsysteme, im Gegensatz zu Netzkomponenten, aufgrund des Vorhandenseins von Betriebssystemen eine vollständige Laufzeitumgebung, die Managementprozessen die Zuweisung von Ablaufprioritäten und adäquates Scheduling ermöglicht. Desweiteren sind auf diesen Systemen häufig virtuelle Maschinen   und sogar Skriptsprachen vorhanden, was die Portabilität der Agentenbestandteile begünstigt, da diese nun als gewöhnliche Softwaremodule vorliegen. Ferner bietet das Vorhandensein hoher Verarbeitungsleistung die Möglichkeit, softwaretechnische Konzepte wie Objektorientierung und Modularisierung anzuwenden, die bisher aus Effizienzgründen noch nicht auf Agentenseite realisiert werden konnten. Beispielweise kann der aus dem Software-Engineering bekannte ,,Componentware``-Ansatz (siehe [#!sims94!#], [#!hump95!#]) unmittelbar für die Implementierung modularer Managementagenten genutzt werden. Die Offenlegung der Schnittstellen von Ressourcenmodulen - also der o.a. Intra-Agenten-Schnittstellen - bildet wiederum die Basis für Multi-Vendor-Umgebungen: Drittherstellern eröffnen sich somit Perspektiven, von ihnen entwickelte Managementkomponenten nahtlos in bestehende Agentensysteme einfügen zu können. Beispiele hierfür sind die Erhöhung des Funktionsumfangs von Agentensystemen, einerseits um Module zur Administration neuer Ressourcenklassen (wie z.B. die Erweiterung eines Agenten zur Überwachung von Betriebssystemparametern um Managementdienste für Datenbanksysteme oder SAP R/3) und andererseits zur Bereitstellung erweiterter, generischer Managementfunktionalität (z.B. allgemeine Dienste zur Auswertung von Meßergebnissen und zur Bildung von Zeitreihenanalysen). Wünschenswert ist in diesem Zusammenhang, die Erweiterung der Agentensysteme um neue Managementfunktionalität zur Laufzeit vornehmen zu können, also neue Managementdienste an einen Agenten zu delegieren. Ein Beispiel hierfür ist die Delegierung   von umfassenden Diagnosediensten an ein Agentensystem, nachdem dieses einen Fehlerzustand an den Manager gemeldet hat. Wir werden in Abschnitt einen Ansatz diskutieren, der dies leistet und diesen in Kapitel für unsere Belange erweitern.

Die Möglichkeit, Managementfunktionalität in verteilten Umgebungen delegieren zu können, bedingt eine Kooperation zwischen den am Managementprozeß beteiligten Systemen. Hierbei sind mehrere Kooperationsmodelle  denkbar: Neben der oben angesprochenen Kooperation von Managern und Agenten ist ebenfalls die Kooperation zwischen Agentensystemen möglich; die Behandlung dieser Art von Kooperationsbeziehungen liegt jedoch außerhalb des Untersuchungsgegenstandes der vorliegenden Arbeit.

Ab einer gewissen Größe eines Rechnernetzes ist auch das koordinierte Zusammenspiel zwischen einzelnen Managementsystemen notwendig: Jeweils für einen Teil des Rechnernetzes zuständige Managementsysteme tauschen Informationen mit Partnersystemen aus, um sicherzustellen, daß die eigenen (d.h. lokalen) Betriebsziele nicht im Gegensatz zu globalen Zielvorgaben stehen. Hierfür kann es nicht nur aus Gründen der Ausfallsicherheit notwendig sein, Managementfunktionalität eines Managementsystems temporär an ein Partnersystem zu delegieren. Wir werden im weiteren Verlauf dieser Arbeit Systeme, die diese Eigenschaften haben, als verteilte kooperative Managementsysteme  bezeichnen und in Abschnitt einige Managementszenarien schildern, die die Wichtigkeit der Kooperation von Managementsystemen illustrieren. Ebenfalls wird dort aufgezeigt, daß die im vorigen Abschnitt gemachten Ausführungen bezüglich fehlender Managementinformation zur Administration von Managementsystemen natürlich auch in verteilten kooperativen Umgebungen gelten. Das wesentliche Unterscheidungsmerkmal zwischen verteilten kooperativen Managementsystemen und Mid-level Managern liegt darin, daß letztere in einer festen, vordefinierten hierarchischen Struktur zum Einsatz kommen. Erstere hingegen unterliegen rein technisch keinerlei Hierarchien, obwohl es jederzeit durch geeignete Konfiguration möglich ist, diese in einen hierarchischen Kontext einzuordnen.

Ein betriebliches Argument für verteiltes koopratives Management ergibt sich aus einer besseren Anpassung des Managements an die realen organisatorischen Gegebenheiten einer Unternehmung, in denen die früher starren Hierarchien oftmals einer flexibleren Matrixorganisation gewichen sind. Mit der Modularisierung und der daraus folgenden Flexibilität gelingt eine bessere Abbildung des Managements auf betriebliche Abläufe (,,Workflows``) und Geschäftsprozesse.

Die in Abschnitt vorgestellte Common Object Request Broker Architecture (CORBA) ist eine für Managementzwecke nutzbare Softwarearchitektur, die die Realisierung verteilten kooperativen Managements begünstigt.