DE102021109515A1

DE102021109515A1 - Verfahren und system zur erleichterung eines selbstheilenden netzwerks

Info

Publication number: DE102021109515A1
Application number: DE102021109515.8A
Authority: DE
Inventors: Chinlin Chen; Anu Mercian; Renato Chaves de Aguiar
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-06-25
Filing date: 2021-04-15
Publication date: 2021-12-30
Also published as: US11860724B2; CN113852487A; US20210406114A1

Abstract

Ein System zur Ereignisanalyse ist vorhanden. Während des Betriebs kann das System eine dem Switch zugeordnete Ereignisbeschreibung aus einem Ereignisprotokoll des Switches ermitteln. Die Ereignisbeschreibung kann einem Eintrag in einer Tabelle in einer Switch-Konfigurationsdatenbank des Switches entsprechen. Eine entsprechende Datenbank im Switch kann eine relationale Datenbank sein. Das System kann dann ein Ereignisprotokollsegment erhalten, das ein Teil des Ereignisprotokolls ist und die Ereignisbeschreibung basierend auf einem Bereich von Einträgen umfasst. Anschließend kann das System eine Mustererkennungstechnik auf das Ereignisprotokollsegment basierend auf dem Eintrag in der Schalterkonfigurationsdatenbank anwenden, um ein oder mehrere Muster zu bestimmen, die einem mit der Ereignisbeschreibung verbundenen Ereignis entsprechen. Der Switch kann dann eine maschinelle Lerntechnik unter Verwendung des einen oder der mehreren Muster anwenden, um eine Wiederherstellungsaktion zur Abschwächung des Ereignisses zu bestimmen.

Description

HINTERGRUND
Die vorliegende Offenbarung bezieht sich auf Kommunikationsnetzwerke. Genauer gesagt, bezieht sich die vorliegende Offenbarung auf ein Verfahren und ein System zur Ermöglichung eines selbstheilenden Netzwerks.
Figurenliste

1 zeigt ein beispielhaftes Ereignisanalysesystem, das ein selbstheilendes Netzwerk ermöglicht, gemäß einer Ausführungsform der vorliegenden Anwendung.
2A zeigt beispielhafte Merkmalsgruppen und entsprechende Musterdefinitionen für ein Ereignisanalysesystem, gemäß einer Ausführungsform der vorliegenden Anwendung.
2B veranschaulicht einen beispielhaften Anomalieerkennungsprozess eines Ereignisanalysesystems, gemäß einer Ausführungsform der vorliegenden Anwendung.
3 zeigt einen beispielhaften Selbstheilungsprozess, der durch ein Ereignisanalysesystem ermöglicht wird, gemäß einer Ausführungsform der vorliegenden Anwendung.
4A zeigt ein Flussdiagramm, das den Prozess eines Ereignisanalysesystems veranschaulicht, das ein Ereignisprotokollsegment zur Analyse extrahiert, in Übereinstimmung mit einer Ausführungsform der vorliegenden Anwendung.
4B zeigt ein Flussdiagramm, das den Selbstheilungsprozess eines Ereignisanalysesystems gemäß einer Ausführungsform der vorliegenden Anwendung illustriert.
5 stellt ein Flussdiagramm dar, das den Prozess eines Ereignisanalysesystems veranschaulicht, das eine Wiederherstellungsaktion für den Selbstheilungsprozess validiert, gemäß einer Ausführungsform der vorliegenden Anwendung.
6 zeigt einen beispielhaften Schalter, der mit einem Ereignisanalysesystem ausgestattet ist, gemäß einer Ausführungsform der vorliegenden Anwendung.

