Kriterien für Enterprise Management Architekturen

  Zusätzlich zu den im vorigen Abschnitt beschriebenen grundsätzlichen Aspekten ergeben sich aufgrund der hohen Anforderungen an das Management weitere Bedingungen, denen eine Managementarchitektur genügen muß, um als Basis für das Enterprise Management zu dienen. Diese sind nachstehend aufgeführt:

1.

Der zuverlässige Datentransfer zwischen Managementsystemen: Die zwischen Managerinstanzen ausgetauschten Nachrichten sind, wie das Szenario in Abschnitt aufzeigt, aufgrund ihrer hohen Informationsdichte von großer Wichtigkeit. Es muß daher gewährleistet sein, daß nicht nur Mechanismen zur Manager-to-Manager Kommunikation bestehen, sondern asynchrone Ereignismeldungen von einem Managementsystem zu einer Partnerinstanz auch zuverlässig ihr Ziel erreichen; alternativ zur Anwendung von (meist relativ aufwendigen) Verfahren, die eine ,,exactly-once``-Semantik besitzen, kann auch auf Bestätigungsmechanismen zurückgegriffen werden.

2.

Die effiziente Übertragung großer Datenmengen: Oft müssen sowohl zwischen unterschiedlichen Managern als auch zwischen Managern und Agenten größere Datenmengen ausgetauscht werden. Beispiele hierfür sind das Auslesen der auf einem System eingetragenen Benutzer oder die zum gegenwärtigen Zeitpunkt aktiven Prozesse sowie deren Kenndaten. Letzteres kann, wie Leistungsmessungen an einem von uns entwickelten Managementagenten für UNIX-Systeme ergeben haben, für 100 bis 150 Prozesse zwischen 30 und 45 Sekunden in Anspruch nehmen. Hiervon benötigte die Ermittlung der Managementdaten durch den Agenten sowie deren Übergabe an die Protokollmaschine knapp eine Sekunde; der Engpaßfaktor war hier eindeutig das verwendete Managementprotokoll (im vorliegenden Fall: SNMP). Folglich müssen die Kommunikationsmechanismen darauf ausgerichtet sein, einen zügigen Transfer auch großer Datenmengen zu gewährleisten. Das Szenario in Abschnitt liefert hierfür ein weiteres praxisnahes Beispiel.

3.

Die Skalierbarkeit hinsichtlich sehr großer Mengen an Managementobjekten: Das in Abschnitt beschriebene Szenario verdeutlicht, daß beispielsweise für den Austausch von Abrechnungsdaten zwischen Telekom-Carriern hinsichtlich der Nutzungsdauer geschalteter Verbindungen zahlreiche, sehr feingranulare Managementobjekte, berücksichtigt werden müssen. Überdies sind diese Managementobjekte, die jeweils eine Verbindung repräsentieren, äußerst dynamischer Natur.

4.

Das Bestehen von Sicherheitsmechanismen gegen potentielle Angriffe: Das in Abschnitt aufgeführte Managementszenario hat demonstriert, wie durch unbeabsichtigte Fehlkonfiguration von Managementsystemen in Verbindung mit fehlerhafter Protokollsoftware hohe Kosten entstehen können. Ein bösartiges Ausnutzen dieser Sicherheitsproblematik ist verhältnismäßig unkompliziert und kann beträchtliche Schäden verursachen. Es ist daher notwendig, daß bereits in der Managementarchitektur selbst Mechanismen vorgesehen sind, die die üblichen Bedrohungen (Maskerade, Mitlesen, Modifikation, Verzögerung und Vervielfältigung) verhindern können. Dienste, die diese Mechanismen realisieren, können - je nach Bedarf - bereits von der zugrundeliegenden verteilten Umgebung übernommen, gegebenenfalls verfeinert und an die Bedürfnisse des Managements angepaßt werden.

5.

Das Vorhandensein von Logging-Mechanismen zur Protokollierung außergewöhnlicher Ereignisse ist nicht nur aus Sicherheitsgründen zwingend erforderlich, sondern ist auch im Fehlerfalle von großer Wichtigkeit, um Rückschlüsse auf eventuelle Fehlerursachen ziehen zu können. Nach der Beseitigung des Fehlers sollte es möglich sein, den Fehlerbehebungsvorgang zu dokumentieren und mit den protokollierten Fehlersymptomen zu verknüpfen, um beim Auftreten ähnlicher Fehler bereits über Ansätze zur Behebung des Problems zu verfügen.

6.

