-
Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht
sich allgemein auf Datenkommunikationsnetzwerke und insbesondere
auf ein generisches Benachrichtigungs-Rahmensystem (GNF-System;
GNF = Generic Notification Framework) und ein Verfahren zum Integrieren
von Informationen aus unterschiedlichen Protokollen in eine Verwaltungsstation,
die schnittstellenmäßig mit
einem Netzwerk verbunden ist, und zum Ermöglichen einer Korrelation der
Informationen, um fortschrittlichere Verwaltungsentscheidungen in
Hinblick auf das Netzwerk oder die Station zu treffen. Zusätzlich zu
der Netzwerkverwaltung können
diese Verwaltungsentscheidungen ferner auf die Systemverwaltung
höherer
Ebene gerichtet sein, in dem Fall von verteilten Systemen oder verteilten
Verwaltungsanwendungen, die über
dem Netzwerk arbeiten.
-
Hintergrund
der Erfindung
-
Ein Datenkommunikationsnetzwerk umfaßt allgemein
eine Gruppe von Vorrichtungen, z. B. Computer, Repeater, Brücken, Router
etc., die an Netzwerkknoten positioniert sind, und eine Sammlung von
Kommunikationskanälen
zum Verbinden der verschiedenen Knoten. Hardware und Software, die dem
Netzwerk zugeordnet ist, und insbesondere den Vorrichtungen, ermöglicht es
den Vorrichtungen, Daten elektronisch über die Kommunikationskanäle auszutauschen.
-
Um die verschiedenen Vorrichtungen
zu verfolgen und zu verwalten, die auf einem Netzwerk positioniert
sind, wurden verschiedene Verwaltungsprotokolle entwickelt. Beispiele
dieser Verwaltungsprotokolle umfassen das Simple Network Management Protocol
(SNMP = einfaches Netzwerkverwaltungsprotokoll), das Common Management
Information Protocol (CMIP = allgemeines Verwaltungsinformationsprotokoll),
standardisiert durch die International Organization for Standardization
(ISO), properietäre Protokolle,
die in Umgebungen proprietärer
Netzwerke angetroffen werden können,
wie z. B. SNATM von der IBM Corp. und „NETWARE"TM (NW)
von der Novell Corp., und entfernte Verfahrensrufprotokolle (RPC
= Procedure Call Protocol), wie z. B. das verteilte Rechenumgebungsprotokoll
(DCE-RPC = Distributed Computing Environment Protocol), das durch die
Open Software Foundation entwickelt wurde. Die Verwendung der vorangehenden
Protokolle hat in der Industrie großen Umfang angenommen und zahlreiche
Verkäufer
stellen nun viele Typen von Netzwerkvorrichtungen her, die diese
Protokolle verwenden können.
-
Viele Verwaltungssoftwarepakete („Management
Platforms") sind
aktuell zum Implementieren von „Verwaltungsstationen" auf einem Netzwerk
erhältlich.
Beispiele handelsüblich
erhältlicher
Verwaltungssoftwarepakete umfassen „OPEN-VIEW"TM (oder „HP OPENVIEW"TM)
von der Hewlett-Packard Company, die hierin der Anmelder ist, „NETVIEW"TM von
der IBM Corp., „SPECTRUM"TM von
Cabletron Systems, Inc., „NET-LABS MANAGER"TM von NetLabs,
Inc., und „SUNNET
MANAGER"TM von der SunConnect Inc. Die Knoten an
dem Netzwerk und ihre Verbindungen werden häufig als die Netzwerk-„Topologie" bezeichnet, und
werden am besten in einem graphischen Format angezeigt, und die meisten,
wenn nicht alle, der verfügbaren
Verwaltungssoftwarepakete sehen dieses Merkmal vor. Üblicherweise
kann mit diesen Paketen ein Netzwerk aus unterschiedlichen Ausgangspunkten
betrachtet werden, abhängig
von dem Umfang der Betrachtung, der erwünscht ist. Eine Ansicht des
Netzwerks könnte
z. B. eine sehr breite umfassende Ansicht aller Knoten des gesamten
Netzwerks sein. Eine zweite Ansicht könnte eine Ansicht dieser Abschnitte
eines Netzwerks innerhalb eines lokalen Bereichs sein, z. B. innerhalb
eines bestimmten Orts oder eines Gebäudes. Eine dritte Ansicht eines
Netzwerks, die häufig
ein Segment genannt wird, könnte
eine Ansicht von Knoten sein, die an ein bestimmtes lokales Netzwerkkabel
(LAN-Kabel) angebracht sind.
-
Das sehr erfolgreiche „OPENVIEW"TM von Hewlett
Packard war der Gegenstand verschiedener Patente, einschließlich z.
B. dem U.S.-Patent Nr. 5.185.860 ausgegeben an J. C. Wu am 9. Februar 1993,
und dem U.S.-Patent Nr. 5.276.789 ausgegeben an Besaw u. a. am 4.
Januar 1994. Das U.S.-Patent Nr. 5.185.860 beschreibt ein automatisches
Entdeckungssystem für
ein Verwaltungssystem zum Bestimmen der Netzwerkvorrichtungen und
Verbindungen eines Netzwerks oder der Topologie. Das U.S.-Patent
Nr. 5.276.789 beschreibt ein graphisches Anzeigesystem für eine Verwaltungsstation zum
graphischen Anzeigen der Topologie eines Netzwerks und liefert verschiedene
Ansichten (einschließlich
Internet-, Segmentund Knoten-Ansichten), die durch einen Benutzer
angefordert werden können.
-
Obwohl die momentan verfügbaren Verwaltungsstationen
ein zufriedenstellendes Ausmaß aufweisen,
ist die Technik von Verwaltungsstationen immer noch in ihren Kinderschuhen
und das Verhalten aktueller Verwaltungsstationen kann immer noch
verbessert und optimiert werden. Ein spezifischer Bereich, in dem
Optimierungen betrachtet werden, umfaßt das gemeinsame Verwenden
von Informationen, die aus Ereignissen zwischen Anwendungen hergeleitet
werden, die den Verwaltungsstationen zugeordnet sind. Hierin ist
ein „Ereignis" eine Benachrichtigung,
die durch ein Element in der verwalteten Umgebung emittiert wird,
um eine Zustandsänderung anzuzeigen.
Ereignisse sind üblicherweise
asynchron relativ zu der Verwaltungsstation. Ferner existieren bereits
zahlreiche Ereignis-Weiterleitungs- und -Verbreitungs-Mechanismen,
aber jeder derselben ist umfassend auf eine bestimmte Umgebung oder
eine Protokolldomäne
abgestimmt. Dieser Zustand verursacht verschiedene Probleme.
-
Erstens erfordern viele Anwendungen
Zugriff auf Benachrichtigungen für
mehr als eine der Protokolldomänen,
die die verwaltete Umgebung bilden. Ihre Implementierung ist jedoch
momentan aufgrund der Anzahl und Vielzahl von erforderlichen Protokollen
und Schnittstellen kompliziert. Der Anwendungszugriff auf Ereignisdaten
sollte nicht durch ein erforderliches Verständnis der detaillierten Syntax
und Semantik von umgebungsspezifischen Protokollen, Darstellungen
von und Schnittstellen zu den Ereignisdaten belastet werden.
-
Zweitens besteht kein einzelner gemeinsamer
Mechanismus zum Erhalten von Benachrichtigungen von mehreren Domänen. In
dem Kontext dieses Dokuments ist eine „Benachrichtigung" eine Meldung, die
asynchron im Hinblick auf einen Empfänger und in einer logisch nicht
gerichteten Weise emittiert wird. In bestimmten Fällen wurden
spezifische Module erzeugt, um Benachrichtigungen von einem Mechanismus
zu einem anderen abzubilden, aber dies führt zu einem „n mal
m" Problem und verzerrt
häufig die
Informationen aufgrund der umgebungsspezifischen, häufig nicht
anwendbaren Elemente des Ziels. In bestimmten Fällen gehen Informationen einer
Originalbenachrichtigung vollständig
verloren, da keine semantisch vergleichbare Struktur in dem Ziel vorliegt.
-
Drittens weisen Anwendungen keinen
gemeinsamen Integrationsmechanismus zum Austauschen asynchroner
Meldungen unter den Anwendungen auf.
-
Viertens liegt wenig in dem Weg von
gemeinsam verwendeter Semantik zwischen Anwendungen vor, um die
Erzeugung generischer Funktionen zu ermöglichen. Genauer gesagt gibt
es aktuell keine Art und Weise, eine gemeinsame Ereignisverwaltungskonsole,
einen gemeinsamen Filtermechanismus oder gemeinsame Tools zu implementieren,
die an alle Varianten von Ereignisdaten angewendet werden können.
-
Somit besteht ein nichtadressierter
Bedarf in der Industrie nach einem System und einem Verfahren zum
Verbessern der Operation einer Verwaltungsstation auf einem Netzwerk
durch Integrieren und Korrelieren von Informationen aus unterschiedlichen
Protokollen.
-
Zusammenfassung
der Erfindung
-
Kurz beschrieben ist die vorliegende
Erfindung ein generisches Benachrichtigungsrahmen-System (GNF-System)
und -Verfahren zum Integrieren von Informationen aus unterschiedlichen Protokollen
in einer Verwaltungsstation, die schnittstellenmäßig mit einem Netzwerk verbunden
ist, und zum Ermöglichen
einer Korrelation der Informationen, um höher entwickelte Verwaltungsentscheidungen
zu treffen.
-
Strukturell gesehen weist das generische Benachrichtigungsrahmensystem
einen oder mehrere protokollspezifische Übersetzer in Kommunikation mit
dem Netzwerk auf, einen generischen Benachrichtigungsrahmen in Kommunikation
mit den Übersetzern
und eine oder mehrere Verbraucherkomponenten in Kommunikation mit
dem Rahmen. Die Übersetzer
empfangen Ereignisdatenelemente, die unterschiedlichen Verwaltungsprotokollen
entsprechen, aus dem Netzwerk, und übersetzen die Ereignisdatenelemente
in jeweilige kanonische Datenstrukturen. Jede der kanonischen Datenstrukturen umfaßt (a) einen
Satz von generischen Feldern, die allen der kanonischen Datenstrukturen
gemeinsam sind, (b) eines oder mehrere Attributfelder, die durch den Übersetzer
basierend auf einer Untersuchung einer Protokolldateneinheit (PDU)
erzeugt werden, die jedem der Ereignisdatenelemente zugeordnet sind, und
(c) eine Protokolldateneinheit (PDU = Protocol Data Unit), die allgemein
identisch zu der systemeigenen PDU ist, die mit dem Ereignisdatenelement angekommen
ist. Im wesentlichen ist die PDU in der kanonischen Datenstruktur
eine Einkapselung von systemeigenen Daten, so daß Anwendungen, die die Darstellung
verstehen, vollen Zugriff auf ihre Inhalte haben.
-
Verbraucherkomponenten werden bei
dem Rahmen registriert, um kanonische Datenstrukturen zu empfangen,
die bestimmte Werte für
Attributfelder aufweisen. Ferner leitet der generische Benachrichtigungsrahmen
die geeigneten kanonischen Datenstrukturen an die geeigneten Verbraucherkomponenten
basierend auf den Werten der Attributfelder weiter.
-
Ein Korrelierer kann optional aber
vorzugsweise dem Rahmen zugeordnet sein, um die kanonischen Datenstrukturen
zu korrelieren, um ein intelligentes Ereignisdatenelement herzuleiten,
das im wesentlichen das Ergebnis einer Assimilation und einer logischen
Bewertung von verschiedenen Ereignisdatenelementen ist. Somit werden
Ereignisdatenelemente generisch behandelt und verarbeitet, und dieses
Merkmal ermöglicht,
daß höher entwickelte
Entscheidungen getroffen werden.
-
Die vorliegende Erfindung schafft
ein Benachrichtigungsrahmensystem gemäß Anspruch 1.
-
Die vorliegende Erfindung schafft
ferner ein Verfahren zum Verbessern der Operation einer Verwaltungsstation
an einem Netzwerk durch Integrieren von Informationen aus einer
Mehrzahl von unterschiedlichen Verwaltungsprotokollen, wobei das Netzwerk
eine Mehrzahl von Verwaltungsstationen aufweist, wie folgt: Empfangen
von Ereignisdatenelementen, die unterschiedlichen Verwaltungsprotokollen
aus dem Netzwerk entsprechen; Übersetzen
der Ereignisdatenelemente in jeweilige kanonische Datenstrukturen,
wobei jede der kanonischen Datenstrukturen ein Attributfeld zum
Halten eines Attributs umfaßt,
das durch eine der Mehrzahl von Verwaltungsstationen auf dem Netzwerk
interpretiert werden kann, wobei das Übersetzen eines Ereignisdatenelements
in die kanonische Datenstruktur das Extrahieren aus den Ereignisdatenelementattributen aufweist,
die in dem Attributfeld gespeichert werden sollen; Kommunizieren
der kanonischen Datenstrukturen zu einem Rahmen für eine mögliche Verteilung zu
Verbraucherkomponenten, die mit dem Rahmen verbun den sind; Kommunizieren
eines bestimmten Attributfelds von einer Verbraucherkomponente zu dem
Rahmen, um anzuzeigen, daß die
Verbraucherkomponente eine der kanonischen Datenstrukturen mit dem
bestimmten Attributfeld empfangen möchte; und Kommunizieren einer
kanonischen Datenstruktur mit dem bestimmten Attributfeld von dem
Rahmen zu der Verbraucherkomponente.
-
Ferner schafft die vorliegende Erfindung
ein intelligentes Integrationssystem gemäß Anspruch 9.
-
Die vorliegende Erfindung schafft
ferner ein Verfahren zum Verbessern der Operation einer Verwaltungsstation
auf einem Netzwerk sowohl durch Integrieren als auch durch Korrelieren
von Informationen aus unterschiedlichen Verwaltungsprotokollen, wobei
das Netzwerk eine Mehrzahl von Verwaltungsstationen aufweist, wie
folgt: Empfangen von Ereignisdatenelementen von dem Netzwerk, wobei
die Ereignisdatenelemente unterschiedlichen Verwaltungsprotokollen
entsprechen; Übersetzen
von jedem der Ereignisdatenelemente in eine kanonische Datenstruktur,
wobei die kanonische Datenstruktur ein Attributfeld zum Halten eines
Attributs umfaßt,
das durch eine der Mehrzahl von Verwaltungsstationen auf dem Netzwerk
interpretiert werden kann, wobei das Übersetzen eines Ereignisdatenelements
in die kanonische Datenstruktur das Extrahieren aus dem Ereignisdatenelementattribut
aufweist, das in dem Attributfeld gespeichert werden soll, wobei
die kanonische Datenstruktur in der Lage ist, mit anderen kanonischen
Datenstrukturen korreliert zu werden, die anderen Ereignisdatenelementen
entsprechen, unabhängig
von Protokollen, die den Ereignisdatenelementen zugeordnet sind;
und Korrelieren der kanonischen Datenstrukturen, um ein intelligentes
Ereignis herzuleiten, das im wesentlichen eine Aktion ist, die aus
einer intelligenten Entscheidung auf hoher Ebene resultiert, die
aus einer Assimilation und einer Bewertung verschiedener Ereignisse
hergeleitet wird.
-
Die vorliegende Erfindung weist zahlreiche Vorteile
auf, wobei einige derselben hierin nachfolgend als Beispiele ausgeführt werden.
-
Ein Vorteil ist, daß eine protokollneutrale Darstellung
jedes Ereignisses ausgeführt
werden kann, was die Erzeugung von gemeinsamen Verwaltungsmechanismen,
Filtern, Anzeigen und Tools bedeutend vereinfacht.
-
Ein weiterer Vorteil ist, daß asynchrone
Meldungen zwischen Anwendungen ausgetauscht werden können, die
gemäß unterschiedlichen
Protokollen arbeiten.
-
Ein anderer Vorteil ist, daß die Schnittstelle zwischen
Anwendungen vereinfacht wird.
-
Ein anderer Vorteil ist, daß Anwendungen
die detaillierte Syntax und Semantik der umgebungsspezifischen Protokolle,
Darstellungen von und Schnittstellen zu den Ereignisdaten nicht
verstehen müssen,
um miteinander zu kommunizieren.
-
Ein anderer Vorteil ist, daß Informationen
aus unterschiedlichen Protokollen integriert und korreliert werden
können,
so daß höher entwickelte
Entscheidungen betreffend die Verwaltung getroffen werden können.
-
Ein anderer Vorteil ist, daß höher entwickelte Entscheidungen
für Netzwerkrechenumgebungen getroffen
werden können,
die mehrere heterogene Netzwerke und Netzwerkverwaltungsprotokolle
aufweisen.
-
Andere Merkmale und Vorteile der
vorliegenden Erfindung werden Fachleuten auf dem Gebiet nach der
Untersuchung der nachfolgenden Zeichnungen und der detaillierten
Beschreibung offensichtlich. Es wird beabsichtigt, daß alle solchen
zusätzlichen
Merkmale und Vorteile hierin innerhalb des Schutzbereichs der vorliegenden
Erfindung umfaßt
sind, wie in den beiliegenden Ansprüchen definiert ist.
-
Kurze Beschreibung
der Zeichnungen
-
Die vorliegende Erfindung ist bezugnehmend
auf die nachfolgenden Zeichnungen besser verständlich. Es wird darauf hingewiesen,
daß gleiche
Bezugszeichen innerhalb der Zeichnungen entsprechende Teile bezeichnen.
-
1 ist
ein Blockdiagramm, das ein Beispiel der Implementierung des generischen
Benachrichtigungsrahmensystems (GNF-System) der vorliegenden Erfindung
in einer Verwaltungsstation darstellt, was gegenwärtig das
beste Verfahren zum Praktizieren der Erfindung ist;
-
2 ist
ein Blockdiagramm, das die Entdeckungs/Layout-Software und das GNF-System
aus 1 darstellt;
-
3 ist
ein Blockdiagramm, das den GNF aus 1 darstellt,
der schnittstellenmäßig mit
verschiedenen umgebungsspezifischen Ereignisteilsystemen verbunden
ist, die auf Ereignisse hin arbeiten, die unterschiedliche Protokolle
aufweisen;
-
4 ist
ein schematisches Diagramm, das die kanonische Datenstruktur für Ereignisdaten
darstellt, die durch das GNF-System aus 1 kommuniziert werden;
-
5 ist
ein Blockdiagramm, das die Rollen (d. h. Lieferanten, Verbraucher
und Konfigurierer) darstellt, die durch Komponenten angenommen werden,
die mit dem GNF-System aus 1 interagieren;
-
6 ist
ein Blockdiagramm, das ein Beispiel eines Lieferanten in der Form
eines Ereignisteilsystems aus 3 darstellt;
und
-
7 ist
ein Blockdiagramm, das ein Alarmteilsystem darstellt, das Korrelationsfunktionen
aufweist, das in Verbindung mit dem GNF aus 1 verwendet wird.
-
Detaillierte
Beschreibung der bevorzugten Ausführungsbeispiele
-
Das generische Benachrichtigungsrahmensystem
(GNF-System) der vorliegenden Erfindung kann auf einem computerlesbaren
Medium zur Verwendung durch oder in Verbindung mit einem computerverwandten
System oder Verfahren gespeichert sein. In dem Kontext dieses Dokuments
ist ein computerlesbares Medium eine elektronische, magnetische,
optische oder andere physikalische Vorrichtung oder Einrichtung,
die ein Computerprogramm zur Verwendung durch oder in Verbindung
mit einem computerverwandten System oder Verfahren enthalten oder
speichern kann.
-
Das GNF-System und -Verfahren kann
praktisch in jeder Umgebung implementiert sein, die asynchrone Ereignisse
verarbeitet, die die Ressourcen betreffen, die in einem Netzwerk,
einem verteilten Netzwerk oder einem anderen Kommunikationssystem
verwaltet werden. Bei dem bevorzugten Ausführungsbeispiel sind das GNF-System
und das -Verfahren in einer Verwaltungsstation implementiert. Eine
Verwaltungsstation ist eine Maschine, die zumindest einen Teil des
Verwaltungssystems betreibt. Ein Beispiel einer Verwaltungsstation
wird hierin nachfolgend zu Zwecken der Erörterung diskutiert.
-
1 zeigt
ein Blockdiagramm einer Verwaltungsstation 100, die mit
einem Allzweckcomputersystem implementiert ist, das eine Entdeckungs-/Layout-Software
101 enthält,
die das GNF-System 103 und eine zugeordnete Methode der vorliegenden
Erfindung verwendet. Bezugnehmend auf 1 enthält die Verwaltungsstation 100 einen geeigneten
Prozessor 102.
-
Der Prozessor 102 kommuniziert
mit anderen Elementen innerhalb der Verwaltungsstation 100 über eine
lokale Schnittstelle 104, z. B. einen Bus oder mehrere
Busse. Eine Eingabevorrichtung 106, z. B. eine Tastatur
oder eine Maus, wird verwendet, um Daten von einem Benutzer der
Verwaltungsstation 100 einzugeben, und eine Ausgabevorrichtung 108,
z. B. eine Anzeige oder ein Drucker, wird verwendet, um Daten an
den Benutzer auszugeben. Eine Netzwerkschnittstelle 112 wird
verwendet, um die Verwaltungsstation 100 schnittstellenmäßig mit einem
Netzwerk 118 oder einer Gruppe von Netzwerken zu verbinden,
um es der Verwaltungsstation 100 zu ermöglichen, als ein Knoten auf
dem Netzwerk 118 oder der Gruppe von Netzwerken zu wirken.
Ein Speicher 110 innerhalb der Verwaltungsstation 100 speichert
die Software zum Treiben des Prozessors 102 und allgemein
der Station 100.
-
Wie gezeigt ist, kann der Speicher 110 bei diesem
Ausführungsbeispiel
die nachfolgende Softwarehierarchie umfassen: Auf der höchsten logischen
Ebene, eine oder mehrere Verwaltungsanwendungen 105; auf
der nächsten
logischen Ebene, Entdeckungs-/Layout-Software 101, die in einem
logischen Sinn entlang des GNF-Systems 103 positioniert
ist; und auf der untersten logischen Ebene ein herkömmliches
Betriebssystem 122 und eine herkömmliche Netzwerksoftware 124.
Die eine oder die mehreren Verwaltungsanwendungen 105 verwalten auf
einer hohen Ebene einen Aspekt des Netzwerks 118 oder der
Gruppe von Netzwerken. Sowohl die Entdeckungs-/Layout-Software 101 als
auch das GNF-System 103 können mit dem Betriebssystem 122 und
der Netzwerksoftware 124 kommunizieren, um die Knoten an
dem Netzwerk 118 zu entdecken. Die Netzwerksoftware 124 dient
als die Intelligenz, einschließlich
Validierung, für
die Datenkommunikationsprotokolle. Wie in 1 gezeigt ist, weist die Netzwerksoftware
Teilsysteme 302 auf, die beispielsweise die nachfolgenden
Protokolle implementieren können:
SNMP, CMIP, DCE und properietäre
Protokolle von SNA und NW. Alle der vorangehenden Protokolle sind
in der Technik bekannt.
-
Allgemein ausgedrückt, ist die Entdeckungs-/Layout-Software
101 aus 1 konfiguriert, um
die Netzwerktopologie zu entdecken, d. h. alle Netzwerkknoten und
Knotenverbindungen, die auf dem Netzwerk 118 existieren,
und um eine Abbildung aufzubauen, die verschiedene Teilabbildungen
aufweist, wobei eines derselben zum Ausgeben der Netzwerktopologie
auf der Ausgabevorrichtung 108 verwendet werden kann.
-
Ein Hohe-Ebene-Blockdiagramm des GNF-Systems 103 und
der Entdeckungs-/Layout-Software 101 (1)
ist in 2 erläutert. Mit der
Ausnahme des GNF-Systems 103 ist die Architektur der Entdeckungs-/Layout-Software
101 in 2 im wesentlichen
gleich oder ähnlich
zu der Architektur des bekannten und handelsüblich erhältlichen Verwaltungssoftwarepakets
von Hewlett-Packard mit dem Namen „OPENVIEW"TM. Wie in 2 gezeigt ist, weist die
Entdeckungs-/Layout-Software 101 auf
der allgemeinen Architekturebene einen Entdeckungsmechanismus 202 zum
Entdecken von Knoten und Verbindungen des Netzwerks 118 und
einen Layoutmechanismus 204 zum Empfangen von Topologiedaten
von dem Entdeckungsmechanismus 202 und zum Erzeugen der
Abbildung zum Treiben der Ausgabevorrichtung 108 auf. Ferner
kann eine oder mehrere Verwaltungsanwendungen 108 Anzeige-
und Abbildungs-Informationen
mit dem Layoutmechanismus 204 kommunizieren.
-
Der Entdeckungsmechanismus 202 weist folgende
Merkmale auf: Eine Netzwerküberwachungsvorrichtung 206,
die mit dem Netzwerk 118 verbunden ist, wie durch die Verbindung
208 angezeigt ist, einen Topologieverwalter 210, der mit
der Netzwerküberwachungsvorrichtung 206 verbunden ist,
wie durch die Pfeile 212 und durch das generische Benachrichtigungsrahmensystem
(GNF-System) 103 gezeigt ist, das zu einem späteren Punkt
in diesem Dokument detaillierter beschrieben wird, und eine Topologiedatenbank 214 in
Kommunikation mit dem Topologieverwalter 210, wie durch
den Pfeil 216 angezeigt ist.
-
Die Netzwerküberwachungsvorrichtung 206 überträgt und empfängt Datenpakete
zu und von dem Netzwerk 118. Die Netzwerküberwachungsvorrichtung 206 entdeckt
und überwacht
die Netzwerktopologie, wie durch den Pfeil 208 angezeigt
ist. Wenn sich die Netzwerktopologie an dem Netzwerk verändert, erzeugt
die Netzwerküberwachungsvorrichtung 206 Ereignisse
oder Fallen (SNMP-Sprache), die einen Objektidentifizierer und Objektänderungsinformationen
umfassen. Die Netzwerküberwachungsvorrichtung 206 kann
ferner Ereignisse von anderen Vorrichtungen empfangen, wie z. B.
einem Router, in dem Netzwerk 118. Die Netzwerküberwachungsvorrichtung 206 interagiert
mit dem Netzwerk 118 mit Hilfe der Netzwerksoftware 124 (1), die im wesentlichen
Protokollstapel aufweist, die z. B. IP, TCP, UDP, SNMP, ISO, DCE,
SNA und NW entsprechen, und die im wesentlichen diese Protokolle
implementiert und Validierungsfunktionen ausführt. Ferner besiedelt die Netzwerküberwachungsvorrichtung 206 die
Topologiedatenbank 214 mit Hilfe des Topologieverwalters 210 und
benachrichtigt den Topologieverwalter 210 über Ereignisse
(Topologieänderungen). Schließlich sollte
darauf hingewiesen werden, daß das
U.S.-Patent Nr. 5.185.-860
an Wu, das hierin durch Bezugnahme aufgenommen ist, ein Beispiel eines
Knotenentdeckungssystems beschreibt, das verwendet werden könnte, um
die Netzwerküberwachungsvorrichtung 206 hierin
zu implementieren. Die vorangehende Überwachungsvorrichtung konzentriert
sich auf das Überwachen
von Ereignissen, die Änderungen
in der Topologie betreffen. Andere Überwachungsvorrichtungen könnten in
Verbindung mit der vorliegenden Erfindung verwendet werden und auf
das Überwachen
anderer Aspekte der Umgebung gerichtet werden, wobei in diesem Fall
andere Typen von Verwaltungsinformationen durch die Überwachungsvorrichtung
und das GNF-System 103 weitergeleitet werden könnten.
-
Der Topologieverwalter 210 verwaltet
die Topologiedatenbank 214, wie durch den bidirektionalen Pfeil 216 angezeigt
ist. Der Topologieverwalter 210 fordert die Netzwerküberwa chungsvorrichtung 206 auf,
Topologiedaten zu aktualisieren, die sich auf bestimmte Ereignisse
beziehen, und empfängt
Topologieaktualisierungen, wie durch den Pfeil 212 angezeigt
ist.
-
Die Topologiedatenbank 214 speichert
Topologiedaten basierend auf Objekten, die verwendet werden, um
das Netzwerk aus logischen Gründen
zu partitionieren. Objekte umfassen z. B., aber nicht ausschließlich, ein
Netzwerk, ein Segment, einen Computer, einen Router, einen Repeater,
eine Brücke,
etc. Ferner umfassen die Topologiedaten, die in Hinblick auf die
Objekte gespeichert sind, z. B. aber nicht ausschließlich eine
Schnittstellen- oder Vorrichtungs-Adresse, einen Vorrichtungstyp, einen
Vorrichtungshersteller und ob eine Schnittstelle oder Vorrichtung
das SNMP unterstützt.
-
Der Layoutmechanismus 204 weist
folgendes auf: einen Topologie-Zu-Abbildung-Übersetzer 218 in Kommunikation
mit dem Topologieverwalter 210, wie durch den Pfeil 220 angezeigt
ist, eine graphische Benutzerschnittstelle (GUI = Graphical User Interface) 222 in
Kommunikation mit dem Topologie-Zu-Abbildung-Übersetzer 218, wie
durch den Pfeil 224 angezeigt ist, und eine Abbildungsdatenbank 226 in
Kommunikation mit der GUI 222, wie durch den bidirektionalen
Pfeil 228 angezeigt ist. Die eine oder die mehreren Anwendungen 105 kommunizieren
Informationen mit der GUI 222, wie durch den Pfeil 233 angezeigt
ist.
-
Der Übersetzer 218 wandelt
Topologiedaten, die von der Topologiedatenbank 214 und
dem GNF-System 103 empfangen wurden, in Abbildungsdaten
um und erzeugt verschiedene Teilabbildungen in der Abbildung. Der Übersetzer 218 kann
eine Anforderung an den Topologieverwalter 210 weiterleiten,
wie durch den Pfeil 220 angezeigt ist, um Topologiedaten
betreffend bestimmte Objekte zu erhalten. Zusätzlich zu dem Weiterleiten
von Topologiedaten an den Übersetzer 218 auf
die Anforderung hin, weist der Topologieverwalter 210 den Übersetzer 218 an, wie
durch die entsprechenden Pfeile 220 angezeigt ist, wenn
sich Topologiedaten basierend auf einem Ereignis verändert haben,
so daß der Übersetzer 218 entsprechende Änderungen
in den Teilabbildungen durchführen
kann.
-
Ferner kann sich der Übersetzer 218 in
dem GNF-System 103 registrieren, um einen bestimmten Typ
von Topologiedaten oder Ereignis zu erhalten. Umgekehrt, falls zutreffend,
können
der Topologieverwalter 210 und das GNF-System 103 die
Topologiedaten an den Übersetzer 218 weiterleiten,
wie durch die entsprechenden Pfeile 220, 245 angezeigt ist.
Das GNF-Registrierungsmerkmal eliminiert den Bedarf für den Übersetzer 2185,
ständig
Anfragen (Abfragen) nach gewünschten
Daten zu machen.
-
Die GUI 222 verwaltet die
Abbildungsdatenbank 226, wie durch den Pfeil 228 angezeigt
ist, und verwaltet die Eingabevorrichtung 106 und die Ausgabevorrichtung 108,
wie durch die jeweiligen Pfeile 230, 231 angezeigt
ist. Die GUI 222 empfängt
Abbildungsaktualisierungen von dem Übersetzer 218 und übermittelt
vom Benutzer ausgelöste
Ereignisse an den Übersetzer 218,
wie durch den Pfeil 224 angezeigt ist. Ein vom Benutzer
ausgelöstes
Ereignis umfaßt
eine Anfrage 230 von einem Benutzer, um ein Objekt auseinanderzuziehen.
Schließlich
sollte darauf hingewiesen werden, daß das U.S.-Patent Nr. 5.276.789 an Besaw u. a.,
das hierin durch Bezugnahme aufgenommen ist, eine graphische Benutzerschnittstelle
beschreibt, die verwendet werden könnte, um die GUI 222 hierin
zu implementieren.
-
Das GNF-System 103 der vorliegenden
Erfindung steht in Kommunikation mit der Netzwerküberwachungsvorrichtung 206,
dem Topologieverwalter 210, der GUI 222 und der
einen oder den mehreren Anwendungen 105, wie durch die
entsprechenden Pfeile 242, 244, 246 und 248 in 2 angezeigt ist. Im allgemeinen
ermöglicht
das GNF-System 103 das gemeinsame Verwenden von Ereignissen
aus unterschiedlichen Verwal tungsprotokollen, wie z. B. SNMP, ISO,
DCE, SNA und NW, und ermöglicht
eine Korrelation der Informationen, um höher entwickelte Verwaltungsentscheidungen
zu treffen.
-
Das GNF-System 103 weist
einen Ereignisübersetzer 252 und
einen GNF 254 auf, die in Kommunikation sind, wie durch
den Referenzpfeil 253 angezeigt ist. Der Übersetzer 252 ist
konfiguriert, um Ereignisdaten in eine kanonische Datenstruktur
zu übersetzen
(4), die in der Lage
ist, mit anderen kanonischen Datenstrukturen korreliert zu werden, die
anderen Ereignisdaten entsprechen, unabhängig von Protokollen, die den
Ereignisdaten zugeordnet sind. Ferner ermöglicht es die kanonische Datenstruktur
dem GNF-System 254, gemeinsame semantische Operationen
durchzuführen,
wie z. B. Filtern, Weiterleiten, Verfolgen und Protokollieren. Die
kanonischen Datenstrukturen werden durch den Übersetzer 252 an den
GNF 254 weitergeleitet, der die kanonischen Datenstrukturen
filtern und die Strukturen an Verbraucher weiterleiten kann, wie
z. B. den Topologieverwalter 210, die GUI 222 oder
eine Anwendung 105.
-
3 ist
ein Blockdiagramm, das die Kommunikationsverbindungen darstellt,
die durch das GNF-System 103 in der Station 100 (1) errichtet werden können. Das
GNF-System 103 ist
schnittstellenmäßig mit
einem oder mehreren umgebungsspezifischen Ereignisteilsystem 302 verbunden,
die verschiedenen unterschiedlichen Protokollen entsprechen und
verbindet ferner die verschiedenen Teilsysteme 302 schnittstellenmäßig mit
der einen oder den mehreren Anwendungen 105. Das GNF-System 103 dient
als ein Integrationspunkt, wo Ereignisinformationen gemeinsam verwendet
werden, die Ereignisse betreffen, die sich auf das Netzwerk 118 beziehen. Die
umgebungsspezifischen Ereignisteilsysteme 302 können auf
ein geeignetes Protokoll gerichtet sein, z. B. SNMP, CMIP und DCE-RPC,
oder jene Protokolle, die durch SNA und NW geliefert werden. Bei
dem bevorzugten Ausführungsbeispiel
sind die Teilsysteme 302 innerhalb der Netzwerküberwachungsvorrichtung 206 positioniert
oder derselben zugeordnet (2).
Ferner kann eine der Verwaltungsanwendungen 232 z. B. ein
Alarmteilsystem sein, wie in 3 gezeigt
ist.
-
Die kanonische Datenstruktur ist
in 4 gezeigt und allgemein
durch das Bezugszeichen 424 bezeichnet. Die kanonische
Datenstruktur 424 umfaßt
generische Felder 424a, extrahierte Attribute 424b und
eine systemeigene Protokolldateneinheit (PDU = Protocol Data Unit) 424c.
In einer Hinsicht, wenn dieselbe übertragen wird, ist die kanonische Datenstruktur 224 selbst
eine Form einer PDU. Die generischen Felder 224a sind jene
wenigen Attribute, die als allen umgebungsspezifischen Formaten
gemeinsam (oder annähernd
gemeinsam) betrachtet werden können.
Die extrahierten Attribute sind eine Sammlung von vollständig spezifizierten
Attributen, einschließlich
Name, Typ, Länge
und Wert, die aus den systemeigenen Formaten extrahiert werden können, so
daß dieselben
durch einen Empfänger
interpretiert werden können.
Die umgebungsspezifische PDU 24c ist eine Einkapselung
von systemeigenen Daten, so daß Anwendungen,
die die Darstellung verstehen, einen umfassenden Zugriff auf ihre
Inhalte haben. Für
bestimmte anweisende Typen kann ein systemeigenes Format vielleicht
nicht existieren oder zutreffen, wobei in diesem Fall die umgebungsspezifische
PDU 424c und eventuell die extrahierten Attribute 424b leer
wären.
Eine „Empfehlung" ist eine Benachrichtigung,
die durch ein Element der Verwaltungsstation 100 (1) zu dem Zweck des ordnungsgemäßen Synchronhaltens
ihrer normalen Arbeiten emittiert wird. Als ein Beispiel kann die
Struktur dieser kanonischen Datenstruktur 424 durch eine Objektverwaltungsgruppen-Schnittstellendefinitionssprache
(OMG-IDL = Object Management Group Interface Definition Language)
spezifiziert werden (d. h. eine OMG IDLdefinierte Datenstruktur),
die eine handelsüblich
erhältliche
Sprache zum Beschreiben von Objektschnittstellen und Datenstrukturen
ist.
-
Die generischen Felder 424a sind
jene, die in allen kanonischen Datenstrukturbenachrichtigungen vorhanden
sind, eine umfassend verständliche
Semantik aufweisen und nützliche
Werte in der umfassenden Mehrzahl von Benachrichtigungsinstanzen aufweisen.
Anzahl, Position und Typ dieser Felder ist fest, und daher können dieselben
durch ein Element in der Umgebung für Filterfunktionen verwendet
werden. Es bestehen relativ wenige dieser generischen Felder 424a.
Bei einem bevorzugten Ausführungsbeispiel
umfassen die generischen Felder folgendes: Eine Quellbezeichnung 426a,
die eine Zeichenfolge ist (druckbar), die einen Namen für die Entität enthält, die
die Benachrichtigung ursprünglich
erzeugte; einen Umgebungstyp 426b, der die Art der Benachrichtigung
oder die Umgebung bezeichnet aus der dieselbe stammte (Beispiele
umfassen generisch, SNMP, DCE, SNA, NW, CMIP, etc.; dies müssen eindeutige Werte
sein und müssen
somit über
einen Registrierungsdienst gehandhabt oder inhärent eindeutig sein); eine
Entstehungszeit 426c, was die Zeit ist, zu der die Benachrichtigung
in das GNF-System 103 eingelegt wurde; eine Anzahl extrahierter
Attribute 426d, was die Anzahl extrahierter Attribute ist,
die folgen; eine PDU-Länge 426e,
die die Länge
der systemeigenen PDU 424c anzeigt, wie sie an diese Benachrichtigung
angehängt
ist (vorzugsweise zeigt eine Länge
von Null an, daß keine
systemeigene PDU vorhanden ist).
-
Die Anzahl von extrahierten Attributen 424b ist
in der kanonischen Datenstruktur 424 variabel. Die extrahierten
Attribute 424b weisen eine Sequenz von 4-fach-Attributen 427a–427d auf,
die einen Namen 428a, einen Typ 428b, eine Länge 428c
und einen Wert 428d enthalten. Da alle Elemente in dieser Sequenz
explizit sind, können
Operationen, wie z. B. Vergleiche zum Filtern an denselben vertrauensvoll durchgeführt werden
und ohne einen Bedarf zum Erweitern der Infrastruktur für die Einbringung
neuer Feldnamen. Die verfügbaren
Typen umfassen jene, die durch das OMG IDL definiert sind. Die Attribute 427a–427d können tatsächlich aus
einer umgebungsspezifischen PDU 424c extrahiert werden, wenn
dieselbe auf die kanonische Datenstruktur 424 (somit den
Namen) oder einfach einen variablen Abschnitt der Benachrichtigung
(in dem Fall von Empfehlungen) abgebildet wird.
-
Die PDU 424c ist im wesentlichen
eine Bitzeichenfolge, die durch das GNF-System 103 nicht interpretiert
wird, aber durch das GNF-System 103 gehalten wird. Die
PDU 424c weist üblicherweise
die ursprüngliche,
domänenspezifische
Ereignis-PDU auf, kann jedoch verwendet werden, um Informationen
weiterzuleiten, die durch das GNF-System 103 nicht interpretiert
werden, aber durch dasselbe weitergeleitet werden.
-
Vier Rollen, die durch die Komponenten
gespielt werden können,
die mit dem GNF 254 des GNF-Systems 103 interagieren,
werden nun bezugnehmend auf 5 beschrieben.
Im wesentlichen bestehen drei Rollen, die durch Komponenten gespielt
werden können,
die mit dem GNF-System 103 interagieren: Lieferant 532 (z.
B. die Netzwerküberwachungsvorrichtung 206),
Verbraucher 534 (Z. B. der Topologieverwalter 210,
die GUI 222, eine Anwendung 15), und der Konfigurierer 536 (z.
B. die Netzwerküberwachungsvorrichtung 206,
der Topologieverwalter 210, die GUI 222 und eine
Anwendung 105). Der Lieferant 532 bringt Verwaltungssignale
in den GNF 254 des GNF-Systems 103 ein, wie durch den
Referenzpfeil 538 angezeigt ist, wohingegen der Verbraucher 534 Verwaltungssignale
von dem GNF 254 empfängt,
wie durch den Referenzpfeil 539 angezeigt ist. Der GNF 254 empfängt Verwaltungssignale
von dem Lieferanten basierend auf einer Registrierung des Lieferanten
bei dem GNF 254, wie durch den Referenzpfeil 542 angezeigt
ist, und der GNF 254 überträgt Verwaltungssignale
zu dem Verbraucher, basierend auf der Registrierung des Verbrauchers 534 bei
dem GNF 254, wie durch den Referenzpfeil 544 angezeigt
ist. Im wesentlichen kann der Verbraucher 534 den Konfigurierer 536 darüber informieren,
woran er interessiert ist, und der Konfigurierer 536 kann
ein Filter für
denselben einrichten.
-
Der Konfigurierer 536 konfiguriert
den Lieferanten 532 und den GNF 254, wie durch
jeweilige Referenzpfeile 535 und 537 angezeigt
ist, und empfängt Konfigurationsinformationen
von dem Verbraucher 534, wie durch den Referenzpfeil 543 angezeigt
ist. Es wird darauf hingewiesen, daß in den Figuren Konfigurationszugriffe
durch schmale verlängerte
Streifen angezeigt sind. Der zuvor genannte Austausch von Konfigurationsinformationen
stellt eine Konsistenz zwischen Verwaltungssignalen sicher, die über den
GNF 254 eingebracht, weitergeleitet und empfangen werden.
Es sollte darauf hingewiesen werden, daß die vorangehenden Rollen
in ihrer Eigenschaft vollständig
logisch sind. Eine gegebene Anwendung oder ein Dienst kann tatsächlich eine,
zwei oder alle drei dieser Rollen spielen.
-
Bei der Initialisierung (oder möglicherweise später) fügt der Konfigurierer 536 einen
oder mehrere Filter 541 hinzu, die der GNF 254 beim
Verteilen spezifischer Verwaltungssignale verwenden soll. Der Konfigurierer 536 kann
dann Lieferanten 532 einrichten, um Verwaltungssignale
von Interesse in den GNF 254 einzubringen. Wenn die Übersetzung
von einem systemeigenen Format in die kanonische Datenstruktur 424 (4) durch den Lieferanten 532 durchgeführt wird,
dann kann der Konfigurierer 536 zusätzliche Variationen spezifizieren,
wie z. B. welche systemeigenen Attribute extrahiert werden sollen.
An diesem Punkt versteht der Lieferant 532 seine Mission
und kann sich bei dem GNF 254 so registrieren, daß der GNF 254 mit
dem Erzeugen von Verwaltungssignalen 539 beginnen kann.
-
Der Verbraucher 534 kann
auf ähnliche
Weise eine Konfiguration durch den Konfigurierer 536 erfordern,
wenn der Verbraucher 534 die Flexibilität behält, verschiedene Verwaltungssignale 539 dynamisch
zu verarbeiten. Bei diesem Szenario antwortet der Konfigurierer 536 auf
eine Filteranforderung von dem Verbraucher 534 durch Weiterleiten
der Antwort an den GNF 254, und die Antwort wird schließlich an den
Verbraucher 534 über
den GNF 254 kommuniziert. Sobald die Konfiguration eingerichtet
wurde, weiß der
Verbraucher 534, welche neuen Signale bei dem GNF 254 registriert
werden sollen, wie durch den Referenzpfeil 544 dargestellt
ist. Die Verbraucherregistrierung weist den Verbraucher einfach
zu den Ergebnissen eines Filters zu.
-
Somit kann der Treffpunkt (Leitung
oder Ereigniskanal) entweder durch den Verbraucher 534 eingerichtet
und an den Konfigurierer 536 weitergeleitet werden oder
durch den Konfigurierer 536 ansprechend auf eine Filteranforderung
von dem Verbraucher 534 eingerichtet und zurück zu dem
Verbraucher 534 kommuniziert werden. In jedem Fall ist dieser
Treffpunkt der Ort, an dem der GNF 254 Ereignisse plaziert,
die durch den zugeordneten Filter geleitet werden.
-
Nachdem die erforderliche Konfiguration stattgefunden
hat, kann der Lieferant 532 Verwaltungssignale 538 erzeugen,
die durch das GNF-System 103 zum Verbrauchen durch den
Verbraucher 534 verteilt werden, wie durch den Referenzpfeil 539 angezeigt
ist.
-
In Bezug auf die Implementierung
ist es wichtig zu wissen, daß diese
Rollen (d. h. Lieferant, Verbraucher und Konfigurierer) in ihrer
Eigenschaft logisch sind. Folglich kann die Rolle des Konfigurierers 536 in
der Praxis zwischen verschiedenen Komponenten aufgeteilt sein oder
sein Vorhandensein kann sogar nicht einmal offensichtlich sein,
wenn derselbe in den Lieferanten 532 oder den Verbraucher 534 eingebettet
ist. Ferner ist eine Anzahl der zuvor genannten Konfigurierungsschritte
insofern optional, daß dieselben
nicht durch alle Implementierungen oder Verwendungen des GNF-Systems 103 erforderlich
sind, insbesondere wenn ein bestimmter Lieferant 532 und
Verbraucher 534 statisch in Hinblick auf die Verwaltungssignale
sind, die dieselben handhaben.
-
Bezugnehmend auf 6 können
Lieferanten 532 als Ereignisübersetzer 552 implementiert sein,
die zweckgebunden sein können,
um Ereignisse zu verarbeiten, die sich auf die Protokolle SNMP, CMIP,
DCE, properietäre
Protokolle von SNA, NW etc. beziehen. Die Ereignisübersetzer 252 und
ihre entsprechenden Ereignisteilsysteme 302 sind mit dem
Netzwerk 118 verbunden und empfangen Ereignisse 602 von
dem Netzwerk 118. Ereignisse werden zu einer spezifischen
Adresse und einem Tor gesendet, die jedem Ereignisübersetzer 552 und
dem Ereignisteilsystem 302 entsprechen. Jedes Ereignisteilsystem 302 leitet
Ereignisse 604 zu seinem entsprechenden Ereignisübersetzer 252 weiter.
Ferner wandelt der Ereignisübersetzer 252 die
Ereignisdaten, d. h. die DPU, in die kanonische Datenstruktur 424 (4) um und überträgt die kanonische
Datenstruktur 424 zu dem GNF 254, wie durch den
Referenzpfeil 253 in 6 angezeigt
ist.
-
Die Ereignisübersetzer 252 werden
durch den Konfigurierer 536 (5)
konfiguriert, wie durch den Pfeil 606 in 6 angezeigt ist, in Hinblick darauf,
welche umgebungsspezifischen PDU-Attribute als extrahierte Attribute 227a–227d (4) in der kanonischen Datenstruktur 424 (4) herausgezogen werden
müssen.
Zusätzlich
dazu, wenn die Ereignisübersetzer 252 konfiguriert
sind, liegt es in ihrer Verantwortlichkeit, ihr zugeordnetes Ereignisteilsystem 302 zu
konfigurieren, zu filtern und die entsprechenden Ereignisse an den
Ereignisübersetzer 252 weiterzuleiten,
so daß der
Ereignisübersetzer 252 die ausgewählten Ereignisse
an den GNF 254 weiterleiten kann.
-
Optional kann der GNF 224 mit
einem Spurmechanismus 610 und einem Ereignisprotokollmechanismus 612 ausgerüstet sein.
Der Spurmechanismus 610 ist im Gegensatz zu dem Ereignisprotokollmechanismus 612 an
alle Verwaltungssignale anwendbar, die in den GNF 254 eingebracht
werden. Der Spurmechanismus 610 sowie der Ereignisprotokollmechanismus 612 folgt
dem Verbrauchermodell beim Liefern eines Verbrauchers, um alle Verwaltungssignale
zu empfangen und um eine kurze schriftliche Aufzeichnung von dessen
Auftreten zu erfassen. Der Spurmechanismus 610 kann als
eine Fehlerlösungs(Debugging)
und Stütz-Hilfe
dienen und kann zum Verwalten von Verwaltungsprozessen selbst entworfen
sein.
-
Der Ereignisprotokollmechanismus 612 wird verwendet,
um eine Aufzeichnung aller Ereignistyp-Verwaltungssignale zu erfassen,
die in den GNF 254 eingebracht wurden. Genauer gesagt bewahrt der
Ereignisprotokollmechanismus 612 die Daten der kanonischen
Datenstruktur 424 (4)
für Ereignisverwaltungssignale,
die vorangehend beschrieben wurden, so daß interessierte Anwendungen
auf die generischen Felder 424a, die extrahierten Attribute 424b und
die PDU 424c zugreifen können.
-
Ferner liefert der Ereignisprotokollmechanismus 612 eine
Basis für
eine Ereigniskorrelation und eine Alarmabbildung, wie hierin nachfolgend
beschrieben wird, und ferner liefert derselbe eine historische Aufzeichnung
der Ereignisse, die über
alle verwalteten Umgebungen aufgetreten sind. Der Ereignisprotokollmechanismus 612 sollte
natürlich
konfigurierbar sein, um nur die Ereignisse von Interesse zu protokollieren;
nicht alle Ereignisse, die in den GNF 254 weitergeleitet
werden, müssen
notwendigerweise in einer Datenspeicherung plaziert werden. Als
solches ist es wichtig darauf hinzuweisen, daß der Ereignisprotokollmechanismus 612 seinen
eigenen Verbraucher aufweist, der die Ereignisse empfängt und
dieselben in die Datenbank schreibt. Der einzige Unterschied zwischen
diesem Verbraucher und den Verbrauchern 534 ist, daß der Protokollverbraucher
direkt in den GNF 254 eingebaut ist, für ein verbessertes Verhalten.
-
Sowohl der Spurmechanismus 610 als
auch der Ereignisprotokollmechanismus 612 sollten mit konfigurierbaren
Schnittstellen versehen sein, um eine Speicherungstaktik zu spezifizieren,
so daß ein verfügbarer Speicher
nicht überläuft und
Einträge
gemäß einem
absichtlich ausgewählten
Verfahren gelöscht
werden.
-
Das GNF-System 103 kann
in Verbindung mit einem Alarmteilsystem 702 implementiert
sein, wie in 7 dargestellt
ist. Im wesentlichen verwendet das Alarmteilsystem 702 das
GNF-System 103 bei dessen Verwaltung von Alarmen. In dem
Kontext dieses Dokuments ist ein „Alarm" eine aufgezeichnete Interpretation,
mit einem Zustand, von einem oder mehreren Ereignissen. Das Alarmteilsystem 702 weist
die Komponenten auf, die zum Definieren, Aktualisieren, Speichern,
Präsentieren
und Erteilen von Zugriff zu Alarmen verwendet werden. Bei der Architektur
weist das Alarmteilsystem 702 einen Alarmdienst 704,
einen oder mehrere Korrelierer 706, und eine Alarmkonsole 708 auf.
Der Alarmdienst 704 liefert Alarmspeicherungsdienst 710,
basierend auf Daten, die von den Korrelierern 706 und der
Konsole 708 empfangen wurden, wie durch die jeweiligen
Referenzpfeile 712, 714 angezeigt ist. Die Korrelierer 706 bestimmen,
wann Alarme erzeugt werden. Schließlich weist die Konsole 708 Benutzerschnittstellentools
zum Betrachten und Manipulieren von Alarmen auf.
-
Die Eingabe 716 in die Korrelierer 706 kann durch
eine Verwaltungsanwendung 105 (2) geliefert werden, die auf das Verwaltungssignal
hört oder
die durch eine andere relevante oder geeignete Eingabe geliefert
wird. Der GNF 254 ermöglicht
die Implementierung der Korrelierer 706. Die Korrelierer 706 überwachen
den aktuellen Zustand der verwalteten Umgebung gegen Alarmstatus
oder ankommende Benachrichtigungen, um zu bestimmen, wann die Alarmstatus
wahr sind. Wenn diese Zustände
wahr werden, erzeugen die Korrelierer 706 neue Alarme durch Interagieren
mit dem Alarmdienst 704.
-
Der Alarmdienst 704 weist
zwei primäre Funktionen
auf: Liefern einer Schnittstelle, die Zugriff zu Alarmaufzeichnungen
in der Datenspeicherung erteilt und Erzeugen von Verwaltungssignalen,
die Alarmstatusänderungen
an interessierte Anwendungen 105 kommuniziert (2). Wenn die Korrelierer 706 Alarmzustandsstatusänderungen
erfassen, lösen
die Korrelierer 706 den Alarmdienst 704 aus, um den
entsprechenden Alarm zu erzeugen oder ihre Statuswerte zu aktualisieren.
Auf ähnliche
Weise kann eine Anwendung 105 den Alarmdienst 704 verwenden,
um einen Alarm wiederzugewinnen oder angemessene Änderungen
an den Alarmen durchzuführen.
Bei dem bevorzugten Ausführungsbeispiel umfassen
die Daten, die von einer Alarmaufzeichnung verfügbar sind, folgendes: Wenn
der Alarm wahr wird, wenn der Alarm falsch wurde, dessen Status,
eine Referenz auf die Definition von dessen Alarmzustand und eine
Liste der bestimmten Ereignisidentifikationen, die den Alarmzustand
wahr machen.
-
Wenn die Alarmstatusänderungen
auftreten, erzeugt der Alarmdienst 704 Verwaltungssignale 718 für den GNF 254,
um registrierte Anwendungen 105 über die Änderungen zu benachrichtigen.
Diese Alarmstatus umfassen z. B., aber nicht ausschließlich, Alarmerzeugung
(oder Gültigkeit),
Alarmbestätigung,
Alarmlöschung,
Alarmungültigkeit
(oder nicht mehr wahr), Alarmeskalation, etc.
-
Die Konsole 708 umfaßt verschiedene
Tools zum Warnen des Benutzers über
Alarmstatusänderungen,
und um es dem Benutzer zu ermöglichen, Alarme
zu betrachten und zu manipulieren. Beispiele umfassen eine Alarmüberwachungsvorrichtung
und einen Aufzeichnungsbrowser, eine Ereignisüberwachungs-Vorrichtung und einen -Browser, ein
Schwierigkeiten-Ticket-System
und einen Alarmkonfigurierer, der zum Definieren von Alarmstatus
und zum Registrieren von Benutzerinteresse an bestimmten Alarmen
verwendet wird. Es wird darauf hingewiesen, daß eine Ereignisüberwachungs-Vorrichtung
und ein – Browser
ein einstückiges
Teil der Alarmkonsole 708 sein kann, da primär Ereignisse
vorliegen, die Alarmstatus bilden.
-
Ein Beispiel eines Alarms, um die
Operation des Alarmteilsystems 702 zu zeigen, ist wie folgt.
Es sei angenommen, daß dem
Speicher 124 (1)
in der Form eines Festplattenlaufwerks der Speicherspeicherungsraum
ausgeht. Ein Korrelierer 706 könnte zweckgebunden sein für das Überwachen von
Ereignissen und das Bestimmen, wann der Plattenspeicher 124 sich
an seine volle Kapazität
annähert.
Wenn der vorangehende Korrelierer 706 bestimmt, daß der Plattenspeicher 124 sich
an seine volle Kapazität
annähert,
gibt der Korrelierer 706 eine Platte-Niedrig-Benachrichtigung 712 an
den Alarmdienst 704 aus, der wiederum eine Platte-Niedrig-Benachrichtigung 718 an
den GNF 254 ausgibt. Der GNF 2354 gibt dann die
Platte-Niedrig-Benachrichtigung 720 an einen Registrierte-Aktion-Server 722 aus,
der die Benachrichtigung verbraucht und ein Skript ausführt, das
Aktivitäten
handhabt, um mehr Raum in dem Plattenspeicher 124 zu erhalten.
Es bestehen zahlreiche andere Beispiele von Alarmen, und das zuvor
genannte Beispiel sollte nicht einschränkend sein.
-
Beim Zusammenfassen der detaillierten
Beschreibung sollte darauf hingewiesen werden, daß es für Fachleute
auf dem Gebiet offensichtlich ist, daß viele Variationen und Modifikationen
an dem bevorzugten Ausführungsbeispiel
durchgeführt
werden können,
ohne wesentlich von dem Schutzbereich der vorliegenden Erfindung
abzuweisen, wie es in den nachfolgenden Ansprüchen erläutert ist. Ferner sollen in
den hierin nachfolgenden Ansprüchen
die Strukturen, Materialien, Handlungen und Äquivalente aller Einrichtung-Plus-Funktion- oder Schritt-Plus-Funktion-Elemente
Strukturen, Materialien oder Handlungen zum Ausführen der spezifizierten Funktionen
umfassen.