Nächste Seite: Mailserver-Systeme Aufwärts: Diplomarbeit: Management verteilter Systeme Vorherige Seite: Historische Ansätze Inhalt
Nachdem in den vorausgegangenen Kapiteln bereits auf die Grundlagentechnologien von CIM (Kapitel 3) und auf ältere Standards für das System Management (Kapitel 4) eingegangen wurde, soll das Common Information Model nun ausführlich erläutert werden.
Zunächst wird auf die Rahmenbedingungen von CIM eingegangen: Anforderungen (denen es gerecht werden soll), Organisationen und Gremien (die CIM entworfen haben und es weiter standardisieren) und die geschichtliche Entwicklung (Kapitel 5.1).
Wie SNMP, DMI oder BlueConf kommen für CIM mehrere Protokollschichten zum Einsatz. Die oberste Schicht bildet dabei ein Datenmodell, das in Kapitel 5.2 vorgestellt wird. Anschließend folgt eine Behandlung der darunter liegenden Protokollschichten für Codierung und Transport, die mit dem Modell zusammen das WBEM-Framework bilden (Kapitel 5.3).
Welche Softwarekomponenten das WBEM-Framework ausmachen, wird dann in Kapitel 5.4 erläutert.
Zuletzt soll noch auf vorhandene Implementierungen von CIM eingegangen werden, seien es Einzellösungen, integrierte Lösungen in die Umgebung von Betriebssystemen oder Managementanwendungen oder Implementierungen für Spezialanwendungen (Kapitel 5.5). Diese Zusammenstellung dient gleichzeitig als kleine Marktübersicht für die später im Rahmen des praktischen Teils dieser Arbeit durchgeführte Pilotimplementierung, bei der solche Produkte als Ausgangsbasis für die Programmierung benötigt wurden (Kapitel 8).
In diesem Kapitel soll zunächst eine kurze Einführung in CIM gegeben werden. Dazu gehören:
Zum Zeitpunkt des Entwurfs von CIM existierten bereits einige Standards für das Management von Systemen und Anwendungen. Die wichtigsten davon wurden bereits in vorangehenden Kapiteln beschrieben, wobei auf ihre Stärken, aber auch ihre Schwächen eingegangen wurde. Da CIM erst später entstand, besteht natürlich der Anspruch, ein Konzept zu bieten, das ausgehend von vorausgegangenen Erfahrungen Verbesserungen mit sich bringt. Somit lassen sich einige Anforderungen an CIM formulieren:
![[*]](footnote.png)
möglich sein. D.h., CIM soll sämtliche
Aspekte des Betriebs eines Informationssystems abdecken, so dass der
Einsatz anderer Standards nicht nötig ist, und somit eine Vereinfachung
zustande kommt. Dies impliziert, dass das CIM zugrunde liegende
Datenmodell sehr mächtig und umfassend ist. Außerdem muss ein
Normierungsgremium dafür sorgen, dass das Modell alle Hersteller
gleichermaßen zufrieden stellt und dass Aktualisierungen eingepflegt
werden.
Kurzum: Bei einer Spezifikation, die diese Vorgaben erfüllt, handelt es sich um einen völlig offenen Standard.
Kein Standard kann ohne eine Organisation existieren, die ihn spezifiziert. Wie bereits angedeutet wurde, gilt dies auch für CIM.
Die Distributed Management Task Force
(DMTF) wurde im Jahre 1992 zunächst als Desktop
Management Task Force gegründet. Dabei handelte es sich um ein
Industriekonsortium, für das folgende Firmen Pate standen:
Ziel der Gründungsmitglieder war es, im Zeichen der Misere des IT-Managements der 90er Jahre (siehe Kapitel 2.5) gemeinsam Standards und Produkte für das Management verteilter PC-Arbeitsplätze zur Verfügung zu stellen. Dies führte zur Spezifikation von DMI, welches bereits in Kapitel 4.3 vorgestellt wurde und somit zumindest unter organisatorischen Gesichtspunkten als Vorläufer von CIM gelten kann.
Da sich DMI jedoch nicht so weit durchsetzen konnte, wie dies durch die Gründungsmitglieder gewünscht war, und sich andererseits weitere Firmen fanden, die an einem übergreifenden Standard interessiert werden, wurde CIM entworfen. Dies führte auch zur Umbenennung der DMTF, die jetzt als Distributed Management Task Force operiert, was den Fokus der Aktivitäten auf das Management verteilter heterogener Systeme setzen soll. Zwischenzeitlich verfügt die DMTF über ca. 30 volle Mitgliedsfirmen und ca. 100 Partnerfirmen, die im Rahmen des Standardisierungsprozesses eine beratende Funktion besitzen.
Im Frühjahr 1996 wurde das erste Release von CIM vorgestellt, seitdem zeichnet sich die DMTF für die weitere Pflege des Datenmodells sowie für die Klärung von Fragen der Softwareinteroperabilität veranwortlich.
Die WBEMsource-Initiativeist eine Arbeitsgruppe der
OpenGroup, die selbst ein Industriekonsortium der
meisten großen Hersteller von IT-Systemen ist. Sie hat sich zum Ziel
gesetzt, die Interoperabilität von IT-Systemen zu fördern.
Aufgaben von WBEMsource sind:
Die OpenGroup hat CIM zwischenzeitlich als eigenen Standard übernommen [22], darüber hinaus wurde er als publicly available specification (PAS) bei der ISO eingereicht.
CIM bietet ein sehr mächtiges Datenmodell. Um diese Mächtigkeit zu erreichen, weist das Modell mehrere Ebenen auf:
Eine Übersicht über alle CIM-Schemata zeigt Abbildung 5.1.
Das CIM Metaschema beschreibt innerhalb von CIM wie Dinge in CIM abgebildet werden -- im Gegensatz zu den anderen Schemata, in denen spezifiziert wird, was dargestellt wird. Somit handelt es sich beim Metaschema um eine Definition der Syntax und der Struktur, bzw. der Grammatik. Verglichen mit SNMP oder DMI entspricht dies der Syntax einer MIB oder einer MIF-Datei.
Grundkonzept des Metaschemas -- und somit auch von CIM -- ist die Verwendung objektorientierter Techniken. Als Beschreibungsspache für CIM kommt daher UML (siehe dazu Kapitel 3.6) zum Einsatz: Die UML-Notation des Meta Schema ist in Abbildung 5.2 abgebildet.
Beim CIM Metaschema handelt es sich um nichts anderes als um eine
Untermenge
von UML mit wenigen Erweiterungen. Die Elemente von UML, die dabei
Verwendung finden, sind im
obigen Diagramm als Klassen vorhanden.
Oberklasse des Metaschemas ist Named Element, eine Klasse, die nur eine Bezeichnung Name beinhaltet. Davon abgeleitet ist die Kernkomponente, die Klasse Klasse. Neben diesem Namen verfügt eine Klasse auch noch über beliebig vielen Methoden und Attributen. Ein besonderes Attribut ist ein Verweis auf eine andere Klasse (Reference). Um einen solchen Verweis zu ermöglichen, muss zwischen den zwei Klassen eine Association definiert sein. Diese Klasse enthält dann nur die Referenzen selbst als Attribute.
Die Vererbungsbeziehung zwischen zwei Klassen wird über die Subtype-Supertype-Assoziation dargestellt. Dabei ist es möglich, Attribute und Methoden der Oberklasse zu überschreiben, was die Property- / Method Override-Assoziation zeigt. Jedes Named Element verfügt über eine beliebige Menge an Qualifiern. Diese bezeichnen bei Attributen und Methoden insbesondere ihren Datentyp bzw. Rückgabewert, können aber auch weitere Angaben zu einem beliebigen Named Element machen.
Ein Beispiel für einen Ausschnitt aus einer Welt, die zwar nicht dem
späteren CIM-Datenmodell entspricht, aber auf Ebene des Metaschemas mit
ihr konform ist, zeigt Abbildung 5.3.
Anhand dieses Ausschnitts aus der Welt des Bahnbetriebs soll nun noch einmal beispielhaft erläutert werden, welche Mittel die CIM-Spezifikation zur Verfügung stellt:
Spezielle Arten einer Klasse werden durch Spezialisierung oder Vererbung abgeleitet. Eine spezielle Form eines Zuges ist ein Fernzug, eine noch spezialisiertere Form ist ein Regionalexpress.
Die Eigenschaften einer Klasse werden durch ihre Attribute (properties) dargestellt. So hat jeder Haltepunkt einen Namen. Durch den Qualifier string wird zusätzlich spezifiziert, dass es sich bei diesem Attribut um eine Zeichenkette handelt.
Auf die Klasse Zug können auch Methoden (methods) angewandt werden. Diese sind Abfahren und Anhalten. Ihr Rückgabewert vom Typ uint32 wird ebenfalls durch einen Qualifier beschrieben.
Attribute und Methoden in Unterklassen überschreiben (override) die jeweiligen Angaben der Oberklasse, mit der gleichen Bezeichnung.
Eine Klasse kann immer als ,,Vorlage``für ein reales Objekt stehen. In CIM wird ein Objekt einer bestimmten Klasse, das real besteht, als Instanz (instance) bezeichnet. Der ICE 639 sei eine Instanz der Klasse ICE.
Ein besonderer Typ eines Attributs ist eine Referenz (reference). Das Attribut Zug der Klasse Fahrplan enthält hier keine Zahl, sondern einen direkten Verweis auf das Objekt, für das der Fahrplan gilt.
Assoziationen können die Eigenschaft weak aufweisen. In diesem Fall ist die Klasse auf der ,,schwachen ``Seite von der starken in ihrer Existenz abhängig: Ohne einen passenden Zug kann es auch keinen Fahrplan dazu geben.
Sobald in CIM Klassen instanziiert werden, ergibt sich eine allgemeine Frage, nämlich die Problematik der eindeutigen Objektidentifikation. Im Speziellen tritt dieses Problem bereits schon in Zusammenhang mit dem Qualifier Reference auf: Wie kann man einen solchen Verweis in Textform darstellen?
Diese Frage ist nichts anderes als die Suche nach einem Objektschlüssel im Bereich der objektorientierten Datenbanken. Hier sind zwei Lösungsansätze bekannt:
.
Ein solcher Schlüssel trägt selbst keine Semantik in sich.
Für CIM entschied man sich zur Schlüsselvergabe zugunsten der zweiten Alternative, da die Rückübersetzung von semantikbehafteten Schlüsseln in reale Objekte problemlos möglich ist. Dies vereinfacht die Implementierung von Software, die mit CIM-Instanzen umgeht, erheblich.
Die Benennung eines Objekts erfolgt damit durch Angabe seiner Klasse und seiner Schlüssel-Wert-Paare nach folgendem Schema:
<Klassenname>.<Schluessel_1>=<Wert_1>,[<Schluessel_x>=<Wert_x>]*
Diese Benennung wird auch als Model Path bezeichnet. Im obigen Beispiel lautet der der Pfad zum Zug ICE 639:
ICE.Nummer=639
Hier ist zu berücksichtigen, dass bei vererbten Klassen das Schlüsselschema erhalten bleibt. Somit muss die ICE-Klasse die gleichen Schlüsselattribute die die Zug-Klasse besitzen. Die Definition eines Schlüssels in einer Unterklasse ist nur möglich, wenn in den Oberklassen keine Schlüsselattribute vergeben wurden, was bedeutet, dass sie abstrakt (abstract) ist.
Ein Spezialfall in Rahmen der Schlüsselvergabe ist eine Weak Reference. Für die existenzabhängige Klasse muss hier nur der Schlüssel der anderen Klasse um weitere Attribute erweitert werden, was sich beispielsweise bei der Klasse Fahrplan zeigt: Bei der Zugnummer handelt es sich um den weitergereichten (propagated) Schlüssel der Klasse Zug. Dieser wird dann noch um das Attribut Wochentag erweitert. Somit lautet der Schlüssel des Sonntagsfahrplans des ICE 639:
Fahrplan.Zugnummer=639,Wochentag=So
Die Angabe eines Model Path alleine reicht jedoch nicht aus, um ein Objekt weiträumig identifizieren zu können: Es kann mehrere CIM-Umgebungen geben, in denen eine Klasse ICE existiert, die dann vielleicht auch eine andere Bedeutung hat. Außerdem geht aus dem obigen Pfad nicht hervor, wie dieses Objekt zu erreichen ist. Für den vollständigen Objektnamen (Object Name) muss dem Model Path daher ein Namespace Path vorangestellt werden, der aus einem Namespace Type (gibt an, welches Zugriffsprotokoll verwendet wird) und einem Namespace Handle (gibt eine Adresse an) besteht. Der vollständige Pfad zur obigen Instanz könnte damit lauten:
http://bahnserver.to.com/root/BAHN:ICE.Nummer=639
In diesem Fall kommt als Zugriffsprotokoll HTTP zum Einsatz (siehe dazu Kapitel 5.3). Die CIM-Implementierung läuft auf dem Host bahnserver.to.com und die Implementierung wird durch die Pfaderweiterung root/BAHN erreicht. Die Trennung zwischen Namespace Type, Namespace Handle und Model Path erfolgt jeweils durch einen Doppelpunkt.
Bisheriges Mittel zur Spezifikation der Klassenstruktur eines CIM-Schemas waren UML-Diagramme, in denen Klassen mit ihren Eigenschaften und ihrem Kontext grafisch dargestellt werden. Für die automatisierte Verarbeitung und den Austausch von Klasseninformationen wurde das Managed Object Format (MOF) spezifiziert. Eine MOF-Beschreibung in CIM entspricht dabei dem MIF-Format von DMI (Kapitel 4.3). Da CIM objektorientiert ist, kann man von MOF auch als einer Interface Description Language (IDL, siehe dazu [11]) sprechen.
MOF-Beschreibungen sind Text-Dateien, in denen Klassen mit ihren Attributen, Methoden und Qualifiern strukturiert dargestellt werden. Die Klasse Zug wird in MOF dargestellt als:
[Description ("Diese Klasse beschreibt einen allgemeinen Zug.") ]
class Zug {
[Key, Description ("Das ist die Nummer des Zuglaufs") ]
uint16 Nummer;
uint32 Abfahren();
uint32 Anhalten();
};
Der Qualifier Description dient dabei dazu, Klassen, Attribute oder Methoden näher zu beschreiben. Eine Assoziation, bei der es sich ja ebenfalls um eine Klasse handelt, enthält jeweils eine Referenz auf eine verbundene Klasse:
[Association]
class Zugfahrplan {
[Key, Max (1), Min (1)]
Zug REF Zug;
[Key, Min (1), Weak]
Fahrplan REF Plan;
};
Die Kardinalität wird durch entsprechende Min- oder Max-Qualifier ausgedrückt, ebenso wie die Tatsache, dass es sich hier um eine Weak Association handelt. Schließlich sei hier noch die Klasse Fahrplan erwähnt, die eine Zugnummer als propagated key enthält:
class Fahrplan {
[Propagated ("Zug.Nummer"), Key, Description ("Ein Fahrplan be- "
"schreibt, wann ein Zug wo anhält.") ]
uint16 Zugnummer;
[Key]
string Wochentag;
};
CIM bietet nicht nur die Möglichkeit, Klassen und Instanzen seitens der Management-Komponente zu manipulieren, es ist auch vorgesehen, dass eine Ressource selbst Ereignisse auslösen kann. Dies entspricht dem Konzept der Traps in SNMP (siehe Kapitel 4.1). Ein solches Ereignis wird in CIM Indication genannt.
Ein Event wird im Metaschema durch die Einführung der Klasse Indication als Unterklasse von Class realisiert und durch den Qualifier Indication angegeben. Im Gegensatz zu einer normalen Klasse sind Indications jedoch nicht persistent, das heißt eine Indication-Instanz wird ausgelöst, an eine Management-Anwendung weitergeleitet und verschwindet dann wieder.
Der Grundstein für das Management von Informationssystemen mit Hilfe von CIM wird durch das Common Schema gelegt. Es definiert einige grundlegende Klassen, die soweit generalisiert sind, dass sie für alle Aspekte des Systems Management verwendet werden können. Andererseits kann man an den Klassen bereits konkrete Verwendungsmöglichkeiten erkennen. Das Core Schema in der im Januar 2003 gültigen Version 2.6 ist auszugsweise in Abbildung 5.4 abgebildet. Die Aktualisierung des Core Schemas erfolgt jeweils gemeinsam mit dem Common Schema (siehe Kapitel 5.2.3).
Basis des Core Schemas und somit der kompletten CIM-Klassenhierarchie ist die Klasse ManagedElement, von der alle CIM-Klassen (außer Assoziationen) direkt oder indirekt abgeleitet werden. Sie enthält lediglich die Attribute Caption für eine Kurzbeschreibung und Description für eine detailliertere Beschreibung.
Eine generische Abhängigkeit zwischen Managed Elements und somit zwischen beliebigen Klassen kann durch die Assoziation Dependency dargestellt werden.
Von ManagedElement abgeleitet ist die Klasse ManagedSystemElement. Sie bildet die Oberklasse für alle logischen und physikalischen Komponenten eines Computersystems und kennt daher als zusätzliche Attribute InstallDate (Datum der Inbetriebnahme), Name und Status. Bei Status handelt es sich um eine Aufzählung verschiedener vordefinierter Zustände wie OK, Stressed (Komponente ist überlastet) oder NonRecover (Komponente hat einen nicht behebbaren Fehler).
Zur Abbildung einer Ist-Teil-von-Beziehung von ManagedSystemElements wurde die generische Aggregation Component definiert. Über sie ist beispielsweise die Aufgliederung eines Computersystems in seine Hardwarekomponenten und weiter in Subkomponenten möglich oder eine Zergliederung einer Softwareinstallation in Pakete mit einzelnen Dateien.
Ein PhysicalElement ist jede beliebige Hardwarekomponente. Sie verfügt über Attribute wie SerialNumber (Seriennummer) oder den boolschen Wert PoweredOn (eingeschaltet).
Bei den meisten Komponenten eines IT-Systems handelt es sich jedoch um LogicalElements -- dies ist die von ManagedSystemElement abgeleitete Klasse, die alle abstrakten Objekte wie Dateien, Benutzeraccounts oder aber auch Service Level Agreements oder Konfigurationseinstellungen umfasst.
Allen LogicalElements sind zwei mögliche Assoziationen gemeinsam: Syncronized (synchronisiert) und LogicalIdentity (logische Gleichheit). Die Erstere dient dazu, zu beschrieben, dass beliebige Objekte miteinander synchronisiert sind (z.B. Filesysteme oder Timer). Die Zweitere legt fest, dass zwei Objekte identisch sind. Da die CIM-Spezifikation keine Mehrfachvererbung zulässt, können auf diesem Weg zwei verschiedene Klassen instanziiert und über LogicalIdentity verknüpft werden.
Von LogicalElement abgeleitet sind LogicalDevice, Service und System. Dabei übernimmt ein LogicalDevice die logische Sicht auf eine Hardwarekomponente (Assoziation Realizes). System stellt eine beliebige Art von System dar, das selbst wieder aus einzelnen Komponenten besteht (Aggregation SystemComponent). Dabei ist SystemDevice eine spezielle SystemComponent, die Geräte mit Systemen verknüpft.
Klassen, die etwas repräsentieren, was eine Dienstleistung zur Verfügung stellt, sind unter Service zusammengefasst. Dienste können voneinander abhängen (ServiceServiceDependency) und Unterdienste beinhalten (Aggregation ServiceComponent). Service stellt auch Methoden zum Starten (StartService()) und Anhalten zur Verfügung (StopService()). Auf welchem System ein Service abläuft, wird durch HostedService gezeigt. Dabei handelt es sich um eine Weak Association, das System erscheint also im Dienst als Fremdschlüssel.
Eine spezielle und die wichtigste Art von System ist ein ComputerSystem, unabhängig davon, wie es implementiert ist (z.B. Einzelsystem oder Cluster).
Zusammenstellungen von Instanzen können in eine Collection aufgenommen werden. Dabei wird über die Aggregation MemberOfCollection auf die Mitgliederobjekte verwiesen. Speziell für ManagedSystemElements wurde dafür die Klasse CollectionOfMSEs mit CollectedMSEs geschaffen. Damit soll es beispielsweise möglich sein, Konfigurationen zu gruppieren, um diese global bearbeiten zu können. Eine CollectionID dient dabei der Identifikation.
Allen bisher vorgestellten Klassen ist gemeinsam, dass sie abstrakt sind. Das bedeutet, dass eine Instanziierung erst im Rahmen einer Unterklasse möglich ist. Konkret äußert sich dies bei den bisher vorgestellten Klassen dadurch, dass Schlüsselattribute nicht oder unvollständig definiert wurden. Eine Methode zur Erzeugung eindeutiger Schlüssel ist jedoch bereits erkennbar: Ein Attribut CreationClassName zeigt an, welche Unterklasse konkret instanziiert wurde. Dies vermeidet einerseits Kollisionen bei gleichen Attributen in verschiedenen Unterklassen, ermöglicht andererseits eine einheitliche Identifikation von Instanzen auf einem hohen Abstraktionsniveau. Für die Klasse ComputerSystem, für deren Unterklassen eine einheitliche Identifikation gefordert wird, wurde zusätzlich das Attribut NameFormat eingeführt, über das festgestellt werden, auf welcher Basis die Benennung des Systems erfolgt, wie z.B. über einen DNS-Name oder eine X.25-Adresse.
Während die 26 Klassen des Core Schema generelle Klassen für das Systems Management umfassen, repräsentiert das Common Schema einen vollständigen Rahmen für das Management von Systemen.
Von den allgemeinen Anforderungen an CIM (siehe Kapitel 5.1.1) lassen sich damit folgende ableiten:
Im Gegensatz zu einem OO-Modell für ein Softwareprojekt ist das Common Model weder an eine unveränderliche Welt gebunden (da sich die Computertechnik in einem ständigen Wandel befindet), noch gilt das Modell für ein bereits vorher definiertes Computerprogramm (da es für alle Managementanwendungen einsetzbar sein soll).
Aus diesem Grund erfolgt eine regelmäßige Aktualisierung des Common Schema durch die DMTF. Notwendige Anpassungen am Core Schema, die möglichst vermieden werden, erscheinen ebenfalls in diesem Rahmen. Die zum Zeitpunkt der Erstellung dieser Arbeit gültige Version 2.6 datiert vom 4. Juni 2002.
Sie umfasst (einschließlich des Core Schema):
Dies stellt einen weitaus höheren Umfang dar als die 171 Standard-OIDs von SNMP. Das Wachstum des Common Schema im Laufe seiner Aktualisierungen geht aus Abbildung 5.5 hervor.
Da das gesamte Common Schema zu groß ist, befasst sich jeweils eine Arbeitsgruppe der DMTF mit der Fortschreibung eines Bereichs. Resultat ist jeweils eine MOF-Datei, in der dieses Teilschema festgelegt ist.
Der aktuelle Entwurf für die Version 2.7 des Common Schema vom 5. Dezember 2002, der Anfang 2003 verabschiedet werden wird, umfasst insgesamt 12 einzelne Schemata, die alle auf dem Core Schema aufsetzen (siehe Abbildung 5.6) und die an dieser Stelle kurz vorgestellt werden sollen.
Eine detaillierte Vorstellung aller 12 Common Schemata würde sicherlich den
Rahmen dieser Arbeit sprengen. Daher soll an dieser Stelle auf die
wichtigsten und die für
den praktischen Teil relevanten Teile eingegangen werden. Tiefgreifendere
Informationen
über die Schemata finden sich auf der Homepage der
DMTF. Vorgestellt
werden im Folgenden:
Da zwischen den Schemata Abhängigkeiten bestehen, müssen die MOF-Beschreibungen in der korrekten Reihenfolge in eine Management-Anwendung geladen werden, um Vorwärtsreferenzen zu vermeiden. Die Vorstellung der Schemata orientiert sich an dieser Reihenfolge.
Das Event Schema dient der Beschreibung von Ereignissen, die in einer CIM-Umgebung ausgelöst werden können und als Indications bezeichnet werden -- siehe dazu auch Kapitel 5.2.1.3. Teile des Event-Modells sind in Abbildung 5.7 dargestellt.
Jede Indication ist von der Klasse Indication abgeleitet. Die weitere Unterteilung erfolgt nach den möglichen Auslösern:
Für Klassen und Instanzen sind jeweils verfeinerte Klassen für Erzeugung, Löschung und Modifikation spezifiziert, bei Instanzen zusätzlich für das Lesen und für Methodenaufrufe.
Das Benutzerschema, das in Abbildung 5.8 stark gekürzt dargestellt ist, dient der Verwaltung von Benutzern, Gruppen, Benutzerrechten und Autorisierungsverfahren.
Kernkomponente ist die Klasse OrganizationalEntity, die beliebige Klassen einer Organisationshierarchie repräsentiert. Über die Aggregation OrgStructure kann damit eine Baum-Hierarchie aufgebaut werden. Darunter liegen folgende Klassen:
Anhand der Attribute der Klassen OrgUnit, Organization, Group und Person ist zu erkennen, dass es sich hierbei um eine direkte Abbildung der entsprechenden LDAP-Klassen handelt. Dieses Vorgehen wurde u.a. deswegen gewählt, da ein unternehmensweites Usermanagement nur über einen solchen Verzeichnisdienst sinnvoll realisierbar ist und LDAP hierzu eine etablierte Grundlage darstellt.
Andererseits führte dies dazu, dass das User-Security-Schema auch innerhalb der DMTF heftig umstritten ist, da es sehr komplex ist. So ist beispielsweise die Korrelation zwischen einem Systemaccount und einer Person, also zwischen den Klassen Account und Person nur über zwei Assoziationen und die Klasse UsersAccess modellierbar, was eine Implementierung erschwert.
Eine Stärke des Modells ist die ausführliche Behandlung von Autorisierungsverfahren., z.B. auf biometrischem Wege, und von kryptografischen Mitteln wie Certification Agencies (beides hier nicht dargestellt). Eine genauere Untersuchung des Modells zeigte andererseits, dass Benutzerbeschränkungen im Schema nicht enthalten sind.
Mittels des Policy Schemas ist die Modellierung von Regel- und Richtliniensätzen und damit von Service Level Agreements (SLAs) möglich.
Gemeinsame Wurzel aller Policy-Klassen ist Policy, von der PolicySet abgeleitet ist, wobei es sich dabei um eine Zusammenfassung gleichartiger Regeln handelt. Über die Aggregation PolicySetComponent wird der Zusammenhang hergestellt. Ausprägungen eines PolicySet sind PolicyGroup und PolicyRule: Ersteres ist eine Sammlung von Policies (allerdings nun nicht mehr abstrakt), zweiteres eine konkrete Regel und damit die zentrale Klasse des Policy Modells.
Eine Regel wird in PolicyRule formuliert, indem im Attribut ConditionListType angegeben wird, wie Zustände, die per PolicyCondition repräsentiert werden, miteinander verknüpft werden, um eine Bedingung auszulösen. Tritt dann eine Bedingung ein, werden alle über PolicyActionInPolicyRule mit PolicyRule assoziierten PolicyActions verarbeitet.
Zur zeitlichen Beschränkung der Gültigkeit einer PolicyRule kann die Klasse PolicyTimePeriodCondition eingesetzt werden -- was die Modellierung von SLAs ermöglicht.
Das Application Schema ermöglicht die Verwaltung von Softwarepaketen und deckt somit einen Teil des Konfigurationsmanagements ab. Abbildung 5.10 zeigt einen Ausschnitt daraus.
Zentrale Klasse ist SoftwareElement, wobei es sich hierbei um ein spezifisches Softwarepaket handelt, das an ein gewisses Betriebssystem (Attribut TargetOperatingSystem) gebunden ist. Der Leistungsumfang des Pakets wird durch eine Menge an SoftwareFeature-Klassen und über SoftwareFeatureSoftwareElements festgelegt.
Für die Installation eines Softwarepaketes ist es auch relevant zu wissen, welche Voraussetzungen erfüllt sein müssen, und welche Aktionen im Rahmen der Installation durchgeführt werden müssen, was in den Klassen Check und Action und über die zugehörigen Assoziationen SoftwareElementCheck und SoftwareElementAction festgelegt wird.
Mögliche spezielle Prüfungen sind beispielsweise MemoryCheck (Prüfung aus ausreichenden Hauptspeicher), SettingCheck (Prüfung auf nötige Systemeinstellungen) und SoftwareElementVersionCheck (Prüfung der Versionsnummer bei abhängigen Paketen).
Mögliche Aktionen sind beispielsweise ExecuteProgram (Ausführen eines externen Programms), FileAction (Modifikation einer Datei) und ModifySettingAction (Verändern von Systemeinstellungen).
Mit Hilfe des System Schema können Computersysteme insbesondere aus Sicht des Betriebssystems modelliert werden. Abbildung 5.11 zeigt dabei die Kernkomponenten.
Die zentrale Klasse ist ComputerSystem, die von System abgeleitet ist. Ein ComputerSystem kann in verschiedenen Ausprägungen existieren: Meist dürfte es ein UnitaryComputerSystem, also ein einzelner Computer, sein. Andere mögliche Varianten sind Cluster (Kopplung mehrerer Computersysteme, die sich nach außen wie einzelnes verhalten) und VirtualComputerSystem (Computer, der durch einen anderen emuliert wird). Daher gibt es für VirtualComputerSystem die Assoziation HostingCS, die auf das emulierende System zeigt, und für Cluster ParticipatingCS, die auf Mitgliedssysteme zeigt.
Zu jeder Art von ComputerSystem gehört eine beliebige Menge an Betriebssystemen (OperatingSystem). Da der Computer für die Identifikation eingesetzt wird, ist die Aggregation InstalledOS zwischen den beiden schwach. Die Aggregation RunningOS gibt zusätzlich an, welches Betriebssystem momentan seinen Dienst verrichtet.
Zu einem ComputerSystem gehören auch immer Dateisysteme (FileSystem) -- die Zugehörigkeit gibt HostedFileSystem an. Diese Dateisysteme können lokal vorhanden sein (LocalFileSystem) oder von einer anderen Maschine importiert werden (RemoteFileSystem). Von welchem Dateisystem ein Betriebssystem bootet, zeigt die Assoziation BootOSFromFS.
Das mit großem Abstand umfangreichste Schema von CIM 2.6 ist das Device Schema: Es dient der Darstellung von Teilen eines Computersystems aus logischer Sicht. Abbildung 5.12 zeigt einen Ausschnitt aus dem Device Schema.
Kernklasse ist LogicalDevice, welche direkt von LogicalElement abgeleitet ist. Sie besitzt Attribute wie PowerManagementCapabilities zur Verwaltung von Stromsparfunktionen. Über StatusInfo kann festgestellt werden, in welchem Zustand sich ein Gerät befindet. Mögliche Werte sind z.B. Enabled oder Unknown. Über TotalPowerOnHours können die Betriebsstunden des Geräts abgefragt werden, mit Reset() kann es neu initialisiert werden.
Über die Assoziation DeviceConnection wird festgelegt, mit welchen weiteren Geräten ein LogicalDevice in Verbindung steht.
Unterhalb von LogicalDevice befinden sich nun alle Arten von Geräten -- insgesamt wurden 20 verschiedene Typen identifiziert und von LogicalDevice abgeleitet:
Mit Hilfe des Physical Schemas können in CIM reale bzw. physikalische Konstellationen modelliert werden. Einen Ausschnitt zeigt Abbildung 5.13.
Kernklasse ist naheliegenderweise PhysicalElement, welche bereits im Core Schema eingeführt wurde. Sie repräsentiert ein beliebiges physikalisches Objekt mit Attributen wie SerialNumber (Seriennummer) oder Manufacturer (Hersteller). Mögliche Unterklassen sind PhysicalPackage, PhysicalComponent, PhysicalConnector und PhysicalLink. Sie haben folgende Eigenschaften:
Ein besonderer Stecker ist ein Slot, welcher der Aufnahme von Steckkarten dient. Die Verkettung von Slots geht aus den Assoziationen SlotInSlot (für Slotadapter) und AdjacentSlots (für Slotexpander) hervor.
Zur Beschreibung des Standorts einer Komponente kommt die Klasse Location zum Einsatz, die eine Position angibt. Die Beziehung zu einem oder mehreren Dingen entsteht durch PhysicalElementLocation.
Um Netzwerktopologien modellieren zu können, wurde das Network Schema
aus der Taufe gehoben. Es ist in der Lage, seine gesamte
Bandbreite zu
repräsentieren, der Fokus liegt dabei aber hauptsächlich auf Ethernet
auf unterer Ebene und IP auf mittlerer Ebene. Da auch VLANs, QoS
und Routingprotokolle berücksichtigt wurden, ist es möglich, die
vollständige Konfiguration von Routern und Switches abzubilden. Einen
Ausschnitt aus dem Network Schema zeigt Abbildung 5.14.
Wichtiger Teil eines Netzwerks ist ein ProtocolEndpoint, also das logische Ende einer beliebigen Verbindung. Mögliche Enden sind z.B. die abgeleiteten Klassen LANEndpoint und SwitchPort. Ob zwei ProtocolEndpoints aus logischer Sicht gerade miteinander in Verbindung stehen, geht aus ActiveConnection hervor.
Ein LANEndpoint ist beispielsweise das Interface einer Netzwerkkarte. Wenn sich ein IP-Dienst mit seinem ServiceAccessPoint in Form seines IP-Ports auf einen spezifischen Adapter bindet, geht dies aus der Assoziation BindsToLANEndpoint hervor.
Ein beliebiger Netzwerkdienst ist ein NetworkService (abgeleitet von Service), der als wichtigstes Attribut über eine Adresse in URL-Form verfügt (ServiceURL). Er kann über ProvidesEndpoint mit einem oder mehreren ProcolEndpoints in Verbindung stehen, über die der Dienst erreichbar ist.
Besondere Sammlungen innerhalb von Netzwerken sind IPAddressRange und LogicalNetwork. Bei letzterem handelt es sich einfach um ein Netzwerk, das (über die Assoziation InLogicalNetwork) eine beliebige Menge ProtocolEndpoints enthält.
Ein CIM Extension Schema (Erweiterungsschema) ist ein Schema, das ein spezifisches Hard- oder Softwareprodukt repräsentiert und im Idealfall mit diesem ausgeliefert wird. Da ein Extension Schema nicht mehr generisch ist, wird es auch nicht durch die DMTF normiert. Statt dessen werden in einem Extension Schema Klassen des Common Schema durch Vererbung für ein konkretes Produkt angepasst.
Durch den objektorientierten Ansatz von CIM ist es auf diese Weise jederzeit möglich, auch proprietäre Systeme einheitlich zu verwalten, solange das Common Schema als Modellierungsgrundlage verwendet wird.
Klassen, die in einer CIM-Umgebung instanziiert werden, sind immer Klassen des Erweiterungsschemas, da nur sie Objekten der realen Welt entsprechen. Vorhandene Implementierungen und somit auch Extension Schemata werden in Kapitel 5.5 vorgestellt. Auch die Beispielimplementierung dieser Arbeit (Kapitel 8) basiert auf einem Erweiterungsschema (Kapitel 7).
Nachdem die oberste Ebene von CIM in Form seiner Spezifikation und seines Datenmodells vorgestellt wurde, soll nun auf seine Komponenten eingegangen werden. Diese werden für die Codierung von Klassen, Instanzen und Operationen darauf benötigt und für deren Transport. Damit wird eine Kommunikation zwischen Manager und Ressource innerhalb einer CIM-Umgebung ermöglicht.
Die Erweiterung von CIM zu einem Gesamtframework wurde 1998 auf Initiative der DMTF vollzogen, um eine Interoperabilität auf allen Netzwerkschichten zu erreichen. Diese Architektur wurde auf den Namen Web Based Enterprise Management getauft, auch wenn dieser Name ein wenig irreführend ist, da es keinen Zusammenhang mit dem World Wide Web gibt.
Bei der Implementierung entschied man sich für die folgenden etablierten Standards:
Einen Veranschaulichung der Gesamtarchitektur WBEM bietet Abbildung 5.15.
Für die Repräsentation von Klassen und Instanzen und mögliche Operationen darauf kommt XML zum Einsatz, welches bereits in Kapitel 3.3 vorgestellt wurde.
Um CIM in XML darzustellen, wird eine DTD benötigt. Hierzu sind zwei mögliche Ansätze denkbar:
Auch wenn der erste Ansatz eine umfangreichere Validierung und einen intuitiveren Einsatz ermöglichen würde, entschied man sich aus den folgenden Gründen für den zweiteren [3]:
Eine vollständige Erläuterung der XML-DTD würde über den Umfang dieser Arbeit hinausgehen, die DTD selbst findet sich jedoch im Anhang A.1. Einzelne Teile der DTD sollen jedoch an dieser Stelle kurz in Beispielen vorgestellt werden. Wesentliche Bestandteile sind:
Zur Darstellung von Klassen gilt die folgende Definition:
<!ELEMENT CLASS (QUALIFIER*, (PROPERTY | PROPERTY.ARRAY |
PROPERTY.REFERENCE)*, METHOD*)>
<!ATTLIST CLASS
NAME
SUPERCLASS >
Eine Klasse ist also immer ein CLASS-Element mit den möglichen
Attributen NAME (Name der Klasse) und SUPERCLASS (Name der
Oberklasse) und den optional in
beliebiger Menge enthaltenen Elementen:
Die oben aufgeführten Elemente werden natürlich selbst in der DTD definiert, so z.B. PROPERTY:
<!ELEMENT PROPERTY (QUALIFIER*, VALUE?)>
<!ATTLIST PROPERTY NAME;
CLASSORIGIN
PROPAGATED
TYPE #REQUIRED>
Eine PROPERTY -- also eine CIM-Attribut -- enthält damit eine
beliebige Menge an Qualifiern (QUALIFIER) sowie einen optionalen Wert
(VALUE), sowie die Attribute:
"TYPE (boolean|string|char16|uint8|sint8|
uint16|sint16|uint32|sint32|uint64|
sint64|datetime|real32|real64)">
Die Klasse SwitchPort wird in XML damit beispielsweise folgendermaßen repräsentiert:
<CLASS NAME="CIM_SwitchPort" SUPERCLASS="CIM_ProtocolEndpoint">
<QUALIFIER NAME="Version" TYPE="string" OVERRIDABLE="false"
TOSUBCLASS="false">
<VALUE>
2.6.0
</VALUE>
</QUALIFIER>
<QUALIFIER NAME="Description" TYPE="string" OVERRIDABLE="false"
TOSUBCLASS="false">
<VALUE>
Switch Port from which frames are received and out which
they are transmitted.
</VALUE>
</QUALIFIER>
<PROPERTY NAME="PortNumber" CLASSORIGIN="CIM_SwitchPort"
TYPE="uint16">
<QUALIFIER NAME="Description" TYPE="string" OVERRIDABLE="false"
TOSUBCLASS="false">
<VALUE>
Numeric identifier for a switch port.
</VALUE>
</QUALIFIER>
<QUALIFIER NAME="Mappingstrings" TYPE="string" OVERRIDABLE="false"
TOSUBCLASS="false">
<VALUE.ARRAY>
<VALUE>
MIB.IETF|RFC1493-MIB.dot1dPort
</VALUE>
</VALUE.ARRAY>
</QUALIFIER>
</PROPERTY>
</CLASS>
Da eine Klasse durch xmlCIM vollständig beschrieben wird, steht einer Konvertierung in MOF (siehe Kapitel 5.2.1.2) nichts im Wege: Für diesen Zweck existiert ein XSL-Stylesheet (siehe Kapitel 3.3.3.3) [7].
Die Codierung einer Instanz erfolgt fast ähnlich wie die einer Klasse -- die DTD definiert sie als:
<!ELEMENT INSTANCE (QUALIFIER*, (PROPERTY | PROPERTY.ARRAY |
PROPERTY.REFERENCE)*)>
<!ATTLIST INSTANCE
CLASSNAME #REQUIRED>
Das bedeutet, eine Instanz besitzt die gleichen Elemente wie eine
Klasse, bis auf METHOD. Als zwingendes Attribut (CLASSNAME) wird der
Name der Klasse angegeben.
Eine Instanz könnte folgendermaßen aussehen:
<INSTANCE CLASSNAME="CIM_Example">
<PROPERTY NAME="Description" TYPE="string">
<VALUE>Sample Instance</VALUE>
</PROPERTY>
<PROPERTY NAME="Attribute1" TYPE="uint16">
<VALUE>1</VALUE>
</PROPERTY>
<PROPERTY NAME="Attribute2" TYPE="string">
<VALUE>Value 2</VALUE>
</PROPERTY>
</INSTANCE>
Die Codierung von Klassen und ihren Instanzen wurde im vorausgegangenen Kapitel behandelt und ist die Voraussetzung für die Durchführung von Operationen auf diese. WBEM sieht eine definierte Menge von Operationen vor, die in Tabelle 5.1 erläutert werden.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
Alle diese Methoden werden durch die CIM-Implementierung des Zielsystems bearbeitet und sind ihr immanent. Daher werden sie auch als intrinsisch bezeichnet. Alle weiteren Operationen werden als Methodenaufrufe an eine CIM-Instanz interpretiert und an sie weitergereicht. Sie werden daher extrinsisch genannt.
Jede Operation muss in einer XML-Nachricht gekapselt werden. Dies geschieht über das Element CIM, das eine MESSAGE enthält. In dieser ist wiederum der Typ der Operation enthalten, innerhalb dessen per IMETHODCALL der Methodenaufruf (siehe Tabelle) codiert ist. Darin befindet sich -- je nach Aufruf -- eine Klassen- oder Instanzbezeichnung oder -definition. Beispielsweise hat ein CIM-Aufruf folgende Gestalt:
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="87872" PROTOCOLVERSION="1.0">
<SIMPLEREQ>
<IMETHODCALL NAME="CreateInstance">
<LOCALNAMESPACEPATH>
<NAMESPACE NAME="root"/>
<NAMESPACE NAME="cimv2"/>
</LOCALNAMESPACEPATH>
<IPARAMVALUE NAME="NewInstance">
<INSTANCE CLASSNAME="CIM_VideoBIOSElement">
...
</INSTANCE>
</IPARAMVALUE>
</IMETHODCALL>
</SIMPLEREQ>
</MESSAGE>
</CIM>
In diesem Beispiel wurde über die Operation CreateInstance die Instanz NewInstance der Klasse CIM_VideoBIOSElement erzeugt -- innerhalb des INSTANCE-Elements befindet sich hierbei die Beschreibung der Instanz selbst (siehe Kapitel 5.3.1.1).
Wenn diese Operation erfolgreich durchgeführt wurde, erhält der Manager eine Antwort in folgender Gestalt:
<CIM CIMVERSION="2.0" DTDVERSION="2.0">
<MESSAGE ID="87872" PROTOCOLVERSION="1.0">
<SIMPLERSP>
<IMETHODRESPONSE NAME="CreateInstance">
<IRETURNVALUE>
<INSTANCENAME CLASSNAME="CIM_VideoBIOSElement">
<KEYBINDING NAME="KeyAttr">
<KEYVALUE>S4</KEYVALUE>
</KEYBINDING>
</INSTANCENAME>
</IRETURNVALUE>
</IRETURNVALUE>
</SIMPLERSP>
</MESSAGE>
</CIM>
Damit wird mitgeteilt, dass die Instanz NewInstance erfolgreich angelegt wurde -- zur weiteren Verarbeitung erhält der Manager in KEYBINDING-Elementen alle Schlüsselwerte als Rückgabe.
Dieses Beispiel verdeutlicht die Funktionsweise von XML-codierten CIM-Operationen im Rahmen von WBEM. Im Rahmen anderer Operationen variieren die enthaltenen XML-Elemente je nach Bedarf. Der vollständige Umfang möglicher Variationen kann in der DTD (siehe Anh. A.1) oder in der xmlCIM-Spezifikation [8] nachgeschlagen werden.
Nachdem im vorherigen Kapitel 5.3.1.2 die Codierung von
CIM-Informationen auf XML-Basis beschrieben wurde, soll nun noch auf
den Transport eingegangen werden. Als Protokoll hierfür entschied man
sich für das bereits aus dem WWW bewährte Hypertext Transfer Protocol
(HTTP, siehe Kapitel 3.4).
Folgende Gründe mögen dafür die Ursache gewesen sein:
Als TCP-Port für die Verbindung auf eine CIM-Ressource wurde der Port 5988 spezifiziert. Erfolgt die Verbindung SSL-verschlüsselt, muss der TCP-Port 5989 verwendet werden. Die Standard-URI ist /cimom, diese kann aber über einen speziellen HTTP-Header bei der Server-Antwort überschrieben werden. Als HTTP-Methode für einen WBEM-Request muss laut Spezifikation [8] grundsätzlich POST verwendet werden. In dem POST-Request selbst befindet sich dann die gesamte XML-codierte Anfrage, so dass die HTTP-Schicht von WBEM insgesamt nur wenige Aufgaben übernehmen muss.
Ein wichtiges Feature von HTTP wurde jedoch für WBEM übernommen, das in xmlCIM nicht vorgesehen ist: Dabei handelt es sich um die Möglichkeit der Authentifizierung, welche unabdingbar für den Einsatz von WBEM ist. Mögliche Mechanismen sind hier:
Als ein weiterer Sicherheitsmechanismus werden im HTTP-Header einige Informationen über die WBEM-Operationen mit übertragen. Dies ermöglicht eine Filterung in Firewall- oder Proxy-Umgebungen und ist daher in Umgebungen mit hohen Sicherheitsanforderungen von Interesse. Die Header aus Tabelle 5.2 wurden dafür spezifiziert:
|
Ein WBEM-Request kann damit etwa folgendermaßen aussehen:
POST /cimom HTTP/1.1 Host: http://www.myhost.com/ Content-Type: application/xml; charset="utf-8" Content-Length: 1453 CIMOperation: MethodCall CIMMethod: SetPowerState CIMObject: root/cimv2:Win32_LogicalDisk="C:" <?xml version="1.0" encoding="utf-8" ?> ...
Die Antwort hätte dann die folgende Gestalt:
HTTP/1.1 200 OK Content-Type: application/xml; charset="utf-8" Content-Length: 233 Ext: Cache-Control: no-cache CIMOperation: MethodResponse <?xml version="1.0" encoding="utf-8" ?> ...
Nachdem CIM und WBEM im Rahmen ihrer theoretischen Grundlagen und ihrer Spezifikation in den vorausgegangenen Kapiteln ausführlich beschrieben wurden, soll nun auf ihre Implementierung eingegangen werden.
Da WBEM auf Basis eines Client-Server-Konzepts arbeitet, gibt es in einer solchen Architektur zwei Seiten (siehe auch Abbildung 5.15):
Während für das Management beliebige Applikationen zum Einsatz kommen können, die gegebenenfalls spezielle Verwaltungsaufgaben erfüllen, wie beispielsweise die Überwachung von kritischen Systemzuständen oder die Konfiguration von Anwendungen, bedarf es serverseitig einer verwobeneren Infrastruktur, damit ein System WBEM-managebar ist:
Eine Übersicht über diese Gesamtarchitektur zeigt Abbildung 5.16. Der Fluss von Managementinformationen erfolgt dabei zwischen Manager und Ressource auf der linken Seite von oben nach unten über die Schichten Management-Anwendung -- CIMOM -- Provider -- Instrumentierung -- Zielressource. Dem korrespondiert auf der rechten Seite die Beschreibung dieser Informationen: Im Repository ist das CIM-Modell der lokal managebaren Ressourcen hinterlegt.
Ein CIMOM fungiert als zentrale Schaltstelle für alle WBEM-Anfragen, deren Ziel das lokale System ist, auf dem er läuft. Ist eine Anfrage auf eine Klasse bezogen, wird sie über das Repository behandelt. Bezieht sich die Anfrage dagegen auf eine Instanz, wird sie an den entsprechenden Provider weitergeleitet. Auch für den umgekehrten Weg in Form einer Indication ist der CIMOM zuständig. Er weiß, welches Ereignis -- das von einem Provider gemeldet wird -- an welchen Manager zuzustellen ist.
Der Aufbau eines CIMOMs geht im Detail aus Abbildung 5.17 hervor.
Instanzbezogene Operationen (z.B. CreateInstance) werden direkt an den zuständigen Provider weitergereicht, die anschließende Antwort wird an den Manager weitergeleitet. Der Kern muss auch berücksichtigen, dass bestimmte Operationen (z.B. EnumerateInstances) an mehrere Provider weiterzuleiten sind, wenn die Operation auf eine Oberklasse durchgeführt wird, die in verschiedenen Unterklassen durch Provider implementiert wird.
eingesetzt. Aufgabe des Providerinterfaces ist es daher,
die Bibliothek zu laden und eine Funktion aufzurufen, die der
WBEM-Operation entspricht.
Aufgabe eines WBEM-Providers ist es, Instanzen einer einzelnen Klasse zu verarbeiten. Neben extrinsischen Methodenaufrufen sind die möglichen Operationen (vgl. Kapitel 5.3.1.2) in Tabelle 5.3 aufgeführt.
|
Da die einzelnen Operationen, die durch einen Provider durchgeführt werden müssen, sehr rechenintensiv sein können, kann ein Caching gesammelter Informationen sinnvoll sein. Da Informationen über eine Instanz zeitlich veränderlich sind, darf ein CIMOM sie nicht zwischenspeichern oder gar in seinem Repository ablegen. Statt dessen wird empfohlen, bei CPU-intensiven Instanzen, die relativ statisch sind, ein Caching auf Providerebene durchzuführen.
Zusätzlich zur Implementierung der WBEM-Operationen muss ein Provider, der Indications implementiert, das instrumentierte Subsystem überwachen und im Fehlerfall dem CIMOM das Ereignis übergeben.
Da der Aufruf des Providers ausschließlich durch den CIMOM erfolgt, der lokal läuft, bietet sich meist eine Shared Library als Basis für eine Implementierung an. Die entsprechenden WBEM-Aufrufe müssen dann als Funktionen ansprechbar sein. Die Details ergeben sich aus der jeweiligen CIMOM-Implementierung.
Die Beschaffenheit der Schnittstelle selbst spielt für WBEM keine Rolle: Eine entsprechende Umsetzung wird schließlich durch den Provider vorgenommen. Stellt jedoch die gemanagte Komponente kein oder nur ein unzureichendes Interface zur Verfügung, macht dies die Implementierung von WBEM-Providern deutlich aufwändiger.
einen Einblick geben, wie
weit sich der CIM-Standard, der bereits seit Juli 1996 definiert ist,
für das Systems Management durchsetzen konnte.
Die Einteilung vorhandener CIM-Implementierungen erfolgte in vier Kategorien:
Zu den unabhängigen CIMOM-Implementierungen zählen die folgenden Programmpakete, die denen es sich jeweils um OpenSource-Projekte handelt:
In Kapitel 5.5.1.5 findet sich anschließend ein tabellarischer Vergleich der Produkte.
Der OpenWBEM CIMOM wurde
ursprünglich von Caldera für das Volution-Projekt (siehe
Kapitel 5.5.2.3) entwickelt, die Entwicklung wird nach der Übernahme
von SCO weitergeführt. Er ist als eigenständiges Produkt auch
im Quelltext frei erhältlich.
OpenWBEM wurde in C++ geschrieben und setzt ein UNIX-Betriebssystem voraus -- explizit unterstützt werden Linux, SCO OpenUNIX und Solaris.
Zu den Features zählen:
OpenPegasus wurde ebenfalls
in C++ entwickelt. Dabei handelt es sich um ein Projekt der Open Group,
die sich im Rahmen ihrer WBEMsource-Initiative für die Pflege und die
Entwicklung von WBEM-Implementierungen verantwortlich zeichnet.
Ziel bei OpenPegasus war es, einen CIMOM zu entwerfen, der durch Modularität möglichst schlank ist und auf möglichst vielen verschiedenen Betriebssystemen lauffähig ist. Unterstützt werden die meisten gängigen Varianten von UNIX (darunter Linux) und Win32-Systeme. Eine besonders schlanke Variante für Embedded-Systeme ist momentan in Planung.
Es war an dieser Stelle nicht möglich, eine komplette Liste der Features vom OpenPegasus zu erstellen, da die Organisation des Projekts scheinbar relativ chaotisch verläuft, was sich in einer unzureichenden Dokumentation zeigt.
Unterstützt werden aber nachweisbar:
Außerdem wird (je nach Betriebssystem) eine Reihe von Providern mitgeliefert, z.B. für die Klassen ComputerSystem, DNSAdminDomain und OperatingSystem.
Der SNIA CIMOMwurde ursprünglich durch die Storage Networking Industry
Association (SNIA) entwickelt. Bei der
SNIA handelt es sich um ein Industriekonsortium von Herstellern von
Netzwerkspeicherlösungen. Da
Speichernetzwerke zwischenzeitlich eine hohe Komplexität aufweisen,
andererseits aber ein homogenes Management in diesem Bereich von hoher
Bedeutung ist, hat sich die Vereinigung zu CIM als
Management-Framework bekannt -- siehe auch das Kapitel über Bluefin
(5.5.4.2).
Da der SNIA CIMOM zwischenzeitlich auch außerhalb des Speichermanagements eine hohe Akzeptanz erreicht hat, wurde das Projekt an die Open Group übergeben. Die Programmierung erfolgte durchweg in Java, was eigene Erweiterungen vereinfacht. Als Kommunikationsprotokoll wird neben HTTP/XML auch der Java-eigene Standard Remote Method Invocation (RMI) unterstützt.
Zu den Features zählen:
Bei den WBEM Services handelt es sich um den CIMOM, der ursprünglich
von Sun für die WBEM-Unterstützung von Solaris entwickelt wurde. Der
Kern dieser Entwicklung steht nun einer freien Entwicklergemeinde zur
Verfügung. Die
Entwicklung der WBEM Services erfolgte in Java, die Provider-APIs sind
jedoch nicht ganz kompatibel zur SNIA-Implementierung. Gleiches gilt
für die Unterstützung von RMI.
Zu den Features zählen:
Eine kleine Übersicht der Merkmale der vorgestellten Standalone-CIMOMs liefert Tabelle 5.4.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CIM und WBEM wurden zwischenzeitlich von den Herstellen zweier weit verbreiteter Betriebssysteme adaptiert:
Darüber hinaus soll CIM zukünftig in die System Management-Konsole Volution Manager von SCO integriert werden (siehe Kapitel 5.5.2.3).
Weitere Implementierungen von CIM auf Betriebssystem-Ebene sind die folgenden Produkte:
verfolgte das
Ziel, WBEM als Grundlage für die Verwaltung weiter Teile von Linux
einzusetzen, die Implementierung erfolgt in der Scriptsprache Perl.
Da die Homepage des Projekts seit Anfang 2001 nicht mehr
aktualisiert wurde, soll hier auf B4wbem nicht weiter eingegangen
werden.
an, das eine verteilte
Konfiguration, Überwachung und Inventarisierung ermöglicht und über eine
CIM-Schnittstelle verfügt. Mangels Dokumentation oder einer
Demonstrationsversion konnte dieses Produkt nicht weiter untersucht
werden.
Mit dem Betriebssystem
Solaris wird seit Version 8 eine
Unterstützung von CIM und WBEM ausgeliefert. Als CIMOM kommen dabei die
zwischenzeitlich frei verfügbaren WBEM services (siehe
Kapitel 5.5.1.4) zum Einsatz. Zusätzlich wird mit dem CIM
workshop eine
Java-basierte CIM/WBEM-Entwicklungsumgebung mitgeliefert, über die
Klassen und Instanzen bearbeitet werden können (siehe
Abbildung 5.18 und 5.19).
Teil von Sun WBEM ist ein extension schema, auf dessen Basis große Teile der Betriebssystemumgebung per CIM verwaltet werden können. Abbildung 5.19 zeigt beispielsweise die Einstellungen eines Benutzeraccounts. Insgesamt stehen für die folgenden Aufgaben Provider zur Verfügung:
Zur Förderung weiterer Entwicklungen, wie beispielsweise WBEM-fähiger Anwendungen unter Solaris, umfasst die Entwicklungsumgebung neben dem CIM workshop auch einen Satz an APIs (Client-, CIMOM- und Provider-APIs) mit umfangreicher Dokumentation sowie einige Beispielprogramme.
In die Windows-Betriebssysteme von
Microsoft ist CIM seit Windows NT 4 Fixpack 4
integriert und dort unter dem Namen Windows Management
Instrumentation (WMI) bekannt. Microsoft wirbt zwar damit, dass Windows
damit WBEM-fähig ist. Dies ist jedoch insofern nicht der Fall, als dass
CIM-Clients nicht per HTTP und XML mit Windows kommunizieren können,
sondern nur per COM oder DCOM.
Folgende Teile des Betriebssystems sind per WMI managebar:
Abbildung 5.20 zeigt eine Übersicht über die Architektur von WMI.
Mit dem Kommandozeilenprogramm wbemdump.exe können Klassen und Instanzen abgefragt, Methoden aufgerufen, sowie komplexere Abfragen formuliert werden. Der WMI-Browser erlaubt es, die CIM-Klassenhierarchie zu betrachten, mit dem CIM Studio, das auf den WMI-Browser aufbaut, können auch Instanzen bearbeitet werden. Einen Screenshot des CIM Studios zeigt Abbildung 5.21.
Hauptverwendungsmöglichkeit für WMI ist jedoch die mitgelieferte VisualBasic-Script-API, die es ermöglicht, scriptbasierend beliebige Managementtätigkeiten durchzuführen.
Das Produkt Volution
Manager, das ursprünglich von Caldera
entwickelt wurde und nach der Übernahme weiter von SCO gepflegt und
vertrieben wird, ist ein System zur verteilten Inventarisierung,
Überwachung und Konfiguration von Soft- und Hardware.
Folgende Tätigkeiten können über den Volution Manager abgewickelt werden:
Als Zielbetriebssysteme werden neben Linux SCO Open Unix 8, UnixWare und SCO OpenServer unterstützt, während die Konfiguration per Webbrowser geschieht.
Momentan erfolgt die gesamte Datenhaltung und Konfiguration noch in einem LDAP-Server, zukünftig ist hier der Einsatz von WBEM mit dem eigenentwickelten CIMOM OpenWBEM (siehe Kapitel 5.5.1.1) geplant.
Da SCO neben SuSE und TurboLinux an der ,,vereinheitlichten``
Linux-Distribution UnitedLinux beteiligt ist, ist mittelfristig geplant,
UnitedLinux über den Volution Manager WBEM-fähig zu machen.
An dieser Stelle sollen solche Produkte vorgestellt werden, die WBEM auf Seite des Managers unterstützen. Diese sind:
. Seit diesem Zeitpunkt
sind über den FrontLine Manager keine Informationen mehr erhältlich, da das
Produkt scheinbar eingestellt wurde. Daher wird an dieser Stelle nicht
weiter darauf eingegangen.
Mit Tivoli vertriebt IBM eines der
umfangreichsten und am weitesten
verbreitetsten Systems-Management-Softwaresysteme -- neben Tivoli sind
noch OpenView von HP und Patrol von BMC in diesem Bereich
von Bedeutung. Tivoli bietet insgesamt Unterstützung für folgende
Bereiche:
Das Subsystem Tivoli Monitoring dient im Rahmen des Accountings und der Verfügbarkeitsüberwachung speziell der Kontrolle von Betriebssystem und Anwendungen. Als Zielplattformen werden die UNIX-Derivate AIX, HP-UX, Linux, OS/400 und Solaris sowie Windows NT und Windows 2000 unterstützt.
Der funktionale Umfang von Tivoli Monitoring ist vielversprechend: Mittels so genannter Resource Models wird eine Entität überwacht, sie setzt sich zusammen aus [19]:
Wird ein Fehler festgestellt, kann er an die Tivoli-Komponente Enterprise Console weitergereicht werden. Das Interessante an Tivoli Monitoring ist die Datengewinnung: Sie basiert vollständig auf CIM -- das bedeutet: Alles, was über eine CIM-Instrumentierung verfügbar ist, kann auch überwacht werden. Als CIMOM bedient sich Tivoli Monitoring
Die Erstellung von Überwachungsentitäten ist mit der Distributed Monitoring Workbench unter Windows möglich: Die verfügbaren Klassen werden dabei über das WMI-Repository gelesen, in das auch externe Klassen über den Windows-MOF-Compliler geladen werden können.
In den vorherigen Teilen der Marktübersicht wurden einzelne CIMOMs, Betriebssysteme mit CIM-Unterstützung und System-Management-Lösungen, die auf CIM aufsetzen, untersucht. In diesem Kapitel sollen schließlich noch Projekte vorgestellt werden, die sich speziellen Themen widmen und dafür CIM einsetzen. Diese sind:
Das Linux Technology Center der IBM verfügt auch über eine
Abteilung, die nach Lösungen sucht, Linux in großen Unternehmen und
Rechenzentren besser managebar zu machen. Der Ansatz,
dieses Ziel über die Implementierung von WBEM und CIM zu erreichen, wurde
im Standards Based Linux Instrumentation for
Manageability-Projekt (kurz: SBLIM)
umgesetzt.
Da SBLIM ein modulares Konzept verfolgt, wollte man auf einen vorhandenen CIMOM zurückgreifen und sich ausschließlich auf die Implementierung der Provider konzentrieren. Gleichzeitig hielt man es für wünschenswert, wenn es dem Anwender freisteht, welchen CIMOM er einsetzt: So entstand mit dem Native Provider Interface (siehe unten) eine einheitliche C-API zwischen CIMOM und Providern.
Welche Bereiche des Linux-Managements durch einzelne Pakete von SBLIM unterstützt werden, soll hier zur aufgezeigt werden:
Zusätzlich wurde mit der SBLIM reference implementation (SRI) eine Java-GUI als einfache Systems-Management-Konsole erstellt. In ihr kann über eine XML-Datei gesteuert werden, auf welche Art Instanzen einer Klasse angezeigt werden sollen, und welche Aktionen darauf durchgeführt werden sollen.
Während WBEM innerhalb einer CIM-Umgebung die Kommunikation zwischen Manager und Ressource normiert, besteht für die Anbindung von Providern an einen CIMOM bisher kein Standard (zur Veranschaulichung siehe auch Abbildung 5.16). Dieser wurde jedoch für das SBLIM-Projekt gewünscht, so dass er durch die IBM als Native Provider Interface (NPI) spezifiziert wurde [18]. Damit besteht nun eine C-API, zwischenzeitlich in den folgenden CIMOMs implementiert wurde:
Somit ist es nun möglich, NPI-Provider, wie beispielsweise die das SBLIM-Projekts, in Verbindung mit jedem der obigen CIMOMs einzusetzen.
Die API sieht eine bidirektionale Kommunikation zwischen CIMOM und Provider vor. Operationen auf Instanzen werden an die entsprechenden Provider-Funktionen, deren Aufrufe NPI spezifiziert, weitergeleitet -- vergleiche auch Tabelle 5.3:
Initialisierung des Providers
Entladen des Providers
implementiert EnumerateInstanceNames
implementiert EnumerateInstances
implementiert GetInstance
implementiert CreateInstance
implementiert ModifyInstance
implementiert DeleteInstance
implementiert Associators
implementiert AssociatorNames
wie associators, liefert aber Instanzen der Assoziation selbst
wie associatorNames, liefert aber Schlüssel der Assoziationen selb
