Integriertes Management

    Einige Faktoren der Bedeutungszunahme integrierten Managements für Client/Server-basierte kooperative IV-Versorgungsstrukturen wurden bereits in der Einführung zu dieser Arbeit identifiziert. Es ist deutlich erkennbar, daß mit zunehmender Verbreitung offener Systeme und leistungsfähiger Kommunikationsnetze die Kooperation verteilter und heterogener Hard- und Softwarekomponenten eine immer größere Rolle einnimmt. Der Preis dafür ist ein komplexeres technisches Management dieser Systeme, das in heterogener Umgebung nur auf der Basis standardisierter Architekturen effizient zu bewältigen ist. Insbesondere kann man zukünftig nicht mehr wie bisher streng zwischen der Administration des Kommunikationsnetzes (Netzmanagement)  und der Administration der Endsysteme (Systemmanagement)  und Anwendungen (Anwendungsmanagement)  unterscheiden. Man muß vielmehr das Management aller Komponenten dieser Umgebungen zu einem integrierten Management   der DV-Infrastruktur zusammenfassen.

Verteilte Systemumgebungen sowie die in ihnen enthaltenen Komponenten unterscheiden sich stark bezüglich ihres Aufbaus, ihrer Größe oder ihrer Ausrichtung. Es kann folglich auch nicht eine einzige Managementlösung für alle verteilten Systeme geben. Ziel muß es vielmehr sein, einen ,,Baukasten`` von Modulen zu entwerfen, in dem die Teile, die einzelne Problembereiche bearbeiten, so flexibel wie möglich zusammengesetzt werden können, um für jede Umgebung zu einer optimalen Managementlösung zu kommen.

  

Abbildung: Management-Gesamtarchitektur

