Dieser Abschnitt bietet einen ausführlichen Überblick über die Arbeitsweise der Clustering-Funktion von SD-WAN Edge.

Nachfolgend sind wichtige Konzepte aufgeführt, die die Clustering-Funktion von SD-WAN Edge beschreiben:

  • Edge-Clustering kann auf Hubs wie folgt verwendet werden:
    • Um eine größere Tunnelkapazität für einen Hub zu ermöglichen, als ein einzelner als Hub dienender Edge bieten kann.
    • Um die Remote-Spoke-Edges auf mehrere Hubs zu verteilen und die Auswirkungen eines eventuell auftretenden Zwischenfalls zu reduzieren.
  • Cluster Score ist eine mathematische Berechnung der Gesamtauslastung des Systems wie folgt:
    Die drei gemessenen Auslastungsfaktoren sind CPU-Auslastung, Speichernutzung und Tunnelkapazität.
    • Jede Nutzungsmessung wird als Prozentsatz eines Maximums von 100 % behandelt.
    • Die Tunnelkapazität basiert auf der bewerteten Kapazität für ein bestimmtes Hardwaremodell oder eine Virtual Edge-Konfiguration.
    • Alle drei Nutzungsprozentsätze werden gemittelt, um einen ganzzahlbasierten Cluster Score (1 – 100) zu erhalten.
    • Der Durchsatz wird zwar nicht direkt berücksichtigt, aber die Nutzung von CPU und Arbeitsspeicher spiegeln indirekt den Durchsatz und das Flow-Volumen auf einem bestimmten Hub wider.
    • Beispielsweise auf einem Edge 2000:
      • CPU-Nutzung = 20 %
      • Arbeitsspeichernutzung = 30 %
      • Verbundene Tunnel = 600 (von 6000) = 10 %
      • Cluster Score: (20 + 30 + 10)/3 = 20
  • Ein Cluster Score über 70 wird als „Überkapazität“ betrachtet.
  • Eine „logische ID“ ist eine 128-Bit-UUID, die ein Element im VMware-Netzwerk eindeutig kennzeichnet.
    • Beispiel: Jeder Edge wird durch eine logische ID repräsentiert, und jeder Cluster wird durch eine logische ID repräsentiert.
    • Während der Benutzer die Edge- und die Clusternamen bereitstellt, sind die logischen IDs garantiert eindeutig und werden für die interne Identifizierung der Elemente verwendet.
  • Standardmäßig wird die Last gleichmäßig auf Hubs verteilt. Daher ist es erforderlich, dass alle Edges, die Teil eines Clusters sind, dasselbe Modell und dieselbe Kapazität aufweisen.
Jedes Clustermitglied verfügt über eine eigene IP-Adressierung für die WAN- und LAN-Schnittstellen. Alle VMware SD-WAN Edges im Hub-Cluster müssen ein dynamisches Routing-Protokoll wie eBGP mit den Schicht-3-Geräten auf der LAN-Seite mit einer eindeutigen autonomen Systemnummer (Autonomous System Number, ASN) für jedes Clustermitglied ausführen. Dynamisches Routing auf der LAN-Seite des Clusters stellt sicher, dass der Datenverkehr vom DC zu einer bestimmten Spoke-Site über das entsprechende Edge-Clustermitglied geroutet wird.
Wichtig: Hub-Edges in einem Cluster stellen keine Verbindung her oder kommunizieren nicht über Tunnel oder Routingprotokolle miteinander. Sie fungieren als unabhängige Edges für Funktionen der Datenebene. Sie hängen vom LAN-seitigen BGP-Peering zum Core-Switch ab, um den Zweigstelle-zu-Zweigstelle-Datenverkehr zu verarbeiten, wenn die Zweigstelle-Edges mit verschiedenen Hub-Edges im Cluster verbunden sind.

Wie werden Edge-Cluster vom VMware SD-WAN Gateway verfolgt?

