Dieses Kapitel stellt eine Architektur eines CMIP/SNMP Gateways vor, die
einem OSI-Manager eine OSI-Sichtweise auf SNMP-Ressourcen zur Verfügung
stellt. Ein reines stateless Gateway kann aufgrund der Einschränkungen, die
sich beim Einsatz der IBM TMN WorkBench for AIX ergeben, nicht realisiert
werden: Die Komponenten der WorkBench fordern, daß die gesamten zu
überwachenden und steuernden Ressourcen komplett im Agenten durch Instanzen von
Managementobjekten und durch deren Attribute repräsentiert werden. Um dies
für SNMP-Ressourcen anwenden zu können, müssen Informationen aus der MIB
des SNMP-Agenten (der Index der Tabellenzeilen aller SNMP-Tabellen) im
Gateway zwischengespeichert werden (als RDN der Instanzen).
Da ein Übergang zu einem reinen stateful Gateway einer idealen Lösung,
ebenfalls wie ein reiner stateless Ansatz, nicht nahe kommt, werden in dieser
Architektur sowohl stateless als auch stateful Prinzipien integriert:
All jene SNMP-Ressourcen, welche aufgrund der Einschränkungen
der IBM TMN WorkBench for AIX nicht direkt auf SNMP-PDUs abgebildet
werden können (dem entsprechen SNMP-Gruppen und -Tabellenzeilen), weil sie
durch Instanzen im Gateway repräsentiert werden müssen und somit die
Containment-Hierarchie aufbauen, sollen nach dem stateful Ansatz
implementiert werden. Alle anderen SNMP-Ressourcen (dem entsprechen alle
SNMP-Variablen, sie werden durch Attribute in den OSI-Klassen dargestellt)
sollen nach dem stateless Ansatz realisiert werden, das heißt, der Wert eines
OSI-Attributs soll direkt aus dem SNMP-Agenten gelesen werden.
Damit entspricht diese Architektur nicht dem in
4.5 vorgestellten idealisierten Gateway, kommt aber in
einigen Ansätzen diesem recht nahe: So werden SNMP-Tabellenzeilen aufgrund
ihres zeitlichen Verhaltens und damit aufgrund ihrer Art von
Managementinformation in der Gateway-MIB repliziert. Ebenfalls wird der Teil
der Containment-Hierarchie, der den Registrierungsbaum der SNMP-Gruppen im
Gateway repräsentiert, nur einmal aufgebaut und entspricht damit dem
Gesichtspunkt, statische Managementinformation nur einmal oder nur selten zu
replizieren.
Der Attributzugriff widerspricht aber den Vorstellungen einer idealen Lösung:
Dieser wird nach einem reinen stateless Ansatz behandelt, das heißt, alle
Attributzugriffe werden direkt auf SNMP-PDUs abgebildet.
Die aus dieser Architektur resultierende Performance läßt sich folgendermaßen
abschätzen:
Für die Auflösung von Scopes werden keine expliziten Zugriffe auf die
SNMP-Agenten benötigt, da die Containment-Hierarchie im Gateway verwaltet
und von der Global Polling-Komponente konsistent mit der realen
SNMP-Ressource gehalten wird. In dieser Beziehung verhält sich die
Architektur wie ein reines stateful Gateway. Damit ergibt sich auch der
Performance-Vorteil (siehe auch 4.6) gegenüber
den stateless Gateway, welches ja alle Informationen zur Scopeauflösung
direkt aus den SNMP-Agenten beschaffen muß. Bei der Auflösung von Filtern
verhält sich die Architektur dagegen wie ein stateless Gateway. Alle Werte der
Attribute, die im Filter spezifiziert werden, müssen für alle im Scope
selektierten Instanzen explizit aus den SNMP-Agenten gelesen werden, bevor
sie zur Auflösung des Filters herangezogen werden können. Damit treten für
diese Architektur für die Filterauflösung auch die Performance-Nachteile auf,
wie sie bei einem stateless Gateway typisch sind. Ebenso verhält es sich mit
Attributzugriffen, da diese auch nach dem stateless Ansatz erfolgen.
Schließlich darf nicht vergessen werden, daß durch die Replikation der
SNMP-Tabellenzeilen in der Gateway-MIB durch die Global
Polling-Komponente eventuell Inkonsistenzen (siehe 4.4.2)
oder auch hoher Ressourcenverbrauch auftreten können: So wird zur
Konsistenzsicherung einer SNMP-Tabelle in der Gateway-MIB, also dem Erkennen
von neuen bzw. veralteten Tabellenzeilen, immer die gesamte SNMP-Tabelle
benötigt. Diese muß jedesmal nach dem Ablauf des Polling-Intervalls von der
Global Polling-Komponente angefordert werden. Dies kann bei großen
Tabellen zu einer Vielzahl an SNMP-PDUs führen und damit zu langen
Wartezeiten, in denen das Gateway nicht für andere Aufgaben zur Verfügung steht.
Eine denkbare Weiterentwicklung dieser Architektur ist der Übergang zu einem
reinen stateful Gateway. Dazu müßte noch der Attributzugriff dahingehend
verändert werden, daß sich die Attribute ebenfalls, wie SNMP-Tabellenzeilen,
an der Global Polling-Komponente anmelden und von dieser durch den
Einsatz einer bestimmten Strategie repliziert werden. Zukünftige
Performance-Messungen müssen zeigen, ob dieser Schritt sinnvoll ist, da
damit auch der Nachteil des stateful Ansatzes noch schwerwiegender auftritt,
daß die hundertprozentige Konsistenzsicherung der SNMP-Agenten in der
lokalen Gateway-MIB nicht erreicht werden kann (siehe
4.4.2).
Im nächsten Kapitel soll die Implementierung dieser CMIP/SNMP
Gatewayarchitektur beschrieben werden.