DE202016107454U1 - System für die Aufrechterhaltung der Service-Level von Netzwerken - Google Patents

Abstract

System für die Aufrechterhaltung der Service-Level von Netzwerken, das System umfassend: einen computerlesbaren Speicher, der Aufzeichnungen von Netzwerkvorfällen speichert; und einen oder mehrere Prozessoren, die so konfiguriert sind, dass sie auf den computerlesbaren Speicher zugreifen und Anweisungen ausführen, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: mithilfe der Aufzeichnungen der Netzwerkvorfälle, die im computerlesbaren Speicher gespeichert sind, eine erste Vielzahl der Netzwerkvorfälle zu identifizieren, die über einen ersten Teil des Messzeitraums auftreten; eine zweite Vielzahl von Netzwerkvorfällen zu identifizieren, die über einen zweiten Teil des Messzeitraums auftreten, der nach dem ersten Zeit des Messzeitraums erfolgt; eine Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung der ersten und zweiten Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum zu ermitteln; Schweregrad-Metrikwerte für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle zu erzeugen, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jeder der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind; und mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung auszuwählen.

Description

• HINTERGRUND
• Informationen werden über Computernetzwerke übertragen. Die Informationen werden als Bits dargestellt, die in Paketen gruppiert sind. Die Pakete werden von einem Netzwerkgerät, z.B. über Switches und Router, zum anderen weitergereicht, so dass die Informationen über die Computernetzwerke weitergeleitet werden. Jedes Paket wird von seiner Quelle an ein Ziel übertragen, das in den Header-Informationen des jeweiligen Paketes angegeben ist. Quelle und Ziel eines Paketes können jeweils in verschiedenen Teilen des Netzwerks liegen, wobei jeder Teil von einer anderen Partei betrieben wird. Zwischen der Quelle und dem Ziel kann es verschiedene mögliche Routen geben.
• Ein Wide Area Network („WAN“), z. B. das Internet, kann mehrere Subnetze, so genannte autonome Systeme („AS“) beinhalten. Ein autonomes System ist Teil eines Netzwerks, der für andere Teile des Netzwerks so erscheint, als hätte er eine einheitliche Verwaltung einer einzigen Routing-Richtlinie und als stelle er gegenüber den übrigen Teilen des Netzwerks ein einheitliches Bild erreichbarer Netzwerkziele dar, z.B. als Netzwerkadressräume, die über das AS erreichbar sind. In manchen Fällen kann ein autonomes System durch seine Autonomous System Number (ASN) gekennzeichnet sein, die innerhalb des Netzwerks eindeutig ist. Typischerweise hat ein Betreiber eines autonomen Systems Vereinbarungen mit Dritten, dass er Daten über eines oder mehrere der von dem jeweiligen Dritten betriebenen autonomen Systeme leiten darf, gewöhnlich in Form einer „Vergütungs“-Vereinbarung für die Durchleitung, die nutzungsabhängig in Rechnung gestellt oder als „unentgeltliche” Peering-Vereinbarung behandelt wird. Die Daten können dann an einem Peering Point, einem Multi-homed Netzwerkgerät, einem Internet eXchange Point (IXP) oder ähnlichem, gemäß der Vereinbarung zwischen den Betreibern der autonomen Systeme, von einem autonomen System zum anderen übertragen werden. Netzwerkgeräte im WAN können dann über eine Netzwerkroute kommunizieren, die mehrere autonome Systeme überspannen kann.
• ZUSAMMENFASSUNG
• In einigen Aspekten bezieht sich die Offenbarung auf die Aufrechterhaltung der Service-Level von Netzwerken. Dies beinhaltet die Identifizierung einer ersten Vielzahl von Netzwerkvorfällen, die über einen ersten Teil eines Messzeitraums auftreten, und die Identifizierung einer zweiten Vielzahl von Netzwerkvorfällen, die über einen zweiten Teil des Messzeitraums auftreten, der nach dem ersten Teil des Messzeitraums erfolgt. Dies beinhaltet die Ermittlung einer Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung der ersten und zweiten Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum. Dies beinhaltet die Erzeugung von Schweregrad-Metrikwerten für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jeder der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind. Dies beinhaltet dann die Auswahl von mindestens einem der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung.
• In einigen Aspekten bezieht sich die Offenbarung auf ein System für die Aufrechterhaltung der Service-Level von Netzwerken. Das System beinhaltet einen computerlesbaren Speicher, der Aufzeichnungen von Netzwerkvorfällen speichert, und einen oder mehrere Prozessoren, die so konfiguriert sind, dass sie auf den computerlesbaren Speicher zugreifen und Anweisungen ausführen, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen, mithilfe der Aufzeichnungen der im computerlesbaren Speicher gespeicherten Netzwerkvorfälle eine erste Vielzahl von Netzwerkvorfällen zu identifizieren, die über einen ersten Teil des Messzeitraums auftreten, und des Weiteren eine zweite Vielzahl von Netzwerkvorfällen zu identifizieren, die über einen zweiten Teil des Messzeitraums auftreten, der nach dem ersten Teil des Messzeitraums erfolgt. Die Anweisungen veranlassen bei Ausführung den Prozessor, eine Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung auf die erste und zweite Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum zu ermitteln, Schweregrad-Metrikwerte für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle zu erzeugen, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jedem der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind, und mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung auszuwählen.
• KURZBESCHREIBUNG DER ZEICHNUNGEN
• Die obigen und verbundenen Objekte, Merkmale und Vorteile der vorliegenden Offenbarung werden durch Bezugnahme auf die folgende Beschreibung in Verbindung mit den begleitenden Figuren besser verständlich, worin:
• 1 ein Blockdiagramm einer Beispielnetzwerkumgebung ist;
• 2A und 2B Blockdiagramme sind, die veranschaulichen, wie die Kommunikation um einen Netzwerkausfall umgeleitet werden kann;
• 3A eine Beispieltabelle ist, die Service-Level-Vorfallsaufzeichnungen darstellt;
• 3B eine Beispieltabelle ist, die Aggregationen von Service-Level-Vorfallsaufzeichnungen darstellt;
• 4 ein Ablaufdiagramm ist, das ein Beispielverfahren für die Aufrechterhaltung der Service-Level von Netzwerken veranschaulicht;
• 5 ein Venn-Diagramm ist, das einen Filterschnittpunkt für die Priorisierung von Vorfällen veranschaulicht;
• 6 ein Blockdiagramm eines Netzwerkgeräts ist, das für die Verwendung in den verschiedenen beschriebenen Implementierungen geeignet ist; und
• 7 ein Blockdiagramm eines Computersystems ist, das für die Verwendung in den verschiedenen beschriebenen Implementierungen geeignet ist.
• Der Klarheit halber sind ggf. nicht alle Komponenten in jeder Abbildung beschriftet. Die Zeichnungen sollen nicht maßstabgetreu sein. Ähnliche Referenznummern und Kennzeichnungen in den verschiedenen Figuren weisen auf ähnliche Elemente hin.
• AUSFÜHRLICHE BESCHREIBUNG
• Computergeräte kommunizieren über eine Netzwerkroute, die mehrere autonome Systeme („AS“) überspannen kann. Ein AS-Netzwerk oder ein Teil eines AS-Netzwerks, der als Subnetz bezeichnet wird, stellt Services für verschiedene Netzwerkkunden unter einer Vielzahl von Kontexten bereit, einschließlich u. a. Datenservicenetzwerke, Zugriffsnetzwerke, Übertragungsnetzwerke und Netzwerke für mehrere Mandanten (z. B. Computer-„Clouds“, gehostete Computerservices und Network as a Service). Netzwerkadministratoren machen Zusagen gegenüber ihren Kunden und garantieren dabei bestimmte Service-Level, die vom Netzwerk bereitgestellt werden. Diese Service-Level-Agreements („SLA“) definieren eines oder mehrere Service-Level-Ziele (service level objectives, „SLO“) für die Betriebszeit und Qualität des Netzwerks (z. B. Bandbreite, Latenz usw.). Im Allgemeinen ist das SLA eine vertragliche Beschränkung der Toleranz bei Vorfällen, die unvermeidlich auftreten werden und den Netzwerkservice unterbrechen oder verschlechtern. Es kann jedoch schwierig sein, zu ermitteln, ob ein Netzwerkvorfall oder eine Gruppe von Vorfällen genug Auswirkung auf die Service-Level-Ziele hat, um gegen ein SLA zu verstoßen, schon bevor gegen das SLA verstoßen wurde.
• Wie hierin beschrieben, kann ein Netzwerkadministrator einen Servicemonitor verwenden, um Service-Level-Vorfälle (service level incidents, „SLI“) zu verfolgen. Der Administrator kann zum Beispiel ein SLO-Korrelationstool verwenden, das Vorfälle identifiziert, bei denen ein Software-Defined-Network(„SDN“)-Controller sich weigert, einem neuen Kommunikationsfluss Ressourcen zuzuweisen, z. B. weil die Netzwerkkapazität zum Zeitpunkt der Anfrage nicht ausreichte, um die Anforderungen des neuen Flusses zu unterstützen. Es ist unwahrscheinlich, dass jede solche Weigerung zu einem SLA-Verstoß führt. Jedoch können wiederholte Weigerungen zu einem SLA-Verstoß führen. In einigen Implementierungen erfolgt ein SLI immer dann, wenn ein Kommunikationsfluss auf eine Netzwerküberlastung trifft. Einige Kommunikationsprotokolle implementieren ein Überlastungsbenachrichtigungsprotokoll und ein Servicemonitor kann Flüsse erkennen über sie benachrichtigt werden, bei denen das Überlastungsbenachrichtigungsprotokoll eine Überlastung angibt. Im Transmission Control Protocol („TCP“) sind zum Beispiel Header-Bits für Explicit Congestion Notification („ECN“) reserviert und ein Monitor kann einen SLI aufzeichnen, wenn der Fluss Pakete beinhaltet und die ECN-Bits auf die Angabe einer Überlastung eingestellt sind. Als weiteres Beispiel beinhaltet ein SLA in einigen Implementierungen Mindestanforderungen für Werte einer oder mehrerer Metriken für die Kommunikationsqualität gemittelt über einen festen oder gleitenden Zeitraum. Die Kommunikation über das Netzwerk kann mithilfe einer oder mehrerer Metriken gemessen werden, einschließlich z. B. Bandbreite, Durchsatz und Datendurchsatz, wie unten näher beschrieben. Service-Level-Vorfälle können zum Beispiel Vorfälle beinhalten, bei denen eine Netzwerkverbindung nicht verfügbar ist, ein Netzwerkfluss abgelehnt oder unterbrochen wird, ein Netzwerkfluss auf eine Netzwerküberlastung trifft und/oder Vorfälle, bei denen ein Wert für eine Metrik der Netzwerkkommunikationsqualität einen Schwellenwert über- bzw. unterschreitet.
• SLA-Verstöße können durch genaue Überwachung der SLI vorhergesagt und verhindert werden, bevor sie auftreten. Zum Beispiel kann wie hierin beschrieben ein Monitor oder ein Netzwerkanalysator SLI-Aufzeichnungen von einem oder mehreren Überwachungstools sammeln, einige der Aufzeichnungen entsprechend verschiedenen Kriterien herausfiltern und wichtige SLIs aus den restlichen Aufzeichnungen identifizieren. In einigen Implementierungen wird jedem SLI ein Bedeutungsgewicht zum Beispiel auf Basis einer Auswirkung auf den entsprechenden Vorfall zugewiesen. In einigen Implementierungen beinhaltet ein SLA zum Beispiel ein Toleranzlevel für Netzwerkausfälle über einen Zeitraum. Wenn der Service-Level-Vorfall gegen Ende des Zeitraums erfolgt, kann er basierend darauf, ob frühere Vorfälle das Toleranzlevel beeinflusst haben, höher oder niedriger gewichtet werden. Das heißt zum Beispiel, wenn ein bestimmtes SLA sieben Stunden Ausfallzeit pro Monat erlaubt, können einige Sekunden Ausfallzeit gegen Ende eines Monats niedriger gewichtet werden, wenn es diesen Monat nur minimale Ausfallzeit gab, und höher, wenn es umfassende Ausfallzeit gab, was schließlich zu den sieben tolerierten Stunden in diesem Monat oder deren Überschreitung führte. Der Monitor oder Netzwerkanalysator kann dann einen oder mehrere bestimmte Vorfälle identifizieren, in denen Korrekturmaßnahmen den größten Nutzen bei der Verhinderung von SLA-Verstößen haben. Die Ursache dieser bestimmten Vorfälle kann für die Behebung identifiziert werden. Die Vorhersage und Verhinderung dieser SLA-Verstöße kann den Betrieb des Netzwerks durch Aufrechterhaltung der Service-Level von Netzwerken verbessern.
• 1 ist ein Blockdiagramm einer Beispielnetzwerkumgebung 100. Als allgemeine Übersicht stellt 1 mehrere Endknoten 120 dar, die für die Kommunikation mit verschiedenen Hostknoten 160 über ein Netzwerk 110 konfiguriert sind. Auch wenn das Internet ein gutes Beispiel eines großen Netzwerks 110 ist, gilt diese Beschreibung für andere Netzwerke gleichermaßen. Wie gezeigt, greifen Endknoten 120 auf Netzwerk 110 über einen Netzwerkteil 112 zu, der zum Beispiel ein Teil des Netzwerks 110, ein Zugriffsnetzwerk (z. B. eines Internet Service Provider („ISP“)), ein Übertragungsnetzwerk oder ein beliebiges Netzwerk sein kann, das die Kommunikation zwischen den Endknoten 120 und den Hostknoten 160 ermöglicht. Wie in 1 gezeigt, beinhaltet das Netzwerk 110 Netzwerkteile 114 und 116. Alle Netzwerkteile 112, 114 und 116 sind veranschaulichende Netzwerkregionen und können Teile desselben autonomen Systems sein, können getrennte Systeme sein oder können mehrere autonome Systeme beinhalten. Der Netzwerkteil 114 beinhaltet verschiedene Netzwerkknoten 140, über die Daten zwischen den Endknoten 120 und den Hostknoten 160 weitergeleitet werden. Einige Implementierungen können von der Verwendung eines Software-Defined-Network („SDN“) profitieren, in dem Datenweiterleitungsgeräte von einem oder mehreren Netzwerkcontrollern remote gesteuert werden. Demgemäß wird, auch wenn dies in einigen Implementierungen nicht erforderlich ist, der Netzwerkteil 114 als ein SDN veranschaulicht, in dem die Netzwerkknoten 140 Datenweiterleitungsgeräte sind, die von einem oder mehreren Netzwerkcontrollern 146 remote gesteuert werden. Der Netzwerkteil 116 beinhaltet die Hostknoten 160, die zum Beispiel repräsentativ für Hostgeräte in einem oder mehreren Rechenzentren oder Servicezentren sind.
• 1 veranschaulicht außerdem einen Netzwerkmonitor 180, der sich im Netzwerk 110 befindet, mit der Fähigkeit, Service-Level-Vorfälle (service level incidents, „SLI“), die innerhalb des Bereichs des Netzwerks 110 erfolgen, direkt oder indirekt zu überwachen. Der Netzwerkmonitor 180 verwendet eines oder mehrere Speichergeräte 188, um Aufzeichnungen der SLI zu pflegen. Auch wenn nur ein Netzwerkmonitor 180 gezeigt wird, verwenden einige Implementierungen mehrere Netzwerkmonitore 180, die über das gesamte Netzwerk 110 verteilt sind. In einigen solchen Implementierungen nutzen die verteilten Netzwerkmonitore 180 eines oder mehrere Speichergeräte 188 gemeinsam. Ein Netzwerkanalysator 190 greift auf die SLI-Aufzeichnungen zu, die in dem einen oder den mehreren Speichergeräten 188 gespeichert sind, und analysiert diese. In einigen Implementierungen ist der Netzwerkmonitor 180 der Netzwerkanalysator 190 oder beinhaltet diesen. In einigen Implementierungen ist der Netzwerkanalysator 190 getrennt oder verschieden vom Netzwerkmonitor 180.
• Die in 1 veranschaulichten Endknoten 120 und Hostknoten 160 sind Teilnehmer in verschiedenen Datenkommunikationen durch die Netzwerkumgebung 100. Ein Endknoten 120 und Hostknoten 160 kann zum Beispiel ein Computersystem 910 wie in 7 gezeigt und unten beschrieben sein. Ein Hostknoten 160 kann zum Beispiel ein Computersystem sein, das einen Service bereitstellt, und ein Endknoten 120 kann ein Computersystem sein, das den Service nutzt. Ein Hostkonten 160 kann Daten zu einem Endknoten 120 übertragen, der dann als Senke für die übermittelten Daten dient. Genauso kann ein Endknoten 120 Daten zu einem Hostknoten 160 übertragen, der dann als Senke für die übermittelten Daten dient. Ein Endknoten 120 und ein Hostknoten 160 können zwischen dem Senden und Empfangen von Daten abwechseln. Ein Endknoten 120 kann zum Beispiel eine Datenanfrage an einen Hostknoten 160 senden und ein Hostkonten 160 kann auf die Anfrage durch Bereitstellung von Daten antworten. In einigen Fällen können mehrere Endknoten 120 und/oder mehrere Hostknoten 160 an einem Austausch der Daten teilnehmen. Ein Hostknoten 160 kann als Vermittler zwischen mehreren Endknoten 120 fungieren, z. B. als Kommunikationsermöglicher. Jeder Endknoten 120 und Hostknoten 160 kann eine beliebige Anzahl von Rollen erfüllen. Jedoch nehmen in einer solchen Kapazität Endknoten 120 und Hostknoten 160 an Kommunikationen teil, die über die Netzwerkumgebung 100 übertragen werden. Eine Kommunikation zwischen einem Endknoten 120 und einem Hostknoten 160 kann als Fluss von Datenpakten strukturiert sein, z. B. in Form von Datenpaketen in Übereinstimmung mit einem Internetprotokoll wie IPv4 oder IPv6. Ein Fluss kann zum Beispiel ein Open Systems Interconnection „OSI“) Schicht-4-Transportprotokoll wie zum Beispiel das Transmission Control Protocol („TCP“) oder das Stream Control Transmission Protocol („SCTP“) sein, das über die Netzwerke 110, 112, 114 und 116 über IP übertragen wird.
• Ein Endknoten 120 kann ein Laptop, Desktop, Tablet, Electronic Pad, Personal Digital Assistant, Smartphone, Videospielgerät, Fernsehgerät, Fernseh-Zusatzbox (auch „Settop-Box“ genannt), Kiosk, tragbarer Computer oder ein anderes solches Gerät sein. Ein Endgerät 120 kann in der Lage sein, dem Benutzer Inhalte darzustellen oder die Darstellung von Inhalten für den Benutzer unterstützen. In einigen Implementierungen führt ein Endgerät 120 ein Betriebssystem aus, das die Ausführung von Softwareanwendungen auf dem Endgerät 120 verwaltet. In einigen Implementierungen wird das Betriebssystem vom Hersteller oder einem Händler zusammen mit dem Endgerät 120 geliefert. Anwendungen werden innerhalb eines Rechenkontextes ausgeführt, der von dem Betriebssystem gesteuert wird, d.h. „auf” dem Betriebssystem aufsetzend. Anwendungen können nativ mit dem Betriebssystem installiert sein oder später z. B. durch einen Händler oder Benutzer installiert werden. Bei manchen Ausführungsformen kann das Betriebssystem bzw. können die Anwendungen in das Endgerät 120 eingebettet sein, z.B. in einem Festspeicher kodiert.
• Ein Hostknoten 160 kann ein Computer sein, der einen Service für andere Hostknoten 160 oder für Endknoten 120 bereitstellt. Ein Hostknoten 160 kann zum Beispiel ein E-Mail-Server, ein Dateiserver, ein Datenzwischenspeicher, ein Name-Server, ein Content-Server, ein Datenrelais, ein Webseiten-Server oder jeder andere Netzwerk-Service-Host sein. In einigen Implementierungen sind einer oder mehrere Hostknoten 160 Teil eines Content-Delivery-Netzwerks („CDN“). Auch wenn nur in Netzwerkteil 116 gezeigt, können Hostknoten 160 über die gesamte Netzwerkumgebung 100 verteilt sein.
• Die Netzwerkumgebung 100 beinhaltet Netzwerkteile 110, 112, 114 und 116, über die Endknoten 120 und Hostknoten 160 Informationen austauschen. Die Netzwerkknoten 110, 112, 114 und 116 können unter einheitlicher Steuerung, z. B. als Teil desselben AS-Netzwerks, oder unter verschiedener Steuerung sein. Jeder Netzwerkteil 110, 112, 114 und 116 besteht aus verschiedenen Netzwerkgeräten (z. B. Netzwerkknoten 140), die miteinander verbunden sind, um einen oder mehrere Kommunikationspfade (z. B. Datenverbindungen 142) zwischen teilnehmenden Geräten zu bilden. Netzwerkknoten 140 sind zum Beispiel im Netzwerkteil 114 mit Verbindungen 142 veranschaulicht, die eine Datenebene bilden. Jeder Netzwerkknoten 140 veranschaulicht mindestens eine Netzwerkschnittstelle für das Übertragen und Empfangen von Daten über eine verbundene Datenebenenverbindung 142, die zusammen das Netzwerk bilden. In einigen Implementierungen ist das in 6 gezeigte und unten beschriebene Netzwerkgerät 730 für die Verwendung als ein Netzwerkknoten 140 geeignet.
• Die Netzwerkumgebung 100, einschließlich der verschiedenen Netzwerkteile 110, 112, 114, 116, kann aus mehreren Netzwerken bestehen, die jeweils ein Local Area Network (LAN), z. B. ein Unternehmensintranet, ein Metropolitan Area Network (MAN), ein Wide Area Network (WAN), ein Inter-Netzwerk wie das Internet oder ein Peer-to-Peer-Netzwerk, z. B. ein Wi-Fi-Adhoc-Peer-to-Peer-Netzwerk sind. Die Datenverbindungen zwischen Geräten können jede Kombination aus kabelgebunden Verbindungen (z. B. Glasfaser, Mesh, koaxial, Cat-5, Cat-5e, Cat-6 usw.) und/oder drahtlosen Verbindungen (z. B. Funk, Satellit oder mikrowellenbasiert) sein. Die Netzwerkteile 112 und 114 sind als Teile eines größeren Netzwerkteils 110 veranschaulicht, um Beispielen, in denen der Netzwerkmonitor 180 für das Netzwerk 110 verantwortlich ist, zu entsprechen; jedoch können die Netzwerkteile 110, 112, 114 und 116 jeweils öffentliche, private oder eine beliebige Kombination aus öffentlichen und privaten Netzwerken sein. Die Netzwerke können Datennetzwerke bzw. Kommunikationsnetzwerke beliebiger Art und/oder Form sein.
• In einigen Implementierungen sind eines oder mehrere der Netzwerkteile 110, 112, 114 oder 116 mithilfe von Visualisierung der Netzwerkfunktionen (network function virtualization, „NFV“) implementiert. In einem NFV-Netzwerk sind einige Netzwerkfunktionen, die normalerweise in einem Netzwerkgerät 140 implementiert sind, als Software implementiert, die auf einem Prozessor (z. B. einem Allzweck-Prozessor) ausgeführt wird. Bei manchen Ausführungsformen beinhaltet diese virtualisierte Netzwerkfunktion Lastausgleich und/oder Zugangskontrolle und/oder Firewall und/oder Einbruchmeldung und/oder Routing. Andere Netzwerkfunktionen können ebenfalls in dieser Weise virtualisiert werden. In einigen Implementierungen beinhaltet die virtualisierte Netzwerkfunktion Funktionen für die Berichterstellung von Netzwerkmetriken, Netzwerkunterbrechungen und andere Indikatoren von SLIs für einen Netzwerkmonitor 180.
• In einigen Implementierungen sind einer oder mehrere Netzwerkteile 110, 112, 114 und 116 ein Software-Defined-Network („SDN“), in dem Datenweiterleitungsgeräte (z. B. Netzwerkknoten 140) durch Remote-Netzwerkcontroller 146 getrennt von den Datenweiterleitungsgeräten gesteuert werden, z. B. wie in Bezug auf Netzwerkteil 114 gezeigt. In einigen Implementierungen werden die SDN-Netzwerkknoten 140 von einem oder mehreren SDN-Controllern 146 über Steuerebenenverbindungen 148 getrennt, und somit bandextern, von den Datenebenenverbindungen 142 gesteuert. In einigen Implementierungen werden die SDN-Netzwerkknoten 140 über bandinterne Datenebenenverbindungen 142 oder über eine Hybridkombination von bandinternen Datenebenenverbindungen 142 und bandexternen Steuerebenenverbindungen 148 gesteuert. In einigen Implementierungen eines SDN-Netzwerks fließen Mehrpaket-Datenübertragungen über das Netzwerk auf zugewiesenen Routen. Wenn ein SDN-Datenweiterleitungsgerät ein Paket für einen nicht erkannten Fluss empfängt, weist das Datenweiterleitungsgerät dem neuen Fluss eine Route zu oder fordert einen Controller zur Zuweisung auf. Jedes nachfolgend empfangene Paket des Flusses wird dann vom Datenweiterleitungsgerät über dieselbe Route weitergeleitet. In einigen Implementierungen wählt der SDN-Controller 146 eine Route für einen neuen Fluss auf Basis der Kriterien aus, die mit dem Fluss verbunden sind, z. B. auf Basis der Anforderungen, die mit einem OSI Schicht-7-Anwendungsprotokoll verbunden sind, die im Fluss identifiziert werden. Zum Beispiel kann ein Fluss für Voice-over-IP („VoiP“) eine niedrige Netzwerklatenz erfordern, während ein Fluss für das File Transfer Protocol („FTP“) eine höhere Latenz tolerieren kann, und der Controller 146 priorisiert die Leitung des VoiP-Verkehr über Routen mit niedriger Latenz entsprechend. In einigen Implementierungen lehnt der Controller 146 den Fluss ab, wenn er keine geeignete Route für den neuen Fluss identifizieren kann. Die Ablehnung des Flusses kann einen Service-Level-Vorfall darstellen. In einigen Implementierungen meldet der Controller 146 die Ablehnung eines neuen Flusses dem Netzwerkmonitor 180, z. B. über Verbindung 186. In einigen Implementierungen ist die Verbindung 186 Teil der Steuerebene. In einigen Implementierungen ist die Verbindung 186 Teil der Datenebene. In einigen Implementierungen ist der in 6 gezeigte und unten beschriebene SDN-Controller 720 für die Verwendung als ein Netzwerkcontroller 146 geeignet.
• Die Netzwerkumgebung 100 beinhaltet einen oder mehrere Netzwerkmonitore 180. In einigen Implementierungen ist ein Netzwerkmonitor 180 ein Hardwaregerät, das einen oder mehrere Computerprozessoren, Speichergeräte, Netzwerkschnittstellen und Verbindungsschaltungen beinhaltet. In einigen Implementierungen ist ein Netzwerkmonitor 180 ein Computergerät, zum Beispiel das in 7 veranschaulichte und unten beschriebene Computergerät 910. Jeder Netzwerkmonitor 180 befindet sich in oder in Kommunikation mit dem Netzwerk 110, mit der Fähigkeit, Service-Level-Vorfälle (service level incidents, „SLI“), die innerhalb des Bereichs des Netzwerks 110 erfolgen, direkt oder indirekt zu überwachen. In einigen Implementierungen meldet ein Netzwerkcontroller 146 dem Netzwerkmonitor 180 Service-Level-Vorfälle. In einigen Implementierungen melden Kommunikationsteilnehmer, z. B. Hostknoten 160, dem Netzwerkmonitor 180 Service-Level-Vorfälle. In einigen Implementierungen erkennt der Netzwerkmonitor 180 einen Service-Level-Vorfall. In einigen Implementierungen überträgt der Netzwerkmonitor 180 zum Beispiel regelmäßig ein Testpaket (z. B. ein Internet Control Message Protocol(„ICMP“)-Paket) und verwendet Eigenschaften einer Netzwerkantwort auf das Testpaket, um den Netzwerkstatus zu ermitteln. Der Netzwerkmonitor 180 zeichnet in einem oder mehreren Speichergeräten 188 Informationen auf, die für den jeweiligen SLI repräsentativ sind. In einigen Implementierungen wird jeder SLI als eine Aufzeichnung in einer Datenstruktur dargestellt, die zur Analyse in einem oder mehreren Speichergeräten 188 gespeichert sind. In einigen Implementierungen wird jeder SLI als ein Eintrag in einer Datenbank dargestellt, z. B. als ein Satz von Einträgen oder Tabellenzeilen in einer relationalen Datenbank. Aufzeichnungen für jeden SLI können in einem entsprechenden Format gespeichert werden. In einigen Implementierungen befinden das eine oder die mehreren Speichergeräte 188 im Netzwerkmonitor 180 oder am gleichen Ort. In einigen Implementierungen befinden sich das eine oder die mehreren Speichergeräte 188 außerhalb des Netzwerkmonitors 180, z. B. als getrennter Datenserver, Network Attached Storage („NAS“) oder Storage Area Network („SAN“). In einigen Implementierungen beinhaltet der Netzwerkmonitor 180 des Weiteren einen Netzwerkanalysator 190.
• Die Datenspeichergeräte 188 sind Datenspeicher, entweder im Netzwerkmonitor 180 oder extern davon, aber für den Netzwerkmonitor 180 verfügbar. Das Speichergerät 188 kann ein beliebiges Gerät oder eine Sammlung von Geräten beinhalten, die für das Speichern computerlesbarer Daten geeignet sind. Geeignete Datenspeichergeräte beinhalten flüchtigen oder nicht flüchtigen Speicher Network Attached Storage („NAS“) und Storage Area Network („SAN“). Ein Datenspeichergerät kann eines oder mehrere Massenspeichergeräte enthalten, die sich an einem einzigen oder verteilt über verschiedene Orte befinden können. Für die Datenspeicherung geeignete Geräte sind u.a. Halbleiterspeichergeräte, wie z.B. EPROM, EEPROM, SDRAM und Flash-Speicher-Geräte. Geräte, die für die Speicherung geeignet sind, umfassen magnetische Datenträger, z. B. interne Festplatten oder Wechselplatten, magnetooptische Datenträger, optische und andere solche Disklaufwerke mit höherer Kapazität. Die Datenspeichergeräte können virtualisiert sein. Auf die Datenspeichergeräte kann über einen Vermittlungsserver bzw. über ein Netzwerk zugegriffen werden. Datenspeichergeräte können die Daten als eine Sammlung von Dateien, Datenblöcken oder Brocken strukturieren. Datenspeichergeräte können für die Wiederherstellung nach Fehlern sorgen, z.B. mithilfe redundanter Speicherung bzw. mithilfe von Daten zur Wiederherstellung nach Fehlern (z.B. Paritätsbits). Die Speichergeräte 188 können eine Datenbank hosten, z. B. eine relationale Datenbank. Bei manchen Ausführungsformen werden die Daten als Einträge in einer oder mehreren Datenbankentabellen in einer im Datenspeicher gespeicherten Datenbank aufgezeichnet. In einigen Implementierungen wird auf die Daten mithilfe einer Abfragesprache wie der Structured Query Language („SQL“) oder einer Variante wie PostgreSQL zugegriffen. Die Speichergeräte 188 können ein Dateispeichersystem hosten. Daten können als Knowledge-Base strukturiert gespeichert werden. Daten können in verschlüsselter Form gespeichert werden. Der Zugriff auf gespeicherte Daten kann durch eines oder mehrere Authentifizierungssysteme beschränkt werden.
• In einigen Implementierungen kann ein SLI auftreten, wenn die Kommunikation über das Netzwerk unter ein bestimmtes Qualitätslevel fällt. Ein SLA kann zum Beispiel minimale und maximale Schwellenwerte für Durchschnittswerte einer oder mehrerer Qualitätsmetriken für die Netzwerkkommunikation beinhalten, z. B. Durchsatz, Bandbreite, Latenz usw. Durchsatz ist die Menge von Informationen, z. B. Anzahl von Bits, die über einen Teil des Netzwerks in einem festen Zeitraum übertragen wird. Bandbreite ist ein maximal möglicher Durchsatz, wobei die Begrenzung entweder physikalisch oder technisch ist (z.B. einer Richtlinie unterliegt). Eine Überlastung tritt auf, wenn die Netzwerkgeräte versuchen, mehr Durchsatz zu erhalten, als die verfügbare Bandbreite bewältigen kann. Goodput ist der Informationsdurchsatz ohne sonstigen Datenverkehr, wie z.B. Netzwerkkonfigurationsdaten, Protokollsteuerungsinformationen oder die wiederholte Übertragung verlorengegangener Pakete. Latenz ist der Zeitraum von der Übertragung eines Paketes durch einen Absender und der Verarbeitung des Paketes durch den betreffenden Empfänger, d.h. die Sendeverzögerung. Nachlauf (Lag) ergibt sich aus einer Verzögerung, z.B. der Wahrnehmung von Verzögerungen aus Sicht eines Kommunikationsteilnehmers. Zu Nachlauf kann es z.B. kommen, wenn die Latenz eine Toleranzschwelle übersteigt, z.B. wo die Verzögerung für einen Endbenutzer merklich wird oder bestimmte Quality-of-Service(QoS)-Anforderungen für ein bestimmtes Kommunikationsprotokoll nicht erfüllt. Auch wenn eine Verzögerung auftreten kann, wenn Pakete bei der Übertragung verloren gehen oder beschädigt werden, wird dies allgemein als synonym mit Latenz behandelt. Latenz (und Nachlauf) können anhand einer Übertragung in einer Richtung oder als Zeit für die Übertragung in beiden Richtungen für die Übertragung eines Paketes und eine darauf erfolgende Reaktion oder Bestätigung gemessen werden. In manchen Fällen wird die Latenz als Funktion einer Pfadlänge gemessen, d.h. der Anzahl der auf einer Route liegenden Geräte des Vermittlungsnetzwerks („Hops“). Jeder Hop kann zur Gesamtlatenz der Route beitragen. Somit ist zu erwarten, dass ein Pfad mit einer geringeren Anzahl Hops auch eine geringere Latenz hat, und auch weniger Gelegenheiten für Fehlfunktionen bei der Weiterleitung. Variierende Paketverzögerungen (d.h. Übertragungsjitter) bedeutet Schwankungen der Latenz über die Zeit, z.B. da, wo Pakete stoßweise oder mit schwankender Verzögerung eintreffen. Übertragungsfehler können zu einer Verschlechterung des Goodput, zu hoher Latenz oder zu Nachlauf und unerwünschten Schwankungen in der Verzögerung führen. Messgrößen für Übertragungsfehler sind u.a. die Anzahl der Pakete, die erneut gesendet werden müssen, das Verhältnis der Anzahl Pakete, die erneut gesendet werden müssen, zur Anzahl derjenigen Pakete, die bei der ersten Versendung erfolgreich ankommen, und Sendungen, die mit Überlastungen verbunden sind, z.B. Pakete, bei denen „Explicit Congestion Notification“(ECN)-Fahnen gesetzt sind. Ein SLI kann für jeden solchen Übertragungsfehler aufgezeichnet werden, oder wenn Werte für eine oder mehrere Metriken des Übertragungsfehlers einen entsprechenden Schwellenwert über- oder unterschreiten.
• Der Netzwerkanalysator 190 ist für die Analyse der SLI-Aufzeichnungen verantwortlich, die vom Netzwerkmonitor 180 identifiziert werden. In einigen Implementierungen ist der Netzwerkanalysator 190 eine Komponente oder ein Modul des Netzwerkmonitors 180. In einigen Implementierungen ist der Netzwerkanalysator 190 ein Hardwaregerät, das einen oder mehrere Computerprozessoren, Speichergeräte, Netzwerkschnittstellen und Verbindungsschaltungen beinhaltet. In einigen Implementierungen ist der Netzwerkanalysator 190 ein Computergerät, zum Beispiel das in 7 veranschaulichte und unten beschriebene Computergerät 910. Der Netzwerkanalysator 190 liest die SLI-Aufzeichnungen aus den Speichergeräte 188 und priorisiert die dargestellten Service-Level-Vorfälle. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 einen oder mehrere bestimmte Service-Level-Vorfälle, die von den SLI-Aufzeichnungen dargestellt werden, als hohe Priorität. Ein Netzwerkadministrator kann dann die Vorfälle mit hoher Priorität weiter untersuchen und Maßnahmen ergreifen, um die Grundursache der Vorfälle zu beheben.
• 2A und 2B sind Blockdiagramme, die veranschaulichen, wie die Kommunikation um einen Netzwerkausfall 214 umgeleitet werden kann. In einigen Fällen kann ein SLI das Ergebnis eines anscheinend nicht verbundenen Netzwerkausfalls sein. Ein SLI an einer Netzwerkverbindung kann zum Beispiel das Ergebnis einer Überbuchung (Over-Subscription) der Verbindung sein, die durch einen Ausfall bei einer anderen Netzwerkverbindung an einem anderen Ort im Netzwerk verursacht wird. 2A und 2B veranschaulichen dieses Beispiel.
• Als allgemeine Übersicht veranschaulichten 2A und 2B eine Netzwerkumgebung 200, die drei verschiedene Netzwerkregionen 240 _(A), 240 _(B) und 240 _(c) beinhaltet. Die veranschaulichte Netzwerkumgebung 200 beinhaltet einen Datenpfad AC 210 zwischen Regionen 240 _(A) und 240 _(c), einen Datenpfad AB 220 zwischen Regionen 240 _(A) und 240 _(B) und einen Datenpfad BC 230 zwischen Regionen 240 _(B) und 240 _(c). Die veranschaulichten Datenpfade 210, 220, und 230 sind als einzelne Linien gezeigt, die eine beliebige Form des Netzwerkpfads darstellen, einschließlich z. B. eine einzelne Direktverbindung, eine Vielzahl von Verbindungen, eine Verbindungsaggregation, eine Netzwerkstruktur, ein Netzwerk von Verbindungen usw. In 2A fließt Datenfluss 216 direkt von Netzwerkregionen 240 _(A) zu 240 _(c) über Datenpfad AC 210. In 2B blockiert jedoch ein Fehler 214 entlang Datenpfad AC 210 den Fluss 216 von Region 240 _(A) zu Region 240 _(c).
• In 2B fließen Daten von Region 240 _(A) zu Region 240 _(c) durch Region 240 _(B), um den Fehler 214 zu umgehen. Das heißt, der direkte Datenfluss 216 wird durch einen Datenfluss 226 von Region 240 _(A) zu Region 240 _(B) und einen Datenfluss 236 von Region 240 _(B) zu Region 240 _(c) ersetzt. Falls die zusammengesetzte Fähigkeit der Pfade AB 220 und BC 230 (d. h. Pfad ABC) gleich oder größer als die Kapazität des ausgefallenen Pfads AC 210 ist, führt der Fehler 214 nicht zu einem Service-Level-Vorfall (service level incident, „SLI“). Jedoch kann die Umleitung des Verkehrs von Region 240 _(A) zu Region 240 _(c) über Region 240 _(B) mithilfe des alternativen Pfads ABC anderen Verkehr entlang einer oder beider Komponentenpfade AB 220 und BC 230 beeinträchtigen, was zu einem SLI führen könnte. Wenn zum Beispiel jeder Pfad 210, 220 und 230 dieselbe Kapazität und dieselbe Nutzungsrate hat, würde der Fehler 214 die Nutzungsrate von Pfad ABC (Pfade 220 und 230) verdoppeln. Falls diese Rate anfänglich über 50 % liegt, übersteigt die Verdoppelung der Rate die Kapazität und führt zu einem SLI.
• Falls die resultierende Last auf einem Netzwerkpfad in der Nähe der Kapazität liegt, kann es einen SLI bei später hinzugefügtem Verkehr geben. Auch wenn die anfängliche Nutzung einer der Pfade vergleichsweise gering war, gibt es wahrscheinlich einen SLI, wenn die resultierende zusammengefasst Last die Kapazität des Datenpfads übersteigt. Wenn zum Beispiel die kombinierte Last auf Netzwerkpfad BC 230 nach Umleitung des Verkehrs um Fehler 214 in der Nähe der vollen Nutzung liegt, schlägt später hinzugefügter Verkehr von Region 240 _(B) zu Region 240 _(c) entlang des Netzwerkpfads BC 230 fehl. Die resultierende SLI-Aufzeichnung wird mit Verkehr entlang Netzwerkpfad BC 230 verbunden. Die tatsächliche Grundursache ist jedoch der Fehler 214 entlang Netzwerkpfad AC 210.
• Die in den 2A und 2B veranschaulichte Situation ist vereinfacht. In der Praxis beeinträchtigt Verkehr, der um einen Fehler geleitet wird, eine Vielzahl alternativer Pfade und löst Service-Level-Vorfälle an möglicherweise nicht erwarteten Orten aus. Die Analyse der SLI-Aufzeichnungen insgesamt kann jedoch dazu beitragen, eine zugrundeliegende Ursache zu identifizieren. Demgemäß sucht in einigen Implementierungen der Netzwerkanalysator 190 nach Sätzen von Service-Level-Vorfällen auf verschiedenen Pfaden, die zusammengefasst angeben, wo eine Behebungsaktion gerechtfertigt ist. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 korrelierte Vorfälle, die mit verschiedenen Services verbunden sind, bei denen die Ursache wahrscheinlicher das Netzwerk ist, als dass die Ursache mehr mit dem Service selbst verbunden ist.
• In einigen Fällen tritt ein Service-Level-Vorfall (service level incident, „SLI“) auf, wenn Inhalte eines Pakets in einem Fluss nicht durch ein Netzwerk oder einen Teil eines Netzwerks propagiert werden können, oder wenn Inhalte eines Pakets in einem Fluss nicht auf eine Weise propagiert werden, die für eine oder mehrere Netzwerkqualitätsmetriken zufriedenstellend ist. Ein SLI kann zum Beispiel auftreten, wenn Netzwerkressourcen keinem Fluss zugewiesen werden können, wenn Überlastungen bei einem Netzwerkfluss auftreten oder wenn Werte für eine oder mehrere Netzwerkkomunikationsmetriken einen entsprechenden Schwellenwert über- oder unterschreiten. Ein Service Level Agreement („SLA“) kann eine bestimmte Anzahl an Vorfällen oder eine bestimmte zusammengefasste Auswirkung von Vorfällen während eines bestimmten Messzeitraums erlauben. Ein SLA kann zum Beispiel die Unterbrechung oder Ablehnung von bis zu 1 % des Flusses wöchentlich tolerieren. In einigen Implementierungen hat ein Zeitraum feste Start- und Endzeiten, z. B. kann eine Woche als Sonntagmorgen um Mitternacht bis zur folgenden Samstagnacht um 23:59 Uhr definiert werden. In einigen Implementierungen ist ein Zeitraum ein gleitendes Zeitfenster, z. B. kann eine Woche als Fenster von 7 aufeinanderfolgenden Tagen oder ein beliebiges Fenster von 168 Stunden definiert werden. In einigen Implementierungen kann ein Messzeitraum ein getrennter Zeitblock oder ein gleitendes Zeitfenster sein, wie durch das SLA angegeben. Die Vorfallstoleranz für einen Messzeitraum wird durch jedes Auftreten eines Vorfalls verringert. Das heißt, wenn ein Vorfall auftritt, wird die restliche Vorfallstoleranz für den Messzeitraum, der den Vorfall umfasst, um die Auswirkung des Vorfalls verringert. Wenn ein SLA 10 Stunden Ausfallzeit pro Monat erlaubt oder toleriert, bleibt bei 2 Stunden Ausfallzeit eine restliche Vorfallstoleranz von 8 Stunden für den Rest des Monats. Wenn ein SLI die Vorfallstoleranz für einen SLA übersteigt, ist der SLI ein SLA-Verstoß.
• In einigen Implementierungen wird, von zwei vergleichbaren Vorfällen, die in der Bedeutung oder Netzwerkauswirkung ähnlich sind, wobei ein SLI mehr Auswirkung auf ein restliches Toleranzlimit eines SLA hat als ein anderer SLI, der SLI mit der größeren Auswirkung auf das restliche Toleranzlimit gegenüber dem anderen SLI priorisiert. In einigen Implementierungen wird ein SLI, der dazu führt, dass ein restliches Toleranzlimit für ein SLA unter einen Schwellenwert fällt, als schwerwiegenderer Vorfall betrachtet, als ein vergleichbarer SLI, der nicht dazu führt, dass ein restliches Toleranzlimit für einen SLA unter den Schwellenwert fällt. In einigen Implementierungen, in denen ein SLA mehr Auswirkung auf ein restliches Toleranzlimit für ein SLA als ein anderer SLI hat, wird der SLI mit der größeren Auswirkung auf das restliche Toleranzlimit gegenüber dem anderen SLI priorisiert, auch wenn andere Faktoren die Priorisierung des anderen SLI nahe legen, z. B. auf Basis der Bedeutung oder der Auswirkung auf das Netzwerk. In einigen Implementierungen werden mehrere Faktoren bei der Identifizierung verwendet, welcher SLI priorisiert werden soll. Zum Beispiel veranschaulicht die unten erörterte 5 ein Beispiel der Verwendung mehrerer Filter zur Identifizierung eines Satzes der Prioritätsvorfälle.
• 3A und 3B sind Beispieltabellen, die Service-Level-Vorfallsaufzeichnungen darstellen. In einigen Implementierungen werden Service-Level-Vorfälle durch Netzwerkvorfallsaufzeichnungen dargestellt. In einigen Implementierungen beinhaltet eine Netzwerkvorfallsaufzeichnung nur genug Informationen, um den entsprechenden Vorfall zu identifizieren. In einigen Implementierungen beinhaltet eine Netzwerkvorfallsaufzeichnung zusätzliche Informationen, z. B. Informationen, die bei der späteren Diagnose nützlich sein können. In einigen Implementierungen beinhaltet eine Netzwerkvorfallsaufzeichnung mindestens Zeit- und Datumsinformationen für das Auftreten eines Vorfalls, Routeninformationen für das Auftreten des Vorfalls und eine Beschreibung oder Klassifizierung für einen Service, der durch das Auftreten des Vorfalls beeinträchtigt wurde.
• 3A veranschaulicht ein Beispiel einer Tabelle 300 von Service-Level-Vorfall(service level incident, „SLI“)-Aufzeichnungen, in der jeder SLI durch eine jeweilige Zeile 372 dargestellt ist, die Dateneinträge für einen beeinträchtigten Fluss umfasst (z. B. einen Fluss, für den keine Route zugewiesen werden konnte oder für den die zugewiesene Route nicht mehr verfügbar ist). Wie gezeigt, beinhaltet jede Zeile 372 Dateneinträge für eine Quelle 312 und ein Ziel 316 des beeinträchtigten Flusses, ein Service-Level-Ziel (service level objective, „SLO“) 322 und eine Servicekennung 332 für den Service, der durch den beeinträchtigten Fluss unterstützt wird, sowie eine Ereigniszeit 352, wann der Fluss beeinträchtigt war. Die Quelle 312 und das Ziel 316 werden durch Kennungen für die teilnehmenden Enden des Flusses dargestellt, z. B. Netzwerkadressen, Netzwerknamen, Adressbereiche, Domänennamen oder andere solche Kennungen. Das SLO 322 wird durch eine Kennung für das SLO dargestellt, z. B. einen Namen oder eine Zahl. In einigen Implementierungen ist der Name von SLO 322 eine beschreibende Zeichenfolge. In einigen Implementierungen ist der Name von SLO 322 eine Gruppenklassifizierungskennung. In einigen Implementierungen ist der Name von SLO 322 eine beschreibende Eigenschaft des Ziels, z. B. ein maximales Vorfallstoleranzlimit. Die Servicekennung 332 identifiziert den Service oder die Servicegruppe, der/die vom SLI beeinträchtigt wird. Wenn der Fluss zum Beispiel mit einem bestimmten Service verbunden ist, der von einem oder mehreren Hostknoten 160 gehostet wird, kann die Servicekennung 332 eine Zeichenfolge sein, die den Service identifiziert. Die Ereigniszeit 352 ist ein Zeitstempel, der angibt, wann der SLI aufgetreten ist oder wann die SLI-Aufzeichnung eingegeben wurde (was im Allgemeinen mit dem Auftreten des SLI übereinstimmen kann, jedoch möglicherweise nicht genau derselbe Moment ist). Auch wenn dies als einzelne Tabelle 300 gezeigt wird, können die in 3A dargestellten Informationen als mehrere Tabellen oder in einer nicht relationalen Datenbankstruktur gespeichert werden. Die Tabelle 300 wird als Beispiel dafür bereitgestellt, wie Service-Level-Vorfälle in Datenspeicher 188 dargestellt werden können; in einigen Implementierungen können alternative Datenstrukturen verwendet werden.
• 3B veranschaulicht eine Beispieltabelle 305, die Aggregationen von Service-Level-Vorfallsaufzeichnungen darstellt. In der Beispielstabelle 305 wird jeder Satz von SLI-Aufzeichnungen durch eine jeweilige Zeile 374 dargestellt, die zusammengefasste Dateneinträge enthält, die SLI-Aufzeichnungen für verschiedene beeinträchtigte Flüsse entsprechen (z. B. wie in der in 3A dargestellten Tabelle 300 gezeigt). Wie gezeigt, beinhaltet jede Zeile 374 Dateneinträge für eine Quellregion 314 und Zielregion 318 der Flüsse, die durch einen oder mehrere der dargestellten Sätze von Vorfällen beeinträchtigt werden, ein zusammengefasstes SLO-Level 324 und eine zusammengefasste Service- oder Serviceklassifizierungskennung 334 für die Services, die durch die beeinträchtigten Flüsse unterstützt werden, eine Zahl 340 der SLI-Aufzeichnungen im Satz und Start 354 und Ende 356 eines Ereigniszeitbereichs, in dem die Flüsse beeinträchtigt waren. Der Quellenbereich 314 und Zielbereich 318 werden durch Kennungen für die teilnehmenden Enden der Flüsse dargestellt, z. B. Netzwerkadressen, Netzwerknamen, Adressbereiche, Domänennamen oder andere solche Kennungen. Das SLO-Level 324 wird durch eine Kennung für eine Generalisierung des SLO dargestellt, z. B. einen Namen oder eine Zahl. In einigen Implementierungen kann der dargestellte Satz des SLI dieselbe SLO haben. In diesem Fall kann das SLO-Level 324 gleich dem SLO 322 sein. In einigen Implementierungen kann der dargestellte Satz des SLI eine gemeinsame SLO-Eigenschaft haben und die gemeinsame SLO-Eigenschaft wird als SLO-Level 324 verwendet. In einigen Implementierungen ist das SLO-Level 324 eine Generalisierung der Ziele für die Flüsse, die durch den Satz dargestellt werden. Ähnlich identifiziert die Service- oder Serviceklassenkennung 334 den Service oder die Servicegruppe, der/die von den dargestellten SLIs beeinträchtigt wird. In einigen Implementierungen kann die Tabelle 305 nach der Zahl 340 sortiert werden. Der Start 354 und 356 des Ereigniszeitbereichs sind Zeitstempel, die die Zeitstempel 352 für den dargestellten Satz von Vorfällen einrahmen. Auch wenn dies als einzelne Tabelle 305 gezeigt wird, können die in 3B dargestellten Informationen als mehrere Tabellen oder in einer nicht relationalen Datenbankstruktur gespeichert werden. Die Tabelle 305 wird als Beispiel dafür bereitgestellt, wie Sätze von Service-Level-Vorfällen in Datenspeicher 188 dargestellt werden können; in einigen Implementierungen können alternative Datenstrukturen verwendet werden.
• In einigen Implementierungen werden die in der Tabelle 305 dargestellten Daten, die in 3B gezeigt wird, durch Anwendung eines oder mehrerer Filter oder Aggregationsabfragen der Daten erzeugt, die in der Tabelle 300 dargestellt sind, die in 3A gezeigt wird. In einigen Implementierungen wird zum Beispiel eine Abfrage verwendet, um ähnliche SLIs zu identifizieren, die in einem bestimmten Zeitbereich entlang verschiedener Netzwerkkorridore passieren, wobei ein Netzwerkkorridor eine Gruppe von Netzwerkpfaden zwischen zwei Endknotensammlungen oder Regionen ist. Ein Netzwerkkorridor kann zum Beispiel durch parallele Netzwerkpfade, gemeinsame Netzwerkpfade, Kooperationsnetzwerkpfade Verbindungsaggregationen und andere solchen Redundanzen charakterisiert sein. Die Enden eines Netzwerkkorridors können geografische Regionen, Netzwerkserviceregionen, kolokalisierte Computergeräte, Rechenzentren, naheliegende Adressbereiche usw. sein. In einigen Implementierungen verwendet der Netzwerkanalysator 190 ein Paar Netzwerkadresssätze, um einen Netzwerkkorridor darzustellen, wobei jeder der Sätze der Netzwerkadressen Endknoten für das jeweilige Ende des Netzwerkkorridors identifiziert oder definiert.
• Eine Abfrage oder ein Satz von Abfragen kann verwendet werden, um SLI-Aufzeichnungen für häufig auftretende Vorfälle zu identifizieren, die getrennte Services entlang eines bestimmten Netzwerkkorridors beeinträchtigen, die ein Problem in diesem Netzwerkkorridor angeben können. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 Sätze von SLI-Aufzeichnungen mit einer Zahl 340 über einem gewissen Mindestschwellenwert, der zum Beispiel eine vorkonfigurierte Zahl oder ein vorkonfigurierter Prozentsatz sein kann.
• 4 ist ein Ablaufdiagramm, das ein Beispielverfahren 400 für die Aufrechterhaltung der Service-Level von Netzwerken veranschaulicht. Als allgemeine Übersicht von Verfahren 400 identifiziert ein Netzwerkanalysator 190 in Phase 410 eine erste Vielzahl von Netzwerkvorfällen, die über einen ersten Teil des Messzeitraums auftreten. In Phase 420 identifiziert der Netzwerkanalysator 190 eine zweite Vielzahl von Netzwerkvorfällen, die über einen zweiten Teil des Messzeitraums auftreten, der nach der ersten Zeit des Messzeitraums erfolgt. In Phase 430 ermittelt der Netzwerkanalysator 190 eine Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung der ersten und zweiten Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum. In Phase 440 erzeugt der Netzwerkanalysator 190 Schweregrad-Metrikwerten für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jedem der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind. Und in Phase 450 wählt der Netzwerkanalysator 190 mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung aus.
• Unter genauerer Bezugnahme auf 4 identifiziert in Phase 410 ein Netzwerkanalysator 190 eine erste Vielzahl von Netzwerkvorfällen, die über einen ersten Teil des Messzeitraums auftreten. Der Netzwerkanalysator 190 identifiziert die Netzwerkvorfälle durch Zugreifen auf die Aufzeichnungen, die durch den/die Netzwerkmonitor(en) 180 in Datenspeicher 188 gespeichert werden. In einigen Implementierungen fragt der Netzwerkanalysator 190 den Datenspeicher 188 ab, um SLI-Aufzeichnungen für Vorfälle zu identifizieren und/oder abzurufen, die während des ersten Teils des Messzeitraums auftreten. In einigen Implementierungen verwendet der Netzwerkanalysator 190 eine Abfrage (z. B. eine SQL-Abfrage), um die Aufzeichnungen zu identifizieren, während er gleichzeitig die Aufzeichnungen gemäß Kriterien, die den Umfang der Analyse begrenzen, herausfiltert oder zusammenfasst. Die Kriterien können zum Beispiel Aufzeichnungen für Vorfälle beseitigen, die offensichtlich isoliert auftreten oder nicht verbundene Services betreffen. In einigen Implementierungen schränken die Kriterien die identifizierten Aufzeichnungen auf einen bestimmten Netzwerkkorridor ein. In einigen Implementierungen identifizieren die Kriterien Cluster von Vorfällen, z. B. in Bezug auf Zeit, Geografie oder Netzwerktopologie. In einigen Implementierungen gibt die Abfrage nur Aufzeichnungssätze für Aufzeichnungen von Vorfällen zurück, die mehr als eine Schwellenwertzahl der Zeiten während des ersten Teils des Messzeitraums passierten. In einigen Implementierungen werden mehrere Abfragen oder Filter verwendet, um Vorfallsaufzeichnungen für das Einschließen in die erste Vielzahl der Netzwerkvorfälle zu identifizieren. Die unten dargestellte 5 veranschaulicht ein Venn-Diagramm für die Identifizierung eines Satzes von Prioritätsvorfällen 540 mithilfe einer Kombination von Abfragen oder Filtern 510, 520 und 530.
• Unter erneuter Bezugnahme auf Phase 410 von 4 stellt der erste Teil des Messzeitraums einen historischen Kontext für die Analyse der Ereignisse in späteren Teilen des Messzeitraums bereit, z. B. einen zweiten Teil des Messzeitraums. Der erste Teil des Messzeitraums kann zum Beispiel ein Zeitraum sein, der mit Beginn des ersten Messzeitraums beginnt und bei einem Prozentsatz des Messzeitraums endet, z. B. bei der Hälfte oder siebenundsechzig Prozent des Messzeitraums. Der erste Teil kann zum Beispiel ein Zeitraum sein, der mit Beginn des Messzeitraums beginnt und zum Zeitpunkt des Zugriffs auf den Datenspeicher 188 in Phase 410 endet. In einigen Implementierungen beginnt der erste Teil der Zeit zu Beginn des Messzeitraums und endet zu Beginn eines zweiten Teils der Zeit, die wiederum am Ende des Messzeitraums oder zum Zeitpunkt des letzten Service-Level-Vorfalls endet. In solchen Implementierungen ist das Ende des ersten Teils der Zeit ein Versatz vom Ende des Messzeitraums, z. B. sodass der zweite Teil der Zeit eine feste Länge z. B. die letzten sechs Stunden des Messzeitraums hat, oder sodass der zweite Teil der Zeit ein vorkonfigurierter Prozentsatz des Messzeitraums z. B. die letzten zehn Prozent des Messzeitraums ist. In einigen Implementierungen wird der erste Teil der Zeit so ausgewählt, dass der zweite Teil der Zeit kürzer als eine feste Zeitlänge oder ein vorkonfigurierter Prozentsatz des Messzeitraums ist. Das heißt zum Beispiel, dass in einigen Implementierungen der erste Teil der Zeit sechs Stunden vor Ende des Messzeitraums oder bei neunzig Prozent des Messzeitraums endet, wobei der kürzere Zeitraum gilt (wobei sechs Stunden oder neunzig Prozent Beispielzahlen sind, andere Längen sind ebenfalls geeignet).
• In Phase 420 identifiziert der Netzwerkanalysator 190 eine zweite Vielzahl von Netzwerkvorfällen, die über einen zweiten Teil des Messzeitraums auftreten, der nach dem ersten Zeit des Messzeitraums erfolgt. Der Netzwerkanalysator 190 identifiziert die Netzwerkvorfälle durch Zugreifen auf die Aufzeichnungen, die durch den/die Netzwerkmonitor(en) 180 in Datenspeicher 188 gespeichert werden. In einigen Implementierungen fragt der Netzwerkanalysator 190 den Datenspeicher 188 ab, um SLI-Aufzeichnungen für Vorfälle zu identifizieren und/oder abzurufen, die während des zweiten Teils des Messzeitraums auftreten. In einigen Implementierungen verwendet der Netzwerkanalysator 190 eine Abfrage (z. B. eine SQL-Abfrage), um die Aufzeichnungen gemäß Kriterien, die den Umfang der Analyse begrenzen, zu identifizieren. Die Kriterien können zum Beispiel für Aufzeichnungen von Vorfällen ausgewählt werden, die zu den in Phase 410 identifizierten Vorfällen gehören oder mit ihnen verbunden sind. In einigen Implementierungen verwendet der Netzwerkanalysator 190 dieselben Abfragen und Filter, die in Phase 410 verwendet wurden, angewandt auf den zweiten Teil des Messzeitraums.
• In einigen Implementierungen ist der zweite Teil des Messzeitraums fortlaufend zum ersten Teil des Messzeitraums wie oben beschrieben. Der zweite Teil des Messzeitraums kann zum Beispiel ein Zeitraum sein, der mit Ende des ersten Messzeitraums beginnt und am Ende des Messzeitraums endet. Der zweite Teil kann zum Beispiel ein Zeitraum sein, der mit Ende des ersten Zeitraums beginnt und zum Zeitpunkt des Zugriffs auf den Datenspeicher 188 in Phase 420 endet. In einigen Implementierungen überlappt sich der zweite Teil mit dem ersten Teil oder umfasst diesen. Im Allgemeinen stellt der erste Teil des Messzeitraums einen Kontext für die Analyse der Netzwerkleistung während des zweiten Teils des Messzeitraums bereit. Service-Level-Vorfälle, die während des zweiten Teils des Messzeitraums auftreten, können dann im Vergleich zum Kontext identifiziert werden, der durch den ersten Teil oder den ersten und zweiten Teil des Messzeitraums bereitgestellt werden.
• In Phase 430 ermittelt der Netzwerkanalysator 190 eine Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung der ersten und zweiten Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum. Für jedes SLA, das durch die Service-Level-Vorfällen in der ersten und zweiten Vielzahl der Netzwerkvorfälle beeinträchtigt wird, identifiziert der Netzwerkanalysator 190 ein entsprechendes Vorfallstoleranzlimit und eine Auswirkung auf das entsprechende Vorfallstoleranzlimit, z. B. ein resultierendes restliches Toleranzlimit für den Messzeitraum.
• In Phase 440 erzeugt der Netzwerkanalysator 190 Schweregrad-Metrikwerten für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jeder der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind. Jedem SLI kann ein Score für die Darstellung des Schweregrads des Vorfalls gemäß einer oder mehreren Metriken zugewiesen werden. In einigen Implementierungen berücksichtigen die Metriken eine Zahl der entsprechenden Vorfälle während des Messzeitraums. In einigen Implementierungen beinhalten die Metriken einen Priorisierungswert, der mit dem beeinträchtigten Netzwerkpfad verbunden ist. In einigen Implementierungen weisen die Metriken den verschiedenen Services verschiedene Werte zu, z. B. einen höheren Schweregrad-Score für Vorfälle, die Services mit höherer Priorität beeinträchtigen. Der Score-Wert, d. h. der Schweregrad-Metrikwert, wird dann mit einem Faktor angepasst, d. h. gewichtet, der das entsprechende restliche Vorfallstoleranzlimit für das SLA darstellt, das vom Vorfall beeinträchtigt wird. In einigen Implementierungen erhöht sich der Gewichtungsfaktor, wenn sich das restliche Vorfallstoleranzlimit null nähert. In einigen Implementierungen beinhaltet die Schweregradmetrik eine Vorfallsfrequenz für den Messzeitraum.
• In Phase 450 wählt der Netzwerkanalysator 190 mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung aus. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 einen oder mehrere Vorfälle mit Schweregrad-Metrikwerten über einem Schwellenwert. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 einen oder mehrere Vorfälle mit Schweregrad-Metrikwerten im obersten Perzentil (z. B. oberstes 75. Perzentil oder oberstes 90. Perzentil usw.). In einigen Implementierungen identifiziert der Netzwerkanalysator 190 einen oder mehrere Vorfälle mit den höchsten Schweregrad-Metrikwerten für Vorfälle, die im zweiten Teil des Messzeitraums auftreten. In einigen Implementierungen wird die Behebung eines Vorfalls mit einem hohen Schweregrad-Metrikwert die gesamten Netzwerkbedingungen wahrscheinlicher verbessern als die Behebung von niedriger eingestuften Vorfällen.
• 5 ist ein Venn-Diagramm, das einen Filterschnittpunkt für die Priorisierung von Vorfällen veranschaulicht. In einigen Implementierungen von Verfahren 400 wählt der Netzwerkanalysator 190 eine Teilmenge der zweiten Netzwerkvorfälle für die Behebung auf Basis einer Vielzahl von Vorfallsfiltern aus. Wie in 5 gezeigt, identifiziert der Netzwerkanalysator 190 in einigen Implementierungen einen eingestuften Satz von Vorfällen mit hoher Priorität durch Identifizierung des Schnittpunkts 540 der Filter 510, 520 und 530. Ein erster Filter 510 identifiziert Vorfälle mit den höchsten Auftretenshäufigkeiten, z. B. mithilfe einer oder mehreren Abfragen der Service-Level-Vorfallsaufzeichnungen, die in Speicher 188 gespeichert sind. In einigen Implementierungen wählen die Abfragen Aggregationen ähnlicher Vorfälle aus und sortieren sie nach einer jeweiligen Zahl der Vorfälle in der jeweiligen Zusammenfassung. Ein zweiter Filter 520 identifiziert Vorfälle, die mit den größten Clustern verbunden sind. In einigen Implementierungen sind zum Beispiel Vorfälle nach gemeinsamen oder ähnlichen Attributen gruppiert. In einigen Implementierungen sind Vorfälle nach beeinträchtigten Netzwerkverbindungen, Knoten, Routen oder Endknotenregionen gruppiert, sodass die resultierenden Cluster Vorfälle gruppieren, die denselben Netzwerkkorridor beeinträchtigen. Der Clustering-Filter 520 identifiziert die größten Cluster und ermöglicht es dem Netzwerkanalysator 190, Vorfälle zu priorisieren, die mit den größten Clustern verbunden sind. Ein dritter Filter 530 identifiziert Vorfälle mit den höchsten gewichteten Auswirkungsscores. In einigen Implementierungen wird Vorfällen ein Wert für eine oder mehrere Auswirkungsmetriken zugewiesen, die die Auswirkung des Vorfalls auf die Netzwerkqualität messen. Die Werte werden durch einen oder mehrere Faktoren gewichtet, einschließlich z. B. ein restliches Toleranzlevel für ein entsprechendes Service-Level-Ziel oder ein Service-Level-Agreement. In einigen Implementierungen identifiziert der Netzwerkanalysator 190 einen Satz von Prioritätsvorfällen auf Basis des Schnittpunkts 540 dieser Filter 510, 520 und 530. In einigen Implementierungen werden andere Filter verwendet. In einigen Implementierungen werden zusätzliche Filter verwendet.
• In einigen Implementierungen erzeugt der Netzwerkanalysator 190 einen Bericht, der die ausgewählten Netzwerkvorfälle identifiziert. In einigen Implementierungen wird der Bericht einem oder mehreren Systembetreibern per E-Mail, SMS-Textnachricht, automatischem Telefonanruf, Sofortnachricht oder über ein anderes verfügbares Medium für die Kommunikation bereitgestellt.
• 6 ist ein Blockdiagramm eines Beispielnetzwerkgeräts 730. Das Beispielnetzwerkgerät 730 ist für die Verwendung bei der Implementierung hierin beschriebenen zwischengeschalteten Netzwerkgeräte, in Übereinstimmung mit einer veranschaulichenden Implementierung, geeignet. Das unten unter Bezugnahme auf 7 beschriebene Computersystem 910 kann auch als Netzwerkgerät 730 geeignet sein. Mit Visualisierung der Netzwerkfunktionen (network function virtualization, „NFV“) werden zum Beispiel einige Netzwerkfunktionen, die normalerweise in Hardwareschaltungen implementiert sind, als Software implementiert, die in einem Prozessor (z.B. einem Allzweck-Prozessor) ausgeführt wird. Als allgemeiner Überblick beinhaltet das Netzwerkgerät 730 ein Steuermodul 744 und einen Speicher 736, z. B. für das Speichern von Gerätekonfigurations- und Routingdaten. Das Netzwerkgerät 730 beinhaltet eine Weiterleitungs-Engine 734, die die Gerätekonfigurations- und Routingdaten, die in Speicher 736 gespeichert sind, zur Verwaltung des Datenverkehrs an Netzwerkschnittstellen 738 verwendet. In einigen Implementierungen ist das Netzwerkgerät 730 für die Verwendung in einem Software-Defined-Network („SDN“) implementiert, in dem das Netzwerkgerät 730 durch einen externen SDN-Controller 720 gesteuert wird, z. B. über eine Steuerebenenverbindung 712. Der SDN-Controller 720 beinhaltet ein Steuermodul 742 und Speicher 726. Das unten unter Bezugnahme auf 7 beschriebene Computersystem 910 kann auch als SDN-Controller 720 geeignet sein. In einigen Implementierungen sind eine oder mehrere funktionelle Komponenten von Netzwerkgerät 730 oder SDN-Controller 720 als Softwarekomponenten implementiert, die von einem Allzweck-Prozessor ausgeführt werden.
• Unter genauerer Bezugnahme auf 6 beinhaltet das Netzwerkgerät 730 einen Satz von Netzwerkschnittstellen 738. Jede Netzwerkschnittstelle 738 kann durch eine oder mehrere Verbindungen mit einem oder mehreren externen Geräten verbunden sein, die ein Netzwerk bilden (z. B. das in 1 gezeigte Netzwerk 110). Externe Geräte senden Datenpakete über diese Verbindungen zum Netzwerkgerät 730, die über eine Eingangsschnittstelle (z. B. Netzwerkschnittstelle 738(a)) ankommen. Das Netzwerkgerät 730 leitet die empfangenen Datenpakete über eine Eingangsschnittstelle (z. B. Netzwerkschnittstelle 738(c)) an einen geeigneten nächsten Hop weiter. In einigen Implementierungen ermittelt die Weiterleitungs-Engine 734, welche Netzwerkschnittstelle 738 für die Weiterleitung jedes empfangenen Datenpakets verwendet werden soll.
• Die Weiterleitungs-Engine 734 verwendet Konfigurations- und Routingdaten in Speicher 736, um den Datenverkehr an Netzwerkschnittstellenports 738 zu verwalten. Die Konfigurations- und Routingdaten im Speicher 736 werden vom Steuermodul 744 gesteuert. In einigen Implementierungen aktualisiert die Weiterleitungs-Engine 734 Paket-Header, bevor sie Pakete an eine Eingangsnetzwerkschnittstelle 738 weiterleitet. Die Weiterleitungs-Engine 734 kann zum Beispiel ECN-, TTL- oder Prüfsummeninformationen in Paket-Header aktualisieren. In einigen Implementierungen beinhaltet ein ankommendes Paket Routinganweisungen, die in einen Header des ankommenden Pakets eingebettet sind, und die Weiterleitungs-Engine 734 leitet das Paket auf Basis der eingebetteten Anweisungen weiter.
• Der Speicher 736 kann jedes Gerät sein, das für die Speicherung computerlesbarer Daten geeignet ist. Beispiele hierfür sind u.a. Halbleiterspeichergeräte, wie z.B. EPROM, EEPROM, SRAM und Flash-Speichergeräte. In einigen Implementierungen beinhaltet der Speicher 736 eines Netzwerkgeräts 730 speziellen Speicher für die Identifizierung von Paketflüssen, z. B. Ternary Content Addressable Memory (TCAM). In einigen Implementierungen beinhaltet der Speicher 736 eines Netzwerkgeräts 730 speziellen Speicher für die Pufferung von Paketflüssen, während sie das Netzwerkgerät 730 durchqueren. Ein Netzwerkgerät 730 kann eine beliebige Anzahl von Speichergeräten 736 haben.
• Steuermodul 744 verwaltet die Leistung des Netzwerkgeräts 730. In einigen Implementierungen empfängt das Steuermodul 744 Anweisungen von einem externen Steuergerät. Zum Beispiel kann das Steuermodul 744 in einem Software-Defined-Network („SDN“) Steueranweisungen von einem SDN-Controller 720 empfangen, der sich außerhalb des Netzwerkgeräts 730 befindet. In einigen Implementierungen verarbeitet das Steuermodul 744 Routeninformationspakete (z. B. Steuerebenenpakete) und aktualisiert den Speicher 736 mit Änderungen an Routingtabellen, die von der Weiterleitungs-Engine 734 verwendet wurden. In einigen Implementierungen liest das Steuermodul 744 Daten, die an einer Eingangsschnittstelle 738 ankommen, in einen Puffer, der im Speicher 736 gespeichert ist. Das Steuermodul 744 kann mithilfe eines Allzweck-Prozessors oder einer Logikschaltung für spezielle Zwecke implementiert werden, z. B. einer anwendungsspezifischen integrierten Schaltung („ASIC“).
• 7 ist ein Blockdiagramm eines Beispielcomputersystems 910. Das Beispielcomputersystem 910 ist für die Verwendung bei der Implementierung hierin beschriebener Computerkomponenten, in Übereinstimmung mit einer veranschaulichenden Implementierung, geeignet. Als allgemeiner Überblick beinhaltet das Computersystem 910 mindestens einen Prozessor 950 für die Durchführung von Aktionen in Übereinstimmung mit den Anweisungen und eines oder mehrere Speichergeräte 970 oder 975 für das Speichern von Anweisungen und Daten. Das veranschaulichte Computersystem 910 beinhaltet einen oder mehrere Prozessoren 950 in Kommunikation über einen Bus 915 mit Speicher 970, mindestens einen Netzwerkschnittstellen-Controller 920 mit Netzwerkschnittstelle 922 für die Verbindung zu einem Netzwerkgerät 924 (z. B. für den Zugriff auf ein Netzwerk) und andere Komponenten 980, z. B. Eingabe/Ausgabe("I/0")-Komponenten 930. Im Allgemeinen führt/führen der/die Prozessor(en) 950 Anweisungen aus, die vom Speicher empfangen werden. Der/die veranschaulichte(n) Prozessor(en) 950 sind in Zwischenspeicher 975 integriert oder direkt mit ihm verbunden. In manchen Fällen werden Anweisungen aus Speicher 970 in den Zwischenspeicher 975 gelesen und von dem/den Prozessor(en) 950 von Zwischenspeicher 975 ausgeführt.
• Genauer kann/können der/die Prozessor(en) 950 jede Logikschaltung sein, die Anweisungen verarbeitet, z. B. Anweisungen, die aus dem Speicher 970 oder Zwischenspeicher 975 geholt werden. In vielen Ausführungsformen kann/können der/die Prozessor(en) 950 Mikroprozessoreinheiten oder Prozessoren für spezielle Zwecke sein. Das Rechengerät 910 kann auf einem beliebigen Prozessor oder einer beliebigen Prozessormenge basieren, die in der Lage sind, wie hier beschrieben zu arbeiten. Der/die Prozessor(en) 950 können Einkern- oder Mehrkernprozessoren sein. Der/die Prozessor(en) 950 können mehrere verschiedene Prozessoren sein. In einigen Ausführungsformen ist/sind der/die Prozessor(en) 950 als Schaltung auf einem oder mehreren „Chips“ implementiert.
• Der Speicher 970 kann jedes Gerät sein, das für die Speicherung computerlesbarer Daten geeignet ist. Der Speicher 970 kann ein Gerät mit festem Speicher oder ein Gerät zum Lesen von Wechselspeichermedien sein. Beispiele beinhalten alle Formen von nicht flüchtigem Speicher, Medien und Speichergeräten, Halbleiterspeichergeräten (z. B. EPROM, EEPROM, SDRAM und USB-Flash-Speichergeräte), magnetische Datenträger, magnetooptische Datenträger und optische Datenträger (z. B. CD-ROM, DVD-ROM, oder Blu-Ray^®-Discs). Ein Rechensystem 910 kann beliebig viele Speichergeräte 970 haben.
• Der Zwischenspeicher 975 ist im Allgemeinen in Form eines Computerspeichers, der für schnelle Zugriffszeiten in enger Nähe zu dem/den Prozessor(en) 950 platziert ist. In einigen Implementierungen ist der Zwischenspeicher 975 Teil von oder auf demselben Chip wie der/die Prozessor(en) 950. Bei einigen Implementierungen gibt es mehrere Ebenen des Cache 975, z. B. die Cache-Ebenen L2 und L3.
• Der Netzwerkschnittstellen-Controller 920 verwaltet den Datenaustausch über die Netzwerkschnittstelle (922 (manchmal als Netzwerkschnittstellenport bezeichnet). Der Netzwerkschnittstellen-Controller 920 verwaltet die Bitübertragungs- und Sicherungsschicht des OSI-Modells für die Netzwerkkommunikation. In einigen Implementierungen werden Aufgaben des Netzwerkschnittstellen-Controllers durch einen oder mehrere der Prozessoren 950 behandelt. In einigen Implementierungen ist der Netzwerkschnittstellen-Controller 920 in den Prozessor 950 integriert, z. B. als Schaltung auf demselben Chip. In einigen Implementierungen hat ein Computersystem 910 mehrere Netzwerkschnittstellen, 922, die von einem einzigen Controller 920 gesteuert werden. Bei einigen Implementierungen hat ein Rechensystem 910 mehrere Netzwerkschnittstellen-Controller 920. In einigen Implementierungen ist jede Netzwerkschnittstelle 922 ein Verbindungspunkt für eine physische Netzwerkverbindung (z. B. eine Cat-5-Ethernet-Verbindung). In einigen Implementierungen unterstützt der Netzwerkschnittstellen-Controller 920 drahtlose Netzwerkverbindungen und eine Schnittstelle 922 ist ein drahtloser (z. B. Funk) Empfänger/Sender (zum Beispiel für ein beliebiges der IEEE 802.11-Protokolle, Nahfeldkommunikation „NFC“, BLUETOOTH, BLE, ANT oder jedes andere drahtlose Protokoll). In einigen Implementierungen implementiert der Netzwerkschnittstellen-Controller 920 eines oder mehrere Netzwerkprotokolle, z. B. Ethernet. Im Allgemeinen tauscht ein Computergerät 910 Daten mit anderen Computergeräten über physische oder drahtlose Verbindungen über eine Netzwerkschnittstelle 922 aus. Die Netzwerkschnittstelle 922 kann direkt mit einem anderen Gerät oder über ein zwischengeschaltetes Gerät, z. B. ein Netzwerkgerät wie einem Hub, einer Bridge, einem Switch oder einem Router, mit einem anderen Gerät verbunden sein, das Computergerät 910 mit einem Datennetzwerk wie dem Internet verbindet.
• Das Computersystem 910 kann Schnittstellen für eine oder mehrere Eingabe- oder Ausgabekomponenten (“I/0”) 930 bereitstellen. Zu den Eingabegeräten zählen ohne Einschränkung Tastaturen, Mikrofone, Touchscreens, Fußpedale, Sensoren, MIDI-Geräte und Zeigegeräte wie eine Maus oder ein Trackball. Zu den Ausgabegeräten zählen ohne Einschränkung Videodisplays, Lautsprecher, refreshable Braille-Terminal, Lichter, MIDI-Geräte und 2-D- oder 3-D-Drucker.
• Die anderen Komponenten 980 können eine E/A-Schnittstelle, serielle Anschlüsse für externe Geräte und beliebige zusätzliche Koprozessoren beinhalten. Computersystem 910 kann zum Beispiel eine Schnittstelle (z. B. eine Universal Serial Bus(„USB“)-Schnittstelle) für das Anschließen von Eingabegeräten, Ausgabegeräten oder zusätzlichen Speichergeräten (z. B. tragbarer Flash-Speicher oder ein externes Medienlaufwerk) beinhalten. In einigen Implementierungen beinhaltet ein Computergerät 910 ein zusätzliches Gerät 980, z. B. einen Koprozessor. Zum Beispiel kann ein mathematischer Koprozessor dem Prozessor 950 bei Berechnungen mit hoher Präzision oder komplexen Berechnungen helfen.
• Implementierungen des Gegenstands und die in dieser Spezifikation beschriebenen Vorgänge können in digitalen elektronischen Schaltungen oder in Computer-Software implementiert sein, die in einem greifbaren Medium, Firmware oder Hardware verkörpert sind, einschließlich der in dieser Spezifikation offenbarten Strukturen und ihrer strukturellen Entsprechungen oder in Kombinationen von einer oder mehreren von ihnen. Implementierungen des in dieser Spezifikation beschriebenen Gegenstandes können als ein oder mehrere Computerprogramme auf einem physischen Medium, d. h. als ein oder mehrere Module von Computerprogrammbefehlen implementiert werden, die auf einem oder mehreren Computerspeichermedien für die Ausführung durch oder die Steuerung des Betriebes eines datenverarbeitenden Apparates kodiert werden. Bei einem Computer-Speichermedium kann es sich um ein maschinell lesbares Speichergerät, einen maschinell lesbaren Speicherträger, ein zufälliges oder serielles Speicher-Array oder Speichergerät oder um eine Kombination aus einem oder mehreren dieser Geräte handeln oder in ihnen enthalten sein. Bei dem Computer-Speichermedium kann es sich auch um eine oder mehrere unterschiedliche physische Komponenten oder Medien (z. B. mehrere CDs, Disks oder andere Speichergeräte) handeln, bzw. kann das Speichermedium darin enthalten sein. Das Computerspeichermedium ist greifbar und speichert Daten, z. B. computerausführbare Anweisungen, in nicht flüchtiger Form.
• Ein Computerprogramm (auch als Programm, Software, Softwareanwendung, Script oder Code bezeichnet) kann in einer beliebigen Form von Programmiersprache geschrieben sein, einschließlich kompilierter Sprachen, interpretierter Sprachen, deklarativer Sprachen und verfahrensorientierter Sprachen, und das Computerprogramm kann in jeder beliebigen Form bereitgestellt werden, z. B. als eigenständiges Programm oder als ein Modul, eine Komponente, eine Subroutine, ein Objekt oder eine andere Einheit, die für die Verwendung in einer Rechenumgebung geeignet ist. Ein Computerprogramm kann, muss aber nicht, einer Datei in einem Dateisystem entsprechen. Ein Programm kann in einem Teil einer Datei gespeichert sein, die andere Programme oder Daten enthält (z. B. ein oder mehrere Scripts, die in einem Dokument in Markup-Sprache gespeichert sind), in einer einzelnen Datei speziell für das betreffende Programm oder in mehreren koordinierten Dateien (z. B. Dateien, die ein oder mehrere Module, Bibliotheken, Unterprogramme oder Teile von Code speichern). Ein Computerprogramm kann auf einem Computer oder mehreren Computern eingerichtet sein oder ausgeführt werden, die an einem Standort angeordnet sind oder über mehrere Standorte verteilt sind und über ein Kommunikationsnetz verbunden sind.
• Die in dieser Beschreibung dargestellten Prozesse und Logikabläufe können durch einen oder mehrere programmierbare Prozessoren durchgeführt werden, die eines oder mehrere Computerprogramme ausführen, um Aktionen durch das Arbeiten mit Eingabedaten und das Erzeugen von Ausgaben auszuführen. Die Prozesse und logischen Abläufe können auch von logischen Sonderzweckschaltungen durchgeführt werden, und das Gerät kann als eine solche Sonderzweckschaltung implementiert werden, z. B. als FPGA (Field Programmable Gate Array) oder ASIC (Application Specific Integrated Circuit). Solch eine Sonderzweckschaltung kann als Computerprozessor bezeichnet werden, selbst wenn es sich nicht um einen Universalprozessor handelt.
• Auch wenn diese Spezifikation viele spezifische Implementierungsdetails enthält, sollten diese nicht als Einschränkungen des Umfangs von Erfindungen oder der Ansprüche ausgelegt werden, sondern als Beschreibungen von Merkmalen, die für bestimmte Implementierungen bestimmter Erfindungen spezifisch sind. Bestimmte Eigenschaften, die in dieser Spezifikation im Kontext gesonderter Implementierungen beschrieben sind, können auch in Kombination in einer einzelnen Implementierung implementiert werden. Umgekehrt können verschiedene, im Kontext einer einzelnen Implementierung beschriebene Merkmale auch in mehreren Implementierungen separat oder in einer beliebigen geeigneten Unterkombination implementiert werden. Außerdem können ein oder mehrere Merkmale einer beanspruchten Kombination in manchen Fällen aus der Kombination herausgelöst werden, auch wenn die Merkmale vorstehend als in gewissen Kombinationen funktionierend beschrieben oder gar als eine Kombination beansprucht werden, und die beanspruchte Kombination kann an eine Unterkombination oder eine Variation einer Unterkombination verwiesen werden.
• Ebenso werden Tätigkeiten in den Zeichnungen zwar in einer bestimmten Reihenfolge dargestellt, aber dies sollte nicht als Erfordernis verstanden werden, dass diese Tätigkeiten in der bestimmten gezeigten Reihenfolge oder in einer aufeinanderfolgenden Reihenfolge durchgeführt werden müssen oder dass alle dargestellten Tätigkeiten durchgeführt werden müssen, um erwünschte Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und eine Parallelbearbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung verschiedener Systemkomponenten in den oben beschriebenen Implementierungen nicht als eine solche Trennung in allen Implementierungen erfordernd aufgefasst werden, und es versteht sich, dass die beschriebenen Programmkomponenten und Systeme grundsätzlich zusammen in ein einziges Softwareprodukt integriert oder zu mehreren Softwareprodukten verkapselt werden können.
• Verweise auf „oder“ können als einschließend ausgelegt werden, sodass alle Begriffe, die mithilfe von „oder“ beschrieben werden, einen beliebigen einzelnen, mehr als einen oder alle beschriebenen Begriffe angeben können. Die Ordinalzahlwörter „Erster“, „Zweiter“, „Dritter“ usw. sind nicht unbedingt so gemeint, dass sie eine Reihenfolge angeben, und werden allgemein nur dazu verwendet, zwischen ähnlichen Gegenständen oder Elementen zu unterscheiden.
• Somit wurden bestimmte Implementierungen des Gegenstands beschrieben. Diese und andere Ausführungsformen fallen in den Umfang der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen beschriebenen Handlungen in einer anderen Reihenfolge ausgeführt werden und dennoch erwünschte Ergebnisse erzielen. Zusätzlich erfordern die in den beigefügten Figuren dargestellten Prozesse nicht notwendigerweise die bestimmte gezeigte Reihenfolge oder aufeinanderfolgende Reihenfolge, um erwünschte Ergebnisse zu erzielen. Bei bestimmten Implementierungen können Multitasking oder eine Parallelbearbeitung verwendet werden.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Nicht-Patentliteratur
• IEEE 802.11-Protokolle [0062]

Claims (10)

1. System für die Aufrechterhaltung der Service-Level von Netzwerken, das System umfassend: einen computerlesbaren Speicher, der Aufzeichnungen von Netzwerkvorfällen speichert; und einen oder mehrere Prozessoren, die so konfiguriert sind, dass sie auf den computerlesbaren Speicher zugreifen und Anweisungen ausführen, die, wenn sie von einem Prozessor ausgeführt werden, den Prozessor veranlassen: mithilfe der Aufzeichnungen der Netzwerkvorfälle, die im computerlesbaren Speicher gespeichert sind, eine erste Vielzahl der Netzwerkvorfälle zu identifizieren, die über einen ersten Teil des Messzeitraums auftreten; eine zweite Vielzahl von Netzwerkvorfällen zu identifizieren, die über einen zweiten Teil des Messzeitraums auftreten, der nach dem ersten Zeit des Messzeitraums erfolgt; eine Vielzahl restlicher Vorfallstoleranzlimits auf Basis einer Auswirkung der ersten und zweiten Vielzahl der Netzwerkvorfälle bei entsprechenden Sätzen von Vorfallstoleranzlimits für den Messzeitraum zu ermitteln; Schweregrad-Metrikwerte für mindestens eine Teilmenge der zweiten Netzwerkvorfälle auf Basis zusammengefasster Auswirkungseigenschaften von einer oder mehreren der zweiten Vielzahl der Netzwerkvorfälle zu erzeugen, die durch restliche Vorfallstoleranzlimits gewichtet werden, die mit jeder der zweiten Netzwerkvorfälle in der Teilmenge der zweiten Netzwerkvorfälle verbunden sind; und mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle zur Behebung auszuwählen.
2. System nach Anspruch 1, worin die identifizierte erste Vielzahl und zweite Vielzahl der Netzwerkvorfälle durch Netzwerkvorfallsaufzeichnungen dargestellt werden, die im computerlesbaren Speicher gespeichert sind.
3. System nach Anspruch 2, worin eine Netzwerkvorfallsaufzeichnung mindestens Folgendes beinhaltet: (i) Zeit- und Datumsinformationen für das Auftreten eines Vorfalls, (ii) Routeninformationen für das Auftreten des Vorfalls, und (iii) eine Beschreibung oder Klassifizierung für einen Service, der durch das Auftreten des Vorfalls beeinträchtigt wurde.
4. System nach Anspruch 1, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, die Teilmenge der zweiten Netzwerkvorfälle auf Netzwerkvorfälle zu begrenzen, die ein Auswahlkriterium erfüllen.
5. System nach Anspruch 4, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, die Teilmenge der zweiten Netzwerkvorfälle auf Basis einer Zahl der Netzwerkvorfälle auszuwählen, die das Auswahlkriterium der Überschreitung eines Schwellenwerts erfüllen.
6. System nach Anspruch 1, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen die Teilmenge der zweiten Netzwerkvorfälle auf Netzwerkvorfälle zu begrenzen, die Netzwerkflüsse beeinträchtigen, die jeweils mindestens einen jeweiligen Endknoten in einer gemeinsamen geografischen Region haben.
7. System nach Anspruch 1, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, die Teilmenge der zweiten Netzwerkvorfälle auszuwählen, worin die Auswahl der Teilmenge der zweiten Netzwerkvorfälle die Identifizierung eines Netzwerkvorfalls umfasst, der einen Netzwerkfluss zwischen einem ersten Endknoten und einem zweiten Endknoten beeinträchtigt, basierend darauf, dass der erste Endknoten eine Netzwerkadresse in einem ersten Satz von Netzwerkadressen hat und der zweite Endknoten eine Netzwerkadresse in einem zweiten Satz der Netzwerkadressen hat.
8. System nach Anspruch 7, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, den ersten Satz der Netzwerkadressen und den zweiten Satz der Netzwerkadressen auf Basis einer gemeinsamen Netzwerkverbindung zwischen Knoten, die im ersten Satz der Netzwerkadressen adressiert werden, und Knoten, die im zweiten Satz der Netzwerkadressen adressiert werden, auszuwählen.
9. System nach Anspruch 1, worin der Messzeitraum ein rollierendes Zeitfenster ist.
10. System nach Anspruch 1, worin die Anweisungen, wenn sie vom Prozessor ausgeführt werden, den Prozessor veranlassen, mindestens einen der Vorfälle in der Teilmenge der zweiten Netzwerkvorfälle für die Behebung auf Basis eines Vergleichs der Schweregrad-Metrikwerte auszuwählen.

Images