Die systemübergreifende Kombination von Modulen verschiedener Hersteller (siehe Abb. ) wird durch standardisierte Managementarchitekturen  [#!slom94!#,#!hean99a!#,#!rose94!#] ermöglicht. Sie definieren:

• im Organisationsmodell  die Rollen der am Managementprozeß beteiligten Systeme und deren jeweilige Zuständigkeitsbereiche (Domänen) : In der Regel werden Systeme, die aktive Rollen übernehmen, also steuernd auf andere Systeme einwirkend, als Manager  bzw. Managementsysteme  bezeichnet. Andererseits werden passive Komponenten identifiziert, die ihrerseits von anderen Systemen administriert werden; man bezeichnet diese Systeme als Agenten  bzw. Agentensysteme . Es sei bereits an dieser Stelle erwähnt, daß ein System auch beide Rollen spielen kann, d.h. sowohl als Manager, als auch als Agent agiert. Solche Systeme werden im weiteren als verteilte kooperative Managementsysteme  bezeichnet.
• die zur Kommunikation zwischen den obigen Systemen erforderlichen Kommunikationskanäle, die durch Managementprotokolle  realisiert werden. Sie setzen funktionsfähige End-to-End Verbindungen zwischen Managern und Agenten voraus und erlauben die Ausführung von Operationen durch Managementsysteme auf Agentensystemen bzw. die Zustellung von Nachrichten durch Agenten an Manager. Die Spezifikation dieser Aspekte geschieht im Kommunikationsmodell .
• ein einheitliches Format, in dem Managementinformation, also Information, die zu Managementzwecken auszutauschen ist, beschrieben wird. In einer Management Information Base (MIB) , deren Struktur durch das Informationsmodell  determiniert wird, ist die Gesamtheit der Managementschnittstellen abgelegt, die ein Agent einem Manager zur Verfügung stellt. Dies beinhaltet nicht nur alle Operationen, Nachrichten und Attribute, sondern u.U. auch Angaben über die Struktur des vom Agenten verwalteten Systems, wie z.B. Enthaltenseinsbeziehungen zwischen einzelnen Objektklassen. Aufgrund der Tatsache, daß die Systemarchitekturen der eingesetzen Manager- und Agentensysteme völlig verschieden sein können, sind die Datenstrukturen einer herkömmlichen Programmiersprache kein geeignetes Format zur Beschreibung von Managementinformation. Es werden daher oft eigenständige, managementspezifische Notationen zur Beschreibung von Managementinformation verwendet.
• die für das Management von Systemen erforderliche Managementfunktionalität , die sich aus Managementdiensten  zusammensetzt. Typische Beispiele, die im Funktionsmodell  einer Managementarchitektur festgelegt werden, sind Dienste für die Verwaltung der Netztopologie und zur Überwachung von Schwellwerten sowie zur Zustellung, Vorverarbeitung und Filterung von Ereignismeldungen. In objektorientierten Managementarchitekturen werden diese Dienste in einer zur Managementinformation äquivalenten Weise spezifiziert, d.h. in Form von Objektklassen. Da die Beschreibung dieser Dienste plattformübergreifend geschehen muß, finden auch hier managementspezifische Notationen Anwendung. Generell gibt es zwei Varianten, wie Managementdienste ausgeführt sind: Erstere hat zum Ziel, die Semantik von Managementobjekten zu verfeinern, indem diese mittels Vererbung generische Managementinstrumentierung erhalten. Beispiele hierfür sind Dienste zur Berechnung statistischer Größen und zur Bildung von Durchschnittswerten. Die zweite Alternative besteht aus abgesetzt implementierbaren Diensten, die ihrerseits Objektklassen für eigenständige Komponenten enthalten, welche mit den im Informationsmodell spezifizierten Managementobjektklassen interagieren. Typische Vertreter dieser Gattung sind Objekte zur Filterung und Zustellung asynchroner Ereignismeldungen.

Für den Austausch von Managementdaten existieren zwei verschiedene Konzepte: Das sogenannte Pull-Modell  beruht auf dem Abfragen von Agenten durch das Managementsystem, d.h. die Agenten liefern Managementinformation nur auf explizite Anfragen des Managers. Geschehen diese Anfragen in wiederkehrenden zeitlichen Intervallen, spricht man von Polling . Demgegenüber liegt ein Push-Modell  vor, wenn Agenten ohne vorherige Aufforderung durch das Managementsystem selbsttätig Managementinformation an den Manager senden. Dies ist der Fall bei asynchronen Ereignismeldungen, in denen ein Agent einen (oder mehrere) Manager über wichtige Zustandsänderungen informiert. Zwischen diesen beiden Modellen zum Austausch von Managementdaten sind ebenfalls Mischformen möglich, wie beispielsweise das im Internet-Management (siehe ) verwendete ,,trap-directed polling`` . Das Ziel ist dabei, die Reaktionszeit auf Seiten des Managers im Falle von Zustandsänderungen bei den Agenten zu minimieren, ohne zusätzlichen Netzverkehr durch das Setzen verkleinerter Pollingintervalle zu erzeugen: Ein Agent sendet eine asynchrone Ereignismeldung an den Manager, deren Aufgabe weniger darin besteht, Managementdaten zu übertragen, als vielmehr den Manager über das Auftreten eines außergewöhlichen Ereignisses zu benachrichtigen, der seinerseits umgehend (d.h. früher, als eigentlich geplant) einen neuen Pollingzyklus , jedoch mit gleichbleibenden Intervallen, einleitet (vgl. hierzu die in [#!pemc97!#] gemachten Ausführungen).

Sollen Managementlösungen flexibel an verschiedene Einsatzumgebungen angepaßt werden können, müssen sowohl innerhalb der Managementsysteme als auch der Agenten selbst die Module möglichst frei kombinierbar sein. Dies ist notwendig, da bereits auf einem einzigen System häufig eine Vielzahl von Anwendungskomponenten unterschiedlicher Hersteller in ein integriertes Management einzubinden sind. Die Module, die den Anschluß einer Komponente an das Management liefern (sog. Ressourcen-Module) , werden i.a. mit der zu administrierenden Komponente mitgeliefert und stammen in der Regel jeweils von verschiedenen Herstellern. Damit sind auch innerhalb der Agenten Schnittstellen (sog. Intra-Agenten-Schnittstellen)  offenzulegen, um die notwendige herstellerübergreifende Koexistenz und Kooperation der Module eines Agenten zu erlauben. Das reibungslose Zusammenwirken unterschiedlicher Agentenmodule innerhalb eines Agentensystems ist eine wesentliche Grundlage für flexibel konfigurierbare Managementlösungen. In der Literatur [#!whgu98!#] werden Agenten, die diesen Designprinzipien folgen, als erweiterbare Agenten (extensible agents)   bezeichnet; wir werden in Abschnitt darauf genauer eingehen.

Auf der Seite der Managementsysteme erreicht man die geforderte Modularität durch Offenlegung der Architektur und der Programmierschnittstellen sogenannter Managementplattformen , die wesentliche Integrationsaufgaben abdecken: Sie stellen eine gemeinsame Infrastruktur und Ablaufumgebung für Managementapplikationen verschiedener Hersteller bereit und unterstützen dies durch einheitliche Darstellung, Speicherung und Verwaltung sämtlicher Managementobjekte eines Rechnernetzes, auf deren Information mit plattformeigenen graphischen Werkzeugen wie z.B. MIB-Browsern oder kommandozeilenorientierten Hilfsmitteln zugegriffen werden kann. Typischerweise verfügen Managementplattformen über mehrere Kommunikationsmodule, die den Austausch von Managementinformation über standardisierte Managementprotokolle gestatten; die Erweiterung der Plattformfunktionalität um ressourcenspezifische Dienste (wie z.B. das Management von Routern) durch sogenannte Managementapplikationen  ist zwar prinzipiell möglich, da die entsprechenden Programmierschnittstellen (z.B. zur Ereignisverwaltung oder zur Topologiedatenbank) offengelegt (jedoch nicht standardisiert) und Entwicklungswerkzeuge ebenfalls im Lieferumfang enthalten sind bzw. im Rahmen einer Entwicklerlizenz erworben werden können. Die Menge an nutzbaren Schnittstellen und der Komfort der Entwicklungswerkzeuge variieren jedoch erheblich und bieten den Herstellern Möglichkeiten, um sich gegenüber Mitbewerbern abzugrenzen. Folglich basieren Managementapplikationen immer auf konkreten Plattformimplementierungen, was nicht nur den Verlust von Portabilität mit sich bringt, sondern auch das Prinzip offenen Managements konterkariert. So ist beispielsweise die Router-Managementapplikation CiscoWorks auf den Plattformen HP OpenView und IBM Tivoli TME10 NetView ablauffähig, jedoch nicht auf Cabletron SPECTRUM, obwohl der Austausch von Managementdaten in allen Fällen über dasselbe standardisierte Managementprotokoll erfolgt.

Das Netzmanagement  als erste Ausprägungsform integrierten Managements, das auf die Überwachung und Steuerung von Netzkomponenten mit dem Ziel der Bereitstellung von Konnektivität abstellt, hat den breiten Einsatz von Managementplattformen begünstigt, da selbst in großen Rechnernetzen die Anzahl der Netzkomponenten noch relativ überschaubar ist. Der ausgesprochen hohe Kaufpreis, die Komplexität der Bedienung und die beträchtlichen Anforderungen an die Hardware des Systems, auf dem die Plattform läuft, haben zusätzlich dazu geführt, daß der Einsatz von Plattformen häufig eine zentralistische Organisation des Managements impliziert: Wenige, speziell geschulte Netzadministratoren administrieren und überwachen das gesamte Kommunikationssystem von einer zentralen Stelle aus. Eng damit verbunden ist auch der Designgrundsatz, daß sämtliche ,,Managementintelligenz``, d.h. das Problemlösungswissen und die dazugehörige Verarbeitungsfunktionalität an zentraler Stelle vorgehalten werden und Ressourcen lediglich managementrelevante Daten bereitstellen sollten. Dies beruht auf der Tatsache, daß auf Netzkomponenten wie Modems, Multiplexern, Hubs oder Bridges häufig nicht genügend Kapazität zur Vorverarbeitung von Managementinformation vorhanden ist. Ein charakteristisches Beispiel für eine Managementarchitektur, der eine zentralistische Organisation des Managements zugrunde liegt, ist das in Abschnitt besprochene Internet-Management.