Die Verteilung von Managementaufgaben auf mehrere Managementsysteme bzw. die Delegierung von Aufgaben an Agentensysteme sind, wie es bereits in Abschnitt angesprochen wurde, notwendig, um die Skalierbarkeit des Managements auch für sehr große Kommunikationssysteme zu gewährleisten. Eine Architektur für das Enterprise Management sollte über geeignete Mechanismen zum Transfer von Managementfunktionalität verfügen, der sowohl von den Managementsystemen als auch von den Agenten initiierbar sein sollte. Letzteres impliziert eine hohe Autonomie der Agentensysteme, die situationsbezogen von sich aus entscheiden, welche Art von Managementdiensten erforderlich ist und diese aus einem Pool von Diensten beziehen können. Solche Systeme werden als Selbststeuernde Systeme  (Self-managed Systems)  bezeichnet; sie befinden sich jedoch überwiegend noch im Stadium der Forschung [#!weau96!#].

7.

Die Möglichkeit der Abfrage von Metainformationen  (sog. Management Knowledge  oder Kontext-Wissen) über vorhandene Managementsysteme bzw. Agenten zählt ebenfalls zu den wichtigen Managementdiensten, da so beispielweise zur Laufzeit ermittelt werden kann, welche MIBs von einem gegebenen Agenten implementiert werden. Dies ist besonders hilfreich bei der Initialkonfiguration eines Managementsystems, das sich so bereits bei der Autodiscovery des Netzes Detailinformationen bezüglich der darin befindlichen Ressourcen, Systeme und Anwendungen beschaffen kann. So könnten aufgrund der Tatsache, daß ein Managementsystem Router erkennen kann, deren Routing-Tabellen über das Management ausgelesen werden um somit präzise Informationen bezüglich der Netzstruktur zu gewinnen. Bisher müssen die MIBs aller zu administrierenden Ressourcen durch den Administrator in die Plattformen eingespielt werden, damit diese die über den Minimalumfang hinausgehende Ressourceninformation überhaupt nutzen können. Eine andere Anwendung besteht in der Ermittlung derjenigen Agenten, welche gegenwärtig von einem bestimmten Managementsystem überwacht werden oder welche Managementdienste überhaupt zur Vefügung stehen.

8.

Der Reifegrad  einer Managementarchitektur ist oftmals das ausschlaggebende Auswahlkriterium. Dies kann sich einerseits auf den Status des Standardisierungsprozesses beziehen, der ein Maß für die Vollständigkeit der technischen Vision und die universelle Einsetzbarkeit ist. Andererseits ist ein hoher Grad an Marktdurchdringung - der oft als Synonym für Investitionssicherheit gilt - ein wichtiger Indikator für den Reifegrad einer Architektur.

9.

Während die Verfügbarkeit leistungsfähiger Entwicklungswerkzeuge primär kein architekturbezogenes Kriterium zu sein scheint, so hat dies doch großen Einfluß auf die Auswahl einer Architektur: Die Einfachheit der Implementierung, die überwiegend an die Verfügbarkeit von Entwicklungswerkzeugen gekoppelt ist, schlägt sich im Vorhandensein einer hohen Zahl implementierter architekturspezifischer Managementdienste nieder. Im Zweifelsfall wird immer diejenige Architektur bevorzugt, deren eingeschränkter Dienstumfang durch eine vollständige Implementierung kompensiert wird, gegenüber einer Architektur mit einer großen Menge spezifizierter Dienste, die ihrerseits jedoch nur unvollständig am Markt erhältlich sind. So hatte das OSI-Management lange Zeit den Ruf, eine nur unter großen Komplikationen implementierbare Architektur zu sein, weil einerseits lediglich eine sehr komplexe Programmierschnittstelle für das verwendete Managementprotokoll zur Verfügung stand und andererseits nur eine geringe Zahl an spezifizierten Diensten auch tatsächlich implementiert wurde. Nicht zuletzt deswegen konnte es sich im Bereich lokaler Netze nie durchsetzen.

10.

Die einfache Abbildbarkeit der Notationen der Informationsmodelle auf Implementierungssprachen zählt ebenfalls zu den wichtigen Faktoren, von denen die flexible Einsetzbarkeit einer Managementarchitektur maßgeblich abhängt. Wünschenswert ist das Vorhandensein von Abbildungsvorschriften auf eine möglichst hohe Zahl von Implementierungssprachen, um eine Migration proprietärer Managementlösungen hin zu offenen Managementarchitekturen zu vereinfachen.