Zehn Jahre ist es her, daß das Simple Network Management Protocol (SNMP) für das Netz-Management entwickelt wurde. Es ist heute das wohl am weitesten verbreitete Protokoll für den Austausch von Management-Informationen zwischen Managed Nodes und Management-Stations. Die Information wird in Form von einfachen Objekten, bestehend aus Name und Wert, übertragen. Diese einfachen Objekte sind in den MIBs (Management Information Base) definiert. Einige davon sind genormt, die meisten aber herstellerspezifisch. Auf der Management-Station muß die Semantik dieser einfachen Objekte bekannt sein, weil hier aus ihnen ein grafisches User Interface aufgebaut wird. Insbesondere die Verknüpfung von Objekten bereitet in der Praxis immer wieder Schwierigkeiten. Für das hauptsächlich im Desktop-Bereich verbreitete DMI (Desktop Management Interface) gilt das gleiche.

Mitte der 90er Jahre änderte sich der Zugriff auf entfernte Daten übers Netz ganz entscheidend durch HTML (Hypertext Markup Language) und HTTP (Hypertext Transfer Protocol). Statt komplizierte Kommandos abzusetzen, klickte man sich mit Web-Browsern durchs Netz. Warum, so die zwangsläufige Frage, sollte man diese Technologie nicht auch für das Netz- und System-Management einsetzen?

Um Web-basiertes Management in einheitliche Bahnen zu lenken, wurde im Juli 1996 die Initiative Web-based Enterprise Management (WBEM) gegründet. Seit Juni 1998 verantwortet die Distributed Management Task Force (DMTF) die gesamten Normungsaktivitäten. Bei ihren Arbeiten konzentrierte sich die DMTF auf drei Schlüsseltechnologien:

- auf das objektorientierte Common Information Model (CIM) zur Datenmodellierung.

- auf HTTP als Zugriffsmechanismus. Der alternative Vorschlag für verzeichnisbasierte Netze verwendet statt dessen das Lightweight Directory Access Protocol (LDAP).

- auf XML als Transportcodierung.

Außerdem sollten existierende Standards wie SNMP und DMI weiterhin eingebunden werden können. Im WBEM-Modell kommunizieren auf dem Managed Node diverse Informationslieferanten, sogenannte Provider, mit einem als CIM Object Manager (CIMOM) bezeichneten Dienst.

Bei diesen Informationslieferanten kann es sich um herkömmliche SNMP- oder DMI-Agenten, aber auch um speziell für CIM entwickelte Software handeln. Investitionen in bestehende Agenten behalten also ihren Wert. Statische und interne Verwaltungsinformationen können zudem im CIM-Repository abgelegt werden.

Der CIMOM stellt für Management-Applikationen eine konsolidierte Sicht auf die verfügbaren Informationen bereit. Diese läßt sich zum Beispiel auch als HTML-Seite für einen Web Browser aufbereiten. Der bevorzugte Transportmechanismus ist jedoch XML über HTTP.

WBEM - Normung von CIM

Ein Schwerpunkt der WBEM-Initiative ist die Entwicklung des objektorientierten Common Information Model. CIM verwendet anders als die einfachen Objektdefinitionen von SNMP und DMI eine Klassenhierarchie, in der ein neues Objekt nur als Instanz einer in dieser Hierarchie enthaltenen Klasse definiert werden kann.

Zudem lassen sich Relationen zwischen Objekten über Assoziationen modellieren, wobei Assoziationen wieder Objekte innerhalb der Klassenhierarchie darstellen. Dadurch ist es möglich, komplexe Zusammenhänge in der Vielzahl von Management-Daten auszudrücken. Die eigentlichen Management-Daten werden in den Properties der Objekte untergebracht.

Die Bestandteile des CIM werden über sogenannte Schemata definiert:

- Meta-Schema: Diese Spezifikation der DMTF definiert keine Klassen, sondern legt die Regeln fest, wie Schemata zu definieren sind.

- Core-Schema: In diesem Schema definiert die DMTF die Klassen der obersten Ebenen in der Vererbungshierarchie. Davon werden letztendlich alle CIM-Klassen abgeleitet.

- Common Schemata: Verschiedene Arbeitsgruppen der DMTF definieren bereichsspezifische, herstellerneutrale und von den Klassen des Core-Schemas abgeleitete Klassen. Beispiele sind Systeme und Peripheriegeräte, Netzwerke, Applikationen, Datenbanken und Ereignisse. Der Prozeß der Standardisierung ist noch längst nicht abgeschlossen. Erst kürzlich wurde mit CIM, Version 2.3, ein Event-Modell spezifiziert.