Sobald ein Hub zu einem VMware SD-WAN-Cluster hinzugefügt wird, bricht der Hub ab und erstellt die Tunnel zu allen ihm zugewiesenen Gateways neu. Außerdem wird jedem Gateway angezeigt, dass der Hub einem Cluster zugewiesen wurde, und eine logische Cluster-ID wird angegeben.

Das SD-WAN-Gateway verfolgt für den Cluster Folgendes:
  • Die logische ID
  • Den Namen
  • Ob der automatische Neuausgleich aktiviert ist
  • Eine Liste mit Hub-Objekten für Mitglieder des Clusters

Für jedes Hub-Objekt im Cluster verfolgt das Gateway Folgendes:

  • Die logische ID
  • Den Namen
  • Eine Reihe von Statistiken, die alle 30 Sekunden durch eine periodische Nachricht aktualisiert werden, die vom Hub an jedes zugewiesene Gateway gesendet wird, einschließlich:
    • Aktuelle CPU-Nutzung des Hubs
    • Aktuelle Arbeitsspeichernutzung des Hubs
    • Aktuelle Tunnelzahl auf dem Hub
    • Aktuelle Anzahl der BGP-Routen auf dem Hub
  • Der aktuelle berechnete Cluster Score basierend auf der oben angegebenen Formel.

Ein Hub wird aus der Liste der Hub-Objekte entfernt, wenn das Gateway mehr als sieben Sekunden lang keine Pakete vom Hub-Edge empfangen hat.

Wie werden Edges einem bestimmten Hub in einem Cluster zugewiesen?

In einer herkömmlichen Hub- und Spoke-Topologie stellt SASE Orchestrator den Edge mit der logischen ID des Hubs zur Verfügung, mit dem er verbunden werden muss. Der Edge fordert bei seinen zugewiesenen Gateways Konnektivitätsinformationen für die logische ID dieses Hubs an, d. h. IP-Adressen und Ports, die der Edge für die Verbindung mit diesem Hub verwendet.

Aus der Perspektive des Edge ist dieses Verhalten identisch mit dem Verhalten beim Verbinden mit einem Cluster. Der Orchestrator teilt dem Edge mit, dass die logische ID des Hubs, mit dem er eine Verbindung herstellen soll, die logische ID des Clusters und nicht die logische ID des einzelnen Hubs ist. Der Edge führt dasselbe Verfahren durch, um eine Hub-Verbindungsanfrage an die Gateways zu senden, und erwartet als Reaktion darauf Verbindungsinformationen.

An diesem Punkt gibt es zwei Abweichungen vom grundlegenden Hub-Verhalten:

  • Abweichung Nr. 1: Das Gateway muss auswählen, welcher Hub zugewiesen werden soll.
  • Abweichung Nr. 2: Aufgrund von Abweichung Nr. 1 erhält der Edge möglicherweise verschiedene Zuweisungen von seinen verschiedenen Gateways.

Die Abweichung Nr. 1 wurde ursprünglich angesprochen, indem der Cluster Score verwendet wurde, um den am wenigsten belasteten Hub in einem Cluster einem Edge zuzuweisen. Obwohl dies logisch ist, erwies es sich in der realen Welt als eine nicht ideale Lösung, da ein typisches Neuzuweisungsereignis Hunderte oder sogar Tausende von Edges betreffen kann und der Cluster Score nur alle 30 Sekunden aktualisiert wird. Mit anderen Worten: Wenn Hub 1 einen Cluster Score von 20 und Hub 2 einen Cluster Score von 21 hat, würden alle Edges 30 Sekunden lang Hub 1 wählen, woraufhin dieser überlastet sein und weitere Neuzuweisungen auslösen könnte.

