next up previous contents index
Next: Implementierungsbeispiel 2: CORBA/SNMP Gateway Up: Abbildung der Kommunikationsmodelle Previous: Abbildung der Kommunikationsmodelle

Implementierungsbeispiel 1: CMIP/SNMP Gateway

 

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!#].


  
Abbildung: Prinzipieller Aufbau eines CMIP/SNMP Management-Gateways

Die durch das Gateway erfüllten Aufgaben lassen sich in zwei zentrale Kategorien unterteilen:


 
Tabelle:   Abbildung der CMIS-Operationen auf SNMP-PDUs
1|c|CMIS-Dienst 1c|SNMP-PDU
M-GET SNMP-GET
M-SET SNMP-SET bzw. SNMP-GET
M-CREATE SNMP-SET
M-DELETE SNMP-SET
M-CANCEL-GET -
M-EVENT-REPORT SNMP-TRAP

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.


  
Abbildung: Architektur des CMIP/SNMP Gateways

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:

Funktionsweise des Gateways  

Die Funktionsweise des Gateway-Prototyps ist nachfolgend am Beispiel eines scoped und filtered M-GET.request dargestellt (siehe auch Abbildung [*]):


  
Abbildung: Ablauf eines M.GET-requests mit Scoping und Filtering

1.
Vom OSI-Managementsystem wird durch den CMIS/ACSE-Stack ein M-GET.request mit den gewünschten Scope-, Filter- und Synchronisationsparametern auf eine Basis-MOC abgesendet.
2.
Das Gateway empfängt diese PDU als M-GET.indication, extrahiert die Parameter und gibt diese an die Naming and Replication-Komponente weiter.
3.
Dort werden die Scopes, Filter und Synchronisationsbedingungen ausgewertet. Hier geschieht die Prüfung, ob eine Instanz der ausgewählten Basis-MOC überhaupt vorhanden ist.
4.
Ist dies nicht der Fall, wird eine M-GET.response, die die Fehlermeldung noSuchInstance enthält, an das Managementsystem zurückgeschickt.
5.
Existiert eine Instanz der Basis-MOC, werden die Scopeparameter dahingehend ausgewertet, daß jede im Scope befindliche Instanz einer MOC eine Kopie der GET-Operation zugestellt bekommt. Dies geschieht durch Übergabe der replizierten Operation an den Core Agent.
6.
Dieser stößt die Bearbeitung der Operation auf den entsprechenden MO-Instanzen an, indem die Callback-Methoden der jeweiligen Attribute getriggert werden.
7.
Diese Callback-Methoden enthalten Funktionen zur Bestimmung der SNMP-OID der jeweiligen Attribute. Anschließend erfolgt für die betroffenen MIB-Variablen jeweils eine SNMP-GET Anfrage, deren Antwort die Wertebelegungen der betrachteten MIB-Variablen enthält.
8.
Der Core Agent nimmt die Ergebnisse entgegen und gibt diese seinerseits an die Protokollinfrastruktur des Gateways weiter.
9.
Die Infrastruktur verpackt die Ergebnisse in M-GET.response PDUs und schickt diese in Form von linked replies an das Managementsystem zurück, wo sie weiterverarbeitet werden können.

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.


  
Abbildung: Management Information Tree des Gateway-Prototypen

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.


  
Abbildung: Anzeigefenster für Anfrage auf die MIB-II System-Gruppe

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.


  
Abbildung: Ergebnis der Anfrage auf die MIB-II System-Gruppe

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.


  
Abbildung: Integration von MIBs für neue Ressourcen in das Gateway

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ß.


next up previous contents index
Next: Implementierungsbeispiel 2: CORBA/SNMP Gateway Up: Abbildung der Kommunikationsmodelle Previous: Abbildung der Kommunikationsmodelle
Copyright Munich Network Management Team