-
Bereich der Erfindung
-
Die
vorliegende Erfindung bezieht sich auf Kommunikationsnetzwerke,
und insbesondere auf ein Netzwerk-Managementsystem (NMS) zur Verarbeitung
von Multi-Server-Änderungsanfragen.
-
Hintergrund der Erfindung
-
Moderne
Netzwerke bestehen aus heterogenen Netzwerkgeräten, den physischen Hardware-Verbindungen
zwischen den Netzwerkgeräten und
aus der Software, die zum Senden, Empfangen und zur Vermittlung/Weiterleitung
von Daten verwendet wird. Die Konfiguration des Kommunikationsnetzwerks
verändert
sich, wenn neue Geräte
und Dienste hinzugefügt,
vorhandene Geräte
verlagert und veraltete Geräte
entfernt werden.
-
Es
ist bekannt, das Netzwerk mit einem Netzwerk-Managementsystem (NMS) auszustatten, um
das Betriebsverhalten des Netzwerks als Ganzes zu überwachen
und die Funktion der einzelnen Netzwerkgeräte sowie den Datenverkehrsfluss
zu steuern. Das Ziel der Überwachung
wird durch die Erfassung der Daten für die Gerätespezifikationen, der Daten
zur Geräte-Konnektivität, der Informationen über Kapazität und relativen
Einsatz von Kommunikationsverbindungen zwischen den Geräten, über Umfang
und Position von Störungen
sowie über
Probleme im Netzwerk, wie beispielsweise Verkehrsüberlastung
und Datenverlust etc. erreicht. Das NMS sammelt diese Daten in einer
Master-Datenbank, die eine zentrale Übersicht über das Netzwerk bietet.
-
Auf
Steuerungsseite werden Netzwerk-Managementsysteme eingesetzt, um
die Netzwerkgeräte
in Übereinstimmung
mit dem Plan für
den Netzwerkbetrieb zu konfigurieren und die Funktion der Netzwerkgeräte durch
Abgleich von Ereignissen und Bedingungen, die Netzwerkelemente und
Unternetze umfassen, zu gewährleisten.
-
Angeregt
durch die Fortschritte im Bereich der Technik und der Architektur
für Datenkommunikation
und den Bedarf, schnell und kostengünstig äußerst skalierbare neue Dienste
zu entwickeln und einzusetzen, entwickeln sich Netzwerk-Managementsysteme
schnell zu stark verteilten Multi-Vendor-Systemen mit offenen Schnittstellen
und Anwendungen, die von den zugrunde liegenden Übertragungstechniken unabhängig sind.
Moderne Netzwerk-Manager pflegen in der Master-Datenbank eine vollständige und
aktuelle Darstellung des Netzwerks und der eingesetzten Techniken
und sind mit einer modernen Netzwerk-Nutzerschnittstelle wie z.
B. GUI (Graphical User Interface) ausgerüstet, die dem Nutzer die Möglichkeit
bietet, diese Informationen anzuzeigen und mit dem Netzwerk zu interagieren.
-
Damit
Netzwerk-Managementsysteme effizient sind, ist es wichtig, dass
sie über
exakte Informationen zur Funktion der Netzwerkgeräte verfügen. Wenn
das NMS eingesetzt wurde, um ein Netzwerkgerät zu konfigurieren, kann man
im Allgemeinen daraus schließen,
dass die Betriebskonfiguration des Geräts aus dem Datenstrom an Konfigurationsbefehlen
resultiert, die dem Gerät
vom Netzwerk-Managementsystem übermittelt
wurden. Zu diesem Zweck bestätigt
das Gerät
dem NMS, wenn eine Änderung tatsächlich umgesetzt
wurde, um zu gewährleisten, dass
die Geräteinformationen
in der Netzknoten-Datenbank und in der Netzwerkmanagement-Datenbank
exakt und synchronisiert sind.
-
Daher
besteht die größte Herausforderung für das NMS
in dem großen
Volumen an Meldungen und der Anforderung, die Meldungen nacheinander zu
verarbeiten. Es ist außerdem
heute allgemein üblich,
dass das Netzwerk-Managementsystem große Netzwerke mit über 1.000
Netzknoten unterstützt (wie
z. B. Telemar, SBC, Telus etc.). Da das Netzwerk durch die Ansammlung
von Teilnetzen mit verschiedenen Technologien und Konfigurationen
wächst, und
sich die Netzwerkgeräte
weiterentwickeln, um komplexere Aufgaben auszuführen, steigt die Auslastung
von Netzwerk-Managementsystemen zur Verarbeitung von Netzwerk-Änderungsmitteilungen und
zur Aufnahme dieser Änderungen
in die Master-Datenbank und die Netzknoten-Datenbanken dementsprechend.
Es ist äußerst wichtig,
dass die Datenbankänderungen
in der Reihenfolge verarbeitet werden, in der sie empfangen werden,
da die NMS-Datenbank andernfalls den Zustand der Netzknoten nicht
exakt widerspiegelt und das NMS daher seine Fähigkeit zur Netzwerkverwaltung
verlieren würde.
-
Es
besteht zunehmend Bedarf an Lösungen, die
die Leistungen zur Ereignisverarbeitung durch Anwendungen zur Meldungs-/Ereignisverarbeitung verbessern,
um das NMS in die Lage zu versetzen, dynamisch auf die wechselnden
Auslastungsbedingungen zu reagieren und unabhängig von der Auslastung optimale
Leistungen und Verarbeitungskapazitäten zu bieten.
-
Die
aktuell verfügbaren
Systeme zur Ereignisverarbeitung führen eine sequenzielle Verarbeitung
der Ereignisse und/oder Meldungen durch. Im
US-Patent 6.493.756 (O'Brien et al.) „System
and method for dynamically sensing an asynchronous network event
within a modular framework for network event processing", ausgestellt am
10. Dezember 2002 an Networks Associates Inc., wird eine Einzel-Thread-Architektur
beschrieben, in der eine Warteschlange mit Netzwerkereignissen sequenziell
verarbeitet wird. Die Meldungen über
Netzwerkereignisse werden von einem Listener-Thread empfangen und
in eine Warteschleife eingestellt. Jede empfangene Meldung wird über einen
Handler-Thread aus der Warteschleife entfernt. Entsprechend jeder
empfangenen Meldung wird ein Action Set-Mapping für einen
Generatorprozess abgerufen, in dem ein Action Set erstellt wird.
Das generierte Action Set wird in eine Ereignis-Warteschlange eingestellt,
wo die sequenzielle Verarbeitung durch Aufruf eines Prozessverfahrens
für jedes
Set erfolgt.
-
Es
gibt derzeit ebenfalls eine Entwicklung in Richtung von Architekturen
mit (parallelen) Mehrfach-Threads, um zu versuchen die Anforderungen für ein hohes
Verarbeitungsvolumen zu erfüllen.
Obwohl die parallele Verarbeitung die Anforderung zur Verarbeitung
einer großen
Anzahl an Meldungen erfüllt,
eignet sie sich doch nicht für
die sequenzielle Verarbeitung von Meldungen. Da die Sequenzialisierung
der Meldungen auf Netzknotenebene jedoch beibehalten werden muss,
weil dies das kennzeichnende Merkmal für die Bildung einer Warteschlange in
einer beliebigen Architektur zur Meldungsverarbeitung darstellt,
gibt es nur wenige und nicht zufrieden stellende Behelfslösungen.
-
Im
Patent
US2003231647 wird
ein System zur Optimierung der Antwortzeit für Ereignisse oder deren Abbildungen
beschrieben, die in eine Warteschlange eingestellt wurden. Es verfügt über einen ersten
Server, der Zugriff auf die Warteschlange hat, eine Software-Anwendung, die auf
dem ersten Server läuft,
und einen zweiten Server, der über
den ersten Server zugänglich
ist, wobei der zweite Server Regeln zur Optimierung beinhaltet.
In einer bevorzugten Ausführungsvariante
greift die Software-Anwendung zumindest in regelmäßigen Abständen auf die
Warteschlange zu, analysiert einige der Ereignisse oder Token in
der Warteschlange und vergleicht die Analyseergebnisse mit den Regeln,
die auf dem zweiten Server zur Verfügung stehen, um ein Maß für die Verarbeitungszeit
jedes analysierten Ereignisses festzulegen; wenn das festgelegte
Maß für eines oder
mehrere der analysierten Ereignisse ausreichend niedrig ist, werden
die entsprechenden Ereignisse modifiziert, um eine höhere Prioritätsstufe
widerzuspiegeln als ursprünglich
zugeordnet, wodurch eine schnellere Verarbeitung der Ereignisse
möglich ist,
die aufgrund des Abgleichs von Ereignissen mit der Warteschlangen-Systemauslastung
freigegeben wurden.
-
Im
Patent
US6584502 wird
ein Feedback-basiertes, adaptives Netzwerk beschrieben, wobei mindestens
ein Teil der Netzwerkelemente Betriebsinformationen über die
Netzwerkbedingungen an einen zentralen Datenspeicher übermittelt.
Die Informationen, die an den Datenspeicher übermittelt werden, werden von
einer Policy-Maschine
analysiert, die eine Vielzahl von anwendungsspezifischen Plugin-Policies
zur Analyse ausgewählter
Informationen aus dem Datenspeicher und zur Berechnung aktualsierter
Steuerungsinformationen, basierend auf der Analyse dieser Informationen
umfasst. Die aktualisierten Steuerungsinformationen werden an ausgewählte Netzwerkelemente
zurückübertragen,
um die Funktion der ausgewählten
Elemente zu steuern. Die dynamische und automatische Feedback-Steuerung
der Netzwerkelemente wird gewährleistet,
damit sich das Netzwerk an veränderte
Bedingungen anpassen kann. Ereignisse in Bezug auf veränderte Bedingungen
im Netzwerk können
mit einem Ereignis-Mitteilungsdienst an ausgewählte Elemente im Netzwerk übertragen
werden. Falls festgelegt wurde, dass ein bestimmtes Merkmal des
Netzwerks nicht den Standards entspricht, die für dieses Merkmal erstellt wurden,
kann die Policy, die dieses bestimmte Merkmal steuert, automatisch
und dynamisch geändert
werden, um die Netzwerkleistungen entsprechend zu beeinflussen.
-
Zusammenfassung der Erfindung
-
Es
ist ein Gegenstand der vorliegenden Erfindung, ein Verfahren und
ein System zur schnellen Verarbeitung von Netzwerk-Änderungsmitteilungen zu bieten,
das die Nachteile von bestehenden Verfahren und Systemen ganz oder
teilweise beseitigt.
-
Die
vorliegende Erfindung bezieht sich auf ein System zur Ereignisverarbeitung
(EPS) für
ein Kommunikationsnetzwerk mit einer Master-Datenbank und einer
Vielzahl lokaler Datenbanken in den jeweiligen Netzknoten. Das System
zur Ereignisverarbeitung umfasst: einen Client zur Meldungsverarbeitung
zum sequenziellen Einstellen einer Vielzahl von Ereignissen in eine
Vielzahl von Ereignis-Warteschlangen,
d. h. eine Ereignis-Warteschlange pro Knoten; eine Vielzahl von
Servern zur Meldungsverarbeitung, d. h. einen Server zur Bearbeitung
eines Ereignisses aus einer bestimmten Ereignis-Warteschlange in Verbindung mit einem
bestimmten Knoten zu einem bestimmten Zeitpunkt, wobei eine bestimmte Änderungsanfrage
für das
bestimmte Ereignis erstellt und diese bestimmte Änderungsanfrage an die spezifizierte
Datenbank übermittelt
wird; und einen Verteiler zur Auswahl eines Servers auf der Basis
der Verfügbarkeit
der Server zur Meldungsverarbeitung zu dem bestimmten Zeitpunkt,
so dass kein Server aus der Vielzahl von Servern zur Meldungsverarbeitung
zu dem bestimmten Zeitpunkt ein anderes Ereignis aus der bestimmten
Ereignis-Warteschlange verarbeitet.
-
Gemäß einem
anderen Aspekt bezieht sich die Erfindung auf ein Verfahren zur
Verarbeitung einer Vielzahl von Netzwerk- Ereignissen in einem Kommunikationsnetzwerk
mit einer Master-Datenbank
und einer Vielzahl lokaler Datenbanken in den jeweiligen Netzknoten,
d. h. ein Verfahren zur Verarbeitung einer Vielzahl von Netzwerk-Ereignissen. Das
Verfahren umfasst die folgenden Schritte: a) Pflege einer Vielzahl
von Ereignis-Warteschlangen in einem Client zur Meldungsverarbeitung,
wobei ein bestimmtes Ereignis einem bestimmten Netzknoten zugeordnet
ist; und b) Verteilung der Ereignisse von den einzelnen Ereignis-Warteschlangen
an eine Vielzahl von Servern zur Meldungsverarbeitung; und c) gleichzeitige
Verarbeitung der Ereignisse in den Servern zur Meldungsverarbeitung,
d. h. jeweils ein Server zur Verarbeitung eines bestimmten Ereignisses aus
der bestimmten Ereignis-Warteschlange, während kein anderer Server aus
der Vielzahl von Servern zur Meldungsverarbeitung zu diesem Zeitpunkt ein
anderes Ereignis aus der bestimmten Ereignis-Warteschlange verarbeitet,
zu dem ein Server das Ereignis verarbeitet.
-
Vorteilhafterweise
ermöglicht
die Erfindung bessere Leistungen des Netzwerk-Managementsystems
in Bezug auf die Ereignis-Verarbeitung,
da diese Architektur mit mehreren Servern und einem Client die Meldungen
schneller verarbeiten kann, während
die Meldungssequenzierung aufrecht erhalten bleibt.
-
Zudem
ist das System gemäß der Erfindung dynamisch
konfigurierbar, wodurch es in der Lage ist, sich an Änderungen
des Meldungsverkehrsvolumens anzupassen.
-
Kurze Beschreibung der Zeichnungen
-
Die
vorgenannten sowie andere Gegenstände, Merkmale und Vorteile
der Erfindung werden aus der folgenden, detaillierten Beschreibung
der bevorzugten Ausführungsvarianten
deutlich, die in Bezug auf die beiliegenden Zeichnungen erfolgt,
wobei:
-
1 eine Übersicht über ein
aktuelles Ereignis-Mitteilungssystem
(nach dem derzeitigen Stand der Technik) ist;
-
2 eine Übersicht über eine
Ausführungsvariante
des Ereignis-Mitteilungssystems gemäß der Erfindung ist;
-
3A die
Abfolge bei der Verarbeitung eines Netzwerk-Ereignisses darstellt;
-
3B die
Abfolge bei der Verarbeitung eines Netzwerkelement-Ereignisses (NE)
darstellt;
-
4A die
Abfolge bei der Verarbeitung eines Netzwerkelement-Ereignisses (NE)
darstellt, die die Auslesung einer Netzsteuerungs-Schnittstelle (NCI)
erfordert; und
-
4B eine
alternative zu der in 4A dargestellten Abfolge darstellt.
-
Detaillierte Beschreibung
-
Zum
besseren Verständnis
der Vorteile der durch die vorliegende Erfindung gebotenen Lösung erfolgt
nachstehend die Beschreibung eines aktuellen Ereignis-Mitteilungssystems. 1 stellt
ein Kommunikationsnetzwerk 1 dar, das mit einem Netzwerk-Managementsystem
(NMS) ausgerüstet
ist, das das Betriebsverhalten des Netzwerks als Ganzes überwacht
und den Betrieb von Netzwerkelementen (NE) und Verkehrsfluss steuert.
In 1 sind nur die Teile des NMS dargestellt, die
für die
Erfindung relevant sind, nämlich
das System zur Ereignisverarbeitung (EPS) 5, eine Master-Datenbank 10 und
ein NM-Prozessblock 3.
-
Somit
bietet das NMS eine zentrale Übersicht über das
von ihm gesteuerte Netzwerk, die in der Master-Datenbank (im Folgenden
auch als „NM-Datenbank" bezeichnet) 10 gespeichert
und gepflegt wird. Die NM-Prozesseinheit 3 umfasst sämtliche
Prozesse im NMS, die für
die Erfindung dadurch relevant sind, dass sie Ereignisse auslösen, die
die Master-Datenbank 10 aktualisieren. Solche NM-Prozesse sind beispielsweise
die Nutzerschnittstelle (z. B. eine GUI), ein Diagnosemodul, ein
Bandbreiten-Zuordnungsprogramm (BWA) etc. Die vorliegende Spezifikation
verwendet für
Ereignisse, die von Prozessen 3 ausgelöst werden den Begriff „Netzwerk-Ereignis".
-
Bei
dem Netzwerk 1 handelt es sich in diesem Beispiel um ein
großes
Netzwerk, dargestellt durch eine Vielzahl von Netzwerkelementen
NE1, NE2, ...NEj, ...NEn mit den zugeordneten Datenbanken 7.
Es ist darauf hinzuweisen, dass sich der Begriff NE hier auf die
NEs bezieht, die von dem NMS über
eine Netzsteuerungs-Schnittstelle
(NCI) 6 verwaltet werden, die in 1 durch
eine doppelte Linie dargestellt ist. Bei dieser Schnittstelle handelt
es sich um ein Anwendungsebenen-Protokoll, das zur Netzwerkverwaltung
verwendet wird. Die NEs werden alternativ dazu auch als „Netzknoten" bezeichnet.
-
Wenn
ein NM-Prozess 3 ein Netzwerk-Ereignis generiert, wird
die Master-Datenbank 10 entsprechend der vom jeweiligen
Prozess 3 angeforderten Änderung modifiziert. Um die
entsprechende Änderung
in den lokalen Datenbanken der betroffenen NE(s) umzusetzen, erfasst
ein Änderungs-Mitteilungsprozess
(CHN) 2, der vom System zur Änderungsverarbeitung 5 ausgeführt wird,
die von den NM-Prozessen 3 generierten Netzwerkereignisse und überträgt die entsprechenden
Meldungen an einen Meldungsprozessor 4. Der Meldungsprozessor 4 empfängt die
Meldungen und übermittelt
sie sequenziell und in der Reihenfolge der Meldungsankunft an die
jeweiligen Netzwerkelemente. Wie oben erläutert, ist es von entscheidender
Bedeutung, dass die Mitteilungen über Netzwerk-Ereignisse und
die Änderungsanfragen
in der Reihenfolge verarbeitet werden, in der sie vom Meldungsprozessor 4 empfangen werden,
da die betroffenen Datenbanken den Zustand der Netzknoten andernfalls
nicht exakt wiedergeben würden.
-
Nimmt
beispielsweise ein Bediener aufgrund einer Anfrage von der GUI eine Änderung
an den Netzwerkelementen NE1, NE2 und NEj vor, die in den Prozessen
der NM-Prozesseinheit 3 enthalten ist, wird die Änderung
sofort in der Datenbank 10 wiedergegeben, und gleichzeitig
empfängt
das EPS 5 das Netzwerk-Ereignis und überträgt die Netzwerk-Änderung
mit Hilfe des Meldungsprozessors 4 über das Netzwerk 1 an
NE1, NE2 und NEj. Infolgedessen implementieren die betroffenen Netzwerkelemente
NE1, NE2 und NEj die Änderung
in den jeweiligen Datenbanken 7-1, 7-2 und 7-j.
-
Alle
Ereignisse, die im Netzwerk stattfinden (z. B. Alarmmeldungen oder
Hinzufügen,
Upgrade, Löschen
von NEs) müssen
auch in der Master-Datenbank 10 gespeichert werden, um
die Master-Datenbank
mit den Datenbanken der NEs zu synchronisieren, die das Ereignis
generiert haben. In der vorliegenden Spezifikation wird für Ereignisse
in einem Netzknoten, die Änderungen
in der jeweiligen lokalen Datenbank bewirken, der Begriff „NE-Ereignisse" verwendet. In diesem
Fall empfängt
der Meldungsprozessor 4 eine NE-Ereignismitteilung von dem entsprechenden
Netzknoten und stellt eine Verbindung zur Datenbank 10 her,
um eine Datenbankänderung im
Hinblick auf die Änderung
anzufordern. Wie oben werden die Änderungen sequenziell verarbeitet,
so dass die Master-Datenbank 10 Konfiguration und Status
des aktuellen Netzwerks immer korrekt widerspiegelt. Der Meldungsprozessor 4 übermittelt
die Netzwerk-Ereignismeldung
ebenfalls an CHN 2 zur Übertragung
des Ereignisses an die Prozesse 3, die davon betroffen
sind.
-
Wenn
NE1 beispielsweise ein Hardware-Update empfangen hat, wird dieses
Netzwerk-Ereignis über
die NCI-Schnittstelle 6 an den Meldungsprozessor 4 übertragen,
der die Master-Datenbank 10 ändert, um die neue Konfiguration
von NE1 widerzuspiegeln. Der Meldungsprozessor 4 informiert
zudem CHN 2 über
das Ereignis, und CHN 2 übermittelt diese Information
an die betroffenen Prozesse, wie z. B. an das Bandbreiten-Zuordnungsprogramm,
wenn das Hardware-Update die Bandbreite von NE1 beeinflusst, sowie
gegebenenfalls an die GUI, um den Bediener über die Änderung zu informieren.
-
Das
Problem bei dem Ansatz aus 1 besteht
darin, dass der Meldungsprozessor 4 einen einzelnen Prozess
darstellt, der sowohl für
die Bearbeitung aller Netzwerk-Ereignisse, die von den Netzwerkelementen
an das NMS übertragen
werden, als auch für
die Übermittlung
aller Änderungsanfragen von
den NM-Prozessen 3 an die Netzwerkelemente verantwortlich
ist. Da von dem Prozessor 4 jeweils nur ein Ereignis gleichzeitig
verarbeitet werden kann, kann die Anzahl an wartenden Ereignissen
bei einem großen
Netzwerk auch relativ groß werden.
Da NEs, die über
die Netzsteuerungs-Schnittstelle 6 miteinander
verbunden sind, in der Regel mit einem Resend-Timer von 15 Sekunden
ausgestattet sind, wird ein Ereignis erneut übertragen, wenn innerhalb dieses
Zeitlimits keine Antwort (Bestätigung,
dass das Ereignis erfolgreich verarbeitet wurde) empfangen wurde.
Daher ist diese Lösung
nicht für
die Anzahl an Ereignissen geeignet, die von großen Kundennetzwerken generiert
werden.
-
Um
die Geschwindigkeit der Ereignisbearbeitung des MP 4 zu
verbessern, schlägt
die vorliegende Erfindung ein System zur Ereignisverarbeitung 50 vor,
das auf einer parallelen Ereignis-Verarbeitung basiert, die Reihenfolge
der Ereignisse jedoch weiterhin berücksichtigt, wie in 2 dargestellt.
Das neue System zur Meldungsverarbeitung verfügt über eine Client-Server-Architektur, und
umfasst genauer gesagt einen Client zur Meldungsverarbeitung (MPC) 20 sowie
mehrere Server zur Meldungsverarbeitung (MPS) 25. MPC 20 steuert
die Sequenzierung der Meldungsverarbeitung, während die MPCs 25 mit
Hilfe einer gemeinsamen Objektbibliothek 27, die spezifische
Verarbeitungsanweisungen für
jeden von den Servern 25 verarbeiteten Meldungstyp enthält, die
eigentliche Meldungsverarbeitung durchführen.
-
Der
Client zur Meldungsverarbeitung (auch als „Client-Prozess" bezeichnet) 20 ist der Eingangspunkt
für alle
Ereignisse innerhalb des Netzwerks 1, die über die
NCI-Schnittstelle 6 empfangen werden, und für alle Ereignisse,
die die Master-Datenbank 10 betreffen. Die Hauptaufgabe
des MPC 20 besteht darin, auf Änderungs-Ereignisse von CHN
(Änderungsmitteilungen) 26 oder
von den Netzwerkelementen NE1–NEn
zu warten. Die Ereignisse werden in eine Warteschlange – eine Warteschlange
pro Knoten – eingestellt,
so dass Ereignisse für
oder von verschiedenen NEs parallel verarbeitet werden können. Sobald
die Warteschlangen eingerichtet wurden, werden die Meldungen an
einen Verteiler 21 übertragen, der
sie zur zeitbasierten Verarbeitung an einen freien Server verteilt.
-
Die
Server zur Meldungsverarbeitung 25 (in der vorliegenden
Beschreibung auch als Server-Prozesse bezeichnet) sind für die umfangreiche
Verarbeitung der Ereignisse verantwortlich, die sie von MPC 20 über den
Verteiler 21 empfangen; die Verwaltung der Server erfolgt
komplett durch den Verteiler. Jeder Server 25 aktualisiert
entweder die NM-Datenbank 10 als Reaktion auf ein Netzwerk-Ereignis oder
die NE-Datenbanken 7 als Reaktion auf ein Netzwerk-Ereignis.
Die NE-Ereignisse werden auf der Basis ihrer Klasse und Position
in der Master-Parameterliste (MPL), die in dem Paket zur Beschreibung
des Ereignisses enthalten ist, an Handler-Funktionen der jeweiligen MPS verteilt.
(MPL ist eine Liste aller Parameter, die in allen Knoten adressierbar sind,
die durch Klasse und Positionsnummer identifiziert werden können). Eine
höhere
Anzahl an MPS 25 ermöglicht
die parallele Verarbeitung von mehr Ereignissen. Die Anzahl an Servern
ist dynamisch konfigurierbar, um Änderungen in der Meldungsverarbeitungs-Auslastung
berücksichtigen
zu können.
-
Genauer
gesagt hat ein MPS 25 drei Hauptfunktionen. Die erste Funktion
besteht darin, die eingehenden Netzwerk-Ereignisse zu übersetzen
und die entsprechenden Felder in der Master-Datenbank 10 zu
aktualisieren. Die zweite Funktion besteht darin, ein Netzwerk-Ereignis in ein NCI-Ereignis
zu übersetzen
und es über
NCI (Netzsteuerungs-Schnittstelle) 6 an die entsprechende
NE zu übertragen.
Die dritte Aufgabe besteht darin, zusätzliche Informationen aus einem
Netzwerkelement abzurufen, wenn die Übersetzungsroutine eines eingehenden
Netzwerk-Ereignisses weitere Informationen erfordert.
-
Diese
beiden Prozesse 20, 25 kommunizieren mit Hilfe
des Verteilers 21 miteinander, der aus den Server-Instanzen
einen verfügbaren
Server auswählt
und die Meldungen zur Verarbeitung an die Server verteilt. Anschließend sendet
der Verteiler eine Meldungs-Identifikation an den Client-Prozess 20,
um die Meldung zu verfolgen. Im Fall von Netzwerkelementen können weiteren
Daten von den NEs erforderlich sein; in diesem Fall ruft der entsprechende
Server die zusätzlichen
Daten nach Bedarf direkt von dem entsprechenden Knoten ab.
-
Wie
oben erläutert,
ist der Client-Prozess 20 für die Erfassung aller NEs und
Netzwerk-Ereignisse verantwortlich. Der Client-Prozess 20 pflegt
vorzugsweise drei Warteschlangen, um die Sequenzierung der Meldungsverarbeitung
zu steuern, die von den Server-Prozessen 25 ausgeführt wird.
-
Eine
hierarchische Ereignis-Warteschlange 22 wird vom Knoten
mit Hilfe einer Knotenkennung (Knoten-ID) eingerichtet, so dass
eine Warteschlange für
jeden Knoten vorhanden ist, für
den Meldungen zur Verarbeitung anstehen. Innerhalb jeder Knoten-Warteschlange gibt
es Ereignis-Mitteilungen in Bezug auf diesen Knoten, die mit einem
Zeitstempel versehen werden, um die Verarbeitung in der Reihenfolge
zu gewährleisten,
in der die Mitteilungen empfangen wurden. Die Reihenfolge der Ereignis-Verarbeitung wird
durch die Tatsache gewährleistet,
dass der Client 20 zu einem gegebenen Zeitpunkt nur ein Ereignis
pro Knoten an den Verteiler 21 senden kann.
-
Der
Client zur Meldungsverarbeitung 20 pflegt außerdem eine
Warteschlange für
anstehende Ereignisse 23, in der das aktuelle Ereignis,
das für
einen Knoten verarbeitet wird, verfolgt wird. Dies geschieht anhand
einer Meldungskennung (Meldungs-ID), die jeder Meldung zugeordnet
wird, und die vom Verteiler 21 zurückgesandt wird, wenn eine Meldung
an einen Server-Prozess 25 gesandt wird. Es gibt eine Obergrenze
für die
maximale Anzahl an Knoten, deren Ereignisse gleichzeitig verarbeitet werden
können.
Diese Obergrenze, die als Höchstgrenze
für anstehende
Ereignisse bezeichnet wird, hängt
von der Anzahl an Server-Prozessen ab, die auf der Basis der Auslastung
der Meldungsverarbeitung dynamisch konfigurierbar ist.
-
Des
Weiteren wird eine Überfluss-Warteschlange 24 eingerichtet,
damit MPC 20 weiterhin Ereignisse verarbeiten kann, auch
wenn zu viele Ereignisse anstehen. Die Überfluss-Warteschlange 24 verfolgt
die Sequenz der Knoten, die bedient werden, nachdem die Höchstgrenze
für anstehende
Ereignisse erreicht wurde, und zwar wiederum anhand der Knoten-ID.
Diese Warteschlange ist erforderlich, weil die Ereignis-Warteschlange
keine Sequenzierung auf Knotenebene aufweist.
-
Der
Client zur Meldungsverarbeitung 20 und die Server 25 sind
vorzugsweise mit der Fähigkeit
zur Erfassung bestimmter Angaben ausgestattet, um die Ereignisbearbeitung
innerhalb des Systems zu überwachen.
Der Client 20 kann beispielsweise Statistiken über die
Gesamtanzahl an empfangenen Ereignissen, die Gesamtanzahl an Ereignissen,
die in Warteschlangen eingestellt wurden, und die Gesamtanzahl an
Ereignissen, die aufgrund einer Zeitüberschreitung aus der Ereignis-Warteschlange
entfernt wurden, erfassen. Er erfasst außerdem die Gesamt-Durchlaufzeit,
die ein Paket innerhalb des Systems vom Zeitpunkt des Empfangs,
an dem das Ereignis bestätigt
wurde, zurück
bis zum Sende-NE benötigt.
Die Server 25 erfassen Angaben über die Zeit, die jedes einzelne
Ereignis zur Verarbeitung benötigt, und
die Anzahl an empfangenen/verarbeiteten Ereignissen innerhalb eines
bestimmten Zeitraums. Diese Zeitangaben werden nach Knotentyp, MLP-Klasse (Master-Parameterliste)
und Positionsnummer gespeichert. Jede dieser Angaben wird verwendet,
um die allgemeine Ereignisgeschwindigkeit für das Meldungs-Mitteilungssystem 5 zu
ermitteln.
-
Experimente
zeigen, dass die Bearbeitung einzelner Ereignisse in Abhängigkeit
vom Ereignistyp unterschiedliche Zeitspannen beanspruchen kann. Dies
hängt hauptsächlich mit
dem Umfang an Netzwerk- oder Datenbankzugriffen zusammen, der für die Ereignisbearbeitung
als Nebeneffekt des empfangenen Ereignisses erforderlich ist. Im
Fall eines Anschlussnamen-Ereignisses wird der Name beispielsweise,
sobald er in einen String übersetzt
wurde, in der Datenbank einfach nur aktualisiert. Ein Kartenstatus-Ereignis
erfordert eine Reihe von Nebenaufgaben, die durchgeführt werden
müssen,
ehe der Status in der Datenbank aktualisiert werden kann. Zu diesen
Aufgaben gehören
die Auflistung aller Anschlüsse
auf der Karte und sämtlicher
Kabel an diesen Anschlüssen
sowie die Statusermittlung aller Kabel nach „oben" oder „unten", in Abhängigkeit von dem empfangenen
Status.
-
Daneben
benötigen
einzelne NE-Ereignisse erheblich länger als das diesem Prozess
derzeit zugeordnete Zeitlimit von fünfzehn Sekunden. Falls für eine beliebige
Karte beispielsweise ein Ereignis „Programmierkarte vom Typ
MPL" empfangen wird,
müssen
alle Datenbankaufzeichnungen in Bezug auf diese Karte in der Datenbank 10 erstellt
werden. Bei großen
Karten mit einer großen
Anzahl an Anschlüssen und
Schaltungen kann die Erstellung bzw. das Löschen dieser Aufzeichnungen
je nach Kartentyp mehrere Minuten in Anspruch nehmen. Die Ereignisbearbeitung
ist für
die Zeit, in der ein aktuelles Ereignis verarbeitet wird, blockiert,
die Architektur der Erfindung bietet jedoch die Möglichkeit,
dass das Ereignis-Verarbeitungssystem 50 weiterhin
Verarbeitungs-Ereignisse für
andere Netzwerkelemente durchführen
kann.
-
Derzeit
verfügt
der Meldungsprozessor 4 (siehe 1) nur über Kenntnisse über das
von ihm bearbeitete Ereignis und das Sende-NE stellt alle anderen
NE-Meldungen in Warteschlangen ein, bis eine Antwort für dieses
Ereignis empfangen wird. Infolgedessen senden die Netzwerkelemente
weiterhin Ereignisse, so lange das Ereignis vorliegt. Die Verbesserung
des Systems zur Meldungsmitteilung 50 gemäß der Erfindung
besteht darin, dass die Identifikation von doppelt eingehenden NE-Ereignissen
möglich
ist. Diese Ereignisse kommen in der Regel von Einrichtungen im Netzwerk,
deren Status schwankt. Sobald ein Ereignis als von einem „schwankenden" Objekt stammend
identifiziert wurde, kann das Ereignis herausgefiltert werden, bis
das Problem mit der betreffenden Einrichtung gelöst ist. Zu diesem Zweck bestätigt der
Client zur Meldungsverarbeitung 20 alle NCI-Ereignisse
unmittelbar nach dem Empfang. Auf diese Weise verfügt der Notifier 26 über eine Übersicht über den
Ereignis-Knotenpuffer.
-
3A beschreibt
die Abfolge der Operationen, die erfolgen, wenn eine Aktualisierung
in der Master-Datenbank 10 durchgeführt wird. Sie beginnt mit dem
Client-Prozess 20, der von CHN 26 eine Mitteilung über das
Netzwerk-Ereignis empfängt
und als Antwort einen Server mit der Verarbeitung des Ereignisses
beauftragt. Der Verteiler übermittelt
die Anfrage an einen verfügbaren
Server-Prozess 25. Der Server übersetzt das Netzwerk-Ereignis in eine
entsprechende MPL-Meldung und erstellt eine NE-Änderungsanfrage
an das NE. Die MPL-Meldung wird dann in die entsprechende lokale
Datenbank eingetragen und die Änderungsanfrage
wird bestätigt. Nach
Empfang der Bestätigung
sendet der Server 25 einen Bestätigungscode zurück, der
an den Client 20 weitergeleitet wird.
-
3B beschreibt
die Abfolge, die auftritt, wenn eine Aktualisierung in einer NE-Datenbank 7 durchgeführt wird.
Sie beginnt mit dem Client-Prozess 20, der das NE-Ereignis
empfängt,
woraufhin der Client einen Server mit der Verarbeitung des Ereignisses
beauftragt; der Verteiler 21 leitet die Anfrage an einen
verfügbaren
Server 25 weiter. Der Server übersetzt das NE-Ereignis in
eine entsprechende Datenbank-Aktualisierungsanfrage und sendet einen Bestätigungscode
zurück,
der an den Client-Prozess 20 weitergeleitet wird, der die Änderung
des NE bestätigt.
-
4A beschreibt
die Abfolge, die auftritt, wenn eine Aktualisierung in einer lokalen
Datenbank durchgeführt
wird und das entsprechende Ereignis weitere Informationen vom NE
erfordert. Die Abfolge ist ähnlich
wie die in 3B, im Rahmen der Ereignis-Verarbeitung
führt der
Server jedoch weitere NCI-Auslesungen
durch, um die erforderlichen zusätzlichen
Informationen zu erhalten. Schließlich trifft die Antwort auf
die NCI-Auslesung vom NE ein, der Server 25 aktualisiert
alle relevanten Informationen in der Datenbank und sendet einen
Bestätigungscode zurück, der
an den Client-Prozess 20 weitergeleitet wird, wobei das
Netzwerk-Ereignis
an diesem Punkt bestätigt
wird. Dieses Szenario ist vom Verhalten bestimmter Netzknoten in
Bezug auf bestimmte Datenbank-Positionen
abhängig,
und es sollte nach Möglichkeit
vermieden werden, da es im Hinblick auf die Netzwerkressourcen kostenaufwändiger ist.
-
4B stellt
eine Alternative zu der in 4A beschriebenen
Abfolge dar, wobei der Unterschied in der Art und Weise besteht,
wie die zusätzlichen
Informationen ausgelesen werden.
-
So
beginnt die Abfolge damit, dass ein NE-Ereignis an einen freien
Server 25 verteilt wird, bei dem vom Server zurückgesandten
Bestätigungscode
handelt es sich jedoch um eine Liste der zusätzlichen Informationen, die
aus dem NE ausgelesen werden müssen.
Wenn der Client 20 den erfolgreichen Abschluss der Netzwerk-Ereignisverarbeitung empfängt, erstellt
er eine nicht blockierende NCI-Auslesung der zusätzlichen Informationen, ehe er
das ursprüngliche
Ereignis bestätigt.
Schließlich trifft
die NCI-Ausleseantwort
vom NE ein und wird wie jedes andere NCI-Ereignis bearbeitet, d.
h. das Ereignis wird an den Server weitergeleitet. Ab diesem Punkt
wiederholt sich die Abfolge. Es ist darauf hinzuweisen, dass es
absolut möglich
ist, dass die darauf folgende Ereignisbearbeitung eine andere NCI-Auslesung
ergibt, obwohl dies aus der Abbildung nicht hervorgeht.
-
Es
ist darauf hinzuweisen, dass das in 4B dargestellte
Szenario die Effizienz der Ereignis-Verarbeitung geringfügig beeinträchtigt,
da häufig
der gleiche Datensatz aktualisiert wird, wodurch Schlüssel-Konvertierung,
Datensatz-Abruf und Datensatz-Aktualisierung mehrmals, anstatt nur
einmal durchgeführt
werden. Zudem erhöht
dies die Komplexität
der Architektur. Bei einer Multi-Server-Architektur ist es sinnvoller,
die Anzahl an Servern zu erhöhen,
um die Anzahl an Servern zu berücksichtigen,
die während
Netzwerk-Auslesungen blockiert sind, bzw. sein könnten.