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:

• Name Mapping  bezeichnet die Aufgabe, nach Erhalt einer CMIS-Anfrage auf eine bestimmte MOI den korrespondierenden Object Identifier zu berechnen. Dies ist notwendig, da die Zugehörigkeit der Ressource zum Internet-Management für das Managementsystem transparent ist.
• Mit Service Mapping  wird die Transformation von CMIS-Diensten (die Scoping und Filtering beinhalten können) in entsprechende SNMP-PDUs bezeichnet. Nach Eintreffen eines CMIS-Requests müssen diejenigen MOIs identifiziert werden, die im Scope des Requests liegen und auf die folglich die Operation angewandt werden muß. Daraufhin muß geprüft werden, ob deren Attribute die Filterkriterien erfüllen. Ist dies der Fall, wird die Operation auf den betroffenen MOIs ausgeführt. Tabelle gibt einen Überblick, wie die CMIS-Operationen auf SNMP-PDUs durch das Gateway abgebildet werden.

  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.

 

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:

• Der Infratop-Prozeß setzt sich aus zwei Komponenten zusammen, die als Infrastructure bzw. Naming and Replication bezeichnet werden. Dieser Prozeß stellt den Kern eines Agenten dar, da er sowohl CMISE als auch ACSE realisiert und darüber hinaus auch den Management Information Tree verwaltet sowie die Gültigkeit von Name Bindings für M-CREATE bzw. M-DELETE Anfragen überprüft. Ferner ist der Infratop für die Verarbeitung von Scopes und Filtern verantwortlich, die im wesentlichen darin besteht, eine Anfrage an alle im Scope liegenden MOIs zu replizieren. Während dies einerseits eine wesentliche Verringerung des Entwicklungsaufwandes bedeutet, werden wir im folgenden sehen, daß wir uns damit auch eine signifikante Einschränkung bezüglich der dynamischen Erweiterbarkeit unseres Gateways einhandeln.
• Discr ist die zur OSI Event Report Management Function  [#!iso10165-5!#] konforme Komponente, die eine flexible Ereignisfilterung und -weiterleitung auf der Basis von EFDs zuläßt.
• Logr stellt als Implementierung der OSI Log Control Function  [#!iso10165-6!#] Dienste zur persistenten Speicherung von Ereignismeldungen bereit.
• Der Agent schließlich beinhaltet die MOIs sowie die Dienste zum Zugriff auf die konkrete Ressourceninstrumentierung. Wir haben hier eine SNMP-Programmierschnittstelle eingebunden, um so die entsprechenden PDUs erzeugen zu können.

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.

• Für die in Abbildung angegebenen 5 Ressourcen mit der MIB-II sowie der UNIX Workstation MIB benötigt die Erstellung des MIT beim Start des Managementsystems ca. 90 Sekunden.
• Die Abfrage der Wertebelegungen einer SNMP-Gruppe auf einem System (wie in Abbildung dargestellt) variiert zwischen 1 Sekunde (für die system-Gruppe) und 15 Sekunden (Auslesen der aktuellen Prozeßliste).
• Die Abfrage einer MIB-Variable über alle 5 Systeme mit Scope und Filter benötigt zwischen 10 und 12 Sekunden.
• Komplexe Abfragen auf mehrere MIB-Variablen mit zusammengesetzten Filtern auf allen 5 Systemen dauert bestenfalls 30 Sekunden und im ,,worst case`` bis zu 3 Minuten.

  

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