4.6 Vorstellung des Konzeptes

  In den vorhergehenden Abschnitten wurden verschiedene Ansätze vorgestellt, die nun bewertet werden. Zuerst wird entschieden, ob ein zustandsloses oder ein zustandsbehaftetes Gateway als Basis für das Konzept dienen soll. Sobald dies feststeht, wird zwischen den verschiedenen Lösungsansätzen abgewogen.

Bei der Frage, ob ein zustandsloses oder ein zustandsbehaftetes Gateway besser geeignet ist, muß folgendes betrachtet werden (vgl. auch 4.2.1):

• Der Zugriff auf die Schattenobjekte von Seiten des Managers ist bei einem zustandsbehafteten Gateway sehr schnell, da kein Lookup auf die SNMP-Instanzen erfolgt. Bei einem zustandslosen Gateway muß hingegen bei jedem Zugriff auf ein Schattenobjekt mit einem SNMP-Agent kommuniziert werden.
• Der Zugriff auf SNMP-Ressourcen ist auf effektive und effiziente Weise möglich. Mit GetBulk und GetNext können mit einem Mal sehr viele SNMP-Variablen abgefragt werden. In einem zustandslosen Gateway hat dies keinen Sinn, da zusätzlich abgefragte Information nicht gespeichert werden kann.
• Im zustandsbehafteten Gateway können die im Gateway gespeicherten Werte mit den Werten der entsprechenden Managed Objects verglichen werden und so Veränderungen der Informationsinhalte festgestellt werden. Veränderungen können durch Events einer Managementanwendung gemeldet werden. Damit kann ein Controlling von SNMP-Ressourcen, welche sonst nur durch Polling verwaltet werden können, simuliert werden.
• Die im Gateway gespeicherten Werte müssen zum Zeitpunkt des Zugriffs mit den entsprechenden Werten in der SNMP-Umgebung konsistent sein. Häufig notwendige Aktualisierung durch SNMP-Requests kann sich negativ auf die Netzlast auswirken und damit den Vorteil des zustandsbehafteten gegenüber dem zustandslosen Gateway relativieren.
• Inkonsistenzen in den Schattenobjekten bei einem zustandsbehafteten Gateway können nicht vollständig ausgeschlossen werden. Um den Grad der Inkonsistenz minimal zu halten, sind komplexe Strategien und Mechanismen notwendig.

Fazit: Für statische Information ist ein zustandsbehaftetes Gateway, für Information, die sich oft ändert, ein zustandsloses Gateway geeigneter. Da in den Agenten sowohl gleichbleibende als auch dynamische Werte vorkommen, kann weder das zustandslose noch das zustandsbehaftete Gateway kategorisch abgelehnt werden. Die beste Lösung ist vielmehr ein Gateway, welches die ,,Dynamik`` der Information in den einzelnen Managed Objects berücksichtigt, und zur Laufzeit entscheidet, ob eine SNMP-PDU benötigt wird. Dazu sind geeignete Kennzahlen und -werte notwendig, die das dynamische Verhalten der Managementobjekte beschreiben ([ACH93], [HAB91]).

Ein wichtiges Kriterium bei der Bewertung der besprochenen Ansätze ist also, in wie weit sich der jeweilige Ansatz für diese Lösung eignet. In dieser Diplomarbeit wurde für den in 4.3.3 auf Seite beschriebene Ansatz entschieden. Abbildung 4.15 zeigt nochmal diesen Ansatz: Jedes Schattenobjekt repräsentiert mit seinen Methoden und Attributen eine oder mehrere SNMP-Managementobjektinstanzen. Eine Managementanwendung kann auf SNMP-Instanzen zugreifen, indem sie mit CORBA-Requests die (Attributzugriffs-)Methoden entsprechender Schattenobjekte aufruft. Für den Informationsaustausch mit SNMP-Agenten ist die Komponente snmpserver im Gateway zuständig. Die Funktionalität dieser Komponente besteht darin, SNMP-PDUs zu erzeugen, zu senden und zu empfangen. Die Schattenobjekte rufen die Methoden dieses Gatewayobjektes auf und übergeben dabei als Parameter die Adresse des Zielagenten, an den die SNMP-PDU geschickt, und den Identifikator der SNMP-Instanz, auf die zugegriffen werden soll. Diese Werte werden einmalig in jedem Schattenobjekt bei dessen Erzeugung gesetzt.

  

