Aufgabe eines CMIP/SNMP Gateways ist es, einem OSI-konformen
Managementsystem zu ermöglichen, mit dem vollständigen
CMIS-Funktionsumfang auf SNMP-Agenten zugreifen zu können. Dies
erfordert erstens eine Umsetzung der Managementoperationen und
zweitens eine Abbildung der auszutauschenden Managementinformationen.
Für den Austausch von Managementoperationen zwischen diesen beiden
Architekturen bedarf es einer Protokollkonvertierung, die vom
Management-Gateway durchzuführen ist.
Prinzipieller Aufbau eines CMIP/SNMP Gateways
Die aus [#!nmf28!#] übernommene Abbildung
illustriert die Doppelrolle des Gateways,
das gegenüber dem OSI-Manager eine Agentenrolle und gegenüber dem
SNMP-Agenten einen Managerrolle einnimmt. Die Bezeichnungen der
Schnittstellen und Referenzpunkte zwischen den einzelnen Komponenten
folgen den Festlegungen des TMN-Referenzmodells [#!itum3010!#].
Die durch das Gateway erfüllten Aufgaben lassen sich in zwei zentrale Kategorien unterteilen:
Asynchrone Ereignismeldungen, die von SNMP-Agenten an das Gateway gesandt werden, müssen durch das Gateway den Proxy-Objekten zugeordnet und durch diese an das Managementsystem gesandt werden. CMIS-Operationen wie M-CREATE und M-DELETE sind bekanntlich nur auf mehrfach instantiierbaren Objekten ausführbar (in SNMP sind dies Tabellen) und werden dort durch das Ändern der sogenannten Row Status Variable realisiert. M-CANCEL-GET ist die einzige CMIS-Operation, die keine Entsprechung in SNMP hat; ihre Funktionalität muß daher mit anderen Mitteln nachgebildet werden, beispielsweise durch Implementierung einer Abort-Operation im Gateway, das daraufhin die Verarbeitung des Requests abbricht und die bisher ermittelten Ergebnisse verwirft.
Architektur des CMIP/SNMP Gateway-Prototyps
Die in den vorangehenden Abschnitten identifizierte Doppelrolle eines CMIP/SNMP Management-Gateways (sowohl OSI/TMN-Agent als auch SNMP-Manager) impliziert, daß wir uns zur Implementierung unseres Prototypen auf Entwicklungssysteme für OSI/TMN-Agenten abstützen können. Wir müssen nunmehr dafür sorgen, den OSI/TMN-Agenten um Funktionen für das oben angesprochene Name- und Service Mapping zu erweitern und eine SNMP-Programmierschnittstelle zum Auslösen der entsprechenden Protokolloperationen sowie zur Entgegennahme von SNMP-Traps zu integrieren.
Unsere Wahl der Entwicklungsumgebung fiel auf die IBM TMN Products ([#!IBMTMNGI96!#], [#!fehn96!#]), da dieses System einige für unsere Aufgabenstellung wichtige Merkmale aufweist: Die NetView TMN Support Facility [#!IBMTMNSFUG96!#] ist eine vollständige OSI/TMN-Managementplattform, d.h. sie beinhaltet sowohl eine OSF als auch eine WSF und stellt dem Entwickler Programmierschnittstellen zur Entwicklung von TMN-Applikationen bereit. Das Produkt unterstützt die generischen Objektkataloge M.3100 [#!itum3100!#] und OMNIPoint und stellt ein Rahmenwerk zur Entwicklung OSI/TMN-konformer Managemenetagenten bereit. Die eigentliche Entwicklungsumgebung wird unter dem Namen TMN WorkBench for AIX [#!IBMTMNWBMO96!#] vermarktet. Sie besteht aus Werkzeugen zur Modellierung von Managementinformation wie MOC-Browsern und -Editoren mit deren Hilfe neue Objektklassen werkzeugunterstützt von bestehenden MOCs abgeleitet werden können. Zu diesem Zweck steht eine Vielzahl an Basis-MOCs in maschinenlesbarer Form bereit. OSI/TMN-konforme Agenten werden von der Entwicklungsumgebung aus GDMO/ASN.1-Objektbeschreibungen in C++ Programmrümpfe übersetzt, die dann in Form sog. Callback-Methoden vorliegen. Letztere beinhalten die eigentliche Managementinformation, d.h. die konkrete Managementinstrumentierung. Diese Methoden werden genau dann vom Agentensystem aufgerufen, wenn Operationen auf den dazugehörigen MIB-Variablen erfolgen.
Der wesentliche Vorteil der IBM TMN Entwicklungsumgebung besteht nun
darin, diese Callback-Methoden unter Zuhilfenahme der in der
TMN/C++ API standardisierten Abbildungsregeln automatisch zu erzeugen,
um so den Entwickler vollständig von den CMIS-Spezifika
abzuschirmen. Die eigentliche Kommunikation auf der Basis des
Protokolls CMIP geschieht vollkommen transparent für den Entwickler,
was gegenüber der Alternative XMP/XOM eine signifikante
Vereinfachung bedeutet. Die Nutzung dieser Vorteile durch die
Abstützung auf die IBM-Entwicklungsumgebung legt jedoch ebenfalls die
programmtechnische Architektur unseres Gateways fest, wie sie in
Abbildung dargestellt ist.
Nach seiner Instantiierung besteht das Gateway aus vier unterschiedlichen Prozessen:
Die Funktionsweise des Gateway-Prototyps ist nachfolgend am Beispiel
eines scoped und filtered M-GET.request dargestellt
(siehe auch Abbildung ):
Von SNMP-Agenten ausgesandte Traps müssen vom Gateway in OSI-Notifikationen übersetzt und zu den entsprechenden EFDs weitergeleitet werden. Diese übernehmen schließlich den Transport zu den jeweiligen OSI-Managern.
Wir haben zur Verdeutlichung des Vorgangs in Abbildung
einen Ausschnitt der Operatorkonsole des
OSI-Managementsystems dargestellt, in dem sich unterhalb der Knoten
TelcoNet (das gesamte Kommunikationssystem) und TelcoSys
(die über das Gateway administrierte SNMP-Domäne) die eigentlichen
Ressourcen wiederfinden, die in unserem Fall vier Workstations
(sunhegering2, ibm1, hp7, hp4) und einen Ethernet-Switch (enswitch1)
umfassen. Die Workstations verfügen jeweils über die MIB-II (mib2)
und eine weitere von uns entwickelte UNIX Workstation MIB (lrz-unix), die in
Abschnitt
vorgestellt wird. Die Bestandteile der
einzelnen MIBs (9 Gruppen der MIB-II, 5 Gruppen der Unix Workstation
MIB) ergeben sich aus der untersten Zeile der Darstellung.
Um die Abbildung übersichtlich zu halten, haben wir die lediglich
die MIB-II des Systems sunhegering2 sowie die UNIX Workstation MIB des
Systems hp4 im Detail ausgewählt. Eine expandierte Darstellung
erreicht man durch Selektion des jeweiligen Symbols.
Die aus Abschnitt
bekannte Abbildung von
SNMP-Gruppen auf OSI-MOCs wird hier sichtbar. Ferner zeigt sich, daß
die Gruppe system, die sowohl in der MIB-II als auch in der UNIX
Workstation MIB existieren, geeignet umbenannt werden mußte (
internetSystem bzw. lrz-system), um einen Namenskonflikt mit
der Basis-MOC system des OSI-MIT zu vermeiden.
Die vorher angesprochenen Parameter zur Konfiguration des Gateways
(z.B. hinsichtlich der Pollingintervalle) werden über die MOI
CMIP/SNMP dem Management zur Verfügung gestellt, die am rechten
Rand der Abbildung sichtbar ist.
Das Auslösen einer Abfrage auf einem oder mehreren Managed Objects
geschieht durch Selektion des entsprechenden Symbols und
Vervollständigen der notwendigen Angaben in einem weiteren Fenster.
Hierbei kann u.a. der Scope einer Operation angegeben werden sowie die
für diese Operation geltenden Filterregeln. Außerdem kann eine
Synchronisationsbedingung (atomic/best effort) angegeben
werden. Schließlich werden diejenigen Attribute ausgewählt, deren
Wertebelegung angezeigt werden soll. Innerhalb der Filterregeln
können die Attribute mit Vergleichsoperatoren (bezüglich Zahlen und
Strings) versehen werden; diese Terme lassen sich dann mit logischen
Operatoren verknüpfen. Man erhält so die Möglichkeit,
zusammengesetzte Abfragen zu definieren, die starke Ähnlichkeit mit
der Datenbank-Abfragesprache SQL haben. Sämtliche Abfragen lassen sich auch
persistent speichern bzw. laden. Denkbare Abfragen wären zum
Beispiel: ,,Ermittlung des Systemnamens aller Workstations, deren
Root-Partition zu mehr als 80% belegt ist`` oder ,,Löschen aller
Prozesse eines Benutzers, welche seit mehr als 24 Stunden laufen``.
Solche zusammengesetzten Abfragen kommen der Ausdruckskraft von
Management-Zielvorgaben bereits sehr nahe und bieten so den
Netzadministratoren ausgezeichnete Überwachungs- und
Eingriffsmöglichkeiten, die aufgrund der verteilten Auswertung auf
den Agentensystemen ebenfalls ausgesprochen gut skalieren. Auf Seiten
des Managementsystems werden somit nur die Abfragen formuliert und die
Ergebnisse der Abfragen in Empfang genommen. Hierdurch besteht die
Möglichkeit, auch mehrere unterschiedliche Abfragen parallel
durchzuführen. Abbildung stellt die
graphische Anzeige einer Anfrage auf die system-Gruppe der
MIB-II (hier aus den oben genannten Gründen als internetSystem
bezeichnet) auf dem System ibmhegering1 graphisch dar. Das
daraufhin zurückgelieferte Ergebnis ist in Abbildung
dargestellt.
Ein deutliches Indiz für die Leistungsfähigkeit des Gateway-basierten Integrationsansatzes ist die nahtlose Integration des SNMP-Managements in OSI, da es unser Gateway-Prototyp ermöglicht, diese ursprünglich nur bei OSI verfügbaren Abfragen auch auf solchen Systemen auszuführen, die lediglich SNMP-Agenten besitzen. Es ist unmittelbar einsichtig, daß solche Abfragen in einer reinen SNMP-Umgebung nicht möglich sind, da in SNMP-PDUs jeweils nur die Wertebelegungen konkreter Variablen abgefragt werden können und eine Filterung lediglich auf Seiten des Managementsystems möglich ist. Aus Skalierbarkeitsgründen ist dies in der Praxis oft undurchführbar.
Um eine Vorstellung der Antwortzeiten unseres Gateways zu vermitteln, werden wir nun einige in Abhängigkeit der Komplexität der Abfrage empirisch ermittelte Meßwerte vorstellen. Es sei jedoch an dieser Stelle betont, daß wir die reine Bearbeitungszeit durch das Gateway nicht ermitteln konnten, sondern uns vielmehr auf die (für den Benutzer sichtbare) gesamte Zeitspanne zwischen Anfragezeitpunkt und Ergebniszustellung konzentriert haben, die jedoch offensichtlich stark von der Ressourcenanzahl sowie der Komplexität der Abfrage abhängt.
Es ist deutlich zu erkennen, daß der hohe Komfort der OSI-Abfragen zu
einem erhöhten Datenaufkommen zwischen Gateway und SNMP-Agenten
führt, da die Verarbeitung und Auswertung der Anfragen vollständig
durch das Gateway erfolgt.
Erweiterung des Gateways um neue Ressourcen
Wir werden uns nun der Problematik zuwenden, wie unser CMIP/SNMP-Gateway um neue Ressourcen-MIBs für SNMP-fähige Geräte erweitert werden kann.
Zuerst muß, wie in Abbildung dargestellt ist,
die MIB-Definition einer neuen Ressource mit Hilfe des
IIMC-Algorithmus vom Internet-Informationsmodell in GDMO übersetzt
werden. Anschließend erfolgt innerhalb der Entwicklungsumgebung durch
das TMN/C++ API die Umsetzung der GDMO-Objektklassenbeschreibungen in
C++ Callback-Klassen, deren Methoden vom Entwickler in entsprechende
SNMP-Aufrufe umgesetzt werden müssen. Nachdem dies geschehen ist,
wird das gesamte Gateway neu übersetzt und gebunden, was in unserem
Falle der beiden unterstützten MIBs auf einer IBM RS/6000 Workstation
(Modell 3BT) mit 128 MB Hauptspeicher ca. 60 Minuten dauert. Das
Ergebnis ist ein CMIP/SNMP-Gateway, dessen Codegröße ohne
Abstützung auf shared libraries knapp 40 Megabyte beträgt.
Folglich ist die Erweiterung um neue MIBs gegenwärtig relativ
aufwendig, da das vollständige Gateway für jede neu hinzukommende
MIB neu übersetzt werden muß.