DE102021109547A1

DE102021109547A1 - Sdwan overlay- routing- dienst

Info

Publication number: DE102021109547A1
Application number: DE102021109547.6A
Authority: DE
Inventors: Arijit Sarcar; Laxminarayana Tumuluru; Dilip Gupta; Stephen Su; Harish Magganmane; Shijie MA; Sivaram Dommeti
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2020-10-07
Filing date: 2021-04-15
Publication date: 2022-04-07
Anticipated expiration: 2041-04-16
Also published as: CN114401221B; US20220109620A1; DE102021109547B4; CN114401221A; US11463343B2

Abstract

Systeme und Verfahren für das Routing von Geräten in softwaredefinierten Weitverkehrsnetzen (SDWAN) werden unter Verwendung eines Cloud-basierten Overlay-Routing-Dienstes bereitgestellt, der einen Cloud-BGP-Dienst (CBS) und ein Pfadberechnungsmodul (PCM) sowie auf der Mieterseite implementierte Overlay-Agenten (OAs) nutzt. Die Oas, der CBS und das PCM können miteinander interagieren, z. B. lokale Zustände, Routenpräfixe usw. veröffentlichen/aktualisieren, um das Routing im SDWAN zu erstellen/aufrechtzuerhalten.

Description

Hintergrund
Software-definierte Weitverkehrsnetze (SDWANs) sind Netztopologien, die Standorte eines Weitverkehrsnetzes (WAN) miteinander verbinden und dabei die Grundsätze des Software-definierten Netzwerks (SDN) nutzen, z. B. die Trennung der Kontrollschicht der Verkehrsverwaltung von der Datenweiterleitungsschicht. SDWANs unterstützen die Konsolidierung der Infrastruktur durch Virtualisierung von Netzwerkfunktionen (NFV). NFV reduziert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN durch die Virtualisierung der Netzwerkfunktionen mithilfe virtueller Maschinen auf gängiger und kostengünstiger „Standard“-Hardware.
Figurenliste
Die vorliegende Offenbarung wird in Übereinstimmung mit einer oder mehreren verschiedenen Ausführungsformen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen lediglich der Veranschaulichung und stellen lediglich typische oder beispielhafte Ausführungsformen dar.

1 zeigt ein Beispiel für eine SDWAN-Umgebung in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
2 zeigt ein Beispiel für die Systemarchitektur eines SDWAN-Overlay-Routing-Dienstes in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
3A zeigt eine schematische Darstellung eines Beispiels eines Pfadberechnungsmoduls gemäß den Ausführungsformen der hierin offenbarten Technologie.
3B zeigt eine schematische Darstellung eines Beispiels eines Cloud Branch Gateway Protokolldienstes in Übereinstimmung mit Ausführungsformen der hier offengelegten Technologie.
4 zeigt ein Beispielverfahren in Übereinstimmung mit verschiedenen Ausführungsformen der hier offengelegten Technologie.
5 ist ein Beispiel für eine Computerkomponente, die zur Implementierung verschiedener Merkmale der in der vorliegenden Offenbarung beschriebenen Ausführungsformen verwendet werden kann.

