Next: Einschränkung von Inkonsistenzen
Up: Die Einbettung des Gateways
Previous: Die Behandlung von SNMP-Traps
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:
- IP-Adresse
- Community-Strings
- die von diesem Agenten unterstützten Internet-MIBs
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: Einschränkung von Inkonsistenzen
Up: Die Einbettung des Gateways
Previous: Die Behandlung von SNMP-Traps
Copyright Munich Network Management Team