In den Abbildungen beziehen sich gleiche Referenznummern auf die gleichen Abbildungselemente.
DETAILLIERTE BESCHREIBUNG
Die folgende Beschreibung soll den Fachmann in die Lage versetzen, die Erfindung herzustellen und zu verwenden, und wird im Zusammenhang mit einer bestimmten Anwendung und deren Anforderungen gegeben. Verschiedene Modifikationen der offengelegten Ausführungsformen werden für den Fachmann ohne weiteres ersichtlich sein, und die hierin definierten allgemeinen Prinzipien können auf andere Ausführungsformen und - Anwendungen angewendet werden, ohne vom Geist und Umfang der vorliegenden Erfindung abzuweichen. Somit ist die vorliegende Erfindung nicht auf die gezeigten Ausführungsformen beschränkt, sondern ihr ist der weitestgehende Anwendungsbereich gemäß den Ansprüchen zuzuerkennen.
Übersicht
Das Internet ist das Bereitstellungsmedium für eine Vielzahl von Anwendungen, die auf physischen und virtuellen Geräten laufen. Solche Anwendungen haben einen steigenden Bedarf an Bandbreite mit sich gebracht. Infolgedessen wetteifern die Gerätehersteller darum, Switches zu bauen, die verschiedene Funktionen ausführen können. Die daraus resultierende Komplexität des Switches kann jedoch die Schwierigkeit erhöhen, einen Fehler im Switch zu erkennen. Außerdem kann ein Netzwerk eine Reihe solcher komplexer Switches enthalten. Darüber hinaus kann das Netzwerk verschiedene Arten von Switches enthalten. Jede Art von Switch kann unterschiedliche Fähigkeiten und Funktionalitäten haben. Wenn ein Ereignis (z. B. eine Anomalie oder ein Fehler) auftritt, muss ein Administrator daher möglicherweise jeden Switch im Netzwerk einzeln beheben.
Ein gemeinsames Element zwischen verschiedenen Typen von Switches im Netzwerk können die von den Switches geführten Protokolldateien sein. Die Protokolldatei in jedem Switch kann die mit dem Switch verbundenen Ereignisse aufzeichnen. Solche Ereignisse können die Konfigurationsänderungen, Operationen und Anwendungen des Switches umfassen. Die Verwendung der Protokolldatei zur Überwachung der Switches kann jedoch eine Herausforderung darstellen, da die Größe einer Protokolldatei sehr groß sein kann. Beispielsweise kann die Größe einer Protokolldatei in einem Switch innerhalb einer Woche auf eine beträchtliche Größe anwachsen (z. B. in der Größenordnung von Gigabytes). Darüber hinaus kann bei mehreren Switches im Netzwerk die kombinierte Größe der Protokolldateien bis zu Petabytes an Daten anwachsen. Infolgedessen kann die Fehlersuche in den Protokolldateien ineffizient und zeitaufwändig sein.
Eine Ausführungsform der vorliegenden Erfindung stellt ein System zur Ereignisanalyse in einem jeweiligen Switch in einem Netzwerk bereit. Während des Betriebs kann das System eine dem Switch zugeordnete Ereignisbeschreibung aus einem Ereignisprotokoll des Switches ermitteln. Die Ereignisbeschreibung kann einem Eintrag in einer Tabelle in einer Switch-Konfigurationsdatenbank des Switches entsprechen. Eine entsprechende Datenbank im Switch kann eine relationale Datenbank sein. Das System kann dann ein Ereignisprotokollsegment erhalten, das ein Teil des Ereignisprotokolls ist und die Ereignisbeschreibung basierend auf einem Bereich von Einträgen umfasst. Anschließend kann das System eine Mustererkennungstechnik auf das Ereignisprotokollsegment basierend auf dem Eintrag in der Schalterkonfigurationsdatenbank anwenden, um ein oder mehrere Muster zu bestimmen, die einem mit der Ereignisbeschreibung verbundenen Ereignis entsprechen. Der Switch kann dann eine maschinelle Lerntechnik unter Verwendung des einen oder der mehreren Muster anwenden, um eine Wiederherstellungsaktion zur Abschwächung des Ereignisses zu bestimmen.
In einer Variante dieser Ausführungsform kann das System eine Anzahl von Wiederherstellungsaktionen in einer Aktionsdatenbank im Schalter verwalten. Eine jeweilige Wiederherstellungsaktion kann einem oder mehreren Mustern entsprechen.
In einer weiteren Variante kann das System das maschinelle Lernverfahren auf die Aktionsdatenbank anwenden und dabei das eine oder die mehreren Muster verwenden, um die Wiederherstellungsaktion aus der Aktionsdatenbank zu bestimmen.
In einer Variante dieser Ausführungsform ist das maschinelle Lernverfahren ein vortrainiertes Modell, das auf den Schalter geladen wird.
In einer Variante dieser Ausführungsform kann das System die Wiederherstellungsaktion in einer Schattendatenbank auswerten und anhand der Auswertung bestimmen, ob die Wiederherstellungsaktion einen Konflikt in der Schalterkonfigurationsdatenbank erzeugt. Die Schattendatenbank kann eine Kopie der Schalterkonfigurationsdatenbank sein und wird nicht zur Bestimmung der Konfiguration des Schalters verwendet.
In einer Variante dieser Ausführungsform kann das System bestimmen, ob es sich bei dem Ereignis um ein kritisches Problem handelt, und die Wiederherstellungsaktion am Schalter ausführen, wenn es sich bei dem Ereignis um ein nicht kritisches Problem handelt.
In einer weiteren Variante kann das System vor dem Ausführen der Wiederherstellungsaktion eine Bestätigung von einem Benutzer einholen, wenn das Ereignis ein kritisches Problem ist.
In einer Variante dieser Ausführungsform kann das System einen Satz von Merkmalsgruppen des Schalters und einen Auslöser, der das Ereignis anzeigt, basierend auf der Überwachung des Satzes von Merkmalsgruppen bestimmen. Eine jeweilige Merkmalsgruppe kann ein oder mehrere zugehörige Merkmale des Schalters enthalten. Der Auslöser kann einer Merkmalsgruppe entsprechen, die mit dem Ereignis verbunden ist.
In einer weiteren Variante kann das System einen Satz von Mustern, die für die Merkmalsgruppe definiert wurden, mit Ereignisbeschreibungen im Ereignisprotokollsegment abgleichen, indem es die Mustererkennungstechnik verwendet.
In einer Variante dieser Ausführungsform kann der Bereich der Einträge einen ersten Bereich von Einträgen vor einem Protokolleintrag und einen zweiten Bereich von Einträgen nach dem Protokolleintrag umfassen. Der Protokolleintrag kann die Ereignisbeschreibung im Ereignisprotokoll enthalten.
Die hier beschriebenen Ausführungsformen lösen das Problem der Ereigniserkennung und -wiederherstellung in einem Switch in einem Netzwerk, indem sie (i) ein Ereignis (z. B. eine Anomalie) effizient identifizieren, indem sie ein Muster in einem relevanten Protokollsegment bestimmen, und (ii) ein Modell der künstlichen Intelligenz (KI) verwenden, um eine Wiederherstellungsaktion zu bestimmen, die dem Ereignis entspricht. Auf diese Weise kann ein entsprechender Switch in einem Netzwerk automatisch ein Ereignis und eine entsprechende Wiederherstellungsaktion erkennen. Wenn das Ereignis nicht kritisch ist, kann der Switch dann die Wiederherstellungsaktion ausführen, wodurch die Selbstheilung im Netzwerk erleichtert wird.
Mit bestehenden Technologien kann ein entsprechender Switch mit einem oder mehreren Überwachungsagenten ausgestattet werden. Jeder Überwachungsagent kann ein Hardwaremodul oder eine Softwareanwendung sein, die in der Lage ist, eine bestimmte Funktion des Switches zu überwachen. Zum Beispiel kann ein Überwachungsagent die Routing-Operationen überwachen (z. B. Konfiguration, Betrieb und Stabilität), und ein anderer Überwachungsagent kann das Minimum-Spanning-Tree-Protokoll (MSTP) überwachen. Ein jeweiliger Überwachungsagent kann ein Ereignis identifizieren, das mit der entsprechenden Funktion des Switches verbunden ist. Da der Switch jedoch eine große Anzahl von Funktionen aufweisen und in einer Vielzahl von Szenarien eingesetzt werden kann, können die von den Überwachungsagenten des Switches gemeldeten Ereignisse vielfältig und zahlreich sein.
Die Behebung eines Netzwerkereignisses (z. B. eines Problems, das durch ein anormales Ereignis entstanden ist) kann die Identifizierung des Ereignisses und die schnelle Behebung des Problems, das das Ereignis verursacht hat, umfassen, um die Auswirkungen zu verringern. Die manuelle Identifizierung der Ressourcen und Maßnahmen zur Behebung eines von den Überwachungsagenten gemeldeten Ereignisses durch einen Administrator kann fehleranfällig und zeitaufwändig sein. Um den Prozess weiter zu rationalisieren, kann der Administrator die Ereignisprotokolle des Switches nutzen. Der Administrator kann die Einträge in den Ereignisprotokolldateien mithilfe von Schlüsselwortsuche und Regelabgleich manuell untersuchen, um Ereignisse zu identifizieren. Bei einem groß angelegten Einsatz (z. B. in einem großen und verteilten Netzwerk) kann die Identifizierung eines Ereignisses mit einer manuellen Prüfung jedoch undurchführbar sein. Außerdem kann es selbst bei einer effizienten Identifizierung eines Ereignisses schwierig sein, das mit dem Ereignis verbundene Problem zu lösen. Infolgedessen ist ein Administrator möglicherweise nicht in der Lage, sich proaktiv auf ein anormales Ereignis vorzubereiten und entsprechende Wiederherstellungsmaßnahmen zu bestimmen.
Um dieses Problem zu lösen, kann ein entsprechender Switch in einem Netzwerk mit einem Ereignisanalysesystem ausgestattet werden, das effizient Probleme im Zusammenhang mit einem Ereignis identifizieren und eine korrigierende Wiederherstellungsaktion durchführen kann. Die Wiederherstellungsaktion kann eine oder mehrere Operationen oder Konfigurationsänderungen umfassen. Das System kann die Analyse einer Ereignisprotokolldatei, die Mustererkennung in den Einträgen (oder Protokollen) der Ereignisprotokolldatei und die Benachrichtigungen von Überwachungsagenten kombinieren, um die Selbstheilung für einen entsprechenden Switch und seine zugehörigen Verbindungen zu erleichtern. Die jeweiligen Instanzen des Systems auf den Switches des Netzwerks können sich untereinander synchronisieren und in Verbindung miteinander arbeiten, um ein selbstheilendes Netzwerk zu ermöglichen.
Der Switch kann eine Switch-Datenbank zum Speichern von Konfiguration, Status und Statistiken im Zusammenhang mit dem Switch in verschiedenen Tabellen/Spalten der Datenbank pflegen. Um ein Ereignis effizient zu ermitteln, kann das System eine zusätzliche Spalte in jeder Konfigurationstabelle der Datenbank pflegen. Diese zusätzliche Spalte kann als Merkmalsspalte bezeichnet werden. Für jede Klasse oder Kategorie der Konfiguration (z. B. Routing, Hochverfügbarkeit usw.) kann das System ein oder mehrere Schlüsselwörter in die Merkmalsspalte aufnehmen. Die Schlüsselwörter können den im Ereignisprotokoll gemeldeten Ereignissen entsprechen (d. h., die Schlüsselwörter können in den Ereignisprotokolleinträgen oder Protokollen erscheinen).
Während des Betriebs können Monitoring-Agenten auf einem jeweiligen Switch in einem Netzwerk die Konfiguration und den Status des Switches überwachen. Die Überwachung aller Funktionen eines Switches kann ineffizient sein. Daher kann das System, anstatt alle Funktionen des Switches zu überwachen, die Funktionen gruppieren. Beispielsweise können Routing-bezogene Funktionen und Vorgänge, wie Link Layer Discovery Protocol (LLDP), Spanning Tree Protocol (STP), Virtual Local Area Network (VLAN) und Address Resolution Protocol (ARP), in einer Routing-Funktionsgruppe zusammengefasst werden. Beim Erkennen eines Ereignisses für eine Funktionsgruppe kann ein Überwachungsagent einen Auslöser für das System erzeugen. In einigen Ausführungsformen kann der Überwachungsagent den Status der Funktionsspalte ändern, die mit der Funktionsgruppe verbunden ist. Die Statusänderung der Merkmalsgruppe kann als Auslöser für die Merkmalsgruppe wirken.
Der Status der Merkmalsspalte kann ein Schlüsselwort enthalten, das mit einem Ereigniseintrag in der Ereignisprotokolldatei übereinstimmen kann. Das System kann dann den Ereigniseintrag in der Ereignisprotokolldatei identifizieren (z. B. basierend auf dem Schlüsselwort oder einem Zeitstempel des Ereignisses). Das System kann dann ein Umgebungsfenster des Ereigniseintrags für die Ereignisprotokolldatei bestimmen. Das System kann das Umgebungsfenster basierend auf einem Bereich von Einträgen (z. B. einem vordefinierten Bereich) bestimmen, der durch einen oberen und einen unteren Schwellenwert angegeben wird. Der Bereich kann für jedes Merkmal oder eine Gruppe von Merkmalen definiert werden. Der obere Schwellenwert kann ein zeitlicher Bereich vor einem dem Eintrag zugeordneten Zeitstempel sein, und der untere Schwellenwert kann ein zeitlicher Bereich nach dem Zeitstempel sein. Weiterhin kann der obere Schwellenwert eine Anzahl von Einträgen vor dem Ereigniseintrag und der untere Schwellenwert eine Anzahl von Einträgen nach dem Ereigniseintrag angeben. Das System kann dann ein Ereignisprotokollsegment (z. B. einen Teil der Ereignisprotokolldatei), das dem umgebenden Fenster entspricht, das dem oberen und unteren Schwellenwert entsprechen kann, aus der Ereignisprotokolldatei erhalten.
Nachdem das System das Ereignisprotokollsegment erhalten hat, kann es eine Mustererkennung für das Ereignisprotokollsegment durchführen. Das System kann einen Satz von Mustern verwalten, die für die Merkmalsgruppe definiert werden können. In einigen Ausführungsformen kann das System die Rosie Pattern Language (RPL) basierend auf dem Satz von Mustern verwenden. Der Satz von Mustern kann die vordefinierten netzwerkbezogenen Muster oder Vorlagen sein, die in RPL verfügbar sind. Darüber hinaus kann das System auch Definitionen für erweiterte Muster pflegen, die spezifisch für die Software und Hardware eines jeweiligen Switches sind. Nach der Identifizierung eines oder mehrerer Muster im Ereignisprotokollsegment kann das System eine Selbstwiederherstellungsaktion basierend auf den identifizierten Mustern bestimmen.
Das System kann eine Zuordnung zwischen einem jeweiligen Muster aus der Menge der Muster und einer entsprechenden Wiederherstellungsaktion pflegen. Der Schalter kann mit einer Aktionsdatenbank ausgestattet sein, die die Abbildung speichern kann. Die Aktionsdatenbank kann eine relationale Datenbank sein. Die Schalterdatenbank und die Aktionsdatenbank können der gleiche Datenbanktyp sein (z. B. auf dem gleichen Datenbankmanagementsystem (DBMS) laufen), aber jede Datenbank kann ein eindeutiges Schema haben. Diese Datenbanken können auch unterschiedliche Datenbanktypen sein. Da ein einzelnes Muster mehrere Wiederherstellungsaktionen haben kann, kann das System ein KI-Modell (z. B. ein auf maschinellem Lernen basierendes Modell) verwenden, um das Muster mit einer Wiederherstellungsaktion abzugleichen. Um eine leichtgewichtige Ausführung auf einem Schalter zu gewährleisten, kann das KI-Modell ein vortrainiertes KI-Modell sein. Das KI-Modell kann die ermittelten Muster als Eingaben erhalten und die Wiederherstellungsaktion bestimmen. Wenn es sich bei dem Ereignis um ein nicht kritisches Ereignis handelt, kann das System die Wiederherstellungsaktion ausführen, um das Ereignis zu entschärfen.
In einigen Ausführungsformen kann das System die Wiederherstellungsaktion in einer Schattendatenbank validieren, die sich von der Schalterdatenbank und der Aktionsdatenbank unterscheidet, bevor sie ausgeführt wird. Die Schattendatenbank kann eine Kopie der Schalterdatenbank sein. Durch Einfügen (oder Anwenden) der Wiederherstellungsaktion in die Schattendatenbank kann das System feststellen, ob die Wiederherstellungsaktion einen Konflikt mit der Konfiguration eines anderen Elements des Schalters verursacht. Wenn die Validierung erfolgreich ist, kann das System die Wiederherstellungsaktion ausführen.
Das System kann auch ein Client-Server-Modell ermöglichen, bei dem der Client auf einem jeweiligen Switch des Netzwerks ausgeführt werden kann und der Server sich auf einem Netzwerkmanager oder einer Cloud-Plattform befinden kann. Das KI-Modell kann von dem Server auf dem Netzwerkmanager basierend auf Einträgen in den Ereignisprotokollen der Switches im Netzwerk trainiert werden. Nach dem Training kann das KI-Modell auf die Switches des Netzwerks geladen werden. Wenn ein neues Ereignis auftritt, erkennt das in den Switches eingesetzte KI-Modell das entsprechende Muster möglicherweise nicht. Daher kann das System auf den Switches das Ereignis und die Muster als neuen Datenpunkt an den Server senden. Der Server kann das KI-Modell anhand der neuen Datenpunkte neu trainieren. In regelmäßigen Abständen kann der Server das aktualisierte KI-Modell an die Switches senden. Mithilfe des aktualisierten KI-Modells auf den Switches kann das System den neuesten Satz von Mustern erkennen.
Wenn das Ereignis ein kritisches Ereignis ist, kann das System das Ereignis und die Wiederherstellungsaktion an den Netzwerkmanager senden. Die Serverinstanz des Systems kann das Ereignis und die Wiederherstellungsaktion einem Administrator präsentieren. Der Administrator kann feststellen, ob die Wiederherstellungsaktion eine geeignete Lösung für das Ereignis ist. Wenn dies der Fall ist, kann der Administrator die Wiederherstellungsaktion genehmigen. Nach Erhalt der Genehmigung kann das System die Wiederherstellungsaktion auf dem Schalter ausführen. Es ist zu beachten, dass das System die Wiederherstellungsaktion in der Schattendatenbank auch für ein kritisches Ereignis validieren kann. Wenn die Validierung für eine Wiederherstellungsaktion (z. B. sowohl für kritische als auch für nicht kritische Ereignisse) nicht erfolgreich ist, kann das System die Wiederherstellungsaktion an den Netzwerkmanager senden.
In dieser Offenbarung wird der Begriff „Switch“ in einem allgemeinen Sinne verwendet und kann sich auf jeden eigenständigen oder Fabric-Switch beziehen, der in einer beliebigen Netzwerkschicht arbeitet. Der Begriff „Switch“ ist nicht so zu verstehen, dass Ausführungsformen der vorliegenden Erfindung auf Layer-2-Netzwerke beschränkt sind. Jedes Gerät, das Datenverkehr an ein externes Gerät oder einen anderen Switch weiterleiten kann, kann als „Switch“ bezeichnet werden. Jedes physische oder virtuelle Gerät (z. B. eine virtuelle Maschine/Switch, die auf einem Computergerät arbeitet), das Datenverkehr an ein Endgerät weiterleiten kann, kann als „Switch“ bezeichnet werden. Beispiele für einen „Switch“ sind u. a. ein Layer-2-Switch, ein Layer-3-Router, ein Routing-Switch, eine Komponente eines Gen-Z-Netzwerks oder ein Fabric-Switch, der eine Vielzahl ähnlicher oder heterogener kleinerer physischer und/oder virtueller Switches umfasst.
Der Begriff „Paket“ bezieht sich auf eine Gruppe von Bits, die zusammen über ein Netzwerk transportiert werden können. „Paket“ sollte nicht als Beschränkung von Ausführungsformen der vorliegenden Erfindung auf Schicht-3-Netzwerke interpretiert werden. „Paket“ kann durch andere Begriffe ersetzt werden, die sich auf eine Gruppe von Bits beziehen, wie z. B. „Nachricht“, „Rahmen“, „Zelle“, „Datagramm“ oder „Transaktion“. "
Netzwerk-Architektur
1 zeigt ein beispielhaftes Ereignisanalysesystem, das ein selbstheilendes Netzwerk ermöglicht, gemäß einer Ausführungsform der vorliegenden Anwendung. Wie in 1 dargestellt, umfasst ein Netzwerk 100 die Switches 101, 102, 103, 104 und 105. In einigen Ausführungsformen ist das Netzwerk 100 ein Gen-Z-Netzwerk, und ein entsprechender Switch des Netzwerks 100, z. B. Switch 102, ist eine Gen-Z-Komponente. Ein Gen-Z-Netzwerk kann eine speicher-semantische Struktur sein, die zur Kommunikation mit den Geräten in einer Computerumgebung verwendet werden kann. Durch die Vereinheitlichung der Kommunikationswege und die Vereinfachung der Software durch eine einfache Speichersemantik können Gen-Z-Komponenten Hochleistungslösungen für komplexe Systeme ermöglichen. In einem solchen Szenario basiert die Kommunikation zwischen den Switches im Netzwerk 100 auf einer speicher-semantischen Fabric. In einigen weiteren Ausführungsformen ist das Netzwerk 100 ein Ethernet- und/oder IP-Netzwerk, und ein entsprechender Switch des Netzwerks 100, z. B. Switch 102, ist ein Ethernet-Switch und/oder IP-Router. In einem solchen Szenario basiert die Kommunikation zwischen den Switches im Netzwerk 100 auf Ethernet und/oder IP.
Mit bestehenden Technologien kann ein jeweiliger Switch mit einem oder mehreren Überwachungsagenten ausgestattet sein, von denen jeder ein einzelnes Merkmal oder eine Merkmalsgruppe des Switches überwachen kann. Zum Beispiel ein Überwachungsagent 140, der eine Funktionsgruppe des Schalters 102 überwachen kann. Der Überwachungsagent 140 kann ein Ereignis 150 identifizieren, das mit dem entsprechenden Merkmal des Schalters 102 verbunden ist. Da der Switch 102 jedoch eine große Anzahl von Funktionen aufweisen und in verschiedenen Szenarien im Netzwerk 100 eingesetzt werden kann (z. B. als Aggregat-, Edge- oder Core-Switch), können die von den Überwachungsagenten des Switches 102 gemeldeten Ereignisse vielfältig und zahlreich sein.
Die Behebung eines Ereignisses im Netzwerk 100 kann die Identifizierung des Problems, das das Ereignis verursacht, und die schnelle Behebung des Problems zur Verringerung der Auswirkungen umfassen. Die manuelle Identifizierung der Ressourcen und Maßnahmen zur Behebung eines vom Überwachungsagenten 140 gemeldeten Ereignisses durch einen Administrator kann fehleranfällig und zeitaufwändig sein. Um den Prozess weiter zu rationalisieren, kann der Administrator die Ereignisprotokolle oder Einträge in der Ereignisprotokolldatei 120 des Switches 102 verwenden. Der Administrator kann die Einträge in der Ereignisprotokolldatei 120 mithilfe von Schlüsselwortsuche und Regelabgleich manuell untersuchen, um das mit dem Ereignis 150 verbundene Problem zu identifizieren. Bei einem groß angelegten Einsatz im Netzwerk 100 kann die Identifizierung des Problems mit einer manuellen Prüfung jedoch undurchführbar sein. Außerdem kann selbst bei einer effizienten Identifizierung eines Problems die Behebung des Problems eine Herausforderung darstellen. Infolgedessen ist ein Administrator möglicherweise nicht in der Lage, sich proaktiv auf ein Ereignis vorzubereiten und entsprechende Wiederherstellungsmaßnahmen für das Problem, das das Ereignis 150 verursacht, zu bestimmen.
Um dieses Problem zu lösen, kann ein entsprechender Switch im Netzwerk 100 mit einem Ereignisanalysesystem 110 ausgestattet werden, das ein oder mehrere Probleme, die das Ereignis 150 verursachen, effizient identifizieren und eine korrigierende Wiederherstellungsaktion durchführen kann. In dieser Offenlegung kann sich das System 110 auf eine Instanz des Systems 110 beziehen, die auf dem Switch 102 arbeitet. Das System 110 kann die Analyse der Ereignisprotokolldatei 120, die Mustererkennung in den Einträgen der Ereignisprotokolldatei 120 und die Benachrichtigungen von Überwachungsagenten, wie z. B. dem Überwachungsagenten 140, kombinieren, um die Selbstheilung für den Switch 102 und zugehörige Verbindungen im Netzwerk 100 zu erleichtern. Die Instanzen des Systems 110 auf den Switches des Netzwerks 100 können in Verbindung miteinander arbeiten, um die Selbstheilung im Netzwerk 100 zu erleichtern.
Der Switch 102 kann eine Switch-Datenbank 126 zum Speichern von Konfiguration, Status und Statistiken in Verbindung mit dem Switch 102 in verschiedenen Tabellen/Spalten der Datenbank 126 unterhalten. Um ein Ereignis effizient zu bestimmen, kann das System 110 eine zusätzliche Merkmalsspalte in jeder Konfigurationstabelle pflegen. Eine Konfigurationstabelle kann Konfigurationsinformationen des Schalters 102 speichern. Für jede Merkmalsgruppe kann die Merkmalsspalte ein oder mehrere Schlüsselwörter enthalten, die den in der Ereignisprotokolldatei 120 gemeldeten Ereignissen entsprechen können. Während des Betriebs kann der Überwachungsagent 140 beim Erkennen des Ereignisses 150 für die entsprechende Funktionsgruppe einen Trigger 142 für das System 110 erzeugen. Der Überwachungsagent 140 kann den Status der Merkmalsspalte ändern, die der Merkmalgruppe zugeordnet ist. Die Statusänderung der Merkmalsgruppe kann als Trigger 142 für die Merkmalsgruppe wirken.
Eine Event Engine 112 des Systems 110 kann den Trigger 142 verwalten. Ein Alarmmodul 122 kann Trigger 142 basierend auf der Datenbank 126 bestimmen. Ein Heartbeat-Modul 124, das die Ereignisprotokolldatei 120 periodisch überwachen kann, kann einen Ereigniseintrag identifizieren, der dem Auslöser 142 entspricht, und ein Ereignisprotokollsegment aus der Ereignisprotokolldatei 120 basierend auf dem Ereigniseintrag bestimmen. Nach Erhalt des Ereignisprotokollsegments kann die Pattern-Engine 114 des Systems 110 eine Mustererkennung auf dem Ereignisprotokollsegment basierend auf den Schlüsselwörtern des Merkmalsspalteneintrags durchführen und ein mit dem Ereignis 150 verbundenes Muster bestimmen. Das System 110 kann eine Zuordnung zwischen einem jeweiligen Muster aus einem Satz von Mustern, die mit den typischen Netzwerkproblemen/-ereignissen verbunden sind, und einer entsprechenden Wiederherstellungsaktion aufrechterhalten. Switch 102 kann mit einer Aktionsdatenbank 128 ausgestattet sein, in der die Abbildung gespeichert werden kann.
Da ein einzelnes Muster mehrere Wiederherstellungsaktionen haben kann, kann eine Action Engine 116 des Systems 110 ein KI-Modell verwenden, um das ermittelte Muster mit einer Wiederherstellungsaktion 144 in der Abbildung in der Aktionsdatenbank 128 abzugleichen. Die Wiederherstellungsaktion 144 kann eine oder mehrere Operationen oder Konfigurationsänderungen umfassen. Wenn das Ereignis 150 ein nicht-kritisches Ereignis ist (z. B. im Zusammenhang mit einem nicht-kritischen Problem), kann eine Wiederherstellungs-Engine 118 des Systems 110 die Wiederherstellungsaktion 144 ausführen, um die Auswirkungen des Ereignisses 150 abzuschwächen. Um sicherzustellen, dass die Wiederherstellungsaktion 144 keinen Konflikt mit dem Rest der Switch-Konfiguration verursacht, kann die Wiederherstellungs-Engine 118 die Wiederherstellungsaktion 144 vor der Ausführung in einer Schattendatenbank 130 validieren.
In einigen Ausführungsformen kann das System 110 auch ein Client-Server-Modell ermöglichen. Die Client-Instanz von System 110 kann auf einem entsprechenden Switch des Netzwerks 100 ausgeführt werden, und die Server-Instanz kann auf einem Netzwerkmanager 160 laufen. Der Netzwerkmanager 160 kann sich im Netzwerk 100 befinden oder in der Cloud bereitgestellt werden (z. B. über das Internet zugänglich) und die Netzwerkkonfigurationen und -verwaltung für einen entsprechenden Switch im Netzwerk 100 erleichtern. Wenn das Ereignis 150 ein kritisches Ereignis ist (z. B. im Zusammenhang mit einem kritischen Problem), kann die Recovery Engine 118 das Ereignis und die Wiederherstellungsaktion 144 an den Netzwerkmanager 160 senden. Die Serverinstanz des Systems 110 kann das Ereignis und die Wiederherstellungsaktion 144 einem Administrator präsentieren. Dann kann der Administrator bestimmen, ob die Wiederherstellungsaktion 144 eine geeignete Lösung für das Ereignis 150 ist.
Das KI-Modell kann von der Serverinstanz des Systems 110 beim Netzwerkmanager 160 auf der Grundlage von Einträgen in den Ereignisprotokollen der Switches im Netzwerk 100 trainiert werden. Nach dem Training kann das KI-Modell auf die Switches des Netzwerks 100, wie z. B. Switch 102, geladen werden. Wenn das Ereignis 150 ein neues Ereignis ist (z. B. ein Ereignis, mit dem das KI-Modell nicht trainiert wurde), erkennt das in Switch 102 eingesetzte KI-Modell das entsprechende Muster möglicherweise nicht. Folglich kann die Instanz des Systems 110 auf dem Schalter 102 Informationen, die mit dem Ereignis 150 verbunden sind, als einen neuen Datenpunkt an die Serverinstanz des Systems 110 senden. Die Serverinstanz des Systems 110 kann das KI-Modell anhand der neuen Datenpunkte neu trainieren. In regelmäßigen Abständen kann die Serverinstanz des Systems 110 das aktualisierte KI-Modell an die Switches des Netzwerks 100 senden. Infolgedessen können die KI-Modelle der Client-Instanzen von System 110 auf den Switches den neuesten Satz von Mustern erkennen.
2A zeigt beispielhafte Merkmalsgruppen und entsprechende Musterdefinitionen für ein Ereignisanalysesystem gemäß einer Ausführungsform der vorliegenden Anwendung. Ein jeweiliger Switch im Netzwerk 100, z. B. Switch 102, kann eine Reihe von Funktionen 202 unterstützen. Zum Beispiel kann Switch 102 Routing-bezogene Funktionen und Operationen unterstützen, wie LLDP, STP (und alle Varianten davon), VLAN und ARP. Der Switch 102 kann auch ein proprietäres Protokoll zur Unterstützung spezieller Operationen unterstützen. Die Funktionen 202 können auch eine oder mehrere Richtlinien und Zugriffskontrolllisten (ACL) umfassen, die Sicherheit und Berechtigungen für einen jeweiligen Benutzer bereitstellen können.
Die Überwachung jedes Merkmals des Schalters 102 kann schwierig sein. Daher kann das System 110 relevante Merkmale in einer Merkmalsgruppe gruppieren und diese Merkmalsgruppe überwachen. Infolgedessen können die Funktionen 202 des Switches 102 in eine Reihe von Funktionsgruppen 204 gruppiert werden. Die Routing-bezogenen Funktionen und Operationen in den Funktionen 202 können in einer Routing-Funktionsgruppe 212 gruppiert werden. Eine Funktionsgruppe kann sowohl Standard- als auch proprietäre Funktionen eines Switches enthalten. Beispielsweise kann eine Hochverfügbarkeits-Featuregruppe 214 ein Standard-Feature, wie z. B. Synchronisation, und ein proprietäres Feature enthalten. Für den Switch 102 definierte Richtlinien und ACLs können in einer Sicherheitsfunktionsgruppe 216 gruppiert werden. Es ist zu beachten, dass der Switch 102 mehr (oder weniger) der in 2A dargestellten Funktionen und Funktionsgruppen enthalten kann.
Um eine Mustererkennung an einem Ereignisprotokollsegment durchzuführen, kann die Pattern Engine 114 einen Satz von Musterdefinitionen 206 verwalten, der eine oder mehrere Musterdefinitionen für jede der Merkmalsgruppen 204 (mit gestrichelten und gepunkteten Linien gekennzeichnet) enthalten kann. Eine Musterdefinition kann ein oder mehrere Ereignisse darstellen, die am Switch 102 auftreten können. Zum Beispiel kann ein Verbindungsausfall oder ein Port-Flap-Ereignis einer Musterdefinition entsprechen, die Paketverluste anzeigt. Auf diese Weise kann eine Musterdefinition anzeigen, welches Ereignis am Switch 102 aufgetreten sein könnte. Musterdefinitionen 206 können von einem Administrator oder einer Mustererkennungstechnik, die von der Pattern Engine 114 verwendet wird, vordefiniert werden. Wenn die Pattern Engine 114 RPL verwendet, können die Musterdefinitionen 206 die vordefinierten netzwerkbezogenen Muster sein, die in RPL verfügbar sind. Darüber hinaus kann das System auch Definitionen für erweiterte Muster pflegen, die für die Software und Hardware eines jeweiligen Switches spezifisch sind, wie z. B. das proprietäre Merkmal in den Merkmalen 202.
In einigen Ausführungsformen kann die Pattern Engine 114 „normale“ Muster lernen, wenn der Schalter 102 ohne ein anormales Ereignis arbeitet. Diese Muster können eine Grundmusterdefinition in Musterdefinitionen 206 erzeugen (z. B. zusätzlich zu den RPL-Mustern). Der Überwachungsagent 140 kann periodisch Protokollinformationen an die Pattern Engine 114 liefern. Durch die Durchführung einer Mustererkennung in den Protokollinformationen kann die Pattern Engine 114 ein Baseline-Muster für den Switch 102 bestimmen. Dieses Grundlinienmuster kann es der Pattern Engine 114 ermöglichen, ein anomales Muster in einem Ereignisprotokolleintrag zu bestimmen. Die Patten-Engine 114 kann auch die Splunk-Mustererkennungstechnik mit regulären Ausdrücken verwenden. Wenn Merkmale 202 des Schalters 102 mit regulären Ausdrücken definiert sind, kann die Pattern-Engine 114 Splunk verwenden, um ein Merkmal mit einem entsprechenden Protokolleintrag abzugleichen.
2B veranschaulicht einen beispielhaften Anomalieerkennungsprozess eines Ereignisanalysesystems, gemäß einer Ausführungsform der vorliegenden Anwendung. Der Schalter 102 kann eine Schalterdatenbank 126 zum Speichern von Konfiguration, Status und Statistiken, die dem Schalter 102 zugeordnet sind, in verschiedenen Tabellen, wie z. B. Tabelle 240, unterhalten. Die Datenbank 126 kann eine relationale Datenbank sein, die auf einem DBMS läuft. Die Tabelle 240 kann eine Reihe von Spalten 242 enthalten, die die mit einer Funktionsgruppe 250 verbundene Konfiguration speichern können. Um ein Ereignis effizient zu bestimmen, kann das System 110 eine zusätzliche Spalte 244 in der Tabelle 240 führen. Diese zusätzliche Spalte 244 kann als Merkmalsspalte bezeichnet werden. Für die Merkmalsgruppe 250 kann das System 110 ein Schlüsselwort 232 in die Merkmalsspalte 242 aufnehmen. Das Schlüsselwort 232 kann den Ereignissen entsprechen, die in der Ereignisprotokolldatei 120 gemeldet werden (d. h., das Schlüsselwort 232 kann in den Ereignisprotokolleinträgen erscheinen).
Die Ereignisprotokolldatei 120 kann eine Reihe von Einträgen 221, 222, 223, 224, 225 und 226 enthalten. Ein entsprechender Eintrag in der Ereignisprotokolldatei 120 kann eines oder mehrere der folgenden Elemente enthalten: einen Zeitstempel (z. B. Datum und Uhrzeit), eine Art von Aktion (z. B. die Aktion des Switches 102 oder die Aktion eines Nachbarn), eine relevante Anwendung (z. B. ein Protokolldämon), Ereignisinformationen (z. B. einen Bezeichner und einen Indikator, ob es sich bei dem Eintrag um einen Informations- oder Fehlereintrag handelt) und eine Ereignisbeschreibung. Beispielsweise kann die Ereignisprotokolldatei 120 beim Empfang eines NTP-Pakets (Network Time Protocol) den folgenden Eintrag 222 erstellen:

2019-08-19T05:45:65.747267+00:00 switch ntpd[45584]:
- Ereignis|1102|LOG_INFO|AMM|1/5|NTP-Server 1 Paket empfangen

Der Überwachungsagent 140 kann die Merkmale der Merkmalsgruppe 250 im Schalter 102 überwachen. Beim Erkennen des Ereignisses 150 für die Merkmalsgruppe 250 kann der Überwachungsagent 140 den Auslöser 142 für das System 110 erzeugen. Der Überwachungsagent 140 kann den Status der Merkmalsspalte ändern, die der Merkmalgruppe 250 zugeordnet ist. Die Statusänderung der Merkmalsgruppe 250 kann als Auslöser 142 für die Merkmalsgruppe 250 wirken. Da der Status der Merkmalsspalte 244 das Schlüsselwort 232 enthalten kann, das mit einem Ereigniseintrag in der Ereignisprotokolldatei 120 übereinstimmen kann, kann das System 110 dann den Ereigniseintrag 224 (mit gestrichelten Linien gekennzeichnet) in der Ereignisprotokolldatei 120 identifizieren. Das System 110 kann den Eintrag 224 basierend auf dem Schlüsselwort 232 und einem Zeitstempel des Ereignisses 150 identifizieren.
Wenn Switch 102 beispielsweise eine große Anzahl von NTP-Paketen innerhalb eines kurzen Zeitraums empfangen hat, kann der NTP-Daemon von Switch 102 eine hohe Prozessorauslastung haben. Die Überflutung von Switch 102 mit Anforderungsverkehr kann den Switch 102 überfordern und eine Blockierung des wesentlichen Verkehrs verursachen. Ein solches anomales Sicherheitsmuster kann auf einen NTP-Amplifikationsangriff hindeuten, was zu einem entsprechenden Eintrag in der Ereignisprotokolldatei 120 führen kann. Die Einträge 223, 224 und 225 können dann jeweils sein:

