4.4 Zustandsbehaftetes Gateway

  Eine weitere Möglichkeit ist, die Kommunikation zwischen dem Manager und den Agenten zu entkoppeln. Während bei den vorherigen Fällen jeder Aufruf einer Attributzugriffsfunktion auf eine SNMP-PDU abgebildet wird, soll nun der Fall betrachtet werden, bei dem die Kommunikation von Manager mit den Schattenobjekten einerseits und die Kommunikation von Gateway mit den Managementobjekten andererseits und zwar unabhängig stattfinden.

Bei einem zustandsbehafteten Gateway werden Werte der Agenten-MIBs im Gateway repliziert. Gespeichert werden diese Werte in den Attributen der Schattenobjekte und müssen regelmäßig aktualisiert werden, damit sie zum Zeitpunkt des Zugriffs von Seiten des Managers mit den tatsächlichen Werten in den entsprechenden Managed Objects konsistent sind. Diese virtuelle Konsistenz setzt die Managementanwendung voraus; mit welcher Strategie diese gewährt wird, ist für die Managementanwendung irrelevant.

Es können zwei Möglichkeiten unterschieden werden:

• Jedes Schattenobjekt sorgt selbst dafür, daß seine Information aktuell ist
• Ein ausgezeichneter Prozeß im Gateway ist für die Konsistenz der Information aller Schattenobjekte zuständig.

Im ersten Fall stellt kann man sich jedes Schattenobjekt als einen einzigen Prozeß vorstellen, der regelmäßig aktiv wird, um die eigenen Attributwerte mit den dazugehörigen Werten in der SNMP-Umgebung abzugleichen -- auch wenn niemals auf die Attribute des Schattenobjektes zugegriffen wird. Wie oft das ,,Update`` geschieht, hängt von der Implementierung des Schattenobjektes ab. Idealerweise werden bei der Implementierung Informationen über das dynamische Verhalten der SNMP-Managementobjekte berücksichtigt.

Die bisher besprochenen zustandslosen Gateways in 4.3.2 und 4.3.3 können zu einem zustandsbehafteten Gateway ausgebaut werden, indem die Schattenobjekte selbst die Funktionalität der Konsistenzerhaltung übernehmen. Die Schritte (2)-(3) in der Abbildung 4.6 bzw. die Schritte (2)-(5) in Abbildung 4.8 (Informationsaustausch mit SNMP-Agent) folgen dann nicht notwendigerweise unmittelbar bei einem Zugriff auf das Schattenobjekt, sondern möglicherweise zeitlich versetzt.

Die Abbildung 4.9 zeigt den zweiten Fall. Wieder will ein Manager, der den Wert des Attributs SysLocation lesen und ruft deshalb, wie schon beschrieben, die Attributzugriffsfunktion Get_SysLocation auf (1).

  

Abbildung 4.9: Entkoppelter Informationsaustausch

Nun gibt aber das Schattenobjekt den Wert des Attributs (der notwendigerweise im Schattenobjekt gespeichert sein muß) unmittelbar an den Manager zurück (2). Bei dieser Aktion wird keine SNMP-PDU erzeugt.

Da die Schattenobjekte die Attributwerte nicht selbst mit den Werten der entsprechenden Managed Objects konsistent halten, müssen diese Werte regelmäßig vom Gateway aktualisiert werden. Zu diesem Zweck fragt das Gateway (im einfachsten Fall in festen Zeitintervallen) die Managementinformation von den Agenten ab (3, 4) und schreibt diese in das zugehörige Attribut des Schattenobjektes (5). Dazu ist eine neue Methode im Schattenobjekt notwendig, da:

• auf die Attribute eines Objektes prinzipiell nur mit objekteigenen Methoden zugegriffen werden kann,
• nicht jedes Attribut eines Schattenobjektes eine Set-Operation zur Verfügung stellt, die statt dieser Methode verwendet werden könnte und,
• je nachdem, ob der Manager oder das Gateway die Set-Operation des Schattenobjektes aufruft, unterschiedlich reagiert werden muß. Der Set-Aufruf des Managers muß auf eine Set-Operation auf das entsprechende Managementobjekt in der SNMP-Umgebung repliziert werden, während beim Gateway das Attribut des Schattenobjektes aktualisiert (und keine PDU verschickt) werden soll. Problem dabei ist, daß das Schattenobjekt nicht feststellen kann, wer der Aufrufer der Set-Operation ist.

Alternativ dazu kann das Gateway ein Schattenobjekt auffordern, sich selbst zu aktualisieren. Auch bei dieser Variante entscheidet das Gateway über den Zeitpunkt des Abgleichs.

Eine weitere Frage ist, wie oft ein derartiges Update erfolgen soll. Je seltener das Gateway die Information in den Schattenobjekten mit der in den Managementobjekten vergleicht, desto größer ist die Gefahr, daß bei einem Zugriff auf Schattenobjekte von Seiten des Managers die Information nicht konsistent ist. Da die Anzahl der Schattenobjekte in der Regel sehr hoch ist, ist andererseits ein häufiges Aktualisieren sehr aufwendig und (deshalb) nur mit einer nach oben begrenzten Frequenz möglich. Wenn sich die Managementinformation in den Agenten kontinuierlich ändert, wie es z. B. bei Zählervariablen der Fall ist, ist ein gewisser Inkonsistenzgrad in den Schattenobjekten nicht vermeidbar.

Umgekehrt kann es sein, daß ein Manager ein Attribut mit einem neuen Wert belegt, beispielsweise das Attribut SysLocation durch einen Aufruf von Set_SysLocation() wie in Abbildung 4.10(1) gezeigt. In diesem Fall muß das entsprechende Managementobjekt aktualisiert werden (s. 4.1, Replikation von Operationen). Da Managementinformation auf der CORBA-Seite ausschließlich in den Schattenobjekten gespeichert wird, kann das Gateway bei einem Vergleich der entsprechenden SNMP-Werte nicht feststellen, welche Information gültig ist. Deshalb ist es notwendig, daß das Schattenobjekt dem Gateway meldet, eines seiner Attribute verändert wurde . Eine Möglichkeit ist, dem Gateway einen Event zu schicken (Abb. 4.10 (2a)). Das Gateway verschickt daraufhin die notwendige SNMP-PDU (3). In Anlehnung an ein zustandsloses Gateway (Abb. 4.8), kann das Schattenobjekt auch selbst die Initiative ergreifen und explizit die Erzeugung einer SNMP-PDU (durch eine Aufruf einer entsprechenden Gateway-Methode, 2b) veranlassen.

  

Abbildung 4.10: Schreibender Zugriff auf Attribut