IBM NetView for AIX

    Ein in die Tivoli-Produktlinie integriertes Werkzeug, das in seiner gegenwärtigen Funktionalität erste Ansätze verteilten Managements bietet, ist IBM NetView for AIX in der uns vorliegenden Version 4.1. Ursprünglich aus der Lizenzierung von Hewlett-Packard's Netzmanagementsoftware OpenView hervorgegangen, ist dieses SNMP-basierte Produkt seitdem von IBM in Eigenregie weiterentwickelt worden. Es verfügt nun hinsichtlich der dieser Arbeit zugrundeliegenden Fragestellung über interessante Eigenschaften, die über den Funktionsumfang bisheriger isolierter SNMP-Managementplattformen hinausgehen und nachfolgend kurz skizziert sind. Eine ausführliche Gegenüberstellung von IBM NetView und HP OpenView anhand eines am Lehrstuhl neu entwickelten und in der Praxis eingesetzten Kriterienkataloges (siehe Abschnitt ) findet der an Details interessierte Leser in [#!domb97!#].

Ein Anzeichen für die Positionierung von NetView als kooperatives Managementsystem ist das Vorhandensein einer sogenannten Manager Overtake Funktion , die es einem Managementsystem ermöglicht, die Aufgaben eines ausgefallenen Partnersystems automatisch zu übernehmen. Damit ein Managementsystem vom Ausfall eines Partnersystems Kenntnis erhält, ist es notwendig, den Status derjenigen Prozesse zu überwachen, aus denen das Partnersystem besteht, bzw. den für das Partnersystem verfügbaren Speicherplatz im Dateisystem zu ermitteln. Die Entscheidung, ursprünglich vom Partnersystem überwachte Ressourcen nunmehr selbst zu steuern, wird anhand einer kritischen Menge ausgefallener Prozesse bzw. der Unterschreitung einer Mindestmenge an Speicherplatz getroffen. Die hierzu nötigen Informationen liefert die sogenannte NetView6000 MIB, welche die oben angesprochenen Prozeßstatus- bzw. Speicherplatz-Informationen in insgesamt zwei Tabellen enthält.

Es ist unmittelbar einsichtig, daß die in dieser MIB enthaltenen zwei Tabellen nur einen sehr rudimentären Schritt in die Richtung eines Managements verteilter kooperativer Managementsysteme darstellen. Außerdem sind sämtliche MIB-Variablen als ,,read-only`` klassifiziert; Eingriffsmöglichkeiten im Sinne (pro-)aktiven Managements sind bisher nicht vorhanden. Auch hier zeigt sich, daß die Definition geeigneter MIBs für Managementsysteme bislang noch nicht erfolgt ist. Kapitel zeigt auf, welche Managementinformation erforderlich ist, um das Management solcher Systeme zu gewährleisten.

Die Notwendigkeit eines weiteren Problembereichs, nämlich die Bereitstellung geeigneter Managementfunktionalität wird deutlich bei der Betrachtung des NetView Polling-Algorithmus, der in Abbildung schematisch dargestellt ist.

  

Abbildung: Verhalten des IBM NetView Polling-Algorithmus

Ziel eines Polling-Algorithmus ist, festzustellen, welche überwachten Ressourcen momentan verfügbar sind, um diejenigen Icons, die diese Ressourcen repräsentieren, in der Topologie-Darstellung der Managementplattform geeignet einzufärben. Hierdurch wird ein Netzadministrator in die Lage versetzt, auf einen Blick zu erkennen, welche Ressourcen momentan in Betrieb sind, bzw. für welche Ressourcen Maßnahmen zur Fehlerdiagnose eingeleitet werden müssen. Die Ermittlung der Verfügbarkeit von Ressourcen geschieht durch das Versenden von ICMP echo-Paketen, die in geeigneten Zeitabständen (i.d.R. alle 5 Minuten) zu den Ressourcen gesandt werden.

Der bei NetView verwendete Polling-Algorithmus für eine Ressource lautet in Pseudocode wie folgt:

pollingtimeout := 10 Sekunden;
if (pollingtimeout < 150 Sekunden) then
        poll( Ressource )
        if (antwort_erhalten) then system_inoperativ := false
                else pollingtimeout := 2 * pollingtimeout
        endif;
else system_inoperativ := true
endif;

Der Algorithmus basiert auf der Prämisse, daß der Zustand einer Ressource nur dann auf inoperative (ohne Funktion, fehlerhaft) geändert werden sollte, wenn nachweislich mehrere Versuche gescheitert sind, zur Ressource Kontakt aufzunehmen. Damit soll verhindert werden, daß eine Ressource, die sich zum Polling-Zeitpunkt gerade in der Initialisierungsphase befindet, als fehlerhaft markiert wird. Ferner wird nach jedem erfolglosen Versuch der Timeout-Wert (beginnend mit 10 Sekunden) für das Polling verdoppelt, um sicherzugehen, daß auch im Falle extrem hoher Round-Trip-Delays aktive Ressourcen auch als solche erkannt werden. Für die maximale Anzahl von Versuchen innerhalb eines Pollingzyklus hat sich in der Praxis ein Wert von ,,4`` bewährt; dies impliziert, daß eine nicht erreichbare Ressource nach frühestens 150 Sekunden den Status ,,inoperativ`` zugewiesen bekommt. Um zu verhindern, daß während dieser Zeit keine weiteren Systeme befragt werden können, ist die maximale Anzahl der simultan ausstehenden ICMP-Antworten auf den Wert 3 festgelegt.

Während ein solcher Algorithmus beim Ausfall einzelner Komponenten einen tolerierbaren Kompromiß zwischen Netzbelastung und Plattformaktivität darstellt, ist es unmittelbar einleuchtend, daß ein solcher Algorithmus sehr schlecht skaliert, wenn ein Teil eines großen Rechnernetzes, beispielsweise bereits durch den Ausfall einer zentralen Komponente (z.B. Router), vom restlichen Kommunikationssystem getrennt wird. Bereits beim Ausfall von 3 Ressourcen sind sämtliche Pollingaktivitäten des Managementsystems für die Dauer von 2,5 Minuten (150 Sekunden) blockiert. Wünschenswert ist es daher, aus mehreren Polling-Algorithmen denjenigen auswählen zu können, der am geeignetsten für die spezifische Topologie eines Rechnernetzes erscheint. Obwohl in jüngster Zeit mehrere intelligente Polling-Algorithmen entwickelt wurden, können diese in herkömmlichen Managementplattformen nicht eingesetzt werden, da hier keinerlei Möglichkeiten bestehen, solche Algorithmen zur Laufzeit einzubinden. Kapitel stellt daher einen Ansatz vor, der unter anderem die dynamische Auswahl solcher Algorithmen gestattet.