Nutzung von Infrastruktur-Diensten für ein integriertes Ereignismanagement

  Die Verarbeitung asynchroner Ereignismeldungen durch eine Managementplattform geschieht i.w. in folgenden Schritten:

• Von den Agenten der überwachten Systeme werden (im Fehlerfalle oder bei Überschreitung vorher definierter Schwellwerte) Ereignismeldungen an die Managementplattform gesandt, die diese empfängt und nach festgelegten Regeln filtert. Hauptaufgabe der Filterung ist es also, aus den eingehenden Ereignis-Rohdaten Managementinformation zu gewinnen. Filterkriterien sind beispielsweise die Art der Ressource, der Typ und der Zeitpunkt der Ereignismeldung oder die Häufigkeit des Auftretens.
• Die gefilterte Managementinformation wird anschließend der Managementapplikation bzw. dem Administrator zur Verfügung gestellt. Die durch den Administrator ausgelösten Aktionen werden über die Plattform an die Ressourcen zur Ausführung übermittelt.

Die Aufgabe bestand nun darin, die vorhandenen NetView-Dienste für das Management von Ereignissen so zu erweitern, daß sowohl SNMP-Traps als auch CORBA-Events von einer zentralen Stelle empfangen werden können. Unser Ansatz basiert auf dem CORBA Event Service [13], der Mittel für die asynchrone Kommunikation zwischen verteilten Objekten spezifiziert. Hierbei wird zwischen Objekten, die Ereignisse erzeugen (sog. Supplier) und empfangenden Objekten (sog. Consumer) unterschieden. Die Kommunikation zwischen diesen Objektarten erfolgt durch Aufruf einer Methode des Consumers durch den Supplier; zur Entkopplung der beiden werden sogenannte Event Channels eingesetzt, die ihrerseits sämtliche Ereignisse, die von Suppliern kommen, an diejenigen Consumer weiterleiten, die sich für die betreffenden Events registriert haben. Man erhält somit die Möglichkeit, durch ,,Multiplexing`` ein Ereignis mehreren Consumern bzw. die Ereignisse sämtlicher Supplier einem Consumer zuzustellen. Letzterer Fall spiegelt unsere Anwendung der Event Channels wider.

Da NetView selbst nicht in der Lage ist, CORBA-Events zu verarbeiten, mußten diese im ersten Schritt in SNMP-Traps umgewandelt werden. Es wurde also ein Event-Gateway implementiert, das die NetView-Ereignisdienste kapselt. Nachdem die Ereignismeldungen empfangen wurden, können sie nun ebenso wie SNMP-Traps durch die NetView-Dienste gefiltert, protokolliert und an der graphischen Benutzerschnittstelle angezeigt werden. Es hat sich gezeigt, daß durch die Abstützung auf vorhandene Plattformdienste bereits mit geringem Aufwand gute Ergebnisse erzielt werden konnten.

  

Abbildung: Verarbeitung von CORBA-Events bei einer multiarchitekturellen Plattform

Der zweite Schritt bestand darin, einer CORBA-Managementapplikation die bereits von NetView gefilterten Ereignisse zuzustellen, um diese geeignet weiterverarbeiten zu können. Hierbei agiert nun die Plattform als Event-Supplier und die CORBA-Applikation als Consumer, die wiederum durch Event Channels entkoppelt sind. Das entsprechende Objekt, das den NetView-Dienst kapselt, wurde in Anlehnung an die OSI Event Report Management Function EFD_Supplier genannt, da seine Funktionalität identisch zu der eines OSI Event Forwarding Discriminator (EFD) ist: Die Managementapplikation registriert sich beim EFD_Supplier-Objekt für den Empfang gefilterter Ereignismeldungen einer bestimmten Art durch das Setzen eines Attributs des EFD_Suppliers auf den gewünschten Filterstring. Als Filterstring können alle in NetView erlaubten Filterregeln verwendet werden. Für jede Filterart kann ein EFD_Supplier-Objekt nach Bedarf erzeugt werden, an dem beliebig viele Consumer über Event Channels angeschlossen sein können.