Implementierungsbeispiel 2: CORBA/SNMP Gateway

 

In Analogie zum CMIP/SNMP Gateway vermittelt ein CORBA/SNMP Gateway zwischen einem CORBA-konformen Managementsystem und mehreren SNMP-Agenten (siehe Abbildung ). In der CORBA-Architekturdomäne ist das Gateway eine Anwendung, die über einen ORB mittels CORBA-Requests von einem CORBA-Managementsystem angesprochen werden kann. Aus Sicht der SNMP-Agenten hingegen ist das Gateway ein SNMP-Manager. Die wesentlichen Aufgaben des Gateways liegen auch hier in der transparenten Weiterleitung von CORBA-Requests auf SNMP-PDUs sowie die Übermittlung der Ergebnisse. Eine Besonderheit der Kopplung von CORBA mit SNMP liegt darin, daß CORBA-Objekte bereits explizit vom Managementsystem adressiert werden und das Auslesen bzw. Setzen von MIB-Attributen durch Aufrufe der diesen Attributen zugeordneten get()- bzw. set()-Methoden geschieht. Ein anderes Spezifikum von CORBA ist, wie bereits vorher erwähnt, daß die Struktur von CORBA-Requests im Gegensatz zu den PDUs eines Managementprotokolls variabel ist. Eine zentrale Komponente zur Ermittlung der in Frage kommenden MOI sowie zur Weiterleitung der Anfragen ist somit nicht erforderlich. Ein weiterer Aspekt von CORBA besteht darin, daß sich eine Anfrage grundsätzlich nur auf eine Objektinstanz bezieht; ein leistungsfähiger Scoping und Filtering-Mechanismus, wie ihn das OSI-Management kennt, fehlt hier. Somit entfällt auch die Möglichkeit der verteilten Auswertung von Anfragen bezüglich mehrerer MOIs auf den Agenten bzw. dem Gateway. Schließlich müssen SNMP-Traps vom Gateway angenommen und einem CORBA-basierten Managementsystem über die in Abschnitt diskutierten Event Channels  zugestellt werden.
 

Architektur des CORBA/SNMP Gateway-Prototyps  

Aufgrund der Komplexität des Gesamtsystems liegt es nahe, das Gateway in verschiedene Komponenten zu zerlegen, die jeweils eine bestimmte Aufgabe erfüllen. Im einzelnen können folgende Komponenten identifiziert werden:

  

Abbildung: Architektur eines CORBA/SNMP Management-Gateways

Proxy-Objekte sind die Instanzen der in IDL beschriebenen Objektklassen, die die SNMP-MIB des Agenten repräsentieren und durch den JIDM-Algorithmus erzeugt wurden. Diese Proxy-Objekte sind Teil des Gateways. Der Manager greift auf die Proxy-Objekte zu, indem er die Methoden der Proxy-Objekte mittels CORBA-Requests aufruft, worauf diese mit CORBA-Responses antworten. Wie für alle CORBA-Clients üblich, kann der Manager über die statische und/oder die dynamische Aufrufschnittstelle Methoden der Proxy-Objekte aufrufen. Die statische Aufrufschnittstelle ist für Managementzwecke allerdings wenig geeignet, da dazu die Client-Stubs aus der IDL-Beschreibung der Proxy-Objekte zu den Client-Programmen der Managementanwendung zur Übersetzungszeit gebunden werden müssen. Jedesmal, wenn neue Proxy-Objektklassen hinzukommen und verwendet werden sollen, müßte bei Verwendung der statischen Aufrufschnittstelle die Managementanwendung also neu übersetzt werden. Dies ist natürlich nicht praktikabel.

Für die dynamische Aufrufschnittstelle benötigt die Managementanwendung Objektreferenzen auf die Proxy-Objekte, auf die zugegriffen werden soll. Diese Referenzen werden dem Managementsystem wahlweise durch den Naming Service oder durch Events (etwa vom Gateway, wenn dort ein Proxy-Objekt erzeugt wurde) zur Verfügung gestellt. Beim Methodenaufruf gibt der Manager in einem Request die Objektreferenz des adressierten Proxy-Objektes, die aufzurufende Methode sowie die dazugehörigen Parameter an. Anhand der Objektreferenz lokalisiert der ORB das Proxy-Objekt und ruft dort die gewünschte Methode auf.