2019-08-19T05:46:02.788056+00:00 switch system[45584]:
- Ereignis17601 |LOG_ERR|AMM|-|Hohe CPU-Auslastung durch Daemon 12mac-mgrd
2019-08-19T05:46:32.984564+00:00 switch policyd[26099]:
- Ereignis|6901|LOG_INFO|AMM|-|Aktion ausgelöst durch Monitoring Agent
2019-08-19T05:46:37.986937+00:00 switch policyd[26099]:
- Ereignis|5507|LOG_INFO|AMM|-|Konfigurationsänderung System 110

Das System 110 kann dann ein Umgebungsfenster des Ereigniseintrags 224 in der Ereignisprotokolldatei 120 bestimmen. Das System 110 kann das umgebende Fenster basierend auf einem Bereich von Einträgen (z. B. einem vordefinierten Bereich) bestimmen, der durch einen oberen und einen unteren Schwellenwert angegeben wird. Der Bereich kann spezifisch für die Merkmalsgruppe 250 sein. Der obere Schwellenwert kann ein zeitlicher Bereich vor einem dem Eintrag 224 zugeordneten Zeitstempel sein, und der untere Schwellenwert kann ein zeitlicher Bereich nach dem Zeitstempel sein. Außerdem kann der obere Schwellenwert eine Anzahl von Einträgen vor dem Eintrag 224 und der untere Schwellenwert eine Anzahl von Einträgen nach dem Eintrag 224 angeben. Zum Beispiel können der obere und der untere Schwellenwert für die Merkmalsgruppe 250 2 bzw. 1 sein. Alternativ können der obere und der untere Schwellenwert für die Merkmalsgruppe 250 10 Sekunden bzw. 5 Sekunden betragen. Das System 110 kann dann ein Ereignisprotokollsegment 220 (z. B. einen Teil der Ereignisprotokolldatei 120), das dem umgebenden Fenster entspricht, aus der Ereignisprotokolldatei 120 erhalten.
Nach Erhalt des Ereignisprotokollsegments 220 kann die Pattern Engine 114 eine Mustererkennung für das Ereignisprotokollsegment 220 durchführen. Das System 110 kann einen Satz von Musterdefinitionen 208 verwalten, die für die Merkmalsgruppe 250 definiert werden können und in den Musterdefinitionen 208 enthalten sein können. In einigen Ausführungsformen kann die Pattern-Engine 114 eine Mustererkennungstechnik, wie RPL und Splunk, basierend auf den Musterdefinitionen 208 verwenden. Musterdefinitionen 208 können die vordefinierten netzwerkbezogenen Muster sein, die in der Mustererkennungstechnik verfügbar sind. Musterdefinitionen 208 können auch die Definitionen für erweiterte Muster sein, die spezifisch für die Software und Hardware des Switches 102 sind. Nach der Identifizierung eines Musters 234 im Ereignisprotokollsegment 220 kann die Pattern Engine 114 eine auf dem Muster 234 basierende Selbstwiederherstellungsaktion bestimmen.
3 zeigt einen beispielhaften Selbstheilungsprozess, der durch ein Ereignisanalysesystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Anwendung ermöglicht wird. Das System 110 kann eine Zuordnung zwischen einem jeweiligen Muster aus dem Satz von Mustern und einer entsprechenden Wiederherstellungsaktion pflegen. Der Schalter 102 kann mit einer Aktionsdatenbank 128 ausgestattet sein, die die Abbildung in einer Tabelle 260 speichern kann, die eine Musterspalte 262 und eine entsprechende Wiederherstellungsaktionsspalte 264 enthalten kann. Da das Muster 234 mehrere Wiederherstellungsaktionen haben kann, kann die Aktions-Engine 116 ein KI-Modell 310 (z. B. ein auf maschinellem Lernen basierendes Modell) auf die Tabelle 260 anwenden. Das KI-Modell 310 kann Muster 234 mit der Wiederherstellungsaktion 144 abgleichen. Um eine leichtgewichtige Ausführung auf dem Schalter 102 zu gewährleisten, kann das KI-Modell 310 ein vortrainiertes KI-Modell sein.
Das AI-Modell 310 kann das Muster 234 als Eingabe verwenden und die Wiederherstellungsaktion 144 bestimmen (z. B. entsprechen das Muster 234 und die Aktion 144 den Eingabe- bzw. Ausgabeschichten des AI-Modells 310). Wenn die Wiederherstellungsaktion 144 für das Muster 234 bestimmt wird, kann die Wiederherstellungs-Engine 118 bestimmen, ob das Ereignis 150 ein kritisches Ereignis ist, indem sie feststellt, ob das Ereignis 150 mit einem kritischen Problem verbunden ist. Zum Beispiel kann ein mit NTP verbundenes Problem ein nicht-kritisches Problem sein, während ein mit STP verbundenes Problem ein kritisches Problem sein kann. Wenn das Ereignis 150 ein nicht-kritisches Ereignis ist, kann die Wiederherstellungs-Engine 118 die Wiederherstellungsaktion 144 ausführen, um das Ereignis 150 abzuschwächen. Wenn das Muster 234 beispielsweise einem NTP-Verstärkungsangriff entspricht, kann die Wiederherstellungsaktion 144 angeben, dass der Switch 102 den Server blockieren soll, der die NTP-Pakete sendet. Nach der Ausführung der Wiederherstellungsaktion 144 am Schalter 102 kann der entsprechende Eintrag in der Ereignisprotokolldatei 120 lauten:

2019-08-19T05:46:46.984564+00:00 switch system110[26099]:
- Ereignis|6901|LOG_INFO|AMM|-|NTP-Server sperren

In einigen Ausführungsformen kann die Wiederherstellungs-Engine 118 die Wiederherstellungsaktion 144 auf der Schattendatenbank 130 vor der Ausführung der Wiederherstellungsaktion 144 validieren. Die Schattendatenbank 130 kann eine Schattenkopie der Schalterdatenbank 126 sein. Eine Schattenkopie kann eine Kopie sein, die nicht direkt zur Konfiguration oder zum Betrieb des Schalters 102 verwendet wird. Durch Einfügen (oder Anwenden) der Wiederherstellungsaktion 144 in die Schattendatenbank 130 kann die Wiederherstellungsmaschine 118 feststellen, ob die Wiederherstellungsaktion 144 einen Konflikt mit der Konfiguration eines anderen Elements des Schalters 102 verursacht. Wenn die Validierung erfolgreich ist, kann die Wiederherstellungs-Engine 118 die Wiederherstellungsaktion 144 ausführen. Es ist zu beachten, dass das Wiederherstellungsmodul 118 die Wiederherstellungsaktion 144 in der Schattendatenbank 130 auch dann validieren kann, wenn das Ereignis 150 ein kritisches Ereignis ist. Wenn die Validierung für die Wiederherstellungsaktion 144, unabhängig davon, ob das Ereignis 150 ein kritisches oder unkritisches Ereignis ist, nicht erfolgreich ist, kann die Wiederherstellungs-Engine 118 eine weitere Verifizierung der Wiederherstellungsaktion 144 anfordern (z. B. von einem Netzwerkmanager 160).
Das System 110 kann auch ein Client-Server-Modell unterstützen, bei dem die Instanz des Systems 110 auf dem Schalter 102 die Client-Instanz sein kann und eine Server-Instanz des Systems 110 auf dem Netzwerkmanager 160 arbeiten kann. Wenn das Ereignis 150 ein kritisches Ereignis ist oder die Wiederherstellungsaktion 144 einen Konflikt auf dem Switch 102 verursachen kann, kann die Recovery Engine 118 das Ereignis 150 und die Wiederherstellungsaktion 144 an den Netzwerkmanager 160 senden. Die Serverinstanz des Systems 110 kann einem Administrator das Ereignis 150 und die Wiederherstellungsaktion 144 präsentieren. Der Administrator kann bestimmen, ob die Wiederherstellungsaktion 144 eine geeignete Lösung für das Ereignis 150 ist. Wenn dies der Fall ist, kann der Administrator die Wiederherstellungsaktion 144 genehmigen. Nach Erhalt der Genehmigung kann die Wiederherstellungs-Engine 118 die Wiederherstellungsaktion 144 am Switch 102 ausführen und die entsprechenden Konfigurationsänderungen an die Switch-Datenbank 126 übertragen.
Betrieb
4A zeigt ein Flussdiagramm, das den Prozess eines Ereignisanalysesystems veranschaulicht, das ein Ereignisprotokollsegment zur Analyse extrahiert, in Übereinstimmung mit einer Ausführungsform der vorliegenden Anwendung. Während des Betriebs kann das System einen Ereignisauslöser für ein Ereignis bestimmen (Vorgang 402) und einen dem Ereignis entsprechenden Eintrag in der Ereignisprotokolldatei identifizieren (Vorgang 404). Das System kann dann ein Ereignisprotokollsegment basierend auf den oberen und unteren Schwellenwerten, die mit dem Eintrag verbunden sind, bestimmen (Vorgang 406) und das Ereignisprotokollsegment aus der Ereignisprotokolldatei extrahieren (Vorgang 408).
4B zeigt ein Flussdiagramm, das den Selbstheilungsprozess eines Ereignisanalysesystems gemäß einer Ausführungsform der vorliegenden Anwendung veranschaulicht. Während des Betriebs kann das System ein Schlüsselwort aus der Merkmalsspalte der Schalterdatenbank erhalten (Vorgang 452). Das System kann dann eine Mustererkennungstechnik auf das Ereignisprotokollsegment basierend auf dem erhaltenen Schlüsselwort und einer oder mehreren Musterdefinitionen anwenden (Vorgang 454). Anschließend bestimmt das System ein Muster basierend auf der Mustererkennungstechnik (Vorgang 456). Das System kann dann ein KI-Modell, basierend auf dem ermittelten Muster, auf die in der Aktionsdatenbank verfügbaren Wiederherstellungsaktionen anwenden (Vorgang 458). Anschließend kann das System eine Wiederherstellungsaktion auf der Grundlage des KI-Modells bestimmen (Vorgang 460).
5 stellt ein Flussdiagramm dar, das den Prozess eines Ereignisanalysesystems veranschaulicht, das eine Wiederherstellungsaktion für den Selbstheilungsprozess validiert, gemäß einer Ausführungsform der vorliegenden Anwendung. Während des Betriebs kann das System die Wiederherstellungsaktion auf die Schattendatenbank des Schalters anwenden (Vorgang 502) und auf einen Konflikt mit der vorhandenen Konfiguration prüfen (Vorgang 504). Auf diese Weise kann das System validieren, bevor es die Wiederherstellungsaktion auf den Schalter überträgt. Der Switch kann dann feststellen, ob ein Konflikt erkannt wird (Vorgang 506). Wenn ein Konflikt erkannt wird, kann das System die Serverinstanz des Systems auf dem Netzwerkmanager bezüglich des Konflikts benachrichtigen (Vorgang 512).
Wenn andererseits kein Konflikt erkannt wird, kann das System prüfen, ob das Ereignis ein kritisches Ereignis ist (Vorgang 508). Wenn das Ereignis ein kritisches Ereignis ist, kann das System die Wiederherstellungsaktion an die Serverinstanz des Systems auf dem Netzwerkmanager zur weiteren Verarbeitung senden (Vorgang 514). Wenn das Ereignis kein kritisches Ereignis ist, kann das System die Wiederherstellungsaktion auf den Switch anwenden, wodurch die entsprechenden Änderungen in der Switch-Datenbank übernommen werden (Vorgang 510).
Beispielhaftes Schaltersystem
6 zeigt einen beispielhaften Switch, der mit einem Ereignisanalysesystem ausgestattet ist, gemäß einer Ausführungsform der vorliegenden Anwendung. In diesem Beispiel umfasst ein Switch 600 eine Anzahl von Kommunikationsanschlüssen 602, einen Paketprozessor 610, einen Analyselogikblock 630 und eine Speichereinrichtung 650. Der Switch 600 kann auch Switch-Hardware (z. B. die Verarbeitungshardware des Switches 600, wie seine ASIC-Chips) enthalten, die Informationen enthält, auf deren Grundlage der Switch 600 Pakete verarbeitet (z. B. Ausgangsports für Pakete bestimmt). Der Paketprozessor 610 extrahiert und verarbeitet Header-Informationen aus den empfangenen Frames. Der Paketprozessor 610 kann eine Switch-Kennung (z. B. eine MAC-Adresse und/oder eine IP-Adresse) identifizieren, die dem Switch im Header eines Pakets zugeordnet ist.
Die Kommunikationsports 602 können Inter-Switch-Kommunikationskanäle für die Kommunikation mit anderen Switches und/oder Benutzergeräten enthalten. Die Kommunikationskanäle können über einen regulären Kommunikationsport implementiert werden und auf einem beliebigen offenen oder proprietären Format basieren. Die Kommunikations-Ports 602 können einen oder mehrere Ethernet-Ports enthalten, die in einem Ethernet-Header gekapselte Frames empfangen können. Die Kommunikationsanschlüsse 602 können auch einen oder mehrere IP-Anschlüsse umfassen, die in der Lage sind, IP-Pakete zu empfangen. Ein IP-Port ist in der Lage, ein IP-Paket zu empfangen und kann mit einer IP-Adresse konfiguriert werden. Der Paketprozessor 610 kann Ethemet-Frames und/oder IP-Pakete verarbeiten.
Der Schalter 600 kann eine Schalterdatenbank 652, eine Aktionsdatenbank 654 und eine Schattendatenbank 656 (z. B. im Speichergerät 650) verwalten. Bei diesen Datenbanken kann es sich um relationale Datenbanken handeln, die jeweils ein eindeutiges Schema haben können und auf einer oder mehreren DBMS-Instanzen laufen können. Der Analyselogikblock 630 kann eines oder mehrere der folgenden Elemente enthalten: einen Musterlogikblock 632 und einen Aktionslogikblock 634, einen Wiederherstellungslogikblock 636 und einen Validierungslogikblock 636. Während des Betriebs kann der Analyselogikblock 630 einen Trigger empfangen, der ein Ereignis anzeigt, das mit dem Schalter 600 verbunden ist, basierend auf einer Statusänderung in einer Merkmalsspalte in der Schalterdatenbank 652. Der Analyselogikblock 630 kann einen Eintrag bestimmen, der das Ereignis in der Ereignisprotokolldatei des Schalters 600 anzeigt, und ein Ereignisprotokollsegment basierend auf dem Eintrag erhalten.
Der Musterlogikblock 632 kann dann eine Mustererkennung an dem Ereignisprotokollsegment durchführen, um ein oder mehrere Muster zu bestimmen, die dem Ereignis entsprechen. Anschließend kann der Aktionslogikblock 634 ein KI-Modell verwenden, um eine Wiederherstellungsaktion aus einem Satz von Wiederherstellungsaktionen zu bestimmen, die in der Aktionsdatenbank 654 gepflegt werden. Das KI-Modell kann die ein oder mehreren Muster und die entsprechende Merkmalsspalte verwenden, um die Wiederherstellungsaktion zu bestimmen. Der Validierungslogikblock 368 kann die Wiederherstellungsaktion in der Schattendatenbank 656 validieren, die eine Schattenkopie der Schalterdatenbank 654 sein kann. Nach erfolgreicher Validierung kann der Wiederherstellungslogikblock 636, wenn es sich bei dem Ereignis um ein nicht kritisches Ereignis handelt, die Wiederherstellungsaktion auf den Schalter 600 anwenden, wodurch die entsprechenden Konfigurationsänderungen in die Schalterdatenbank 652 übernommen werden. Ist die Validierung hingegen nicht erfolgreich oder handelt es sich bei dem Ereignis um ein kritisches Ereignis, kann der Wiederherstellungslogikblock 636 Informationen über die Wiederherstellungsaktion an einen Netzwerkmanager senden.
Die Datenstrukturen und der Code, die in dieser detaillierten Beschreibung beschrieben werden, sind typischerweise auf einem computerlesbaren Speichermedium gespeichert, das jedes Gerät oder Medium sein kann, das Code und/oder Daten zur Verwendung durch ein Computersystem speichern kann. Das computerlesbare Speichermedium umfasst unter anderem flüchtige Speicher, nichtflüchtige Speicher, magnetische und optische Speichergeräte wie Disketten, Magnetbänder, CDs (Compact Discs), DVDs (Digital Versatile Discs oder Digital Video Discs) oder andere Medien, die in der Lage sind, jetzt bekannte oder später entwickelte computerlesbare Medien zu speichern.
Die im Abschnitt „Detaillierte Beschreibung“ beschriebenen Methoden und Prozesse können als Code und/oder Daten verkörpert werden, die wie oben beschrieben in einem computerlesbaren Speichermedium gespeichert werden können. Wenn ein Computersystem den auf dem computerlesbaren Speichermedium gespeicherten Code und/oder die Daten liest und ausführt, führt das Computersystem die Methoden und Prozesse aus, die als Datenstrukturen und Code verkörpert und in dem computerlesbaren Speichermedium gespeichert sind.
Die hier beschriebenen Methoden und Prozesse können von Hardware-Modulen oder -Geräten ausgeführt werden und/oder in diesen enthalten sein. Diese Module oder Geräte können unter anderem einen anwendungsspezifischen integrierten Schaltkreis (ASIC-Chip), ein feldprogrammierbares Gate-Array (FPGA), einen dedizierten oder gemeinsam genutzten Prozessor, der ein bestimmtes Softwaremodul oder ein Stück Code zu einem bestimmten Zeitpunkt ausführt, und/oder andere heute bekannte oder später entwickelte programmierbare logische Geräte umfassen. Wenn die Hardware-Module oder -Geräte aktiviert werden, führen sie die darin enthaltenen Methoden und Prozesse aus.
Die vorstehenden Beschreibungen von Ausführungsformen der vorliegenden Erfindung wurden nur zum Zweck der Veranschaulichung und Beschreibung dargestellt. Sie erheben keinen Anspruch auf Vollständigkeit und schränken diese Offenbarung nicht ein. Dementsprechend werden viele Modifikationen und Variationen für den Fachmann auf dem Gebiet der Technik offensichtlich sein. Der Umfang der vorliegenden Erfindung wird durch die beigefügten Ansprüche definiert.

