Nächste Seite: Common Information Model (CIM) Aufwärts: Diplomarbeit: Management verteilter Systeme Vorherige Seite: Technische Grundlagen Inhalt
Bevor im Kapitel 5 auf das Common Information Model eingegangen wird, sollen an dieser Stelle frühere Standards vorgestellt werden, die
Das sind:
Das Simple Network Management Protocol (SNMP) wurde Ende der achtziger Jahre durch die IETF als Internet-Standard verabschiedet und war eigentlich als ein Provisorium auf Basis von TCP/IP gedacht, bis die Entwicklung von CMIP (Kapitel 4.2) als ISO-Standard fertiggestellt ist.
Inzwischen hat sich SNMP jedoch als der Standard für das Netzwerkmanagement etabliert, so dass Netzwerkgeräte von fast jedem Hersteller per SNMP managebar sind.
Eine SNMP-Infrastruktur besteht aus folgenden Subsystemen:
Diese Gesamtarchitektur von SNMP ist in Abbildung 4.1 illustriert.
Die Management Information Base (MIB) ist ein hierarchisch strukturierter Baum, dessen Blätter die eigentlichen managed objects enthalten. Der Zugriff auf einzelne Blätter erfolgt über eine eindeutige Zahlenkombination, wobei ein Ast einem Einzelwert entspricht. Der gesamte Pfad (Object identifier oder OID) entsteht durch Aneinanderreihung der Zahlen, getrennt durch einen Punkt.
Die Hierarchie der obersten Ebenen folgt dabei zunächst den Organisationen, die für die Normierung von SNMP verantwortlich sind, so dass momentan drei Top-Level OIDs existieren:
Im IETF-Standard RFC 1213 leiten sich von der ISO über die Zwischenstufen org (organisations), DOD (Department of Defence) und Internet die in SNMP standardisierten OIDs ab, die für alle SNMP-Implementierungen den kleinsten gemeinsamen Nenner darstellen. Diese beginnen alle mit der OID 1.3.6.1.2.1 (siehe Abbildung 4.2).
Unterhalb der OID 1.3.6.1.4 (private) sind aber auch herstellerspezifische Erweiterungen möglich, so dass Firmen MIBs speziell für ihre Produkte erstellen können.
SNMP verlangt für jede OID auch die Definition von Syntax und Codierung. Die Syntax ist der Datentyp, der über den Standard ASN.1 (Abstract Syntax Notation) der ISO notiert wird. Für die Codierung, aus der Informationen über einen plattformübergreifenden Datenaustausch hervorgehen, kommen die Basic Encoding Rules (BER) zum Einsatz, bei denen es sich ebenfalls um einen ISO-Standard handelt.
Die Datentypen von SNMP sind:
SNMP ist momentan der unangefochtene Standard für das Netzwerkmanagement, was vermutlich daran liegt, dass es keine Alternativen gibt, die ähnlich einfach zu implementieren sind, und dass diese Norm schon recht lange existiert.
Die Einfachheit -- und möglicherweise die Tatsache, dass SNMP ursprünglich nur als Übergangslösung gedacht war -- führen aber zu gravierenden Nachteilen. Diese sind:
Das Common Management Information Protocol (CMIP) befand sich gerade in der Entwicklung, als SNMP (Kapitel 4.1) standardisiert wurde und sollte ein endgültiger Standard für das Management von Netzwerken werden.
Viele Schwachstellen von SNMP wurden in CMIP ausgemerzt:
![[*]](footnote.png)
ein Alarm ausgelöst werden
kann.
Trotz dieser Vorteile konnte sich CMIP nie etablieren. Dies hatte eine Hauptursache: Es war zu schwierig zu implementieren, was besonders deswegen ein Manko darstellte, da es im Bereich des Netzwerkmanagement gilt, viele kleine Geräte mit Managementfunktionen auszustatten, die nur über sehr begrenzte Hardware-Ressourcen verfügen.
Einige der Vorteile flossen dafür nachträglich in SNMP ein. So unterstützt SNMP zwischenzeitlich auch Events (Traps), Authorisierungsmechanismen und ACLs.
Das Desktop Management Interface (DMI) entstand im Jahr 1992 durch die Desktop Management Task Force (DMTF), einem Industriekonsortium unter Beteiligung der meisten großen IT-Anbieter. Ziel der DMTF war damals zunächst, die Misere des IT-Managements der 90er Jahre (siehe Kapitel 2.5) zu bewältigen, was im Speziellen durch die Entwicklung von Standards und Systemen für die Verwaltung verteilter PC-Arbeitsplätze geschehen sollte. In späterer Zeit stellte sich die DMTF weitere Ziele -- da auf CIM als Nachfolger von DMI in Kapitel 5 ausführlich eingegangen wird, wird auf die DMTF an späterer Stelle detailliert eingegangen.
Um ein System DMI-konform zu machen, sind vier Komponenten zu implementieren [1]:
Die Gesamtarchitektur von DMI geht aus Abbildung 4.3 hervor. Darin ist zu erkennen, dass der Service Provider zusätzlich über eine Datenbank verfügt, in der die Objektbeschreibungen abgelegt werden. Darüber hinaus wurde im Laufe der Entwicklung von DMI parallel zur obigen Architektur die Möglichkeit eingeführt, in Form eines Data Block Interfaces direkt über Betriebssystemebenen hinweg auf Hardwarekomponenten zuzugreifen.
Die Beschreibung von managebaren Systemkomponenten erfolgt in DMI durch eigene Attribute. Diese Attribute werden zugunsten der Übersichtlichkeit und zur Adressierung in Gruppen zusammengefasst. Dabei kann eine Gruppe einfach oder mehrfach instanziiert werden -- dieses Konstrukt wird als Tabelle bezeichnet. So bilden z.B. alle IP-Routing-Einträge des Betriebssystems eine Tabelle. Primärschlüssel ist dabei jeweils eines dieser Attribute.
Als Beschreibungssprache für DMI kommt das Managed Information Format zum Einsatz. Dazu werden Komponenten, Gruppen und Attribute in einer Textdatei aufgeführt -- eine MIF-Datei kann beispielsweise so aussehen:
//
// SAMPLE MIF FOR THE FICTIONAL ACS-100
// MFG. BY ANY COMPUTER SYSTEM, INC.
//
START COMPONENT
NAME = "ANY COMPUTER SYSTEM, MODEL 100"
DESCRIPTION = "THIS COMPONENT REPRESENTS THE BASE CONFIGURATION"
"OF A SYSTEM MANUFACTURED BY ANY COMPUTER, INC."
"THREE GROUPS ARE INCLUDED:"
"THE COMPONENTID GROUP, "
"THE SERVICE GROUP, AND "
"THE SYSTEM CHASSIS GROUP."
START PATH
NAME = "CHASSIS GROUP CODE"
DOS = "C:\\ANY\\DOS\\CHASSIS.OVL"
WIN16 = "C:\\ANY\\WIN3X\\CHASSIS.DLL"
END PATH
//
// COMPONENT ID GROUP
//
// THIS IS THE REQUIRED GROUP CONTAINING THE
// REQUIRED ATTRIBUTES FOR ALL COMPONENTS.
//
START GROUP
NAME = "COMPONENTID"
ID = 1
CLASS = "DMTF|COMPONENTID|001"
// THIS GROUP IS DMTF SANCTIONED
DESCRIPTION = "THIS GROUP DEFINES ATTRIBUTES COMMON TO ALL"
" COMPONENTS. THIS GROUP IS REQUIRED."
START ATTRIBUTE
NAME = "MANUFACTURER"
ID = 1
ACCESS = READ-ONLY
STORAGE = COMMON
TYPE = STRING(64)
VALUE = "ANY COMPUTER SYSTEM, INC."
END ATTRIBUTE
START ATTRIBUTE
NAME = "PRODUCT"
ID = 2
ACCESS = READ-ONLY
STORAGE = COMMON
TYPE = STRING(64)
VALUE = "ACS-100"
END ATTRIBUTE
START ATTRIBUTE
NAME = "VERSION"
ID = 3
...
Speziell für die hardwarenahe Wartung von PC-Arbeitsplätzen entstand 1997 durch die Firma intel der Standard Wired for Management (WfM). Dabei handelt es sich um ein Framework, das für ein WfM-konformes System vorschreibt, dass fünf verschiedene Verwaltungskomponenten implementiert sein müssen.
Der Zugriff darauf erfolgt dabei über DMI oder SNMP, um etablierte Managementstandards einsetzen zu können. Falls DMI eingesetzt wird, muss der Hersteller eine passende MIF-Beschreibung ausliefern, ansonsten eine MIB.
Eine genaue Veranschaulichung der Architektur von WfM bietet Abbildung 4.4.
WfM wird zwischenzeitlich von intel nicht mehr als eigener Standard propagiert, statt dessen wurde WfM in das Designed for Windows XP-Programm von Microsoft aufgenommen. Das bedeutet, dass PC-Systeme, die über das Designed for Windows XP-Zertifikat verfügen, auch WfM-konform sein müssen.
Die einzelnen Komponenten von WfM sind [15]:
BlueConf entstand 2002 als eine Studie der Thinking Objects Software GmbH. Dabei sollte eine Möglichkeit gefunden werden, das Application Management unter UNIX-Betriebssystemen zu vereinfachen und die Verwaltung großer Rechnerfarmen zu ermöglichen.
Die Anforderungen waren im Detail folgende [10]:
Genaue Konzepte und weitere Details können in den Arbeiten von VÖLKEL [30], HAMBRECHT [10] und SEITZ [26] nachgeschlagen werden.
Die Architektur von BlueConf, die grafisch aus Abbildung 4.5 hervorgeht, sieht eine direkte Anbindung zwischen der zu verwaltenden Anwendung und einer Konfigurations-API vor. Dies macht zwar eine Modifikation des Quelltexts des Programms nötig, führt aber andererseits zu einer Ablösung der unter UNIX üblichen Konfigurationsdateien (siehe dazu Kapitel 3.2.2.1).
Das bedeutet, dass eine Anwendung, sobald sie gestartet wird, über BlueConf-API-Aufrufe versucht, ihre Konfiguration zu laden. Diese Client-API kennt wiederum über einen Plugin-Manager mindestens ein Backend, um die benötigten Daten aus dem Repository zu holen. Dabei findet die Kommunikation zwischen Backend und Repository über ein Netzwerk statt, so dass ein zentrales Repository möglich ist.
Als Protokolle und Backends sind hierfür bisher XML über SOAP und LDAP vorgesehen, Erweiterungen, z.B. für ein lokales Caching wären auch denkbar. Auf Seiten des Konfigurationsfrontends kommt die gleiche Architektur zum Einsatz, jedoch erweitert durch eine API, über die auch ein schreibender Zugriff möglich ist.
Das eigentliche Datenmodell von BlueConf ist recht einfach gehalten: Dabei werden die Werte der Konfigurationsdateien für das XML-Backend einfach in XML dargestellt. Für jede Anwendung kann dann eine DTD definiert werden. Die Konfiguration des UNIX-Syslog-Daemon kann in BlueConf z.B. so aussehen:
<syslog>
<rule>
<selector>
<facility>mail</facility>
<priority>*</priority>
</selector>
<action>/var/log/maillog</action>
</rule>
<rule>
<selector>
<facility>cron</facility>
<priority>*</priority>
</selector>
<action>/var/log/cron</action>
</rule>
...
</syslog>
Ein Wunsch bei der Verwaltung großer verteilter Systeme ist eine schnelle initiale Einrichtung. Darüber hinaus ist es oft wünschenswert, dass frühere Konfigurationszustände wiederhergestellt werden können, was durch eine Versionierung, also eine zeitliche Verfolgung der Konfigurationsdaten möglich wäre.
Im Entwurf von BlueConf wurde versucht, beiden Wünschen Rechnung zu tragen, bei ersterem durch die Möglichkeit, Standardwerte festzulegen, die dann gültig sind, wenn für eine spezielle Anwendung auf einem speziellen System noch keine Konfigurationswerte vergeben wurden. Dies wird mit Abbildung 4.6 illustriert.
Auch wenn BlueConf bisher nicht so weit implementiert wurde, ist dieses Konzept richtungsweisend, da es bisher in keinem anderen Framework berücksichtigt wurde. Es gilt jedoch noch zu überlegen, wie diese Hierarchie genau strukturiert werden soll, und wie sie in verschiedenen Backends, wie z.B. XML oder LDAP repräsentiert werden kann.