- Extension Schemata: Hersteller können ihre eigenen Klassen in diesem Schema definieren. Diese sollen jedoch von Klassen des Common-Schema abgeleitet werden. Das hat gegenüber den Mechanismen von SNMP/DMI den Vorteil, daß auch unbekannte, herstellerspezifische Klassen eingeschränkt im Kontext des Vererbungsbaums interpretiert werden können. Der Wildwuchs an herstellerspezifischen MIB-Objekten wird dadurch bei CIM unterbunden. Beispiele für herstellerspezifische Schemata sind das Win-32-Schema von Microsoft oder das FSCSV-Schema (Fujitsu Siemens Computers Serverview) für das Server-Management von Fujitsu-Siemens-Rechnern.

Neben der eher theoretisch orientierten Arbeit der DMTF sind inzwischen auch CIM-Implementationen entstanden. So hat Microsoft bereits mit der Windows Management Instrumentation (WMI) eine Umsetzung eines CIMOM sowie mehrerer Provider in einigen Windows-Versionen zur Verfügung gestellt. Die erste ausgereifte Version wird jedoch erst mit Windows 2000 erwartet. Die meisten Komponenten und Systemeinstellungen eines Windows-basierten Systems sind bei dieser Lösung als CIM-Objekte erhältlich. Der Zugriff auf die Informationen kann über eine DCOM-Schnittstelle (Distributed Common Object Model) oder über ODBC (Open Database Connectivity) erfolgen.

Sun steht dem kaum nach und hat mit den Solaris-WBEM-Services ebenfalls eine CIMOM-Implementation im Angebot. Die Architektur und auch die Zugriffsmechanismen ähneln der Microsoft-Ausführung, jedoch wird ein Java-API anstelle von DCOM bevorzugt.

Unabhängig von CIM bietet WBEM zwei Varianten von Web-basiertem Management. Zum einen lassen sich Web-Agenten auf dem Managed Node installieren. Sie stellen somit jedem Web-Browser Management-Daten direkt über HTTP/HTML zur Verfügung. Gegenüber dem traditionellen Management haben sie jedoch eine Reihe von Nachteilen: So steht dem Administrator keine konsolidierte Sicht wie etwa eine Server-Liste oder die Netztopologie zur Verfügung. Damit sind auch keine Server-übergreifenden Abfragen, Trendprognosen oder Reports möglich.

Die zweite Management-Implementation erfolgt mit Hilfe von Web Extensions. Diese Ausführung läßt sich als eine Art Erweiterung von traditionellen Management-Stationen betrachten. Sie bieten dem Anwender ein übers Web abgesetztes User-Interface an. Die genannten Nachteile gelten in diesem Fall nicht.

Web-basiertes Management - die Zukunft?

Die Möglichkeiten des Web-basierten Managements lassen sich nicht generell beurteilen, der Nutzen hängt von der Größe der Konfigurationen ab. In der Regel gibt es in kleineren Unternehmen keinen Administrator der sich voll und ganz der IT-Verwaltung widmet. Meistens teilen sich einige Mitarbeiter diese Aufgaben je nach Bedarf und Kapazität. Wegen des geringen Aufwands ist für diese Klientel der Einstieg mit Web-Agenten sicher sehr verlockend. Da eine Erweiterung nicht möglich ist, müßte das Unternehmen mit Web-basiertem System-Management allerdings parallel eine traditionelle Management-Infrastruktur (eventuell erweitert um Web Extension) aufbauen, falls irgendwann Bedarf an ausführlichen Management-Funktionen bestehen sollte.

In mittleren und großen Konfigurationen steht meist ein Vollzeit-Administrator oder gar ein entsprechendes Team mit dem entsprechenden Know-how zur Verfügung. Ein Einstieg in ein ausschließlich Web-Agenten-basiertes Management ist hier sicherlich nicht zu empfehlen. Web-Agenten und Web Extensions sind eine Ergänzung des traditionellen Managements und werden zunehmend an Bedeutung gewinnen; sie werden jedoch weder kurz- noch mittelfristig die herkömmlichen Verwaltungsverfahren komplett ersetzen können. Sinnvoll ist ihr Einsatz dennoch, weil die Einbettung in das zur internen Kommunikation genutzte Intranet möglich ist. So können verscheidene Abteilungen eines Unternehmens IT-Reports etwa zur Kapazitäts- und Investitionsplanung oder zur Kostenkalkulation einsehen.