Claims

Ein Verfahren zur Erleichterung eines Ereignisanalysesystems in einem Schalter, das Folgendes umfasst: Ermitteln einer dem Schalter zugeordneten Ereignisbeschreibung aus einem Ereignisprotokoll des Schalters, wobei die Ereignisbeschreibung einem Eintrag in einer Tabelle in einer Schalterkonfigurationsdatenbank des Schalters entspricht, und wobei eine entsprechende Datenbank im Schalter eine relationale Datenbank ist; Erhalten eines Ereignisprotokollsegments, das ein Teil des Ereignisprotokolls ist und die Ereignisbeschreibung basierend auf einem Bereich von Einträgen umfasst; Anwenden einer Mustererkennungstechnik auf das Ereignisprotokollsegment basierend auf dem Eintrag in der Schalterkonfigurationsdatenbank, um ein oder mehrere Muster zu bestimmen, die einem mit der Ereignisbeschreibung verbundenen Ereignis entsprechen; und Anwendung eines maschinellen Lernverfahrens unter Verwendung des einen oder der mehreren Muster, um eine Wiederherstellungsaktion zur Abschwächung des Ereignisses zu bestimmen.
Verfahren nach Anspruch 1, ferner umfassend das Verwalten einer Anzahl von Wiederherstellungsaktionen in einer Aktionsdatenbank im Schalter, wobei eine jeweilige Wiederherstellungsaktion einem oder mehreren Mustern entspricht.
Verfahren nach Anspruch 2, ferner umfassend das Anwenden der maschinellen Lerntechnik auf die Aktionsdatenbank unter Verwendung des einen oder mehrerer Muster, um die Wiederherstellungsaktion aus der Aktionsdatenbank zu bestimmen.
Verfahren nach Anspruch 1, wobei die maschinelle Lerntechnik ein vortrainiertes Modell ist, das auf den Schalter geladen ist.
Das Verfahren nach Anspruch 1, das weiterhin umfasst: Auswerten der Wiederherstellungsaktion in einer Schattendatenbank, wobei die Schattendatenbank eine Kopie der Schalterkonfigurationsdatenbank ist und nicht zur Bestimmung der Konfiguration des Schalters verwendet wird; und Bestimmen, ob die Wiederherstellungsaktion einen Konflikt in der Schalterkonfigurationsdatenbank erzeugt, basierend auf der Auswertung.
Das Verfahren nach Anspruch 1, das weiterhin umfasst: Bestimmen, ob das Ereignis ein kritisches Problem ist; und als Reaktion darauf, dass es sich bei dem Ereignis um ein nicht kritisches Problem handelt, Ausführen der Wiederherstellungsaktion auf dem Switch.
Verfahren nach Anspruch 6, das ferner umfasst, als Reaktion darauf, dass das Ereignis ein kritisches Problem ist, eine Bestätigung von einem Benutzer zu erhalten, bevor die Wiederherstellungsaktion ausgeführt wird.
Das Verfahren nach Anspruch 1, das weiterhin umfasst: Bestimmen eines Satzes von Merkmalsgruppen des Schalters, wobei eine jeweilige Merkmalsgruppe ein oder mehrere verwandte Merkmale des Schalters enthält; und Bestimmen eines Auslösers, der das Ereignis anzeigt, basierend auf der Überwachung des Satzes von Merkmalsgruppen, wobei der Auslöser einer Merkmalsgruppe entspricht, die mit dem Ereignis verbunden ist.
Verfahren nach Anspruch 8, ferner umfassend das Vergleichen, unter Verwendung der Mustererkennungstechnik, eines Satzes von Mustern, die für die Merkmalsgruppe definiert sind, mit Ereignisbeschreibungen im Ereignisprotokollsegment.
Verfahren nach Anspruch 1, wobei der Bereich der Einträge umfasst: einen ersten Bereich von Einträgen vor einem Protokolleintrag, der die Ereignisbeschreibung im Ereignisprotokoll umfasst; und einen zweiten Bereich von Einträgen, der auf den Protokolleintrag folgt.
Ein nicht-transitorisches computerlesbares Speichermedium, das Befehle speichert, die, wenn sie von einem Computer ausgeführt werden, den Computer veranlassen, ein Verfahren zur Erleichterung eines Ereignisanalysesystems in einem Schalter durchzuführen, wobei das Verfahren Folgendes umfasst: Ermitteln einer dem Schalter zugeordneten Ereignisbeschreibung aus einem Ereignisprotokoll des Schalters, wobei die Ereignisbeschreibung einem Eintrag in einer Tabelle in einer Schalterkonfigurationsdatenbank des Schalters entspricht, und wobei eine entsprechende Datenbank im Schalter eine relationale Datenbank ist; Erhalten eines Ereignisprotokollsegments, das ein Teil des Ereignisprotokolls ist und die Ereignisbeschreibung basierend auf einem Bereich von Einträgen umfasst; Anwenden einer Mustererkennungstechnik auf das Ereignisprotokollsegment basierend auf dem Eintrag in der Schalterkonfigurationsdatenbank, um ein oder mehrere Muster zu bestimmen, die einem mit der Ereignisbeschreibung verbundenen Ereignis entsprechen; und Anwendung eines maschinellen Lernverfahrens unter Verwendung des einen oder der mehreren Muster, um eine Wiederherstellungsaktion zur Abschwächung des Ereignisses zu bestimmen.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 11, wobei das Verfahren ferner das Verwalten einer Anzahl von Wiederherstellungsaktionen in einer Aktionsdatenbank im Schalter umfasst, wobei eine jeweilige Wiederherstellungsaktion einem oder mehreren Mustern entspricht.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 12, wobei das Verfahren ferner das Anwenden der maschinellen Lerntechnik auf die Aktionsdatenbank unter Verwendung des einen oder mehrerer Muster umfasst, um die Wiederherstellungsaktion aus der Aktionsdatenbank zu bestimmen.
Nicht-transitorisches, computerlesbares Speichermedium nach Anspruch 11, wobei die maschinelle Lerntechnik ein vortrainiertes Modell ist, das auf den Schalter geladen ist.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 11, wobei das Verfahren weiterhin umfasst: Auswerten der Wiederherstellungsaktion in einer Schattendatenbank, wobei die Schattendatenbank eine Kopie der Schalterkonfigurationsdatenbank ist und nicht zur Bestimmung der Konfiguration des Schalters verwendet wird; und Bestimmen, ob die Wiederherstellungsaktion einen Konflikt in der Schalterkonfigurationsdatenbank erzeugt, basierend auf der Auswertung.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 11, wobei das Verfahren weiterhin umfasst: Bestimmen, ob das Ereignis ein kritisches Problem ist; und als Reaktion darauf, dass es sich bei dem Ereignis um ein nicht kritisches Problem handelt, Ausführen der Wiederherstellungsaktion auf dem Switch.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 16, wobei das Verfahren ferner umfasst, als Reaktion darauf, dass das Ereignis ein kritisches Problem ist, eine Bestätigung von einem Benutzer zu erhalten, bevor die Wiederherstellungsaktion ausgeführt wird.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 11, wobei das Verfahren weiterhin umfasst: Bestimmen eines Satzes von Merkmalsgruppen des Schalters, wobei eine jeweilige Merkmalsgruppe ein oder mehrere verwandte Merkmale des Schalters enthält; und Bestimmen eines Auslösers, der das Ereignis anzeigt, basierend auf der Überwachung des Satzes von Merkmalsgruppen, wobei der Auslöser einer Merkmalsgruppe entspricht, die mit dem Ereignis verbunden ist.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 18, wobei das Verfahren ferner das Vergleichen eines Satzes von Mustern, die für die Merkmalsgruppe definiert sind, mit Ereignisbeschreibungen in dem Ereignisprotokollsegment unter Verwendung der Mustererkennungstechnik umfasst.
Nicht-transitorisches computerlesbares Speichermedium nach Anspruch 11, wobei der Bereich der Einträge umfasst: einen ersten Bereich von Einträgen vor einem Protokolleintrag, der die Ereignisbeschreibung im Ereignisprotokoll umfasst; und einen zweiten Bereich von Einträgen, der auf den Protokolleintrag folgt.