Der snmpserver  ist die Komponente zur Kommunikation mit der SNMP-Umgebung. Hauptaufgabe des snmpserver ist das Aussenden von SNMP-Request-PDUs und das Empfangen der dazugehörigen Response-PDUs. Außerdem muß der snmpserver den Inhalt der Response-PDUs an die richtigen Proxy-Objekte weiterleiten können. Hierzu wird durch den JIDM-Algorithmus zu jeder erzeugten MOC sowie zu jedem Attribut dieser MOC die entsprechende SNMP OID als Konstante in die IDL-Definition des Moduls eingetragen (vgl. dazu auch Anhang ).

Der snmptrapd  ist diejenige Gatewaykomponente, die für den Empfang der von den Agenten stammenden SNMP Trap-PDUs sowie deren Abbildung auf CORBA-Events. Zusammen mit dem snmpserver bildet der snmptrapd den Teil des Gateways, der gegenüber den SNMP-Agenten in der Managerrolle agiert.

Der letzte Bestandteil des Gateways ist der Discovery-Dämon discoverd, dessen Aufgabe im Auffinden neuer SNMP-Ressourcen besteht, wobei dies analog zu den üblichen Discovery-Mechanismen kommerzieller SNMP-Managementplattformen geschieht (Auslesen von ARP-Caches und Routing-Tabellen der Ressourcen, Subnetz-Discovery durch Versenden von ICMP-PDUs, Durchlaufen der Ressourcen-MIBs mit SNMP get-next Operationen usw.). Im Falle eines Auffindens neuer Ressourcen ist diese Komponente demzufolge insbesondere für die Erzeugung neuer Proxy-Objekte zuständig.

In den folgenden Abschnitten wird diskutiert, wie diese Komponenten zur Erreichung eines flexiblen und erweiterbaren Gesamtsystems zusammenwirken.

Funktionsweise des CORBA/SNMP Gateway-Prototyps  

Abbildung zeigt eine Beispielkonfiguration des Gateways zur Laufzeit. In der SNMP-Umgebung läuft ein SNMP-Agent auf dem Rechner sun6. Von der MIB-II des Agenten sind beispielhaft die system-Gruppe und die Routing-Tabelle ( ipRouteTable) der MIB-II IP-Gruppe abgebildet. Der Wert der Variable sysDescr ist ``SunOS 4.0.1``; die Routing-Tabelle besteht aus insgesamt zwei Zeilen. Ein Zeileneintrag (d.h. die SNMP-Instanzen, die zu dieser Zeile gehören) wird mit dem Wert des Spaltenobjektes ipRouteDest eindeutig identifiziert. Der Agent wird über die IP-Adresse 129.188.215.16 und die Portnummer 161 angesprochen.

Im Gateway wurden durch den Discovery-Dämon die in der Abbildung grau unterlegten Proxy-Objekte erzeugt, die der Agenten-MIB entsprechen. Für die system-Gruppe wurde im Gateway eine Instanz der IDL-Schnittstelle systemGroup generiert. In dieser Schnittstelle wurde für jedes Managed Object der SNMP-Gruppe system mit dem JIDM-Algorithmus ein Attribut definiert. Auf die Instanz eines Managed Object kann über das gleichnamige Attribut des Proxy-Objektes zugegriffen werden. Für das Managed Object sysDescr stehen dazu zwei Methoden, get_sysDescr und set_sysDescr, zur Verfügung. Bei einem Aufruf dieser Methoden werden zusätzlich die Werte von zwei Attributen benötigt, um die richtige SNMP-Instanz zu adressieren: Während das Attribut destination des Proxy-Objektes der Klasse systemGroup die IP-Adresse des Agenten beinhaltet, ist das Attribut indexinfo mit dem Zugriffsidentifikator der SNMP-Variablen belegt, die das Proxy-Objekt repräsentiert (hier: .0). Die Objektidentifikatoren der SNMP-Variablen wurden zuvor als Konstante im Interface Repository abgelegt.

