| |
Hauptseminar Neue Konzepte für das Management komplexer vernetzter Systeme WS 00/01, Prof. Dr. Heinz-Gerd Hegering
Internet Management
Alexander Hersonski (hersonsk@in.tum.de)
29
4.4.12 Nachteile
Ein Manko das SNMP seit seinen Kindertagen mit sich trägt ist auch in SNMPv3 noch vorhanden. Jegliche
Wiederverwendung der MIB Informationen ist ausgeschlossen. Die Modellierung der darzustellenden
Informationen wird dadurch unnötig kompliziert. Alle neu vorgestellten Managementansätze wie JMAPI oder
WBEM basieren mittlerweile auf der Objektorientierung.
4.4.13 Offene Fragen
Die größte offene Frage bleibt die Akzeptanz von SNMP unter den Herstellern von Betriebsystemen und
Managementanwendungen. Wie schon bei SNMPv2 ist auch bei SNMPv3 das Securitymodell komplex. Es
erlaubt zwar eine feine Granulierung der Berechtigungen, stellt aber bei der Programmierung von
Managementanwendungen hohe Anforderungen an die Programmierer. Und der Erfolg von SNMPv3 steht und
fällt mit der Akzeptanz unter den Programmierern Eine weitere nicht zu unterschätzende Frage ist das
gleichzeitige Entstehen von anderen Architekturen wie JMAPI und WBEM. Zwar sind die beiden genannten
Architekturen nicht mit SNMPv3 zu vergleichen, jedoch wird die jeweilige Entwicklung auf die jeweils andere
Architektur sicherlich Einfluß nehmen.
6. Das Internet-Funktionsmodell
Das Funktionsmodell einer Managementarchitektur zergliredert den Gesamtaugabenkomplex Management in
Management-Funktionsbereiche (Konfigurationsmanagement, Fehlermanagement, Abrechnungsmanagement
u.ä.) und versucht, allgemeine (generische) Managementfunktionen festzulegen. Das Funktionsmodell liefert
also die Basis für Bibliotheken von Management-Teillösungen und für die Delegierung von
Managementfunktionalität an Agenten. Im Funktionsmodell sind also für die einzelnen Funktionsbereiche die
erwartete Funktionalität und die Dienste sowie Managementobjekte zur Erbringung der Funktionalität zu
definieren.
SNMP wurde als reines Management Framework definiert, das sich um die Übertragung der Informationen
kümmert, jedoch nicht um die Information selbst. Die eigentliche Funktionalität wird der Managementstation
überlassen. Die Frage, was mit den gewonnenen Informationen gemacht werden soll oder wie auf bestimmte
Ereignisse reagiert werden soll wird nicht spezifiziert.
6.1 Die historische Manager-to-Manager MIB
Hinsichtlich der Kooperation von Managementsystemen, wurde im Rahmen der SNMPv2-Vorschläge die
Manager-to-Manager MIB (M2M-MIB) [#!RFC1451!#] entwickelt, deren Ziel darin besteht, einem Manager
den Zugriff auf die Informationen anderer Manager zu ermöglichen (seit 1996 hat den Status ,,historic`` und ist
somit offiziell nicht mehr gültig). Ein Managementsystem, das diese MIB implementiert, agiert gegenüber
anderen Managern in einer Agentenrolle und bietet diesen folgende Dienste an, die jeweils eine Tabelle der
M2M-MIB bilden:
·
Die Konfiguration von Alarmen: Es kann festgelegt werden, unter welchen Bedingungen der Manager
einen Alarm an andere Manager schickt. Die hierzu notwendigen Informationen beinhalten u.a. neben
der Object-ID der zu überwachenden Variable sowie deren aktuellen Wert auch die Art der
Überwachung (absoluter Wert, Differenz zum vorherigen Meßwert) und die minimalen und maximalen
Schwellwerte. Werden diese unter- bzw. überschritten, wird ein Event generiert. Die
snmpAlarmTable der M2M-MIB stellt somit rudimentäre Filtermöglichkeiten zur Verfügung.
·
Die Verwaltung dieser Events geschieht in der snmpEventTable, deren Aufgabe darin besteht, die
Reaktionen auf einen Event den jeweiligen Eventtypen zuzuordnen.
·
Diese Aktionen wiederum werden in einer weiteren Tabelle definiert, in der diejenigen Manager
verzeichnet sind, die sich für ein bestimmtes Ereignis interessieren und die daher durch eine
Notification benachrichtigt werden sollen. Dies geschieht durch das Aussenden einer Inform-PDU.
|  |
|
| |
|
|