Stattdessen versucht das Gateway zunächst eine faire mathematische Verteilung unter Missachtung des Cluster Score. Die logischen Edge-IDs, die von einem sicheren Zufallszahlengenerator auf dem Orchestrator erzeugt wurden, werden (bei genügend Edges) eine gleichmäßige Verteilung der Werte aufweisen. Das bedeutet, dass anhand der logischen ID eine faire Anteilsverteilung berechnet werden kann.

  • Logische Edge-ID modulo die Anzahl der Hubs im Cluster = Zugewiesener Hub-Index
  • Beispiel:
    • Vier Edges mit logischen IDs, die auf 1, 2, 3, 4 enden
    • Cluster mit 2 Hubs
    • 1 % 2 = 1, 2 % 2 = 0, 3 % 2 = 1, 4 % 2 = 0 (Hinweis: „%“ steht für den Operator „modulo“)
    • Edge 2 und 4 wird der Hub-Index 0 zugewiesen
    • Edge 1 und 3 wird der Hub-Index 1 zugewiesen

    Diese Vorgehensweise ist konsistenter als eine Zuweisung vom Typ „Round-Robin“, weil es bedeutet, dass den Edges jedes Mal derselbe Hub zugewiesen wird. Dadurch wird die Zuweisung und Fehlerbehebung prädiktiver.

Hinweis: Wenn ein Hub neu gestartet wird (z. B. aufgrund von Wartung oder Ausfall), wird er vom Gateway getrennt und aus dem Cluster entfernt. Dies bedeutet, dass die Edges nach dem Neustart aller Edges (aufgrund der oben beschriebenen Logik) immer gleichmäßig verteilt werden, aber nach jedem Hub-Ereignis, das zum Verlust der Konnektivität führt, ungleichmäßig verteilt sind.

Was geschieht, wenn die maximal zulässige Tunnelkapazität eines Hubs überschritten wird?

Die Edge-Zuweisungslogik versucht, die Edges gleichmäßig auf alle verfügbaren Hubs zu verteilen. Nach einem Ereignis (z. B. Neustart) auf dem Hub sind die Edges jedoch nicht mehr gleichmäßig verteilt.

Hinweis: In der Regel versucht das Gateway bei erstmaliger Zuweisung, Edges gleichmäßig auf Hubs zu verteilen. Eine ungleichmäßige Verteilung wird nicht als ungültiger Status angesehen. Wenn die Zuweisungen ungleichmäßig sind, aber kein einzelner Hub 70 % der Tunnelkapazität überschreitet, gilt die Zuweisung als gültig.

Aufgrund eines solchen Ereignisses auf dem Hub (oder dem Hinzufügen zusätzlicher Edges zum Netzwerk) können Cluster einen Punkt erreichen, an dem ein einzelner Hub 70 % seiner zulässigen Tunnelkapazität überschritten hat. Wenn dies geschieht und mindestens ein weiterer Hub eine Tunnelkapazität von weniger als 70 % aufweist, wird automatisch eine gleichmäßige erneute Verteilung durchgeführt, unabhängig davon, ob die Neuverteilung im Orchestrator aktiviert ist. Die meisten Edges behalten Ihre vorhandene Zuweisung aufgrund der prädiktiven mathematischen Zuweisung mithilfe von logischen IDs bei, und die Edges, die anderen Hubs aufgrund von Failover oder vorheriger Neuverteilung der Nutzung zugewiesen wurden, werden neu verteilt, um sicherzustellen, dass der Cluster automatisch zu einer gleichmäßigen Verteilung zurückkehrt.

Was geschieht, wenn der maximal zulässige Cluster Score eines Hubs überschritten wird?

Im Gegensatz zum Tunnelprozentsatz (ein direktes Maß für die Kapazität), auf den sofort reagiert werden kann, wird der Cluster Score nur alle 30 Sekunden aktualisiert, und das Gateway kann nicht automatisch berechnen, wie hoch der angepasste Cluster Score nach einer Edge-Neuzuweisung sein wird. In der Clusterkonfiguration wird ein Parameter für die automatische Neuverteilung bereitgestellt, um anzugeben, ob das Gateway dynamisch versuchen soll, die Edge-Last für jeden Hub nach Bedarf zu verschieben.

