Management by Delegation

  Nachdem also durch CORBA eine Möglichkeit dazu besteht, wird nun betrachtet, was eine flexible Verteilung von Objekten für Vorteile bei der Entwicklung eines Managementsystems mit sich bringt.

Die Struktur nahezu aller gegenwärtig im Einsatz befindlicher Managementsysteme stellt sich wie in Bild dar: Agenten sammeln vor Ort Informationen über die zu überwachenden Bestandteile (Managed Objects), die an den Manager übermittelt werden. Dieser erbringt die eigentliche Managementfunktionalität, indem er die benötigten Daten auswählt, bewertet und nach Bedarf verwendet.

  

Abbildung: Manager/Agenten - Beziehung gebräuchlicher Managementkonzepte

7#7

Dieses Konzept verursacht einen ständigen Datenverkehr zwischen Manager und Agenten, um die Managementinformationen zu übermitteln. Mit einer ansteigenden Zahl von Managed Objects (in der vorliegenden Aufgabenstellung: eine größer werdende Zahl von Webservern) steigt auch die vom Managementsystem übertragene Datenmenge direkt proportional an. Bei einer festen Bandbreite des Netzwerkes bedeutet dies einen höheren prozentualen Anteil am Gesamtdatenverkehr. Diese ungenügende Skalierbarkeit kann theoretisch sogar soweit führen, daß das Netz bereits durch die Managementdaten überfordert ist.
Auch im Fehlerfalle kann dieses Konzept zu Schwierigkeiten führen. Sobald Probleme im Netzwerk auftreten, nimmt der Datenverkehr weiter zu, da der Manager eine Vielzahl von Informationen benötigt, um korrekt reagieren zu können. Es entsteht also genau dann die größte Belastung, wenn das Netz am wenigsten dazu in der Lage ist sie zu bewältigen. Im Extremfall gelangen die entscheidenden Daten überhaupt nicht zum Manager und das Problem bleibt bestehen.

Das Management by Delegation Paradigma bietet hier einen Lösungsansatz. Eine Verschiebung (Delegation) der Funktionalität vom Manager hin zum Agenten, wie in Abbildung aufgezeigt, bedeutet weniger Datenverkehr, da die Informationen direkt vor Ort ausgewertet werden können, ohne den Weg über das Netzwerk zu beschreiten. Dadurch ist eine wesentlich bessere Skalierbarkeit gegeben.
Beim Auftreten eines Fehlers entfällt die zusätzliche Last aus dem selben Grund und erleichtert damit die Gegenmaßnahmen. Die lokalen Daten liegen auch dann vor, wenn das Netz völlig zusammengebrochen ist und ermöglichen zusammen mit den entsprechenden Funktionen auch unter diesen Umständen eine adäquate Fehlerbehandlung.
Wenn die Verzögerung durch den Transport der Daten wegfällt, kann entsprechend schneller auf eingetretene Ereignisse reagiert werden. Solche Zeitvorteile sind vor allem dann relevant, wenn es sich um Hochgeschwindigkeitsnetze handelt, bei denen ebensoschnelle Reaktionszeiten erforderlich sind.

  

Abbildung: Verlagerung von Funktionalität vom Manager zu Agenten

8#8

Unterschieden wird dabei die dynamische und die statische Delegierung. Dynamisch bedeutet in diesem Zusammenhang die Verlagerung von Funktionalität zur Laufzeit, während statisch eine andere Festlegung der Funktionsaufteilung bei der Implementierung bezeichnet, die später nicht mehr verändert werden kann. Mit einer dynamischen Vorgehensweise ließe sich beispielsweise ein Zuladen der jeweils gerade benötigten Funktionalität mit anschließender lokaler Ausführung realisieren. Sie ermöglicht eine wesentlich höhere Flexibilität als die statische Variante und benötigt dennoch nur die gerade erforderlichen Ressourcen, stellt aber ebenso höhere Anforderungen an die Verwaltung des Gesamtsystems.

Aber auch dieser Ansatz weist einige Tücken auf. Es kann nicht Alles beliebig delegiert werden. Gerade Anwendungen wie das Fehlermanagement benötigen oft die Übersicht über das ganze Netzwerk und nicht nur über eine Komponente damit der Fehler lokalisiert werden kann. Dies ist zwar ebenfalls lösbar, jedoch nur unter Verwendung von traditionellen Manager/Agenten - Beziehungen.

Aus den genannten Gründen müssen bei der Umsetzung eines Managementkonzepts nach diesem Paradigma Überlegungen angestellt werden, welche Funktionalitäten delegiert werden können und welche sinnvollerweise nicht.

4