Zur Erreichung einer möglichst umfassenden Integration sind zwei
grundlegende Designalternativen möglich:
Zustandsloses (stateless) Gateway
Der Grundgedanke eines zustandlosen Gateways besteht darin, daß
Operationen auf Proxy-Objekten unmittelbar an die
entsprechenden MOs der Agenten weitergeleitet werden. Hierzu muß das
Gateway gegebene OSI- bzw. CORBA-MOIs auf die dazugehörigen SNMP-OIDs
abbilden, die Art der Operation umsetzen und die SNMP-PDU generieren.
Im Gateway müssen somit die Definitionen der Objektklassen
und der vorhandenen Instanzen vorliegen; es erfogt jedoch keinerlei
(Zwischen-) Speicherung von Informationen bezüglich der aktuellen
Wertebelegung von MO-Instanzen. Das Gateway agiert somit im
wesentlichen in der Rolle eines ,,PDU-Konverters``. Ein Request
vom Manager an das Gateway löst in jedem Fall einen Request
vom Gateway an den ausgewählten Agenten aus. Die hierbei ermittelten
Informationen sind in jedem Fall aktuell, auch wenn diese Abfrage
eine gewisse Bearbeitungszeit erfordert und einen erhöhten Netzverkehr
mit sich bringt, da die Belegungen jeder betroffenen MIB-Variable
einzeln ermittelt werden.
Zustandsbehaftetes (stateful) Gateway
Der Ansatz eines zustandsbehafteten Gateways setzt hier an und zielt auf eine Optimierung des Gesamtsystems Manager/Gateway/Agent hinsichtlich Antwortzeit und Netzverkehr ab: Erreicht wird dies durch die Speicherung von Instanzeninformationen bereits im Gateway. Aufgrund der Tatsache, daß das Gateway Caching von MO-Instanzeninformation durchführt, löst ein Request des Managers auf die Proxy-Objekte des Gateways nicht in jedem Fall auch eine Anfrage vom Gateway an das Agentensystem aus. Hierdurch ergeben sich offensichtlich Vorteile in bezug auf die Antwortzeit und den Netzverkehr, da nur dann aktuelle Werte vom Agentensystem angefordert werden, wenn dies ,,notwendig`` erscheint.
Das grundlegende Problem liegt nun darin, zu entscheiden, wann der ,,richtige`` Zeitpunkt ist, um eine Auffrischung der gespeicherten Daten vorzunehmen, da die Dynamik der MIB-Attribute bekanntlich starken Schwankungen unterliegt: So liegt die Änderungsfrequenz des Namens bzw. der Adresse eines Endsystems nahezu bei Null während die Wertebelegung eines Zählers für eingegangene PDUs sich kontinuierlich ändert. Eine Möglichkeit zur Lösung dieses Problems besteht nun darin, bereits in der MIB für jedes Attribut Informationen bezüglich seiner Dynamik festzuhalten und die MIB-Beschreibung entsprechend zu erweitern. Ein solcher Ansatz liegt dem in [#!hab91!#] entwickelten Konzept zugrunde. Das unmittelbare Problem eines solchen Ansatzes besteht nun darin, daß eine solche Erweiterung zwangsläufig außerhalb der gegenwärtig standardisierten MIB-Definitionen liegt, heutige MIB-Compiler solche Definitionen nicht akzeptieren und somit diese erweiterten MIB-Beschreibungen in kein gegenwärtiges Managementsystem übernommen werden können. Ferner spiegelt dieser Ansatz eine ,,Bottom-up``-Sichtweise wider, da die Information bezüglich der Dynamik dieser Werte ausschließlich vom Hersteller einer Ressource festgelegt werden können. Dies widerspricht jedoch dem Ziel eines betreibergerechten Managements, das idealerweise einem Netzadministrator erlauben würde, die Abfragefrequenz für einzelne Attribute seinem Bedarf entsprechend zu konfigurieren. Dieser Bedarf hängt wiederum stark von den Zielvorgaben des Unternehmens ab, welche sich jedoch bisher nicht automatisch auf einzelne MIB-Attribute abbilden lassen. Bei einem Umfang von mehreren hundert MIB-Variablen pro Endsystem stellt jedoch die manuelle Konfiguration einzelner Attribute ein aus Skalierbarkeitsüberlegungen kritisches Problem dar.
Eine andere Sichtweise verfolgen die in [#!dibo97!#] und [#!divb97!#] beschriebenen neuen Ansätze, die auf eine automatische Klassifikation der MIB-Attribute in Abhängigkeit ihrer Aktualität abzielen. Hierbei wird anhand der Änderungshistorie von Werten empirisch auf die zukünftige Änderungsfrequenz geschlossen, wobei jedoch die Gefahr besteht, daß im Falle einer plötzlich auftretenden Fehlersituation nicht rechtzeitig reagiert werden kann, weil die Abfrage des entsprechenden Attributs mangels vorheriger Dynamik zum notwendigen Zeitpunkt unterbleibt. Aufgrund des geringen Alters dieser Algorithmen und dem damit einhergehenden Mangel an prototypisch ermittelten Erfahrungswerten muß die Praktikabilität dieses Ansatzes gegenwärtig unbeantwortet bleiben. Nicht zuletzt erfordert die Ermittlung der Dynamik von MIB-Attributen die Bildung von Zeitreihenanalysen, was wiederum eine hohe Verarbeitungslast auf dem Gateway impliziert.
Wir haben uns bei unseren Prototypen für einen dritten Weg entschieden, der keine Modifikationen an den MIBs erfordert, einen relativ guten Kompromiß zwischen Verarbeitungslast und Netzverkehr darstellt und überdies verhältnismäßig einfach zu implementieren ist. Grundlage unserer Überlegungen ist eine Heuristik, nach der die Pollingfrequenz anhand des Datentyps eines MIB-Attributes festgelegt wird. Werte zu Datentypen, welche (sehr dynamische) Zähler repräsentieren, werden nicht auf dem Gateway zwischengespeichert, Strings erhalten einen relativ langen Abfragezeitraum zugewiesen, Integer-wertige Attribute liegen in der Mitte. Darüber hinaus sind die datentypbezogenen Polling-Zeiträume vom Benutzer konfigurierbar, d.h. das Gateway selbst besitzt eine MIB, mit der es konfiguriert wird. Wir werden gegen Ende dieses Kapitels auf die Konsequenzen der Gateway-Instrumentierung zurückkommen.