Wenn die automatische Neuverteilung deaktiviert ist und ein Hub einen Cluster Score über 70 hat (aber keine 70 % Tunnelkapazität), wird keine Maßnahme ergriffen.

Wenn der automatische Neuausgleich aktiviert ist und mindestens ein Hub einen Cluster Score von mehr als 70 hat, weist das Gateway dem Hub mit dem niedrigsten Cluster Score einen Edge pro Minute zu, bis alle Hubs unter 70 liegen oder keine Neuzuweisungen mehr möglich sind.

Hinweis: Die automatische Neuverteilung ist standardmäßig deaktiviert.

Was geschieht, wenn zwei VMware SD-WAN-Gateways unterschiedliche Hub-Zuweisungen vornehmen?

Wie es der Natur einer verteilten Steuerungsebene entspricht, bestimmt jedes Gateway die Clusterzuweisung individuell. In den meisten Fällen verwenden Gateways dieselbe mathematische Formel und gelangen somit zur gleichen Zuweisung für alle Edges. In Fällen wie der auf dem Cluster Score basierenden Neuverteilung kann dies jedoch nicht gewährleistet werden.

Wenn ein Edge zurzeit nicht mit einem Hub in einem Cluster verbunden ist, akzeptiert er die Zuweisung von jedem Gateway, das antwortet. Dadurch wird sichergestellt, dass Edges in einem Szenario, in dem einige Gateways ausgefallen sind und andere aktiv sind, nie ohne Zuweisung bleiben.

Wenn ein Edge mit einem Hub in einem Cluster verbunden ist und eine Nachricht erhält, die angibt, dass er einen alternativen Hub wählen soll, wird diese Nachricht in der Reihenfolge der „Gateway-Präferenz“ verarbeitet. Ist beispielsweise das Super-Gateway verbunden, akzeptiert der Edge nur Neuzuweisungen vom Super-Gateway. In Konflikt stehende Zuweisungen, die von anderen Gateways angefordert werden, werden ignoriert. Ebenso würde der Edge, wenn das Super-Gateway nicht angeschlossen ist, nur Neuzuweisungen vom alternativen Super-Gateway akzeptieren. Für Partner-Gateways (wenn keine Super-Gateways vorhanden sind) basiert die Voreinstellung des Gateways auf der Reihenfolge der konfigurierten Partner-Gateways für diesen spezifischen Edge.
Hinweis: Bei Verwendung von Partner-Gateways müssen sowohl den Hubs in einem Cluster als auch den Spoke-Edges dieselben Gateways zugewiesen werden. Andernfalls kann es zu einem Szenario kommen, bei dem ein Spoke-Edge keine Hub-Zuweisungen empfangen kann, da der Spoke-Edge mit einem Gateway verbunden ist, das nicht auch mit den Hubs in einem Cluster verbunden ist.

Was geschieht, wenn ein VMware SD-WAN Gateway ausfällt?

Bei Ausfall eines SD-WAN-Gateways werden die Edges möglicherweise neu zugewiesen, wenn das Gateway mit der höchsten Priorität dasjenige ist, das ausgefallen ist, und das Gateway mit der nächsthöheren Priorität eine andere Zuweisung bereitgestellt hat. Beispiel: Das Super-Gateway hat Hub A diesem Edge zugewiesen, während das alternative Super-Gateway Hub B demselben Edge zugewiesen hat.

Das Super-Gateway, das ausfällt, löst ein Failover des Edge zu Hub B aus, da das alternative Super-Gateway jetzt das Gateway mit der höchsten Priorität für die Konnektivitätsinformationen ist.