In unserem Beispiel wird für jede Zeile der Routing-Tabelle eine Instanz der IDL-Klasse ipRouteTableEntry erzeugt. Analog zum oben geschilderten Fall ist bei beiden Proxy-Objekten das Attribut destination mit der IP-Adresse des SNMP-Agenten belegt. Die Attribute indexinfo sind hingegen mit dem Wert des Spaltenobjektes belegt, das einen Zeileneintrag der Routing-Tabelle eindeutig identifiziert (hier: der Wert des Indextyps ipRouteDest). Das erste Proxy-Objekt erhält den Index (.128.129.215.13) der ersten Tabellenzeile, das andere den der zweiten Zeile (.234.111.116.64). Hierdurch sind die Proxy-Objekte eindeutig einer Zeile der Routing-Table zuzuordnen. Die Elemente einer Zeile können mit den Attributzugriffsfunktionen des entsprechenden Proxy-Objektes ausgelesen bzw. gesetzt werden. Die zentrale Gateway-Komponente zum Erzeugen von SNMP-PDUs ist das snmpserver-Objekt. Die Methoden snmp_get() und snmp_set() erzeugen und versenden SNMP Request-PDUs und empfangen die dazugehörigen SNMP Response-PDUs. Die CORBA-Laufzeitumgebung sorgt dafür, daß ein Aufruf einer Methode eines CORBA-MOs auf das Proxy-Objekt weitergeleitet wird (in der Abbildung durch die gestrichelte Linie dargestellt). Die Schnittstellen der CORBA-MOs (bzw. Proxy-Objekte) können durch ORB-Dienste ermittelt werden.

  

Abbildung: Funktionsweise des CORBA/SNMP-Gateways

SNMP Get/Set-Anfragen

Zunächst sei angenommen, daß der Manager vom Proxy-Objekt der Klasse systemGroup den Wert des Attributs sysDescr auslesen will.

1.

Dies geschieht durch Aufruf der Methode get_SysDescr. Der Aufruf wird dann von der CORBA-Laufzeitumgebung an das Proxy-Objekt weitergeleitet (Schritt (1a) in Abbildung ).

2.

Innerhalb der aufgerufenen Methode erfolgt ein Aufruf der Methode snmp_get des snmpserver-Objektes, von dem jedes Proxy-Objekt eine Objektreferenz speichert. Der Parameter MOinstance dieser Methode setzt sich zusammen aus dem Objektidentifikator von sysDescr und dem Wert des Attributs indexinfo. Der Objektidentifikator einer MIB-Variable steht im Interface Repository und wird aus Effizienzgründen bereits im Proxy-Objekt gespeichert. An ihn wird der Zugriffsidentifikator der SNMP-Variable angehängt. Konkret ergibt sich für den Parameter MOinstance der Wert 1.3.6.1.2.1.1.1.0. Das snmpserver-Objekt erzeugt daraufhin die Variable Binding List für die GetRequest-PDU, die er zusätzlich mit dem Community-String versieht.

3.

Die mit allen Angaben versehene SNMP-PDU wird an den Agenten verschickt, der den Wert der angegebenen Objektinstanz ermittelt (in unserem Beispiel ``SunOS 4.0.1``) und mit einer GetResponse-PDU wieder an das Gateway zurückgesandt.

4.

Aus der eingehenden GetResponse-PDU extrahiert das snmpserver-Objekt den Wert der SNMP-Variable sysDescr und gibt ihn dem Proxy-Objekt weiter (Rückgabewert der Methode snmp_get). Ferner überprüft das Proxy-Objekt, ob eine Fehlersituation aufgetreten ist, d.h. ob eine Exception vom snmpserver-Objekt ausgelöst wurde. Ist dies nicht der Fall, kann das Ergebnis an den Manager zurückgegeben werden.

5.

Für ein zweites Beispiel, das den Zugriff auf SNMP-Tabellen illustriert, nehmen wir an, daß der Eintrag für ipRouteNextHop der ersten Zeile der Routing-Tabelle geändert werden soll. Pakete mit der Zieladresse 128.129.215.13 sollen fortan nicht mehr an die Adresse 128.187.121.15 sondern an die Adresse 131.156.10.176 weitergeleitet werden. Diesen neuen Wert für das Attribut gibt der Manager beim Aufruf der Methode set_IpRouteNextHop des Proxy-Objektes an. Um herauszufinden, auf welchem Objekt er die Methode aufrufen muß, hat der Manager vorher das Attribut ipRouteDest abgefragt. Wiederum sorgt die CORBA-Laufzeitumgebung dafür, daß die entsprechende Methode des Proxy-Objektes aufgerufen wird (Schritt (5a) in Abbildung ).

6.

