Infrastrukturdienste für ein integriertes Ereignismanagement

 

Die Verarbeitung asynchroner Ereignismeldungen durch eine Managementplattform geschieht im wesentlichen in folgenden Schritten:

1.

Von den Agenten der überwachten Systeme werden (im Fehlerfall 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, 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.

2.

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.

Unser Lösungskonzept besteht nun darin, die vorhandenen NetView- Event Management Services (EMS) 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. Wir stützen uns dabei auf den CORBA Event Service [#!sspec97!#], 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, ein Ereignis mehreren Consumern, bzw. umgekehrt die Ereignisse vieler Supplier einem Consumer zuzustellen. Dies ist vorteilhaft, da die Anzahl von Consumer-Objekten für einen Supplier transparent ist: Letzterer muß lediglich eine Objektreferenz kennen (nämlich die des Event Channels), obwohl sich die Anzahl der Consumer-Objekte zur Laufzeit ändern kann. Ferner unterstützt der Event Service typisierte  sowie generische  Ereigniskommunikation. Der Unterschied zwischen diesen Arten besteht darin, daß generische Ereignismeldungen lediglich aus einem Parameter vom IDL-Datentyp any bestehen, während eine typisierte Ereignismeldung eine beliebige Anzahl von Parametern enthalten darf, deren Datentypen ebenfalls frei wählbar sind.

Angesichts der Tatsache, daß wir auf die in den Ereignismeldungen übermittelten Informationen Filter anwenden möchten, haben wir uns für typisierte Ereigniskommunikation entschieden. Wir sind somit in der Lage, Filterkriterien zu definieren, die eine Klassifikation hinsichtlich der Art der Ressource (Netzkomponente, Endsystem, Anwendung), der Ereigniskategorie (Fehler, Topologie, Status) sowie der Wichtigkeit zulassen. Letzteres bietet uns den Vorteil lastbezogener Verarbeitung, da beispielsweise wichtige Ereignisse von einem Supplier per Push-Kommunikation einem Consumer unmittelbar zugestellt werden können, während weniger bedeutsame Ereignisse per Pull-Kommunikation dann von einem Consumer abgerufen werden können, wenn dieser gegenwärtig keine vordringlicheren Aufgaben erledigen muß.

  

Abbildung: Weiterleitung asynchroner Ereignismeldungen

Da NetView selbst nicht in der Lage ist, CORBA-Events zu verarbeiten, müssen diese zunächst in SNMP-Traps umgewandelt werden. Wir haben dazu ein Event-Gateway implementiert (vgl. Abbildung ), das die NetView-Ereignisdienste kapselt, um CORBA-Ereignismeldungen verarbeiten zu können. Dieses bietet eine TypedConsumer-Schnittstelle zum Empfang von CORBA-Ereignismeldungen, transformiert diese in SNMP-Traps und leitet sie an NetView zur weiteren Verarbeitung weiter.

Der Empfang und die Transformation laufen im einzelnen folgendermaßen ab: Das EMS_Event_Consumer Objekt registriert sich beim Event Channel für sämtliche Ereignisse aller Supplier. Die eigentliche Transformation der Ereignisse sowie die Weiterleitung an das Managementsystem geschieht durch das Event_Adapter Objekt, dessen Aufgabe darin besteht, eine Enterprise-specific Trap-PDU zu kreieren, mit den aus dem CORBA-Event übernommenen Parametern auszufüllen und diese an den Manager abzusenden. Diese Abbildung geschieht in Anlehnung an die in [#!omg980503!#] gemachten Festlegungen und wird in einer Tabelle gespeichert. Naheliegenderweise müssen die spezifischen Trap-Typen ebenfalls dem Manager bekanntgemacht werden, was entweder manuell oder (in unserem Fall) durch Konfiguration des NetView Trap-Dämons trapd per entsprechendem Funktionsaufruf geschieht.

Die IDL-Definition eines Event_Adapter Objekts lautet wie folgt:

interface Event_Adapter : SOMObject
{
 void create_pdu(in long tid, in string src);
 void add_arg_long(in long arg);
 void add_arg_string(in string arg);
 void send_pdu();
}

Eine Trap-PDU wird durch Aufruf der create_pdu Methode kreiert und mit dem Trap-Identifikator (tid) sowie der IP-Adresse des Quellsystems vorbelegt (src, ermittelt aus dem host-Parameter des CORBA-Events). Anschließend werden die im typisierten CORBA-Event enthaltenen Parameter mit den beiden add_arg_()-Methoden als ,,Variable-Bindings`` geschrieben. Schließlich wird die PDU mit send_pdu() an das Managementsystem abgesandt.

Wir haben diese IDL-Definition erwähnt, weil sie die Funktionsaufrufe des NetView SNMP-APIs [#!IBMNVPR95!#] kapselt und somit als Beispiel eines IDL Wrappers angesehen werden kann. Da dieses API eine C-Programmierschnittstelle bietet, haben wir unter Zuhilfenahme des von der OMG standardisierten C-Language Mappings eine entsprechende Anbindung vornehmen können.

Nachdem die Ereignismeldungen empfangen wurden, können sie nun ebenso wie SNMP-Traps durch die NetView-Dienste gefiltert und protokolliert werden. Die Definition der Filterregeln kann mit den graphischen Werkzeugen des Managementsystems vorgenommen werden und bietet eine Vielzahl von Filterkriterien wie z.B. die Trap-ID, die IP-Adresse des Quellsystems, der Zeitpunkt des Auftretens, die Häufigkeit des Auftretens usw. Ebenfalls können die empfangenen und gefilterten Ereignismeldungen graphisch im Event Display des Managementsystems angezeigt werden (siehe dazu Abbildung ). Es hat sich gezeigt, daß durch die Abstützung auf vorhandene Plattformdienste bereits mit verhältnismäßig geringem Aufwand gute Ergebnisse erzielt werden können (siehe dazu [#!vogs96!#]).

  

Abbildung: Module der Ereignisverarbeitung

Wir hatten in der Anforderungsanalyse in Abschnitt explizit gefordert, daß auch CORBA-basierte Managementapplikationen in die Lage versetzt werden sollten, von der Managementplattform verarbeitete Ereignisse zugestellt zu bekommen. Der zweite Teil der Aufgabe besteht nun darin, eine Infrastruktur zu definieren, die es ermöglicht, die vom Manager gefilterten Traps wieder in CORBA-Ereignismeldungen zurückzukonvertieren.

Hierbei agiert nun die Plattform als Event-Supplier und die CORBA-Applikation als Consumer, die wiederum durch Event Channels entkoppelt sind. Das Objekt, das den entsprechenden 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 IDL-Definition dieser Objektklasse lautet wie folgt:

interface EFD_Supplier : SOMObject 
{
 attribute string filter; 
 void set_Dispatch(in Event_Dispatcher disp);
 oneway void activate();
}

Eine CORBA-Applikation registriert sich beim EFD_Supplier-Objekt für den Empfang gefilterter Ereignismeldungen einer bestimmten Art durch das Setzen des Attributs filter auf den gewünschten Filterstring. Hierfür können alle in NetView erlaubten Filterregeln verwendet werden. Bei der Initialisierung eines EFD_Supplier-Objekts durch den Aufruf seiner activate()-Methode wird der Inhalt des filter-Attributes ausgelesen und die Filterregel an den NetView Filter-Dämon ovesmd übergeben (siehe auch Abbildung ). Jede Ereignismeldung, die die Filterregel passiert, wird in einen CORBA-Event umgewandelt und über einen Event Channel an die registrierten Consumer (hier: Die jeweiligen Managementapplikationen) weitergeleitet. Die Auswahl des richtigen Event Channels ist Aufgabe des Event_Dispatcher. 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.

Obwohl die Weiterleitung und Verarbeitung der Ereignismeldungen in der Praxis gut funktionieren, hat unsere Implementierung (siehe hierzu die Ausführungen in [#!vogs96!#]) auch gezeigt, daß der Zwang zur Konvertierung der CORBA Events in SNMP-Traps die Achillesferse dieses Ansatzes darstellt: Einerseits müssen geeignete Abbildungen auf Trap-IDs erfolgen, die in separaten Tabellen vorgehalten werden, was bei einer großen Zahl von Ereignisarten einen nicht unerheblichen Verwaltungsaufwand mit sich bringt. Andererseits impliziert die Nutzung des Plattform-Filterdienstes die Beschränkung, daß die Filterkriterien stark SNMP-zentriert sind (z.B. Trap-ID, IP-Adresse der Quelle). Ein eigenständiger CORBA-Service, der die Definition leistungsfähiger Filterregeln zuläßt, ist mit dem Notification Service zwar angedacht, jedoch noch nicht abschließend standardisiert.