Die Figuren sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offengelegt wird.
Detaillierte Beschreibung
Ein softwaredefiniertes Weitverkehrsnetz (SDWAN) ermöglicht es einem Netzwerkadministrator, Zweigstellen über ein Weitverkehrsnetz (WAN) mit einem Hauptstandort zu verbinden. Der Einsatz von Software Defined Networking (SDN) entkoppelt die Entscheidungen über den Netzwerkverkehr von den verschiedenen Geräten innerhalb des Netzwerks, z. B. Routern, Switches, Brücken und anderen gängigen Netzwerkgeräten. Durch diese Entkopplung wird jedes Netzwerkgerät im Wesentlichen zu einem einfachen Gerät für die Weiterleitung von Paketen. Das SDWAN legt auf der Grundlage von Client-Richtlinien (z. B. QoS-Anforderungen, Bandbreite usw.) die potenziellen Verkehrswege durch jedes Netzwerkgerät fest, um die Zweigstellen innerhalb des SDWAN mit dem Kernstandort oder dem Rechenzentrum zu verbinden, das jedem Netzwerkgerät über einen Kontrollkanal zur Verfügung gestellt wird. Anstatt eine Entscheidung über die Weiterleitung des Datenverkehrs zu treffen, wenn Daten empfangen werden, führen die Netzwerkgeräte einfach die vom SDWAN-Administrator festgelegte Route aus.
Wie bereits angedeutet, erleichtert der Einsatz eines SDWAN die Virtualisierung von Netzwerkdiensten über das WAN. Die Netzwerkfunktionsvirtualisierung (NFV) verringert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN, indem die Netzwerkfunktionen mithilfe virtueller Maschinen auf gängigerer und billigerer „Standard“-Hardware virtualisiert werden, anstatt auf proprietärer, dedizierter Hardware (wie traditionell erforderlich). So können beispielsweise Funktionen wie Routing, Lastausgleich und Firewalls als virtuelle Maschinen (VMs) betrieben werden, die in einem Rechenzentrum und/oder in der Cloud gehostet werden. NFV konzentriert sich jedoch auf die Virtualisierung von Funktionen, kümmert sich aber nicht darum, wie die Datenpakete zu den virtuellen Maschinen geleitet werden, auf denen die Netzwerkfunktionen ausgeführt werden. SDWAN in Kombination mit NFV bietet ein umfassenderes virtuelles Netzwerk, bei dem das SDWAN die Routing-Richtlinien für die Verkehrsströme von den Zweigstellen zum Kernstandort oder zum Rechenzentrum, in dem die virtuellen NFV-Maschinen laufen, bereitstellt. Zweigstellenbenutzer sind in der Lage, diese Ressourcen über das SDWAN zu nutzen, wodurch die Abhängigkeit von teurer proprietärer Hardware verringert und die Menge der an den Zweigstellen des WAN erforderlichen Computerhardware reduziert wird.
SDWANs können durch die Schaffung eines virtuellen Overlay implementiert werden, das transportunabhängig ist und die zugrunde liegenden privaten oder öffentlichen Netzverbindungen abstrahiert. Zu diesen Netzverbindungen können Multiprotocol Label Switching (MPLS), Internet-Breitband, Glasfaser, Wireless oder Long Term Evolution (LTE) gehören, um nur einige zu nennen. In einigen Beispielen werden VPN-Tunnel (Virtual Private Network) zwischen WAN-Standorten eingerichtet, um eine private, sichere Verbindung über potenziell anfällige und unsichere öffentliche Verbindungen (z. B. Internetverbindungen) zu ermöglichen. Die Kunden können bestehende WAN-Verbindungen beibehalten und ein Overlay-SDWAN implementieren, das diese Tunnel nutzt, um die Bandbreite zu optimieren, indem der WAN-Verkehr zu und von anderen WAN-Standorten über bestimmte Routen geleitet wird, die diese Tunnel einschließen. Dementsprechend können SDWANs verwendet werden, um die Netzwerkkontrolle über das gesamte WAN zu zentralisieren. Fernanwender, z. B. in Zweigstellen, können Ressourcen nutzen, die in einem Rechenzentrum und/oder in der Cloud gehostet werden, um Anwendungen innerhalb des Netzwerks auszuführen.
SDWAN-Anbieter verlassen sich in der Regel auf das Border-Gateway-Protokoll (BGP), ein standardisiertes Protokoll für externe Gateways, um Routing- und Erreichbarkeitsinformationen zwischen Systemen auszutauschen und ein SDWAN zu realisieren. Bei BGP wird jedoch das Wissen über die Routen gebündelt, und es sind mehrere Ebenen erforderlich, um eine große Anzahl von Zweigstellen zu unterstützen, und ein Mieter/Kunde muss Paare von BGP-Instanzen konfigurieren. In einem SDWAN, in dem die Anzahl der Zweigstellen sehr groß sein kann, sind die Standard-BGP-Mechanismen möglicherweise nicht ausreichend oder nicht praktikabel.
In einer SDWAN-Architektur mit einer einschichtigen Architektur, in der jedes Gerät/Router direkt mit einem Orchestrator kommunizieren kann, um SDWAN zu erreichen, kann das Routing zwischen Zweigstellen-Gateways und Virtual Private Network Clients (VPNCs) durchgeführt werden. Dieses Routing kann als Cloud-basierter Overlay-Routing-Dienst implementiert werden. Der Cloud-basierte Overlay-Routing-Dienst umfasst zwei Haupt-Microservices, einen Cloud-BGP-Dienst (CBS) und ein Pfadberechnungsmodul (PCM), sowie einen Etcd-Cluster (in einer Cloud-Plattform implementiert) und Overlay-Agenten (OAs), die auf der Mieterseite implementiert sind.
Jede OA kann ihre lokal erlernten und statisch konfigurierten Präfixe an den Overlay-Routing-Dienst weitergeben (ein Präfix oder Routing-Präfix kann eine Adresse eines Netzes identifizieren, und Routen können zwischen Präfixen bestimmt/konfiguriert werden), insbesondere an einen von mehreren CBS-Servern. CBS-Server können Routenaktualisierungen an OAs senden, die solche Routenaktualisierungen an einen Underlay-Routing-Stack beim Mandanten weiterleiten. OAs verbinden sich mit CBS-Servern über einen OA-Kanal, der für einen bestimmten CBS-Server lastausgleichend ist. OAs können eine erneute Synchronisierung durchführen, um einen gemeinsamen Status mit den CBS-Servern/dem Overlay-Routing-Dienst zu erreichen. Danach veröffentlichen die OAs erneut gelernte Routen (zusammen mit allen relevanten Tunnel-Flaps), woraufhin die CBS-Server diese Statusaktualisierungen an alle PCMs in einem bestimmten Cluster veröffentlichen. Die Veröffentlichung dieser Zustandsaktualisierungen löst in jedem PCM neue Routenberechnungen aus, woraufhin die PCM neue Aktualisierungen an alle CBS-Server veröffentlichen, die ihrerseits Aktualisierungen an alle relevanten OAs weiterleiten.
1 zeigt ein Beispiel für ein SDWAN 100, in dem Ausführungsformen der hier offengelegten Technologie anwendbar sind. Das SDWAN-Beispiel 100 ist der Einfachheit halber vereinfacht dargestellt, und ein Fachmann wird verstehen, dass die Technologie der vorliegenden Offenlegung auf SDWANs mit mehr oder weniger komplexen Architekturen anwendbar ist. Wie in 1 dargestellt, umfasst das Beispiel-SDWAN 100 eine Vielzahl von entfernten Standorten 102a, 102b, 102c, 102d, die jeweils über ein SDWAN-Knotengerät verfügen. Ein SDWAN-Knotengerät ist ein Netzwerkgerät, z. B. ein Router, Switch, Modem, eine Brücke, ein Hub oder ein anderes gängiges Netzwerkgerät, das als Gateway oder Zwischenpunkt innerhalb des SDWAN dient. Bei den entfernten Standorten 102a, 102b, 102c, 102d kann es sich um eine Zweigstelle oder einen anderen Benutzer handeln, der sich in größerer Entfernung von einem Kernstandort des Netzwerks, z. B. einem Rechenzentrum, befindet. In verschiedenen Ausführungsformen ist der Kernstandort die Einheit, die virtualisierte Netzwerkfunktionen (VNFs) hostet, die von allen entfernten Standorten 102a, 102b, 102c, 102d gemeinsam genutzt werden können. In verschiedenen Ausführungsformen ist das SDWAN-Knotengerät an den entfernten Standorten 102a, 102b, 102c, 102d so konfiguriert, dass es als Edge-Gerät für den entfernten Standort fungiert und einen Zugangspunkt zum SDWAN 100 bereitstellt. Das SDWAN-Knotengerät an den entfernten Standorten 102a, 102b, 102c, 102d kann in verschiedenen Ausführungsformen ein Modem oder ein anderes Gateway-Netzwerkgerät umfassen.
In verschiedenen Ausführungsformen kann der Verkehr zwischen entfernten Standorten und den Datenzentren über ein SDWAN-Zwischenknotengerät 104 geleitet werden. Das SDWAN-Zwischenknotengerät 104 kann den SDWAN-Knotengeräten an den entfernten Standorten 102a, 102b, 102c, 102d und den Datenzentren 108a, 108b, 108c, 108d ähnlich sein. Das SDWAN-Zwischenknotengerät 104 kann als Zugangspunkt zu den Transportnetzen 106a, 106b des SDWAN 100 für eine Vielzahl von entfernten Standorten dienen. Somit kann das SDWAN-Knotengerät 104 als Zweigstellen-Gateway und die SDWAN-Knotengeräte an entfernten Standorten 102a, 102b, 102c, 102d als VPNCs betrachtet werden. Wie in 1 dargestellt, können die entfernten Standorte 102c und 102d mit dem zwischengeschalteten SDWAN-Knotengerät 104 verbunden sein. Die Verwendung eines oder mehrerer Zwischengeräte, wie des SDWAN-Zwischenknotens 104, innerhalb des SDWAN ermöglicht in einigen Ausführungsformen die Schaffung verschiedener Dienstregionen.
SDWAN 100 umfasst außerdem ein oder mehrere Datenzentren 108a, 108b, 108c, 108d. Jedes Datenzentrum 108a, 108b, 108c, 108d hat auch ein SDWAN-Knotengerät, ähnlich dem SDWAN-Knotengerät an entfernten Standorten 102a, 102b, 102c, 102d. In verschiedenen Ausführungsformen können die Datenzentren 108a, 108b, 108c, 108d eine oder mehrere Anwendungen hosten, die von Benutzern an den entfernten Standorten 102a, 102b, 102c, 102d genutzt werden können. In verschiedenen Ausführungsformen können ein oder mehrere Datenzentren von dem Kunden verwaltet werden, der Eigentümer des SDWAN 100 ist. In anderen Ausführungsformen können ein oder mehrere Rechenzentren von einem dritten Dienstanbieter verwaltet werden.
Jedes Transportnetz 106a, 106b kann mit einer Reihe von Rechenzentren verbunden sein. Wie in 1 dargestellt, ist das Transportnetz 106a mit den Datenzentren 108a, 108b verbunden, während das Transportnetz 106b mit den Datenzentren 108c, 108d verbunden ist. In verschiedenen Ausführungsformen können einige Anwendungen in einem Cloud-Host 110 gehostet werden, auf den von einem oder mehreren Rechenzentren zugegriffen werden kann, die entweder dem Transportnetz 106a oder 106b zugeordnet sind. Wie in 1 dargestellt, bieten die Datenzentren 108b und 108c Zugang zu mindestens einer Cloud-Anwendung, die im Cloud-Host 110 gehostet wird.
Jeder entfernte Standort 102a, 102b, 102c, 102d ist über das SDWAN-Knotengerät mit den Transportnetzen 106a, 106b verbunden. Die Transportnetze 106a, 106b umfassen verschiedene Transporttechnologien, wie öffentliches Internet, Multiprotocol Label Switching (MPLS), privates Internet, asynchroner Übertragungsmodus, drahtloses WAN, Breitband, Satellitenkommunikation oder andere Netzwerktechnologien. In verschiedenen Implementierungen kann es sich bei den Transportnetzen um Netze verschiedener Dienstanbieter handeln. Wie dargestellt, kann das SDWAN 100 mehr als ein Transportnetz umfassen (Transportnetze 106a, 106b). SDWAN 100 kann ein Verfahren zur Definition eines Client-Netzwerks bereitstellen, das die bestehenden Transportinfrastrukturen von Dienstanbietern für das physische Routing des SDWAN-Datenverkehrs zwischen verschiedenen SDWAN-Knotengeräten überlagert. Obwohl in 1 nur zwei Transportnetzwerke 106a, 106b dargestellt sind, können verschiedene Ausführungsformen andere Mengen von Transportnetzwerken umfassen, die zusätzliche Flexibilität bei der Art und Weise bieten, wie der Anwendungsverkehr von entfernten Standorten 102a, 102b, 102c, 102d zu dem zugehörigen Datenzentrum 108a, 108b, 108c, 108d geleitet wird, das die Anwendung hostet. Die Rechenzentren 108a, 108b, 108c, 108d verfügen über eigene SDWAN-Knotengeräte, die Servern und anderen Komponenten des jeweiligen Rechenzentrums den Zugang zum SDWAN 100 ermöglichen.
Innerhalb des SDWAN 100 kann die Konnektivität zwischen entfernten Standorten und den Rechenzentren und/oder Cloud-Anwendungen über eine vom SDWAN-Administrator gehostete Steuerungssoftware gesteuert werden. Der Kunde kann Richtlinien entwickeln, die sicherstellen, dass verschiedene Datenverkehrsklassen innerhalb des Netzwerks so geleitet werden, dass die Anforderungen an die Dienstgüte (QoS) und die Service Level Agreements (SLA) erfüllt werden. Diese Richtlinien werden zur Entwicklung von Routing-Tabellen verwendet, die an die SDWAN-Knotengeräte (wie die in 1 beschriebenen SDWAN-Knotengeräte) verteilt werden. Die SDWAN-Knotengeräte können den Verkehr aus den verschiedenen Sitzungen, die durch das SDWAN-Knotengerät fließen, identifizieren und die in der Routing-Tabelle enthaltenen Routing-Regeln für diese Verkehrskategorie anwenden. Um sicherzustellen, dass die Anforderungen erfüllt werden, können sich die Kunden auf die Grundsätze des Traffic Engineering konzentrieren und die Route, die ein bestimmter Verkehr durch die Transportnetze nimmt, entsprechend den Anforderungen ändern. So kann ein Netzwerkadministrator beispielsweise Regeln für eine bestimmte Verkehrsklasse festlegen, so dass diese im Allgemeinen über das SDWAN-Knotengerät einer Zweigstelle an ein zwischengeschaltetes SDWAN-Knotengerät (zur Anwendung von DPI) und dann über das öffentliche Internet-Transportnetz an ein Rechenzentrum übertragen wird. In bestimmten Szenarien kann derselbe Datenverkehr jedoch auch über ein MPLS-Netzwerk übertragen werden. Dementsprechend können die SDWAN-Knotengeräte und die Datenpfade zwischen Zweigstellen und Rechenzentren/Cloud-Architektur vor der Installation festgelegt werden.
2 zeigt eine Beispielsystemarchitektur 200 zur Realisierung eines SDWAN-Overlay-Routing-Dienstes (SORS) 201 gemäß einer Ausführungsform. Wie in 2 dargestellt, kann jeder Mieter, z. B. die Mieter A-Z, über entsprechende Zweigstellen-Gateways/VPNC-Overlay-Agenten (OAs) verfügen. Zum Beispiel kann Mieter A OAs 214a, 214b haben, Mieter B kann OAs 216a, 216b... haben, Mieter Y kann OAs 218a, 218b haben und Mieter Z kann OAs 220a-c haben. Jede OA kann so konfiguriert sein, dass sie sich mit dem SORS 201 über einen OA-Kanal verbindet. Jede OA kann über ihren jeweiligen OA-Kanal ihre lokal erlernten und statisch konfigurierten Präfixe an SORS 201 veröffentlichen. Jeder OA-Kanal kann einen Open-Source-Remote-Procedure-Call (RPC), wie z. B. gRPC, verwenden, der HTTP/2 für den Transport nutzt. Dies ermöglicht die Erstellung mehrerer, bidirektionaler Streams über dieselbe TCP-Verbindung. So kann jede Anwendung, z. B. ein Routingdienst, ein Tunneldienst usw., ihren eigenen Stream erstellen. Es ist zu beachten, dass für SORS 201 ein spezifischer DNS-Domänenname und eine entsprechende virtuelle IP-Adresse (VIP) angegeben werden können, um den Verkehr der Steuerebene von anderem Managementverkehr zu isolieren.
Es versteht sich, dass jeder OA eine Verbindung zu einem Underlay-Routing-Daemon herstellen kann, um die statisch konfigurierten Präfixe zu erhalten (nicht dargestellt). Ein CBS-Server, z. B. einer der CBS-Server 210a-d (die weiter unten ausführlicher beschrieben werden), kann Routenaktualisierungen an seine entsprechende OA senden, die wiederum die Routenaktualisierungen an den Underlay-Routing-Daemon weiterleitet. Auf diese Weise kann der Underlay-Routing-Daemon die Präfixe konfigurieren, die jeder OA schließlich an SORS 201 veröffentlicht.
Jeder OA 214a/b, OA 216a/b, OA 218a/b, OA 220a/b/c veröffentlicht die lokal erlernten und statisch konfigurierten Präfixe an SORS 201 gegenüber einer ELB-Komponente (Elastic Load Balancing) 212a. ELB 212a führt einen Schicht-4-Lastausgleich durch. Das heißt, ELB 212a kann einen Lastausgleich der Host-to-Host-Kommunikationsdienste für die OSI-Transportschicht durchführen und dann die OA-Kanaldaten an einen Reverse-Proxy/Load-Balancer-Cluster 212 weiterleiten. Das heißt, ELB 212a führt einen Schicht-4-Lastausgleich durch, wenn es OA-Kanaldaten zur Verteilung an den Reverse-Proxy/Lastausgleichs-Cluster 212 annimmt, der die HTTP-Terminierung durchführt und als zwischengeschalteter Proxy-Dienst für die Weiterleitung der OA-Kanaldaten an das SORS 201 fungiert. ELB 212a (oder eine ähnliche/äquivalente Funktion) kann als Einstiegspunkt in die Cloud implementiert werden. Ein Nginx/envoy-Cluster 212 kann jeden OA-Kanal (der sicher ist) beenden und einen OA-Kanal im Klartext zu einem der CBS-Server, z. B. den CBS-Servern 210a-d, aufbauen. In einigen Ausführungsformen können benutzerdefinierte Header von Datenpaketen, die über die OA-Kanäle übertragen werden, als Grundlage für die Auswahl eines bestimmten CBS-Servers verwendet werden, an den ein OA-Kanal weitergeleitet wird. In einigen Ausführungsformen kann eine OA, z. B. OA 214a, solche benutzerdefinierten Kopfzeilen einfügen, um eine Mieterkennung oder andere relevante Felder anzugeben.
Jeder der CBS-Server 210a-210d kann den/die OA-Kanal/Kanäle hosten, der/die zu ihm geleitet wird/werden. Jeder der CBS-Server 210a-210d kann für die Verteilung der vom PCM generierten Routen an alle interessierten OAs eines Mandanten verantwortlich sein, die mit dem jeweiligen CBS-Server (oder der Gruppe von CBS-Servern) verankert sind. Es ist zu beachten, dass alle OAs eines Branch Gateways/VPNC, die zum selben Tenant gehören, mit einem bestimmten CBS-Server oder einer bestimmten Gruppe von CBS-Servern verankert werden können. Dies kann in einigen Ausführungsformen geschehen, um die Speichernutzung auf den CBS-Servern zu optimieren, wo ohne eine solche Speicheroptimierung alle CBS-Server im SORS 201 alle Zustände/Präfixe aller mit jedem der CBS-Server verbundenen Tenants zwischenspeichern müssten.
In der „umgekehrten Richtung“ und wie oben erwähnt, kann jeder der CBS-Server 210a-210d verwendet werden, um die Präfixe und alle Routing-Updates, die von einem OA (z. B. einem oder mehreren der OAs 214a/b, 216a/b, 218a/b, 220 a-c) empfangen werden, an jedes PCM zu veröffentlichen. Bei einem Ausfall eines CBS-Servers leitet der Nginx/envoy-Cluster 212 die OA-Kanalverbindungen an aktive CBS-Server weiter, und die Zweigstellen-Gateways/VPNCs können ihren jeweiligen Status mit einem aktiven CBS neu synchronisieren. Der aktive CBS kann den Redis-Cluster 208 aktualisieren und eine entsprechende Benachrichtigung über den Message Broker 209 und den Redis-Cluster 208 (siehe unten) senden,
In einigen Ausführungsformen kann eine Kombination aus Überwachungsskripten und regelmäßigem Datenvergleich von einem Redis-Cluster 208 aus Redis-Instanzen durchgeführt werden, wobei Redis-Schlüssel von mehreren Redis-Instanzen gemeinsam genutzt werden, die den Redis-Cluster 208 bilden. Der Redis-Cluster 208 kann aus Gründen der Ausfallsicherheit/Redundanz über Slave-Knoten verfügen. Bei den verglichenen Daten kann es sich um Streckenstatus- und Tunnelstatusdaten handeln. Redis kann sich auf einen speicherinternen Datenstrukturspeicher beziehen, der als Datenbank, Cache und Message Broker verwendet werden kann. Ein Datenverlust in einem Redis-Cluster, wie z. B. Redis-Cluster 208, kann z. B. durch den Ausfall eines Redis-Knotens oder durch einen Neustart eines Redis-Knotens entstehen. Bei einem Ausfall oder Neustart können die Daten, die den letzten Zustand der OAs widerspiegeln, von den CBS-Servern 210a-210d im redis-Cluster 208 neu aufgefüllt werden. Die CBS-Server 210a-210d können dann jedes PCM 206a, b...n und den PCM-Scheduler 204 (der weiter unten ausführlicher beschrieben wird) benachrichtigen, um Routen zwischen Zweiggateways und VPNCs für jeden der zugehörigen Tenants neu zu berechnen.
Der PCM-Scheduler 204 (der eine Vielzahl von PCM-Scheduler-Instanzen umfassen kann) kann verwendet werden, um die Mieterzuweisung zu handhaben, z. B. die Zuordnung von PCMs, z. B. PCMs 206a-n, zu Mietern, z. B. Mietern A-Z. Es versteht sich, dass die Mieterzuweisung dynamisch sein kann, und die PCMs 206a- können so konfiguriert werden, dass sie bei Bedarf mit einer Reihe von Mietern arbeiten. Darüber hinaus können alle PCMs so konfiguriert werden, dass sie als Slaves für die PCM-Scheduler-Instanzen 204 fungieren.
Im Betrieb können Zweigstellen-Gateways/VPNCs, in denen OAs (z. B. OAs 214a/b, 216a/b, 218a/b, 220a-c) implementiert sind, mit CBS-Servern 210a-d über entsprechende OA-Kanäle verbunden werden, wie oben beschrieben. Im Gegenzug wird der Zustand der Zweigstellen-Gateways/VPNCs (d. h. Route(n) und Verbindungsstatus), die von den jeweiligen OAs veröffentlicht werden, vom entsprechenden CBS-Server 210a-210d in den Redis-Cluster 208 übertragen. Darüber hinaus kann jeder CBS-Server 210a-210d Benachrichtigungen, die den neuen Zustand der Branch Gateways/VPNCs anzeigen, an einen Message Broker 209, z. B. einen Kafka- oder RabbitMQ-Message Broker, sowie an den redis-Cluster 208 weiterleiten. Es versteht sich, dass der Redis-Cluster 208 und der Message-Broker 209 nebeneinander bestehen können, falls die Zustandsmeldungen nicht den erforderlichen hohen Schreibdurchsatz erreichen. Auf diese Weise kann der PCM-Scheduler 204 alle Benachrichtigungen vom Message-Broker 209 auffangen, und wenn ein Tenant noch keinem PCM zugewiesen ist, kann der PCM-Scheduler 204 diesen noch nicht zugewiesenen Tenant einem geeigneten PCM zuordnen, z. B. einem der PCMs 206a-d. Für PCMs, die bereits einem oder mehreren Mandanten zugewiesen/zugeordnet wurden, können solche PCMs einfach auf Aktualisierungen in mandantenspezifischen Redis-Warteschlangen über die Redis-Knoten des Redis-Clusters 208 warten.
Es sei darauf hingewiesen, dass jeder der CBS-Server 210a-d als Helfer für die Vorsortierung von Statusmeldungen auf Mandantenbasis fungieren kann. Darüber hinaus können PCMs, denen Mandanten zugewiesen sind, weiterhin Zustandsmeldungen aus den oben erwähnten redis-Warteschlangen abrufen. Dementsprechend werden diese PCMs nicht notwendigerweise vom PCM-Scheduler 204 gesteuert. PCM Scheduler 204 kann einen oder mehrere der folgenden Faktoren für die Planung berücksichtigen: die Anzahl der aktiven/aktiven PCMs, die Anzahl der Geräte, z. B. SDWAN-Knoten, die jedem Tenant zugeordnet sind, die Anzahl der einem Tenant zugewiesenen Tunnel sowie die letzte Status-/Konfigurationsaktualisierung für einen Tenant. Die Anzahl der aktiven PCMS, Tenant-Geräte und Tenant-Tunnel kann für den Lastausgleich bei der Zuordnung von Tenants zu PCMs verwendet werden. Die letzte Status-/Konfigurationsaktualisierung, die einem Tenant zugeordnet ist, kann verwendet werden, um einen zuletzt genutzten Tenant von einem PCM zu trennen oder sein Mapping aufzuheben. Darüber hinaus kann der PCM-Scheduler 204 Informationen über die Zuordnung von Tenants zu PCMs sowie Tenant-relevante Informationen, z. B. die Anzahl der Geräte und Tunnel, die einem Tenant zugeordnet sind, in einem verteilten Key-Value-Speicher 202 (z. B. etcd) speichern. Die Speicherung solcher Informationen kann zur Wiederherstellung des PCM-Schedulers 204 im Falle eines Ausfalls oder Neustarts verwendet werden.
In einigen Ausführungsformen kann der PCM-Planer 204 alle PCMs des SORS 201 mithilfe des verteilten KV-Speichers 202 ermitteln. Wie oben erwähnt, kann der verteilte KV-Speicher 202 verwendet werden, um PCM-Tenant-Zuordnungsinformationen zu speichern, und der PCM-Scheduler 204 kann PCMs mit Hilfe von Tenant-Identifikationsinformationen ermitteln, um ein entsprechendes PCM zu finden. Es sollte beachtet werden, dass der verteilte KV-Speicher auch verwendet werden kann, um verteiltes Sperren, Überwachung über Pub/Sub-Echtzeit-Ereignisnachrichten, Service-Erkennung und Führungswahl zu ermöglichen.
Wie bereits erwähnt, kann der PCM-Scheduler 204 aus einer Vielzahl von PCM-Scheduler-Instanzen bestehen, um die Führungsrolle zu übernehmen. In einigen Ausführungsformen kann eine PCM-Instanz zum Master-PCM-Scheduler gewählt werden, während die übrigen PCM-Scheduler-Instanzen als Backup-PCM-Scheduler konfiguriert werden können. So kann der verteilte KV-Speicher 202 für den Fall, dass ein Master-PCM-Scheduler ausfällt, zur Wahl eines neuen Master-PCM-Schedulers aus einem der Backup-PCM-Scheduler verwendet werden. Ein neu gewählter Master-PCM-Scheduler kann einen aktuellen PCM-Scheduler-Status aus dem verteilten KV-Speicher 202 laden (es sei daran erinnert, dass der verteilte KV-Speicher 202 dazu verwendet werden kann, Mieter-PCM-Zuordnung und mieterrelevante Informationen im Namen des PCM-Schedulers 204 zu speichern/zu sichern). In einigen Ausführungsformen kann ein neuer Master-PCM-Scheduler die neuesten Mieter-PCM-Zuordnungen für jedes PCM erhalten und diese Zuordnungen auf der Grundlage der im verteilten KV-Speicher 202 gespeicherten Daten abgleichen.
Um auf die PCM-Erkennung zurückzukommen, kann sich jedes PCM 204a-d bei dem verteilten KV-Speicher 202 registrieren, wenn das PCM in Betrieb genommen wird, und jedes PCM 204a-d kann sich selbst abmelden, bevor es außer Betrieb geht. Der PCM-Scheduler 204 kann eine gRPC-Client-Verbindung zu jedem entdeckten PCM initiieren und in regelmäßigen Abständen PCM-Zustandsprüfungen durchführen. Es folgt eine nicht abschließende Liste von RPCs, die vom PCM-Scheduler 204 angefordert werden können: „keep-alive/health-check“-RPC; „load tenant“-RPC (was sich auf das Laden des aktuellen Zustands eines Tenants aus dem redis-Cluster 208 und die Durchführung einer vollständigen Neuberechnung der Route bezieht); „unload tenant“-RPC (was sich auf die Aufgabe des Tenant-Eigentums durch ein PCM und das Flushen aller Zustandsaktualisierungen bezieht, die für den Tenant durchgeführt und im redis-Cluster 208 aufgezeichnet wurden); „full compute‟ RPC (zur Durchführung einer vollständigen Neuberechnung der Tenant-Route (wenn ein Datenverlust, wie oben beschrieben, festgestellt wird und/oder wenn eine Benachrichtigungswarteschlange voll ist und keine Aktualisierungen abgeholt werden können); „get current“ RPC (für den Abgleich von Tenant-Zuweisungen zwischen PCM Scheduler 204 und einem oder mehreren PCMs 206a-n); „clear tenant“ RPC (die durchgeführt werden kann, um die Daten eines Tenants zu löschen/ungültig zu machen, aber der aktuelle Zustand des Tenants wird nicht in den Redis-Cluster 208 gespült); und „clear all tenants“ RPC (die ähnlich wie die „clear tenant“ RPC durchgeführt werden kann, aber für alle und nicht für einen einzelnen Tenant, um den Zustand eines PCM zu löschen, wenn der Zustand des PCM wiederhergestellt ist).
Jedes PCM, z. B. die PCMs 206a-206n, erstellt, wie oben erwähnt, Routen zwischen SDWAN-Knoten (basierend auf dem Underlay-Routing-Daemon und über die OAs), die dann an alle CBS-Server in einem PCM-Cluster veröffentlicht werden können. Da es sich bei PCM um einen Cloud-Microservice handelt, kann sich die Anzahl der PCM-Knoten in einem PCM-Cluster je nach Anzahl der Kunden/Mieter, Routen, Tunnel usw. entsprechend erhöhen/verringern. Ein PCM-Cluster kann so konfiguriert werden, dass er mehrere verschiedene Mandanten bedient (die durch einen unten beschriebenen Bereitstellungsprozess bestimmt werden), aber ein Mandant wird nur von einem einzigen PCM-Cluster bedient, um Probleme mit der Synchronisierung der Mandanten-PCM-Zuordnung zu vermeiden. In einigen Ausführungsformen wird während der Bereitstellung ein Satz von Mandanten fest an einen PCM-Cluster mit der erforderlichen Anzahl von PCM-Knoten gebunden, und die Bindung kann auf der Anzahl von Mandanten-Präfixen (Routen), der Anzahl von Mandantengeräten usw. basieren.
Wenn ein PCM aus irgendeinem Grund ausfällt oder abstürzt, erfährt der PCM-Scheduler 204 (auf der Grundlage der vom PCM-Scheduler 204 angeforderten Keep-Alive-/Gesundheitsprüfungs-RPCs) schließlich von dem Ausfall/Absturz. Der PCM-Scheduler 204 kann alle Tenants, die dem ausgefallenen PCM zugeordnet sind, einem anderen PCM neu zuweisen. Wenn PCM Scheduler 204 nicht in der Lage ist, eine Verbindung zu einem bestimmten PCM herzustellen, z. B. aufgrund einer Netzwerkpartitionierung, kann PCM Scheduler 204 Mieter, die diesem nicht erreichbaren PCM zugeordnet sind, nach einer bestimmten Zeitspanne/Timeout-Dauer neu zuweisen. Ein PCM kann auch feststellen, dass es nicht mehr mit dem PCM-Scheduler 204 verbunden ist, und nach einer gewissen Zeitspanne/Zeitüberschreitung (die sich von der des PCM-Schedulers 204 unterscheiden kann) kann das PCM sich selbst unter Quarantäne stellen, indem es auf keine Benachrichtigungen von seinem zugehörigen CBS-Server reagiert. Auf diese Weise kann sichergestellt werden, dass nicht zwei oder mehr verschiedene PCMs zur gleichen Zeit auf denselben Mieter einwirken. Es sei darauf hingewiesen, dass es sich bei 2 um eine Beispielarchitektur handelt und dass die Anzahl der Komponenten, die Art der Verbindung/Interaktion zwischen diesen Komponenten usw. in Übereinstimmung mit anderen Ausführungsformen unterschiedlich sein kann.
3A zeigt eine schematische Darstellung einer PCM-Dienstinstanz gemäß einer Ausführungsform. Wie in 3A dargestellt, kann die PCM-Dienstinstanz 300 ein PCM 302A umfassen, bei dem es sich um eine Ausführungsform eines PCM handeln kann, wie z. B. PCM 206a (oben unter Bezugnahme auf 2 beschrieben). Wie oben beschrieben, kann PCM 302A Routen innerhalb eines SDWAN auf der Grundlage von Präfixen/Zuständen berechnen oder erstellen, die von einem Underlay-Routing-Daemon empfangen und von einem Tenant-Gerät (Zweigstellen-Gateway oder VPNC) OA über einen OA-Kanal veröffentlicht werden. Dementsprechend kann die PCM-Dienstinstanz 300 eine Konfigurations-/Tunnelschnittstelle 304 enthalten. Zu Debugging-Zwecken kann PCM 302 einen REST-Server mit Überwachungs-/Debugging-APIs 308 enthalten, um interne Zustände verschiedener Elemente/Komponenten offenzulegen. Solche APIs 308 können abgefragt werden, um diese internen Zustandsinformationen zu erhalten.
PCM 302A kann (nach der erforderlichen Synchronisierung/Re-Synchronisierung) an ein OA veröffentlichen. Die Kommunikation über einen OA-Kanal kann über einen CBS-Server erfolgen, wobei jeder OA-Kanal ein RPC, wie z. B. gRPC 312A, für Transportzwecke verwenden kann. 3A zeigt eine Cloud-BGP-Instanz 310A, die auf einem solchen CBS-Server gehostet oder ausgeführt wird. Typischerweise wird, wie oben beschrieben, die Implementierung eines SDWAN mit BGP durchgeführt, aber Standard-BGP ist möglicherweise nicht praktikabel und ermöglicht nicht die erforderliche Skalierung, die in Übereinstimmung mit verschiedenen Ausführungsformen in Betracht gezogen wird. Das heißt, dass eine SORS-Implementierung skalierbar sein soll, um mehrere Kunden/Mieter mit Zehntausenden von Geräten/Gateways, wie z. B. Zweigstellen-Gateways und VPNCs, zu bedienen. Dementsprechend sollte das CBS die Kapazität/Fähigkeit haben, eine große Anzahl solcher Geräte zu unterstützen. Um dem CBS der SORS-Implementierung die erforderlichen Fähigkeiten zu verleihen, wird das CBS so konfiguriert, dass es horizontal skalierbar ist, um mehrere OAs zu bedienen. Außerdem kann der CBS ein pseudo-zustandsloser Dienst sein und daher mehrere Mieter gleichzeitig bedienen, ohne dass eine feste Bindung besteht. Das heißt, jeder CBS-Server/jede CBS-Instanz kann jedes Gerät bedienen, das zu einem beliebigen Mandanten gehört. Im Gegensatz dazu können Tenants, wie oben beschrieben, fest an einen bestimmten PCM-Cluster gebunden sein, d. h. nur eine PCM-Instanz kann eine Anfrage von einem beliebigen Gerät eines Tenants bedienen.
In einigen Ausführungsformen kann die CBS eine BGP-Routenreflektorfunktionalität implementieren, bei der nicht jedes BGP-System mit jedem anderen BGP-System ein Peering eingehen muss, sondern ein Peering zwischen einem BGP-System und einem Routenreflektor stattfindet. Routing-Ankündigungen können dann an den Routenreflektor gesendet werden, der sie an andere BGP-Systeme weiterleitet. Dementsprechend kann die Cloud-BGP-Instanz 310A eine KV-Pub/Sub-Funktion 310A-1 enthalten, um die Zustandssynchronisierung mit OAs und Routen-Pub/Sub zu ermöglichen, sowie einen Peer/Nachrichten-Handler 310A-2 (der erweitert werden kann, um andere Nutzlasttypen zu unterstützen, z. B. den Betriebsstatus von Tunneln und verkehrstechnische Routen). Es sollte klar sein, dass ein CBS Zustände für Geräteaktualisierungen, die er empfangen hat, beibehalten kann (daher nicht vollständig zustandslos/pseudo zustandslos, wie oben erwähnt), aber in Bezug auf die Geräte, die er bedienen kann, zustandslos ist, d. h. der CBS hat keine Mandantenaffinität. Wie oben beschrieben, kann ein verteilter KV-Speicher verwendet werden, um die Routenüberwachung (pub-sub) zu unterstützen, die der KV pub/sub-Funktion 310A-1 entspricht, sowie die PCM-Führungsfunktionalität zu unterstützen, z. B. die Wahl des Master-PCM-Schedulers und die PCM-Erkennung. Dementsprechend kann die PCM-Dienstinstanz 300 einen verteilten KV-Speicheradapter 306 enthalten.
Es ist anzumerken, dass die Verwendung des herkömmlichen BGP-Routing-Stacks als Routenreflektor nicht möglich ist (daher die hier offengelegte Verwendung von Cloud-BGP), nicht nur wegen der mangelnden Skalierbarkeit, sondern auch, weil herkömmliches BGP TCP für den Transport verwendet, was es schwierig macht, Verbindungen, die von verschiedenen Mietern kommen, auf einen mieterspezifischen PCM-Dienst zu verteilen. Wie bereits erwähnt, kann ein Lastausgleich (basierend auf der Identität eines Mieters (Tenant-ID)) durchgeführt werden, wobei der gesamte Verkehr, der zu einem bestimmten Mieter gehört, an das entsprechende/zugewiesene PCM gesendet wird.
3B zeigt eine schematische Darstellung einer CBS-Instanz 310 gemäß einer Ausführungsform. Die Komponenten/Funktionalität der CBS-Instanz 310 sind ähnlich/entsprechen denen, die oben für die PCM-Dienstinstanz 300 beschrieben wurden. Das heißt, CBS-Instanz 310 kann eine RPC, wie gRPC 312B, für Transportzwecke enthalten, um die Kommunikation zwischen PCM-Service-Instanz 300 und CBS-Instanz 300 zu erleichtern, und gRPC 312C, um die Kommunikation mit OAs eines Mandanten, z. B. einer OA 322, zu erleichtern. Wie die PCM-Dienstinstanz 300 kann auch die CBS-Instanz 310 eine Cloud-BGP-Instanz 310B umfassen. Die Cloud-BGP-Instanz 310B kann eine KV-Pub/Sub-Funktion 310B-1 enthalten, um die Zustandssynchronisierung mit OAs und Routen-Pub/Sub zu ermöglichen, sowie einen Peer/Nachrichten-Handler 310B-2 (der erweitert werden kann, um andere Nutzlasttypen zu unterstützen, z. B. den Betriebsstatus von Tunneln und verkehrstechnische Routen). Wie oben beschrieben, kann die PCM-Führungsfunktionalität, z. B. die Wahl des PCM-Master-Schedulers und die PCM-Erkennung, über einen verteilten KV-Speicher unterstützt werden. Dementsprechend kann die CBS-Instanz 310 einen Adapter 314 für einen verteilten KV-Speicher enthalten.
Wie oben erwähnt, kann Cloud BGP Route Reflectors für Peering verwenden, und daher kann die CBS-Instanz 300 eine Authentifizierungskomponente 316 für die Authentifizierung neuer Peers und die Aktivierung des Dienstes zwischen Geräten enthalten. Wie die PCM-Dienstinstanz 300 kann auch die CBS-Instanz 310 eine Überwachungs-/Debugging-API 320 enthalten, die von einem Benutzer über einen REST-Server (nicht dargestellt) aufgerufen werden kann. Darüber hinaus kann die CBS-Instanz 310 einen Steuerkanal-Multiplexer/Demultiplexer 318 zur Verarbeitung anderer Steuerkanal-Anwendungsaufrufe/Kommunikationen, z. B. Interprozesskommunikation (IPCs) und RPCs, enthalten.
4 ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 400 zur Durchführung von Dienstsicherungsfunktionen gemäß einer Ausführungsform. Bei der Rechnerkomponente 400 kann es sich beispielsweise um einen Servercomputer, einen Controller oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten und die Funktionalität einer Assurance Engine zu realisieren. In der Beispielimplementierung von 4 umfasst die Rechnerkomponente 400 einen Hardwareprozessor 402 und ein maschinenlesbares Speichermedium 404. In einigen Ausführungsformen kann die Computerkomponente 400 eine Ausführungsform eines Prozessors sein.
Bei dem Hardware-Prozessor 402 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in dem maschinenlesbaren Speichermedium 404 gespeichert sind. Der Hardwareprozessor 402 kann Befehle, wie die Befehle 406-412, abrufen, dekodieren und ausführen, um Prozesse oder Vorgänge zum Aufbau von Verbindungen, zur Synchronisierung und zur Veröffentlichung von Routen/Zuständen zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 402 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, z. B. ein Field Programmable Gate Array (FPGA), einen anwendungsspezifischen integrierten Schaltkreis (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 404, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 404 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM), einen nichtflüchtigen RAM (NVRAM), einen elektrisch löschbaren programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte oder ähnliches handeln. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 404 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie unten im Detail beschrieben, kann das maschinenlesbare Speichermedium 404 mit ausführbaren Befehlen kodiert sein, z. B. mit den Befehlen 404-412.
Der Hardware-Prozessor 402 kann die Funktionalität einer oder mehrerer Komponenten/Elemente eines SORS, wie z. B. SORS 201 (2), implementieren und kann die Anweisung 406 ausführen, um eine SDWAN-Geräteidentifikation zu empfangen. Das heißt, dass der CBS (implementiert über einen oder mehrere CBS-Server in einem SORS) und der PCM-Dienst (implementiert über einen oder mehrere PCM-Server in einem SORS) den Betrieb aufnehmen/initialisieren können. Die OAs von Tenant-SDWAN-Geräten, z. B. Zweigstellen-Gateways und VPNCs, können ebenfalls den Betrieb aufnehmen. Zu diesem Zeitpunkt verbinden sich die OAs mit dem SORS unter Verwendung der spezifischen DNS/VIP des SORS über entsprechende OA-Kanäle. Auch hier wird ein spezifischer DNS/VIP verwendet, um den Verkehr der Steuerebene von anderem Managementverkehr zu isolieren. An diesem Punkt können sich die OAs gegenüber dem SORS identifizieren. Die OA-Identifikationsinformationen können die Seriennummer des Geräts, die Mieterkennung, das Authentifizierungs-Token usw. umfassen.
Der Hardware-Prozessor 402 kann die Anweisung 408 zur Authentifizierung des SDWAN-Geräts ausführen. Insbesondere wird das CBS des SORS die OA authentifizieren, indem es die von der OA empfangenen OA-Identifikationsinformationen mit den in einem Authentifizierungsserver oder einer Datenbank gespeicherten Identifikationsinformationen abgleicht. Wie oben in 3B beschrieben, kann die Authentifizierung durch den CBS unter Verwendung der Authentifizierungskomponente 316 durchgeführt werden. Wie oben beschrieben, kann die OA in einigen Ausführungsformen benutzerdefinierte HTTP-Header einfügen, um den Mieter der OA zu identifizieren. Es sei darauf hingewiesen, dass bei einer fehlgeschlagenen Authentifizierung die Verbindung zwischen OA und CBS zurückgesetzt werden kann.
Der Hardware-Prozessor 402 kann die Anweisung 410 ausführen, um eine Synchronisierung mit dem SDWAN-Gerät auf der Grundlage des neuesten Routenstatus und der mit dem SDWAN-Gerät verbundenen lokalen Routenpräfixe durchzuführen. Das heißt, die OA und die CBS können Routeninformationen synchronisieren/resynchronisieren, und die OA kann alle erforderlichen Routenstatus und Tenant-Präfixe hochladen, die mit der OA verbunden sind. Es versteht sich, dass lokale Routen/Routenpräfixe über den Underlay-Routing-Stack gelernt werden können, die der OA über den CBS über einen OA-Kanal an das PCM weiterleiten kann. In einigen Ausführungsformen kann der CBS alle bestehenden, vom PCM erstellten Routen als veraltet markieren und im Falle eines PCM-Ausfalls auf Routenaktualisierungen durch einen neuen PCM-Master warten. Wenn Routen nicht aktualisiert werden, kann das CBS diese Routen als gelöschte Routen kennzeichnen, und die OAs können mit dem PCM synchronisiert werden.
Im Gegenzug kann das PCM diese neuesten Routenzustände/Präfixe (d. h. aktualisierte Routen-/Pfadinformationen) verarbeiten und neue Routen/Pfade erstellen. Das heißt, der Hardware-Prozessor 402 kann die Anweisung 412 ausführen, um die neuen Zustände an das SDWAN-Gerät zu veröffentlichen, die den neu erstellten Routen/Pfaden auf der Grundlage der neuesten Routenzustände/Präfixe entsprechen.
Es sollte beachtet werden, dass die Begriffe „optimieren“, „optimal“ und dergleichen, wie sie hier verwendet werden, so verwendet werden können, dass sie die Leistung so effektiv oder perfekt wie möglich machen oder erreichen. Wie jedoch ein Fachmann, der dieses Dokument liest, erkennen wird, kann Perfektion nicht immer erreicht werden. Dementsprechend können diese Begriffe auch bedeuten, die Leistung so gut oder effektiv wie unter den gegebenen Umständen möglich oder praktikabel zu machen oder zu erreichen, oder die Leistung besser zu machen oder zu erreichen als die, die mit anderen Einstellungen oder Parametern erreicht werden kann.
5 zeigt ein Blockdiagramm eines beispielhaften Computersystems 500, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 500 umfasst einen Bus 502 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen sowie einen oder mehrere Hardware-Prozessoren 504, die mit dem Bus 502 zur Verarbeitung von Informationen verbunden sind. Bei dem/den Hardware-Prozessor(en) 504 kann es sich zum Beispiel um einen oder mehrere Allzweck-Mikroprozessoren handeln.
Das Computersystem 500 umfasst auch Speichereinheiten, wie z. B. einen Hauptspeicher 506, wie z. B. einen Direktzugriffsspeicher (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 502 verbunden sind, um Informationen und Befehle zu speichern, die vom Prozessor 504 ausgeführt werden sollen. Der Hauptspeicher 506 kann auch zum Speichern temporärer Variablen oder anderer Zwischeninformationen während der Ausführung von Befehlen verwendet werden, die vom Prozessor 504 ausgeführt werden sollen. Wenn solche Befehle in Speichermedien gespeichert werden, auf die der Prozessor 504 zugreifen kann, wird das Computersystem 500 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Befehlen angegebenen Operationen ausführen kann.
Das Computersystem 500 umfasst außerdem einen Festwertspeicher (ROM) 508 oder ein anderes statisches Speichergerät, das mit dem Bus 502 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 504 zu speichern. Ein Speichergerät 510, wie z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 502 verbunden, um Informationen und Anweisungen zu speichern. Ebenfalls an den Bus 502 gekoppelt sind ein Display 512 zur Anzeige verschiedener Informationen, Daten, Medien usw. und ein Eingabegerät 514, das es einem Benutzer des Computersystems 500 ermöglicht, das Computersystem 500 zu steuern, zu manipulieren und/oder mit ihm zu interagieren. Eine Art der Interaktion kann über eine Cursorsteuerung 516 erfolgen, wie z. B. eine Computermaus oder ein ähnlicher Steuerungs-/Navigationsmechanismus.
Im Allgemeinen kann sich der hier verwendete Begriff „Engine“, „Komponente“, „System“, „Datenbank“ und dergleichen auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Ein- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es ist klar, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufgerufen werden können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung eine Installation, Dekomprimierung oder Entschlüsselung erfordert). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts zur Ausführung durch das Computergerät gespeichert werden. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
Das Computersystem 500 kann die hier beschriebenen Techniken unter Verwendung von kundenspezifischer festverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem das Computersystem 500 zu einer Spezialmaschine macht oder programmiert. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 500 als Reaktion auf den/die Prozessor(en) 504 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren im Hauptspeicher 506 enthaltenen Befehlen ausführt/ausführen. Solche Anweisungen können in den Hauptspeicher 506 von einem anderen Speichermedium, wie z. B. einem Speichergerät 510, eingelesen werden. Die Ausführung der im Hauptspeicher 506 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 504, die hier beschriebenen Prozessschritte durchzuführen. In alternativen Ausführungsformen können fest verdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die eine Maschine in einer bestimmten Weise arbeiten lassen. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie die Speichervorrichtung 510. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 506. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM und EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nichttransitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 502 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
Wie hierin verwendet, kann der Begriff „oder“ sowohl im einschließenden als auch im ausschließenden Sinne verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke, wie z. B. „kann“, „könnte“, „könnte“ oder „kann“, sollen im Allgemeinen vermitteln, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte einschließen, während andere Ausführungsformen diese nicht einschließen, es sei denn, es ist ausdrücklich etwas anderes angegeben oder im Zusammenhang mit der Verwendung anders zu verstehen. Begriffe und Ausdrücke, die in diesem Dokument verwendet werden, und Variationen davon, sofern nicht ausdrücklich anders angegeben, sollten als offen und nicht als einschränkend verstanden werden. Als Beispiele für das Vorstehende ist der Begriff „einschließlich“ im Sinne von „einschließlich, ohne Einschränkung“ oder dergleichen zu verstehen. Der Begriff „Beispiel“ wird verwendet, um exemplarische Beispiele für den Gegenstand der Diskussion zu geben, nicht um eine erschöpfende oder einschränkende Liste zu erstellen. Die Begriffe „ein“ oder „ein“ sind im Sinne von „mindestens ein“, „ein oder mehrere“ oder ähnlich zu verstehen. Das Vorhandensein von erweiternden Wörtern und Ausdrücken wie „einer oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnlichen Ausdrücken in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Ausdrücke nicht vorhanden sind.

Claims

Ein Verfahren, das Folgendes umfasst: Empfang von Identifikationsinformationen über ein SDWAN-Gerät (Softwaredefined Wide Area Network); die Authentifizierung des SDWAN-Geräts; Synchronisieren eines SDWAN-Routing-Dienstes mit der SDWAN-Vorrichtung auf der Grundlage des letzten Zustands und lokaler Routenpräfixe, die mit der SDWAN-Vorrichtung verbunden sind; und Veröffentlichung neuer Zustände für das SDWAN-Gerät entsprechend den vom SDWAN-Routingdienst auf der Grundlage des neuesten Zustands und der lokalen Routenpräfixe erstellten Routen.
Verfahren nach Anspruch 1, wobei der SDWAN-Routing-Dienst einen Cloud-Branch-Gateway-Protokoll (BGP)-Mikroservice umfasst, der über einen Cluster von Cloud-BGP-Servern und einen Cluster von Pfadberechnungsmodulen (PCMs) implementiert ist.
Verfahren nach Anspruch 2, wobei ein erster Cloud-BGP-Server des Clusters von Cloud-BGP-Servern den neuesten Zustand und lokale Routenpräfixe von einem Overlay-Agenten des SDWAN-Geräts an ein erstes PCM des Clusters von PCMs veröffentlicht.
Verfahren nach Anspruch 3, wobei der Overlay-Agent und der erste Cloud-BGP-Server über einen Overlay-Agenten-Kanal kommunizieren, wobei der Overlay-AgentenKanal in Übereinstimmung mit einem Lastausgleichsmechanismus zugewiesen wird, der einen Mieter, der die SDWAN-Vorrichtung betreibt, und den Cluster von BGP-Servern verbindet.
Verfahren nach Anspruch 4, wobei der Lastausgleichsmechanismus auf einem Hypertext Transfer Protocol (HTTP)-Header oder einem Uniform Resource Locator (URL) basiert, der dem Mandanten zugeordnet ist.
Das Verfahren nach Anspruch 5 umfasst ferner das Einfügen eines benutzerdefinierten Headers in Pakete, die auf dem Overlay-Agenten-Kanal übertragen werden, basierend auf dem HTTP-Header oder der URL, die dem Mieter zugeordnet ist.
Verfahren nach Anspruch 4, wobei der erste Cloud-BGP-Server die Veröffentlichung der neuen Zustände an den Overlay-Agenten des SDWAN-Geräts durchführt, nachdem die neuen Zustände durch das erste PCM an den ersten Cloud-BGP-Server veröffentlicht wurden.
Das Verfahren nach Anspruch 4 umfasst ferner das Einrichten des Overlay-Agenten-Kanals auf der Grundlage einer spezifischen virtuellen Internetprotokoll-Adresse (VIP), die dem SDWAN-Routing-Dienst zugeordnet ist, so dass der Verkehr der Steuerungsebene des SDWAN-Routing-Dienstes vom Verkehr der Verwaltungsebene des SDWAN-Routing-Dienstes isoliert ist.
Verfahren nach Anspruch 4, wobei eine elastische Lastausgleichskomponente des SDWAN-Routingdienstes den Overlay-Agentenkanal als sicheren Kanal beendet und den Overlay-Agentenkanal als Klartextkanal zum ersten Cloud-BGP-Server herstellt.
Das Verfahren nach Anspruch 4 umfasst ferner die Verwaltung des Lastausgleichsmechanismus durch eine PCM-Planungskomponente auf der Grundlage einer Anzahl aktiver PCMs, einer Anzahl von SDWAN-Geräten, die einem Mandanten zugeordnet sind, einer Anzahl von Tunneln für den Mandanten und einer letzten Zustandsaktualisierung, die dem Mandanten zugeordnet ist.
Verfahren nach Anspruch 10, das ferner das Speichern einer Mieter-zu-PCM-Zuordnung und mieterrelevanter Informationen, die durch den Lastausgleichsmechanismus reflektiert werden, in einem verteilten Schlüsselwertspeicher des SDWAN-Routingdienstes umfasst.
Verfahren nach Anspruch 11, das ferner umfasst, dass jedes PCM des Clusters von PCMs über die Mieter-zu-PCM-Zuordnung und mieterrelevante Informationen, die sich in dem verteilten Schlüsselwertspeicher widerspiegeln, ermittelt wird, wobei sich jedes der PCMs bei der Initialisierung der Operation in dem verteilten Schlüsselwertspeicher registriert.
Verfahren nach Anspruch 12, das ferner umfasst, dass der PCM-Scheduler unter Verwendung von Fernprozeduraufrufen an jedes PCM des PCM-Clusters gerichtete Operationen zur Aufrechterhaltung des Betriebs und zur periodischen Gesundheitsprüfung initiiert.
Verfahren nach Anspruch 3, wobei der Overlay-Agent operativ mit einem Underlay-Routing-Daemon verbunden ist, um die lokalen Routenpräfixe zu erhalten.
System zur Bereitstellung eines softwaredefinierten Weitverkehrsnetzes (SDWAN) Overlay-Routing-Dienstes, umfassend: eine Vielzahl von Cloud Branch Gateway Protocol (BGP)-Servern, die zusammen einen Cloud BGP Microservice bilden, um: Informationen zur Identifizierung eines SDWAN-Geräts empfangen und das SDWAN-Gerät authentifizieren; und eine Gruppe von Pfadberechnungsmodulen (PCMs), die zusammen einen PCM-Microservice bilden, um: Synchronisieren von Routen, die mit der SDWAN-Vorrichtung verbunden sind, basierend auf dem letzten Zustand und den lokalen Routenpräfixen, die mit der SDWAN-Vorrichtung verbunden sind; und neue Zustände auf dem SDWAN-Gerät veröffentlichen, die den vom SDWAN-Routingdienst auf der Grundlage des neuesten Zustands und der lokalen Routenpräfixe erstellten Routen entsprechen.
System nach Anspruch 15, wobei der Cloud-BFP-Mikroservice die Informationen, die das SDWAN-Gerät identifizieren, von einem Overlay-Agenten empfängt, der auf dem SDWAN-Gerät implementiert ist, wobei der Overlay-Agent eine Verbindung zu einem Underlay-Routing-Daemon herstellt, um die lokalen Routenpräfixe zu erhalten, und die Informationen über einen Overlay-Agenten-Kanal überträgt.
System nach Anspruch 16, wobei der Overlay-Agent den Overlay-Agenten-Kanal auf der Grundlage einer spezifischen virtuellen Internetprotokoll-Adresse (VIP) einrichtet, die dem System zugeordnet ist, so dass der Verkehr der Steuerungsebene des SDWAN-Overlay-Routing-Dienstes vom Verkehr der Verwaltungsebene des SDWAN-Overlay-Routing-Dienstes isoliert ist.
System nach Anspruch 16, wobei der Cloud-BGP-Mikroservice den neuesten Zustand und lokale Routenpräfixe vom Overlay-Agenten des SDWAN-Geräts an den PCM-Mikroservice veröffentlicht.
System nach Anspruch 16, wobei der Overlay-Agentenkanal in Übereinstimmung mit einem Lastausgleichsmechanismus zugewiesen wird, der einen Mieter, der das SDWAN-Gerät betreibt, und die mehreren Cloud-BGP-Server verbindet.
Das System nach Anspruch 19 umfasst ferner eine PCM-Planungskomponente, um den Lastausgleichsmechanismus auf der Grundlage einer Anzahl aktiver PCMs, einer Anzahl von SDWAN-Geräten, die dem Mandanten zugeordnet sind, einer Anzahl von Tunneln für den Mandanten und einer letzten Statusaktualisierung, die dem Mandanten zugeordnet ist, zu verwalten.