Wenn das-Super-Gateway wiederhergestellt wird, fordert der Edge erneut eine Hub-Zuweisung von diesem Gateway an. Um zu verhindern, dass der Edge im obigen Szenario wieder zu Hub A wechselt, enthält die Hub-Zuweisungsanforderung den zurzeit zugewiesenen Hub (sofern vorhanden). Wenn das Gateway die Zuweisungsanforderung verarbeitet, falls dem Edge zurzeit ein Hub im Cluster zugewiesen ist und dieser Hub einen Cluster Score von weniger als 70 hat, aktualisiert das Gateway seine lokale Zuweisung, damit sie mit der vorhandenen Zuweisung übereinstimmt, ohne seine Zuweisungslogik zu durchlaufen. Auf diese Weise wird sichergestellt, dass das Super-Gateway bei Wiederherstellung den aktuell verbundenen Hub zuweist und ein unnötiges Failover für seine zugewiesenen Edges verhindert.

Was geschieht, wenn ein Hub in einem Cluster seine dynamischen Routen verliert?

Wie oben erwähnt, melden die Hubs den SD-WAN-Gateways alle 30 Sekunden die Anzahl der dynamischen Routen, die sie über BGP gelernt haben. Wenn Routen für nur einen Knoten in einem Cluster verloren gehen, weil sie fälschlicherweise zurückgezogen werden oder die BGP-Nachbarschaft ausfällt, führen die SD-WAN Gateways ein Failover der Spokes Edges auf einen anderen Hub in dem Cluster durch, der eine intakte Routing-Tabelle aufweist.

Da die Updates alle 30 Sekunden gesendet werden, basiert die Routenanzahl auf dem Zeitpunkt, an dem das Update an das SD-WAN-Gateway gesendet wird. Die Neuverteilungslogik für das SD-WAN-Gateway wird alle 60 Sekunden ausgeführt. Das bedeutet, dass Benutzer im unwahrscheinlichen Fall eines Totalausfalls eines LAN-seitigen BGP-Nachbarn mit einem Failover von 30 – 60 Sekunden rechnen können. Um sicherzustellen, dass alle Hubs nach einem solchen Ereignis die Möglichkeit haben, die Gateways erneut zu aktualisieren, ist die Neuverteilung auf maximal einmal pro 120 Sekunden begrenzt. Dies bedeutet, dass die Benutzer bei einem zweiten aufeinander folgenden Ausfall mit einem Failover von 120 Sekunden rechnen können.

Hinweis: Von BGP über IPsec/GRE empfangene Routen werden bei der LAN-seitigen Fehlererkennung nicht berücksichtigt. Wenn eine Sitzung vom Typ „BGP über IPsec/GRE“ ausfällt, wird das Problem nicht aufgrund eines LAN-seitigen Ausfalls erkannt, weshalb kein Cluster-Failover ausgelöst wird.

Wie wird das Routing auf Cluster-Hubs konfiguriert?

Da das Gateway die Spokes anweisen kann, sich mit jedem Hub des Clusters zu verbinden, sollte die Routingkonfiguration auf allen Hubs gespiegelt werden. Wenn die Spokes beispielsweise ein BGP-Präfix 192.168.2.1 hinter den Hubs erreichen müssen, sollten alle Hubs im Cluster 192.168.2.1 mit genau denselben Routenattributen annoncieren.

BGP-Uplink-Community-Tags sollten bei der Cluster-Bereitstellung verwendet werden. Konfigurieren Sie die Clusterknoten so, dass das Uplink-Community-Tag beim Neuverteilen von Routen an BGP-Peers festgelegt wird.

Was passiert, wenn ein Hub in einem Cluster ausfällt?

Das SD-WAN-Gateway wartet 7 Sekunden darauf, dass die Tunnel für inaktiv erklärt werden, bevor ein Failover zu Spoke-Edges durchgeführt wird. Das bedeutet, dass Benutzer mit einem Failover von 7 bis 10 Sekunden (abhängig von RTT) rechnen können, wenn ein SD-WAN-Hub oder alle zugehörigen WAN-Links ausfallen.