Neue Entwicklungen für modulare SNMP-Agenten

 

Die möglichen Ausprägungsformen heutigen SNMP-basierten Managements sind in Abbildung dargestellt: Damit eine SNMP-Managementplattform spezifische Parameter einer Ressource verwalten kann, muß ihr vorher eine formale Beschreibung der Ressource in Form einer oder mehrerer MIBs bekanntgegeben werden (linker Teil der Grafik). Dies geschieht manuell durch den zuständigen Administrator. Die programmtechnische Instrumentierung der Ressourcen erfolgt gewöhnlich über eine C- bzw. C++ Programmierschnittstelle, die die gesamte Menge an Eingriffsmöglichkeiten darstellt. Um die Unabhängigkeit von einer konkreten Programmiersprache zu gewährleisten, wird die Programmierschnittstelle durch MIBs repräsentiert. Diese Kapselung der Instrumentierung kann dabei auf drei verschiedene Arten erfolgen:

  

Abbildung: Möglichkeiten des Zugriffs auf SNMP-basierte MIB-Instrumentierung

Monolithischer Agent  (siehe (1) in Abbildung ): Die von SNMP-Agenten bereitgestellte Managementinformation ist statisch, d.h. sie bleibt während des gesamten Lebenszyklus des Agenten konstant. Dies ist charakteristisch für Netzkomponenten wie Router, Switches oder Hubs, die einerseits über die MIB-II sowie eine oder mehrere - zum Teil herstellerspezifische - MIBs verfügen.

Den Anforderungen des Systemmanagements sind monolithische Managementagenten nicht mehr gewachsen, da ein umfassendes Management eines Endsystems (Workstation, PC) weit über das bloße Bereitstellen von hardwarenahen Informationen hinausgeht. Vielmehr müssen Informationen bezüglich des Betriebssystems sowie der darauf ablaufenden Dienste (Namensdienste, Dateidienste) und Applikationen bereitgestellt werden, die naturgemäß der hohen Dynamik von Software unterliegen. Zwar wird der modularen Kombinierbarkeit dieser Dienste und Anwendungen, wie im ersten Fall, durch mehrere MIBs, die ihrerseits auf eine bestimmte Softwarekomponente zugeschnitten sind, begegnet. Der wesentliche Unterschied erweiterbarer Agenten  ((2) in Abbildung ) zu ersteren besteht jedoch darin, daß die Menge und Ausprägungsform der Dienste und Anwendungen eines Endsystems zur Laufzeit des Agenten wechselt: Applikationen werden installiert bzw. entfernt; eine Workstation übernimmt die Funktion eines Name-, File- oder Webservers bzw. gibt diese ab. Gefordert ist daher ein Mechanismus, der es gestattet, SNMP-Agenten zur Laufzeit um neue Managementfunktionalität zu erweitern bzw. diese wieder zu entziehen. Dies geschieht durch das Master- und Subagenten-Konzept, das in den Arbeiten der Agent Extensibility Working Group (AgentX)  der IETF entwickelt wurde [#!whgu98!#], welche die Interaktionen der SNMP-Protokollmaschine (Master-Agent)  mit gegebenenfalls mehreren MIB-Instrumentierungen (Subagenten)  spezifizieren. Das in [#!RFC2257!#] standardisierte AgentX-Protokoll definiert neben der Zuordnung und Weiterleitung von SNMP-Anfragen vom Master-Agenten an einen oder mehrere Subagenten ebenfalls das dynamische Laden bzw. Entfernen von MIB-Modulen durch das An- bzw. Abmelden von Subagenten beim Master-Agenten zur Laufzeit. Kommunikation zwischen Subagenten ist im AgentX-Protokoll ausgeschlossen. Mit AgentX realisierte modulare Agenten sind für Managementapplikationen vollkommen transparent, da diese lediglich mit dem Master-Agenten kommunizieren und die Subagenten somit nicht in Erscheinung treten. Der Vollständigkeit halber sei erwähnt, daß sich Master- und Subagenten jeweils auf unterschiedlichen Systemen befinden können, was jedoch in der Praxis kaum angewandt wird.

Der Zugriff auf Ressourcen über das Desktop Management Interface (DMI)  [#!dmtf96!#], einem in der PC- und Server-Welt verbreiteten Industriestandard der Desktop Management Task Force (DMTF) , ist ebenfalls über SNMP möglich (siehe (3) in Abbildung ). Die - in der Regel proprietäre - Schnittstelle zur MIB-Instrumentierung (in der DMTF-Terminologie als Component Interface (CI)  bezeichnet) wird durch den Service Provider (SP)  gekapselt; das CI beispielsweise spezifiziert Mechanismen, die das dynamische An- und Abmelden von Subagenten beim Master-Agenten gestatten. An einer offengelegten, standardisierten Schnittstelle, dem Management Interface (MI) , wird die Managementinformation des SP Managementapplikationen bereitgestellt, die entweder lokal oder von entfernten Systemen (per RPC) darauf zugreifen können. Diese Schnittstelle steht sowohl Master-Agenten als auch Managementapplikationen (unter Umgehung des Master-Agenten) offen, um auf die angebotene Managementinformation zuzugreifen. Die Beschreibung der Managementinformation des MI erfolgt dabei im sog. Management Information Format (MIF) , das große Ähnlichkeit zur Internet SMI aufweist und daher anhand von der DMTF spezifizierter Abbildungsregeln problemlos in diese umgewandelt werden kann. Auf Protokollebene wurde ein SNMP-Mapping spezifiziert, so daß DMI-kompatible Managementagenten problemlos in SNMP-Umgebungen integriert werden können.

Die Ziele und Konzepte von DMI, das de facto eine eigenständige Managementarchitektur darstellt, sind sowohl konzeptionell als auch hinsichtlich ihrer technischen Ausführung mit denen des Internet-Managements identisch, weshalb an dieser Stelle auf eine ausführlichere Beschreibung von DMI verzichtet wird. Die Arbeiten an DMI verliefen zeitgleich zur Weiterentwicklung von SNMPv2 und AgentX, was die Ähnlichkeit der Konzepte erklärt. Der eigentliche Nutzwert von DMI besteht aus bereits heute verfügbaren Implementierungen der DMTF-Spezifikationen für PC- und Serverkomponenten sowie der darauf laufenden Software. Demgegenüber steht die Erweiterung des Internet-Managements um MIBs für solche Ressourcenklassen (wie beispielsweise die Host Resources und die Application MIBs) erst am Anfang. Erste Ansätze werden im folgenden Abschnitt vorgestellt.

Grundsätzlich muß ein Managementsystem wissen, welche Arten von MIBs eine gegebene Ressource unterstützt. Da das Internet-Management keinerlei zu OSI oder CORBA vergleichbare Discovery-Mechanismen kennt, um dies zur Laufzeit von den Ressourcen zu erfragen, müssen die in Frage kommenden MIBs zuvor explizit dem Managementsystem bekanntgegeben werden. In der Praxis wird diesem Problem dadurch begegnet, daß eine Vielzahl standardisierter MIBs im Lieferumfang einer Managementplattform enthalten ist; bei herstellerspezifischen MIBs ist dies natürlich nicht gegeben. Diese müssen durch den Administrator explizit in die Plattformdatenbank geladen werden. Hiermit ist zwar eine Möglichkeit geschaffen, die Anzahl unterstützter MIBs eines Agentensystems dynamisch den Gegebenheiten anzupassen; eine Erweiterung der Funktionalität einzelner MIBs ist jedoch nicht vorgesehen und würde im Übrigen auch nur mit hohem Aufwand auf Seiten des Managementsystems durchführbar sein.