Die Repräsentation von SNMP-Tabellenzeilen im Gateway  

Die bisherige Architektur des Gateways erlaubt den Aufbau der Containment-Hierarchie für die Instanzen, die SNMP-Gruppen repräsentieren. Der Zugriff auf die Attribute dieser Instanzen von Managementobjekten erfolgt, wie schon oben erläutert, nach dem stateless Prinzip.
Für die vollständige OSI-Sichtweise auf SNMP-Ressourcen fehlen noch die Instanzen von Managementobjekt-Klassen, welche SNMP-Tabellenzeilen repräsentieren. Sobald diese Instanzen kreiert werden, werden die MIBs der SNMP-Agenten komplett in die lokale Gateway-MIB integriert und so für das Management eines OSI-Managers bereitgestellt.
Bei der ,,direkten Übersetzung`` wird, wie gerade erwähnt, jede SNMP-Tabellenzeile einer Instanz einer Managementobjekt-Klasse zugeordnet. Dabei erhält die Instanz als Relative Distinguished Name den Index der SNMP-Tabellenzeile. Dieser Index kann nur anhand von einer oder mehreren SNMP-GetRequest-PDU(s) bestimmt werden, das heißt, es muß Managementinformation aus der MIB des SNMP-Agenten im Gateway gespeichert werden.
Weiterhin wird eine Veränderung in einer SNMP-Tabelle, also dem Entstehen bzw. Terminieren von Tabellenzeilen, im allgemeinen nicht von einem SNMP-Agent einem SNMP-Manager gemeldet. Das heißt, das CMIP/SNMP Gateway, welches diese SNMP-Tabelle durch Instanzen von Managemenobjekt-Klassen (die eben die Tabellenzeilen repräsentieren), für das Management durch einen OSI-Manager bereitstellen soll, erhält keine Mitteilung über Veränderungen in der SNMP-Tabelle. Es ist also die Aufgabe des Gateways, dafür zu sorgen, daß für jede zu managende SNMP-Tabelle die Instanzen in der lokalen Gateway-MIB konsistent zu den realen Ressourcen (Tabellenzeilen) sind, siehe auch 3.2.4. Das heißt, für jede Tabellenzeile im SNMP-Agent muß genau eine, diese repräsentierende Instanz eines Managementobjekts in der Gateway-MIB existieren. Sobald eine neue Tabellenzeile erstellt bzw. gelöscht wird, muß auch die entsprechende Instanz im Gateway kreiert bzw. gelöscht werden. Dies ist aber wieder abhängig vom Typ der Tabellenzeile: dynamische Tabellen müssen stetig, statische Tabellen dagegen weniger häufig, auf Veränderungen hin überprüft werden. Das Gateway hat also zwei Problematiken zu lösen, siehe auch 4.4.2:

1.

Jede SNMP-Tabelle muß auf Veränderungen hin überprüft werden, um dementsprechend Instanzen kreieren bzw. löschen zu können.

2.

Es muß für jede SNMP-Tabelle die Art dieser Managementinformation bestimmt werden, um entscheiden zu können wie häufig bzw. nach welchen Intervallen diese SNMP-Tabelle überprüft werden soll.

Im Abschnitt 4.4.2 werden 2 Möglichkeiten angegeben, von wem die erste Problematik, die Replikation der SNMP-Tabelle in der Gateway-MIB, ausgeführt werden kann. Der erste Fall, daß jede Instanz selbst für die Konsistenzsicherung mit der realen Ressource verantwortlich ist, kann hier aus folgenden Gründen nicht realisiert werden:
Es wäre für jede Instanz notwendig, einen eigenen Timer zu implementieren, der nach einem bestimmten Intervall die Replikation ausführt. Da aber jede Instanz in der IBM TMN WorkBench for AIX mittels Callbacks kodiert wird und Callbacks nur aufgerufen werden, sobald bestimmte Situationen eintreffen, existiert keine geeignete Möglichkeit, einen Timer regelmäßig zu überprüfen. Denkbar wäre auch ein eigener Thread, in welchen der Timer abläuft. Dies hat aber den Nachteil, daß für eine große Anzahl an SNMP-Tabellen die Anzahl der maximal möglichen Threads überschritten werden kann und somit nicht alle SNMP-Tabellen überwach- und steuerbar wären. Bei dieser Diplomarbeit war aber noch ein anderer Grund ausschlaggebend dafür, daß dieser Fall nicht implementiert wurde: Es gab keine Installation von DCE und damit keine Möglichkeit, Threads zu realisieren.
Weiterhin ist es software-technisch sinnvoll, komplexe und häufig auftretende Module in eigenen Komponenten zu realisieren.
Daher wurde in diesem Gateway die 2. Möglichkeit in Betracht gezogen: Es wird eine zentrale Komponente (mit dem Namen ,,Global Polling``) eingeführt, an welcher die SNMP-Tabellen angemeldet werden.
Die Aufgabe der Global Polling-Komponente ist es, für jede registrierte SNMP-Tabelle einerseits zu überprüfen, ob neue Tabellenzeilen in dieser Tabelle entstanden sind und dementsprechend neue Instanzen in der Gateway-MIB zu kreieren. Andererseits muß diese Komponente feststellen, ob Tabellenzeilen gelöscht wurden, um die entsprechenden Instanzen in der Gateway-MIB zu löschen. Zusammengefaßt ist das Global Polling für die Konsistenzsicherung der Instanzen in der Gateway-MIB mit der realen Ressource (Tabellenzeilen) in den SNMP-Agenten verantwortlich.
Um zu entscheiden, nach welchen Intervallen, also zu welchen Zeitpunkten, die jeweilige Tabelle auf Veränderungen hin überprüft werden soll, wird die 2. Strategie aus 4.4.2 herangezogen:
Für jede angemeldete SNMP-Tabelle existiert ein 32 Bit Wert. Jede Bit-Position stellt dabei ein Intervall dar, mit der Länge 2^Bit-Position Sekunden. Falls eine Überprüfung, nach einem so definierten Zeitpunkt, eine Veränderung in einer Tabelle feststellt, wird dieser 32 Bit Wert um eine Position nach rechts geschoben, womit die Länge des Intervalls halbiert wird. Entsprechend wird die Länge des Intervalls verdoppelt, falls keine Veränderung bei einer Überprüfung einer Tabelle festgestellt werden kann. Somit pendelt dieser 32 Bit Wert und damit die Intervallgröße um annähernd dem zeitlichen Verhalten der jeweiligen Tabelle.
Eine SNMP-Tabelle hat ähnliche Eigenschaften wie eine SNMP-Gruppe: Sie existiert für die gesamte Lebensdauer des SNMP-Agenten. Der Unterschied zwischen einer SNMP-Gruppe und einer SNMP-Tabelle im Gateway ist die Repräsentation. SNMP-Gruppen werden von Instanzen von Managementobjekt-Klassen repräsentiert. Eine Komponente für eine SNMP-Tabelle erscheint im Gateway nicht. Es existieren lediglich Managementobjekt-Klassen und NAME BINDINGs für die Tabellenzeilen dieser SNMP-Tabellen. Damit stellt sich die Frage, wie und wann eine SNMP-Tabelle an der Global Polling-Komponente angemeldet wird.
Aufgrund der eben erwähnten Eigenschaft, daß die Lebensdauer einer SNMP-Tabelle gleich der des Agenten ist, kann die Tabelle zum gleichen Zeitpunkt an der Global Polling-Komponente angemeldet werden, zu der auch die SNMP-Gruppen instanziiert werden. Dies entspricht also dem Zeitpunkt, an dem der SNMP-Agent für das Management durch einen OSI-Manager bereitgestellt werden soll, siehe Abbilding 5.5.

 

