next up previous contents
Next: Einschränkung von Inkonsistenzen Up: Die Einbettung des Gateways Previous: Die Behandlung von SNMP-Traps

,,Local Objects`` für das Management des Gateways  

Für das Management des Gateways selbst steht die Klasse ,, cmipSnmpProxy``[*] zur Verfügung. Beim Starten des Gateways soll eine Instanz dieser Klasse automatisch kreiert werden. Das Kreieren einer Instanz dieser Klasse soll dabei das weitere Kreieren einer Instanz der schon oben erwähnten Klasse ,,snmpComEntity`` bewirken. Damit ist das Management des im Gateway enthaltenen SNMP-Managers ebenfalls möglich. Die Containment-Hierarchie besteht nach dem Start des Gateways aus folgenden Instanzen, siehe Abbildung 5.8.

 
Abbildung 5.8:   Die Containment-Hierarchie nach dem Start des Gateways
39#39

Nun können, explizit durch einen OSI-Manager oder durch einen automatischen Explorationsprozeß, die Instanzen, die für das Management von SNMP-Agenten notwendig sind, kreiert werden. Dazu muß für jeden zu managenden SNMP-Agent eine Instanz der Klasse ,,cmipSnmpProxyAgent`` kreiert werden. Diese Klasse enthält Attribute, die den SNMP-Agenten charakterisieren: Das Kreieren einer Instanz dieser Klasse soll automatisch das Kreieren einer Instanz der Klasse ,,remoteSystem`` bewirkten. Sie dient als Root-Objekt für die Containment-Hierarchie der jeweiligen SNMP-Agenten. So werden anschließend einerseits unter dieser Instanz alle Instanzen von Managementobjekten kreiert, die die SNMP-Gruppen aus der MIB dieses SNMP-Agenten repräsentieren, siehe 5.2.1. Andererseits sollen alle SNMP-Tabellen in diesem SNMP-Agenten an der Global Polling-Komponente angemeldet werden. Die gesamte Containment-Hierarchie sieht zum Beispiel nach dem Kreieren einer Instanz der Klasse ,,cmipSnmpProxyAgent``, die den SNMP-Agenten auf dem Rechner ,,ibmhegering1`` repräsentiert, folgendermaßen aus (wobei dieser Agent die LRZ Systemagenten-MIB unterstützt, siehe Abbildung 5.9):
 
Abbildung:   Die Containment-Hierarchie des Gateways mit einem SNMP-Agenten auf dem Host ,,ibmhegering1``
40#40

Diese Abbildung zeigt deutlich, daß die Containment-Hierarchie der Instanzen, die die MIB des SNMP-Agenten repräsentieren (,,remote Objects``), mit der Struktur dieser MIB in dem Internet-Registierungsbaums übereinstimmt (vergleiche Abbildung 2.12).
Das Beispiel zeigt aber auch die vorhandene Redundanz: Ein SNMP-Agent wird sowohl von einer Instanz der Klasse ,,remoteSystem`` als auch von einer Instanz der Klasse ,,cmipsnmpProxyAgent`` repräsentiert. Dies ist durchaus so gewollt, da bei einer großen Anzahl an zu verwaltenden SNMP-Agenten die Menge der Instanzen unübersichtlich wird. So kann, indem nur der Teilbaum mit der Wurzel ,, cmipsnmpProxy`` betrachtet wird, sofort festgestellt werden, welche und wieviele SNMP-Agenten gerade vom Gateway überwacht werden. Die Instanzen der Klasse ,, remoteSystem`` dienen dabei dazu, einen Zugang zu den MIBs der SNMP-Agenten herzustellen. Wie schon erwähnt, stellen diese Instanzen damit Root-Objekte für die Containment-Hierarchien der Instanzen der jeweiligen SNMP-Agenten (,,remote Objects``) dar.
Weiterhin ist es sinnvoll, die Community-Strings eines SNMP-Agenten nur an einer zentralen Stelle zu verwalten, um auf Änderungen flexibel reagieren zu können. So werden diese, wie schon oben erwähnt, als Attribut in der Instanz der Klasse ,, cmipsnmpProxyAgent`` gehalten. Daraus resultiert, daß jedes ,,remote Object`` zuerst den benötigten Community-String aus dieser Instanz lesen muß, bevor sie SNMP-PDUs zu dem jeweiligen SNMP-Agenten auslösen können.


next up previous contents
Next: Einschränkung von Inkonsistenzen Up: Die Einbettung des Gateways Previous: Die Behandlung von SNMP-Traps
Copyright Munich Network Management Team