Abbildung: Gewähltes Gateway-Konzept

Dadurch erfolgt die Zuordnung von einem Schattenobjekt (bzw. seiner Attribute) zu bestimmten, existierenden SNMP-Managementobjektinstanzen. Eine weitere Komponente im Gateway ist der Discovery-Dämon, dessen Aufgabe es ist, die SNMP-Umgebung zu explorieren und zu gefundenen SNMP-Agenten entsprechende Schattenobjekte zu erzeugen. Voraussetzung dafür ist, daß die Agenten-MIBs als IDL-Schnittstellendefinitionen im Interface Repository vorliegen. Ein SNMP-Trap-Dämon schließlich wartet an Port 162 des Gateway-Rechners auf ankommende SNMP-Trap-PDUs. Je nach Trap erzeugt er unterschiedliche CORBA-Events und schiebt sie in einen (typisierten) EventChannel. Dieser leitet die Events an alle bei ihm registrierten EventConsumer, beispielsweise an eine Managementanwendung weiter.

Dieser Ansatz hat folgende Vorteile:

• Die Schattenobjekte sind einfach, deren Implementierung ist dementsprechend einfach automatisierbar. Damit können sehr viele SNMP-Agenten schnell (d. h. mit wenig Aufwand) einer CORBA-Managementanwendung zur Verfügung gestellt werden.
• Es besteht die Möglichkeit, die Schattenobjekte individuell zu implementieren; damit kann das Gateway stufenweise zu einem zustandsbehafteten Gateway erweitert werden.
• Die IDL-Schnittstellendefinitionen der Schattenobjekte müssen nicht um Methoden ergänzt werden, die das Gateway zur Aktualisierung der Attribute nutzen kann. Dies ist notwendig, wenn die Schattenobjekte nicht selbst die von ihnen gespeicherten Werte konsistent halten.
• Im Gegensatz zum Gateway, bei dem jedes Schattenobjekt selbst SNMP-PDUs erzeugt (4.3.2 auf Seite ), kann bei diesem Ansatz die Komponente, welche die Kommunikation mit der SNMP-Umgebung übernimmt, ausgetauscht, erweitert und verbessert werden, ohne daß die Schattenobjekte verändert werden müssen (vorausgesetzt die Schnittstelle dieser Komponente bleibt gleich).
• In derselben Komponente können Informationen verwaltet werden. Beispielsweise könnten ein Community-String und/oder die Adresse eines bestimmten Agenten für SNMP-PDUs dort zentral gespeichert (und muß gegebenenfalls nur dort verändert) werden; Ebenso können statistische Daten, beispielsweise die Anzahl der verschickten SNMP-PDUs verwaltet und abgefragt werden.
• Sicherheitstechnisch hat dieser Ansatz den Vorteil, daß nur an einer oder wenigen Stellen der Übergang in die SNMP-Welt (im Sinne des Informationsaustausches) erfolgt, statt an beliebig vielen, wie es der Fall wäre, wenn jedes Schattenobjekt SNMP-PDUs erzeugt.

Es muß aber bedacht werden, daß es bei diesem Ansatz jedes Schattenobjekt mit einer Gatewaykomponente kommuniziert (mit Requests an diese Komponente), bevor eine SNMP-PDU erzeugt wird. Dieser zusätzliche Kommunikationsaufwand (innerhalb der CORBA-Umgebung) kann zu Performanceeinbußen führen. Umgekehrt kann die Komponente, welche SNMP-PDUs erzeugt, zum Engpaß werden. Dennoch wurde dieser Ansatz weiterverfolgt. Die im folgenden Abschnitt besprochenen Aspekte beschreiben das Gatewaykonzept genauer.

Im Bezug auf die Abbildung von SNMP-Trap-PDUs auf CORBA-Events wurde der ereignisgesteuerte Ansatz, also das push-Modell gewählt. Des weiteren wurde die typisierte Ereigniskommunikation der generischen vorgezogen. Die Entscheidunggründe wurden bereits im vorherigen Unterkapitel angeführt.