Der Parameter MOinstance für den Aufruf von snmp_set wird auf dieselbe Weise wie oben angegeben berechnet und setzt sich aus der OID (1.3.6.1.2.1.4.21.1.7) sowie indexinfo (.128.129.215.13) zusammen. Der Parameter value hingegen enthält die neue IP-Adresse 131.156.10.176.

7.

Diesmal wird vom snmpserver-Objekt eine SetRequest-PDU erzeugt und an den SNMP-Agenten versandt.

8.

Die vom SNMP-Agenten zurückgeschickte SetResponse-PDU dient primär der Feststellung evtl. aufgetretener Fehler. Falls die SNMP-Variable nicht gesetzt werden konnte (da beispielsweise der Community-String falsch war) wird dies in der Response-PDU durch den Fehler authorizationError angezeigt. Das snmpserver-Objekt löst die der Fehlermeldung entsprechende Standard-Exception NO_PERMISSION aus. Dasselbe tut das Proxy-Objekt, sobald aus der Methode snmp_set zurückgekehrt wird.

Anwendung von GetNextRequest- und GetBulk-Anfragen

Für den schreibenden Zugriff auf SNMP-Agenten kann beim Aufruf der Methode snmp_set() jeweils nur eine SetRequest-PDU an den Agenten gesandt werden. Für den lesenden Zugriff hingegen stehen in SNMP neben der GetRequest-PDU zwei weitere Protokolldateneinheiten zur Verfügung, nämlich GetNext und GetBulk. Mit ihnen können, wie wir in Abschnitt erläutert hatten, Tabellen durchlaufen bzw. auf größere Datenmengen von SNMP-Ressourcen effizienter zugegriffen werden. Der Manager kann beispielsweise alle Attributwerte der einem Tabellenzeileneintrag entsprechenden Objekte gleichzeitig abfragen. Um den gesamten Inhalt der Tabelle vom SNMP-Agenten zu holen, wird SNMP-seitig nur eine einzige GetBulk-PDU benötigt. Aufgrund der Tatsache, daß der JIDM-Algorithmus jede Tabellenzeile auf voneinander unabhängige Proxy-Objekte abbildet, kann von der GetBulk-Optimierung kein Gebrauch gemacht werden, da die die Tabellenzeilen darstellenden Objekte voneinander unabhängig die Methoden des snmpserver-Objektes aufrufen, um die SNMP-PDUs zu generieren. Dieses kann aber weder feststellen, daß zwischen angeforderten SNMP-Variablen ein Zusammenhang besteht, noch kann es a priori wissen, wie viele SNMP-Variablen von den Proxy-Objekten noch angefordert werden, die in einer GetBulk-PDU zusammengefaßt werden könnten. Jeder Methodenaufruf wird einzeln abgearbeitet, was bedeutet, daß mit einer GetRequest-PDU immer nur eine einzige SNMP-Variable abgefragt wird. Folgende Maßnahmen müßten getroffen werden, um GetBulk-PDUs zu unterstützen:

• Erweiterung der Proxy-Objekte dahingehend, daß mehrere (unterschiedliche) Attributzugriffsfunktionen gleichzeitig aufgerufen werden können. Bisher war ein Proxy-Objekt erst nach der Rückkehr aus einer Attributzugriffsfunktion wieder bereit, Methoden abzuarbeiten.
• Modifizieren der Parameter der Methode snmp_get() damit Proxy-Objekte mehr als eine SNMP-Variable übergeben können.
• Im snmpserver-Objekt werden Anforderungen von Proxy-Objekten nach Zielagent sortiert ,,gesammelt`` und mehrere Variablen gleichzeitig in einer GetRequest-PDU oder einer GetBulk-PDU abgefragt. Dies stellt einen Versuch dar, angeforderte MIB-Variablenwerte mit möglichst wenigen SNMP-PDUs zu erhalten.

Hierfür müßte insbesondere das von uns verfolgte Konzept des zustandslosen Gateways aufgegeben werden, da Anfragen entsprechend des Zielsystems in Warteschlangen eingereiht werden müßten, um gemeinsam in einer GetBulk-PDU angefordert werden zu können. Ferner müßte ein Timeout-Mechanismus implementiert werden, der veranlaßt, daß nach Ablauf einer bestimmten Zeit die Warteschlangeninhalte in SNMP-PDUs verpackt und abgeschickt werden. Da uns der Mehrwert im Vergleich zu den Implementierungskosten nicht gerechtfertigt erschien, haben wir von einer Verwendung der GetBulk-Operation abgesehen.