Der Fortschritt der Web-Technologie hat dazu geführt, daß HTML den gestiegenen Anforderungen am Informationstransfer nicht mehr gewachsen ist. Die Extensible Markup Language bietet einen Ausweg aus diesem Dilemma, denn sie läßt sich nicht nur zum Dokumenten-Austausch und -Management verwenden. XML ist ein ideales Mittel, um strukturierte Daten zu transferieren. Da CIM-Informationen diesem Kriterium entsprechen, entwickelte die DMTF ein auf das Management abgestimmtes herstellerunabhängiges Austauschformat: Die XML-Document-Type-Definition (DTD) ist ein Austauschformat von CIM-Klassen und -Objekten und für die Abbildung von CIM-Operationen in XML-Dokumente.

Im Vorfeld mußte die DMTF jedoch klären, ob sie für den Austausch von CIM-Daten via HTTP/XML das Schema-Mapping oder Meta-Schema-Mapping heranziehen wollte. Schema-Mapping bedeutet, daß XML-Tags für sämtliche CIM-Klassen definiert werden müssen, also sowohl für die des Core-Schema, der Common-Schemata als auch für alle herstellerspezifischen Extension-Schemata. Es werden deshalb keine CIM-Klassendefinitionen übertragen, weil sie eben in entsprechenden XML-Document-Type-Definitions definiert sind.

Meta-Schema-Mapping bedeutet dagegen, daß XML-Tags für die CIM-Meta-Klassen definiert werden. Das heißt, es gibt beispielsweise XML-Tags für "Class", "Property" und "Qualifier". Die Anzahl der Tags ist durch das von der DMTF verabschiedete CIM-Meta-Schema beschränkt. Für herstellerspezifische Extension-Schemata müssen keine XML-Tags definiert werden, weil sowohl CIM-Klassendefinitionen als auch CIM-Objekte übertragen werden.

Die DMTF hat sich für das Meta-Schema-Mapping entschieden, denn das Verfahren vermeidet, daß für jedes neu definierte CIM-Extension-Schema eine entsprechende XML-DTD vereinbart werden muß. Die Tatsache, daß XML-DTD keine ungeordneten Listen erlauben, würde zu großen technischen Problemen bei ihrer Definition führen. Auch müßte der Vererbungsbaum der CIM-Klassen für das Mapping flach gestaltet werden, wodurch die Vererbungseigenschaft verlorenginge.

Probleme bei der Browser-Darstellung

Die Entscheidung für das Metaschema-Mapping hat jedoch einige Konsequenzen: Man darf nicht erwarten, daß ein Web-Browser XML-CIM-Daten mittels eines XSL-Style-Sheets (Extensible Style Language) in eine vernünftige grafische Darstellung umwandelt, denn es gibt keine Tags für die darzustellenden Objekte wie CPU-Information oder Disk-Information. Es gibt nur CIM-Klassen und CIM-Objekte als Instanzen dieser Klassen.

Ein Browser kann also nur in Tabellenform die Klassendefinitionen, die Instanzen und in Zuordnungstabellen die Zugehörigkeit der Exemplare zu den Klassendefinitionen darstellen. Der Nutzen von XML-CIM besteht darin, daß sich CIM-Daten und CIM-Operationen zwischen CIM-Applikationen in einem genormten Protokoll austauschen lassen. Beide CIM-Applikationen - zum Beispiel zwei CIMOMs - müssen in der Lage sein, die CIM-Klassenhierarchie aufzubauen und die Instanzen darin zu interpretieren. Das ist jedoch keine triviale Aufgabe, die ein XSL-Style-Sheet durchführen kann. Die Lösung auf Basis einer WBEM-Architektur wäre folgende: Eine Management-Station übernimmt diese Aufbereitung der Informationen, und das User Interface wird als Web Extension über das Web zum Browser übertragen.

ANGEKLICKT

Die 1996 ins Leben gerufene WBEM-Initiative hat sich zum Ziel gesetzt, auf Basis von Web-Standards IT-Management-Informationen auszutauschen. Mittlerweile hat das Standardgremium Desktop Management Task Force (DMTF) die Normungsaktivitäten übernommen und mit dem Common Information Model (CIM) eine Grundlage definiert. Es hat sich jedoch gezeigt, daß das im Web übliche Hypertext Transfer Protocol (HTTP) für den komplexen Datenaustausch nicht geeignet ist. Einen Ausweg sucht das Gremium nun mit der Extensible Markup Language (XML).

*Günther Krönert, Siegfried Hempfer und Bernhard Siebert sind Systemarchitekten beziehungsweise Projektleiter bei Jujitsu-Siemens Computers in München.