MIBs für das Dienste- und Anwendungsmanagement

Im folgenden besprechen wir MIBs, die als Vorstufe eines SNMP-basierten Dienste- bzw. Anwendungsmanagements betrachtet werden können und somit ebenfalls für unsere Zwecke relevant sind.

Die Network Services Monitoring MIB  (NSM MIB) [#!RFC1565!#] definiert allgemeine Attribute, die ein effektives Monitoring von Netzdiensten, (also speziellen Anwendungen wie Datei-, Druck- oder Verzeichnisdienste) ermöglichen sollen. Wie es der Name bereits ausdrückt, steht hier das passive Monitoring im Vordergrund; Eingriffsmöglichkeiten wie das Setzen von Variablen oder das Auslösen von Aktionen sind nicht vorgesehen. Die MIB besitzt eine Tabelle für die in Frage kommenden Dienste (applTable) sowie eine Tabelle für die derzeit offenen Kommunikationsverbindungen dieser Dienste (assocTable). Werden die Verbindungen vom Manager hin zum Netzdienst aufgebaut, so werden sie als inbound associations bezeichnet; in letzterem Fall (d.h. der betroffene Netzdienst initiiert die Verbindung) als outbound associations. Einige Variablen in applTable sind nicht spezifisch für das Management von Netzdiensten, sondern gelten prinzipiell für alle Arten von Software. Beispiele für solche Attribute sind applOperStatus, das den operationellen Zustand einer Anwendung beschreibt (up, down) und applUptime, das die Zeit seit der letzten Instantiierung der Anwendung angibt.

Die System Application MIB  [#!RFC2287!#] erweitert die Host Resources MIB [#!RFC1514!#] um zwei umfangreiche Gruppen, die Informationen in bezug auf die installierte Software sowie momentan ausgeführte Anwendungen bereitstellen. Die sysApplInstalledGroup besteht aus zwei Tabellen, in denen die installierten Softwarepakete sowie deren Bestandteile (d.h. Dateien) verzeichnet sind. Hierfür ist es erforderlich, daß die Softwarepakete mit Hilfe eines speziellen Werkzeuges installiert wurden, das bereits bei der Installation Einträge in der globalen Inventardatenbank des Betriebssystems vornimmt. Bei PC-basierten Betriebssystemen (Windows98, Windows NT) trägt die Setup-Routine diese Informationen in die sogenannte Registry ein; das UNIX-Derivat AIX von IBM besitzt hierfür das System Management Information Tool (SMIT), das Einträge in der vom Object Data Manager (ODM) verwalteten Systemdatenbank anlegt. Einen Sonderfall stellt das Attribut sysApplInstallElmtRole dar, welches für ausführbare Dateien Abhängigkeiten und Einschränkungen über boolesche Werte (z.B. ,,required`` oder ,,dependent``) definiert und es so einem Agenten ermöglicht, zur Laufzeit von Anwendungen Aussagen über ihren Status zu machen.

Die zweite Gruppe (sysApplRunGroup) besteht aus einer Tabelle, die für jede momentan aktivierte Anwendung einen Eintrag enthält. Dieser Eintrag setzt sich (neben dem für Tabellen obligatorischen Index) aus der Startzeit und dem operationellen Status der Anwendung zusammen. In der MIB ist der Status der Anwendung identisch mit dem Status des zugehörigen Hauptprozesses und kann die Werte ,,running``, ,,runnable``, ,,waiting``, ,,exiting`` und ,,other`` annehmen. Eine zweite Tabelle enthält die zu den Anwendungen der ersten Tabelle gehörenden Prozesse sowie die hierfür typischen Managementinformationen (verbrauchte CPU-Zeit, belegter Arbeitsspeicher, Aufrufparameter, Eigentümer usw.). Beiden Tabellen dieser Gruppe ist eine dritte Tabelle zugeordnet, die Einträge beendeter oder abgebrochener Anwendungen bzw. Prozesse enthält. Befinden sich keine Prozesse der Anwendung mehr in der Prozeßliste, gilt die Anwendung als korrekt (complete) beendet. Im anderen Fall muß von einem Fehler ausgegangen werden und der Rückgabewert lautet failed. Die Tabellen enthalten folglich ein Log für Anwendungen. Da Logging- bzw. History-Funktionen elementare Managementfunktionen darstellen, die für eine Vielzahl von Anwendungsbereichen gelten, wäre es natürlich sinnvoller, diese Funktionalität in der Form eines abgesetzt implementierten Logging-Dienstes (wie z.B. OSI mit der Log Control SMF) anzubieten. Das Fehlen eines Funktionsmodells und das Nichtvorhandensein von Vererbungsmechanismen im Internet-Management verhindern dies jedoch.

Managementinformation zu den laufenden Anwendungen kann im wesentlichen durch Polling der Prozeßliste gesammelt werden. Um eine hohe Aktualität der Information zu gewährleisten, müßte ein Agent dieses Polling in kurzen Abständen durchführen, was aber dazu führen kann, daß der Agent einen großen Teil der Rechenressourcen des Systems für sich beansprucht. Es ist generell schwierig, allein aufgrund der Außenbezüge einer Anwendung (hier: die laufenden Prozesse) auf ihren inneren Zustand zu schließen und anhand dessen die Ursache einer eventuellen Terminierung zu identifizieren. Noch schwieriger gestaltet sich das Management im verteilten Fall, bei dem sich eine Anwendung aus Komponenten zusammensetzt, die auf verschiedenen Systemen ablaufen. Hier kann effizientes Management nur durch Instrumentierung der Anwendungen selbst mit expliziten Managementschnittstellen erreicht werden. Ein Designziel der System Application MIB bestand jedoch darin, keine Anwendungensinstrumentierung zu fordern. Die unmittelbare Konsequenz daraus ist das Nichtvorhandensein von Eingriffsmöglichkeiten in den Betrieb einer Anwendung [#!stwe95!#]. Ferner liegt der Fokus dieser MIB auf Anwendungen, die sowohl lokal installiert sind, als auch lokal ablaufen. Beides ist in unserem Fall nicht gegeben, weshalb wir bei der Bearbeitung unserer Fragestellung auf lediglich einen kleinen Teil dieser MIB zurückgreifen können.

Die Application Management MIB , die bisher noch nicht verabschiedet wurde, führt eine dienstorientierte Sicht (service level view) auf verteilte Anwendungen ein und setzt - im Gegensatz zu den vorher besprochenen MIBs - entsprechende Anwendungsinstrumentierung voraus. Sie gestattet beschränkte Eingriffsmöglichkeiten in den Betrieb einer Anwendung (Starten, Stoppen) und verfügt hierzu über mehrere Tabellen, die Anwendungen und Dienste sowie deren Ressourcen (geöffnete Dateien, Kommunikationsbeziehungen, Prozesse) verwalten. Eine solche Tabelle ordnet beispielsweise einer Anwendung einen oder mehrere benannte Dienste zu. Eine weitere Tabelle beinhaltet Informationen zu denjenigen Prozessen, welche die Dienste der ersten Tabelle realisieren. Für NFS-, FTP- oder WWW-Server beispielsweise ergeben sich wichtige Leistungsdaten aus der Statistik der Dateizugriffe. Relevante Fragestellungen sind hier ,,Auf welche Dateien wurde wie oft (lesend oder schreibend) zugegriffen? `` oder ,,Wie groß war die durchschnittlich übertragene Datenmenge (in Bytes)? ``. Hierzu definiert die MIB eine weitere Tabelle (applOpenFileTable) mit Einträgen zu den von einer Anwendung geöffneten Dateien. Die wichtigsten Attribute umfassen: Dateiname, Öffnungszeitpunkt der Datei, Anzahl Lese-/Schreibzugriffe, Anzahl Lese-/Schreibfehler, Anzahl gelesener/geschriebener Zeichen, Zeitpunkt des zuletzt erfolgten Lese-/Schreibzugriffs, Dateigröße. Hierdurch soll einerseits die Bereitstellung grundlegender Daten zur Durchsatz- und Antwortzeitermittlung als Grundlage für das Leistungsmanagement erreicht werden, andererseits sind ebenfalls Informationen für das Konfigurationsmanagement enthalten.

Bei der Application Management MIB wurde versucht, objektorientierte Techniken wie (Mehrfach-)Vererbung über gemeinsame Indizes in den Tabellen zu simulieren. Sie gerät dadurch relativ umfangreich und unübersichtlich, was in erster Linie an der Komplexität der Tabellenindizierung liegt. Es ist gegenwärtig noch nicht entschieden, inwieweit die Hersteller vollständige Implementierungen dieser MIB anbieten werden.