Aus verwandten Gründen kann auch die GetNext-Operation nur eingeschränkt verwendet werden: Durch eine GetNextRequest-PDU werden Informationen vom Agenten zurückgegeben, die nicht dem Proxy-Objekt zugeordnet werden dürfen, das die Methode snmp_get() aufgerufen hat. Wenn beispielsweise die Methode get_ipRouteNextHop() des Proxy-Objektes, das die erste Zeile der Routing-Tabelle repräsentiert (in Abbildung das Proxy-Objekt mit indexinfo=.128.129.215.13), aufgerufen wird und daraufhin eine GetNextRequest-PDU verschickt wird, so wird der entsprechende Spalteneintrag der nächsten Tabellenzeile, also 131.156.10.176 vom Agenten zurückgegeben. Da mit der GetNextRequest-PDU Tabellen durchlaufen werden können, von denen die Zeilenindizes nicht bekannt sind, wird diese PDU im Gateway nur vom Discovery-Dämon eingesetzt.

Weiterleitung asynchroner Ereignismeldungen

Für die Weiterleitung von SNMP-Traps benutzen wir analog zu Abschnitt typisierte Event Channels, von denen jeder einem bestimmten SNMP-Trap zugeordnet ist. Die Event Channels selbst werden in einen Naming Graph eingetragen, wodurch eine CORBA-basierte Managementapplikation die Event Channels auffinden und sich bei diesen zum Empfang von Ereignismeldungen registrieren kann.

Das snmptrapd-Objekt, das an Port 162 SNMP-Trap-PDUs empfängt, registriert sich bei allen Event Channels als Supplier, da sämtliche SNMP-Traps hier eingehen und in typisierte Events umgewandelt werden. Er spielt somit dieselbe Rolle wie der in Abschnitt beschriebene EFD_Supplier und die Verfahren zur Zustellung der Ereignismeldungen an die registrierten CORBA-basierten Managementapplikationen, die in der Rolle des Consumers agieren, laufen somit identisch ab. Wir werden daher zur Vermeidung von Wiederholungen auf eine Diskussion der Mechanismen zur Ereignisweiterleitung verzichten.

Erweiterung des Gateways um neue Ressourcen  

Die von einem Sprachcompiler erzeugten IDL-Klassendefinitionen einer SNMP-MIB (siehe dazu Abschnitt bzw. Anhang ) werden in das Interface Repository des ORB eingetragen (vgl. Abbildung ), also nicht direkt in das Managementsystem, wie es bei SNMP-Managern bzw. SNMP-Plattformen notwendig ist. Für jede neu hinzukommende oder geänderte Agenten-MIB wiederholt sich dieser Vorgang, der im wesentlichen daraus besteht, die aus dem JIDM-Algorithmus erzeugten IDL-Objektbeschreibungen mit dem Code des Gateways neu zu übersetzen und zu binden, um die neuen MO-Beschreibungen dem Gateway bekanntzugeben. Es gibt bisher von der OMG keinen standardisierten Mechanismus, um dies zur Laufzeit zu tun, weshalb wir bei der Implementierung der Discovery-Komponente unseres Gateways einen proprietären Mechanismus der von uns verwendeten SOM/DSOM-Entwicklungsumgebung verwendet haben. Es handelt sich hierbei um das DSOM Metaclass Framework, das es uns gestattet, neue Objektdefinitionen zur Laufzeit in das Interface Repository  einzuspielen und deren Implementierung mit dem Gateway zu verknüpfen (siehe Abbildung ). Im Rahmen des OMG Meta-Object Service ist ein solches Verfahren angedacht, jedoch bisher noch nicht standardisiert worden.

  

Abbildung: Bekanntgabe neuer Ressourcen

In jeder CORBA-Umgebung existiert ein verteiltes Interface Repository, auf das alle CORBA-Anwendungen Zugriff haben. Mit dem einmaligen Laden einer in IDL übersetzten Agenten-MIB ins Interface Repository steht diese MIB (bzw. die entsprechenden Schnittstellendefinitionen) dann automatisch sowohl der Managementanwendung als auch dem Gateway zur Verfügung.