Abbildung 5.5:   Der Algorithmus zum Aufbau der Containmenthierarchie

36#36

In dem, im vorherigen Abschnitt vorgestellten, rekursiven Algorithmus zur Instanziierung von Managementobjekt-Klassen von SNMP-Gruppen werden alle NAME BINDINGs aus der Metadata Database gelesen. Es werden aber nur jene NAME BINDINGs verwendet, die sich auf die Klassen beziehen, welche SNMP-Gruppen repräsentieren. Dieser Algorithmus kann nun so erweitert werden, daß für alle gelesene NAME BINDINGs, die sich auf die Klassen beziehen, welche SNMP-Tabellenzeilen repräsentieren, die dazugehörige SNMP-Tabelle an der Global Polling-Komponente angemeldet wird. Dabei ergibt sich die OID einer SNMP-Tabelle aus der OID einer in dieser Tabelle enthaltenen Tabellenzeile durch entsprechendes Abschneiden eines bestimmten Suffix.

In SNMP-Tabellen kann es möglich sein, mit Hilfe von SNMP-SetRequest-PDUs und damit von einem SNMP-Manager aus, Tabellenzeilen zu Erstellen bzw. zu Löschen (als ungültig zu deklarieren). Indem das Gateway das Kreieren bzw. das Löschen von Instanzen auf diese SNMP-SetRequest-PDUs abbildet, wird es einem OSI-Manager gestattet, Tabellenzeilen in einem SNMP-Agent entsprechend zu erstellen bzw. zu löschen.

Die Abbildung 5.6 zeigt die bisherige Architektur und damit die Funktionsweise des CMIP/SNMP Gateways:

 

Abbildung 5.6:   Die bisherige Gatewayarchitektur

37#37

1.

In der Metadata Database werden alle aus der Übersetzung der Internet-MIBs in OSI-MIBs entstandenen NAME BINDINGs eingetragen.

2.

Sobald ein neuer SNMP-Agent für das OSI-Management bereitgestellt werden soll, werden nach 5.2.1 Instanzen für alle SNMP-Gruppen kreiert.

3.

In dem in 5.2.1 vorgestellten Algorithmus werden alle in den Metadata Database vorhandenen NAME BINDINGs gelesen, es werden aber nur die benutzt, welche sich auf Klassen beziehen, die SNMP-Gruppen repräsentieren. Zusätzlich soll dieser Algorithmus noch für die NAME BINDINGs, welche sich auf die Klassen beziehen, die aus SNMP-Tabellenzeilen entstanden sind, die entsprechende SNMP-Tabelle in der Global Polling-Komponente angemeldet werden.

4.

Damit, durch diese Anmeldung, werden die Instanzen in der Gateway-MIB, die die SNMP-Tabellenzeilen repräsentieren, kreiert.

5.

Die Global Polling-Komponente überprüft schließlich regelmäßig, ob Veränderungen in der SNMP-Tabelle auftreten und damit, ob entsprechend Instanzen gelöscht bzw. kreiert werden müssen.

6.

Der Zugriff auf Attribute in Instanzen wird direkt auf SNMP-PDUs übersetzt und damit der Wert aus der MIB des jeweiligen SNMP-Agenten gelesen bzw. gesetzt.