In questa sezione viene fornita una panoramica approfondita del funzionamento del clustering di SD-WAN Edge.

I seguenti sono concetti importanti che descrivono la funzionalità di clustering di SD-WAN Edge:

  • Il clustering Edge può essere utilizzato negli hub come segue:
    • Per consentire una maggiore capacità del tunnel per un hub, è possibile fornire un singolo Edge che funge da hub.
    • Per distribuire gli Edge spoke remoti tra più hub e ridurre l'impatto di eventuali incidenti che possono verificarsi.
  • Il punteggio del cluster è un calcolo matematico dell'utilizzo complessivo del sistema come indicato di seguito:
    I tre fattori di utilizzo misurati sono l'utilizzo della CPU, l'utilizzo della memoria e la capacità del tunnel.
    • Ogni misura di utilizzo viene trattata come percentuale su un massimo del 100%.
    • La capacità del tunnel si basa sulla capacità nominale di un determinato modello di hardware o sulla configurazione dell'Edge virtuale.
    • Tutte e tre le percentuali di utilizzo sono calcolate sulla media per arrivare a un punteggio del cluster basato su numeri interi (1-100).
    • Sebbene la velocità effettiva non sia considerata direttamente, l'utilizzo della CPU e della memoria riflette indirettamente la velocità effettiva e il volume dei flussi in un determinato Hub.
    • Ad esempio, in un Edge 2000:
      • Utilizzo della CPU = 20%
      • Utilizzo della memoria = 30%
      • Tunnel connessi = 600 (su una capacità di 6000) = 10%
      • Punteggio del cluster: (20 + 30 + 10)/3 = 20
  • Un punteggio del cluster maggiore di 70 è considerato "oltre la capacità".
  • Un "ID logico" è un UUID a 128 bit che identifica in modo univoco un elemento all'interno della rete di VMware.
    • Ad esempio, ogni Edge è rappresentato da un ID logico e ogni cluster è rappresentato da un ID logico.
    • Mentre l'utente fornisce i nomi di cluster e Edge, gli ID logici sono sempre univoci e vengono utilizzati per l'identificazione interna degli elementi.
  • Per impostazione predefinita, il carico viene distribuito in modo uniforme tra gli hub. Di conseguenza, è necessario che tutti gli Edge che fanno parte di un cluster abbiano lo stesso modello e le stesse capacità.
Ogni membro del cluster avrà il proprio indirizzamento IP per le interfacce WAN e LAN. Tutti i VMware SD-WAN Edge nel cluster di hub sono necessari per eseguire un protocollo di routing dinamico, come eBGP, con i dispositivi di livello 3 sul lato LAN con un numero ASN (Autonomous System Number) univoco per ogni membro del cluster. Il routing dinamico sul lato LAN dei cluster garantisce che il traffico da DC a un determinato sito spoke venga instradato tramite il membro del cluster di Edge appropriato.
Importante: Gli Edge hub in un cluster non si connettono né comunicano tra loro tramite tunnel o protocolli di routing. Agiscono come Edge indipendenti per le funzioni del piano dati. Dipendono dal peering BGP lato LAN verso il commutatore core per gestire il traffico da filiale a filiale quando gli Edge della filiale sono connessi a Edge hub diversi nel cluster.

In che modo i cluster Edge vengono monitorati da VMware SD-WAN Gateway?

Dopo aver aggiunto un hub a un cluster di VMware SD-WAN, l'hub rimuoverà e ricreerà i tunnel in tutti i relativi gateway assegnati e indicherà a ciascun gateway che l'hub è stato assegnato a un cluster e fornisce un ID logico del cluster.

Per il cluster, SD-WAN Gateway monitora:
  • L'ID logico
  • Il nome
  • Se è attivato il ribilanciamento automatico
  • Un elenco di oggetti hub per i membri del cluster

Per ogni oggetto Hub nel cluster, il gateway rileva:

  • L'ID logico
  • Il nome
  • Un set di statistiche, aggiornate ogni 30 secondi tramite un messaggio periodico inviato dall'hub a ciascun gateway assegnato, tra cui:
    • Utilizzo corrente della CPU da parte dell'hub
    • Utilizzo della memoria corrente da parte dell'hub
    • Numero corrente di tunnel nell'hub
    • Numero di route BGP corrente nell'hub
  • Punteggio del cluster corrente calcolato in base alla formula specificata in precedenza.

Un hub viene rimosso dall'elenco degli oggetti hub quando il gateway non ha ricevuto pacchetti dall'Edge hub per più di sette secondi.

In che modo gli Edge vengono assegnati a un hub specifico in un cluster?

In una topologia hub e spoke tradizionale, SASE Orchestrator assegna all'Edge l'ID logico dell'hub a cui deve essere connesso. L'Edge richiede ai gateway assegnati informazioni di connettività per l'ID logico dell'hub, ovvero gli indirizzi IP e le porte che verranno utilizzati dall'Edge per connettersi a tale hub.

Dal punto di vista dell'Edge, questo comportamento è identico a quello per la connessione a un cluster. Orchestrator informa l'Edge che l'ID logico dell'hub a cui deve connettersi è l'ID logico del cluster anziché l'ID logico del singolo hub. L'Edge segue la stessa procedura di invio di una richiesta di connessione a un hub ai gateway e si aspetta in risposta informazioni di connettività.

A questo punto, esistono due divergenze rispetto al comportamento dell'hub di base:

  • Divergenza numero uno: il gateway deve scegliere l'hub da assegnare.
  • Divergenza numero due: a causa della differenza numero uno, l'Edge può ricevere diverse assegnazioni dai propri gateway differenti.

Inizialmente si è pensato di risolvere la divergenza numero uno utilizzando il punteggio del cluster per assegnare l'hub meno caricato in un cluster a un Edge. Sebbene in pratica questo sia logico, nel mondo reale, questa soluzione si è rivelata tutt'altro che ideale perché un evento di riassegnazione tipico può coinvolgere centinaia o addirittura migliaia di Edge e il punteggio del cluster viene aggiornato solo ogni 30 secondi. In altre parole, se l'Hub 1 ha un punteggio del cluster pari a 20 e l'Hub 2 ha un punteggio del cluster pari a 21, per 30 secondi tutti gli Edge scelgono l'Hub 1, ma a questo punto l'hub può essere sovraccarico e attivare ulteriori riassegnazioni.

Al contrario, il gateway tenta innanzitutto una distribuzione matematica uniforme senza considerare il punteggio del cluster. Gli ID logici dell'Edge, generati da un generatore di numeri casuali sicuro in Orchestrator, saranno (a condizione che vi sia un numero sufficiente di Edge) una distribuzione uniforme dei valori. Ciò significa che utilizzando l'ID logico, è possibile calcolare una distribuzione uniforme.

  • ID logico dell'Edge modulo numero di hub nel cluster = indice dell'hub assegnato
  • Per esempio:
    • Quattro Edge che hanno ID logici che terminano con 1, 2, 3, 4
    • Cluster con 2 hub
    • 1 % 2 = 1, 2 % 2 = 0, 3 % 2 = 1, 4 % 2 = 0 (Nota: "%" è utilizzato per indicare l'operatore modulo)
    • Agli Edge 2 e 4 viene assegnato l'indice dell'hub 0
    • Agli Edge 1 e 3 viene assegnato l'indice dell'hub 1

    Questa operazione è più coerente rispetto a un'assegnazione di tipo round-robin perché significa che gli Edge tendono a essere assegnati ogni volta allo stesso hub, il che rende più predittiva l'assegnazione e la risoluzione dei problemi.

Nota: Quando un hub viene riavviato (ad esempio a causa di manutenzione o errore), verrà disconnesso dal gateway e rimosso dal cluster. Ciò significa che gli Edge saranno sempre distribuiti uniformemente in seguito al riavvio di tutti gli Edge (a causa della logica descritta sopra), ma verranno distribuiti in modo non uniforme in seguito a qualsiasi evento dell'hub che provochi la perdita di connettività.

Che cosa succede quando un hub supera la capacità massima consentita del tunnel?

La logica di assegnazione dell'Edge tenterà di distribuire in modo uniforme gli Edge tra tutti gli hub disponibili. Tuttavia, dopo un evento (come il riavvio) nell'hub, la distribuzione degli Edge non sarà più uniforme.

Nota: In genere, il gateway tenta di distribuire in modo uniforme gli Edge tra gli hub durante l'assegnazione iniziale. Una distribuzione non uniforme non è considerata uno stato non valido. Se le assegnazioni non sono uniformi ma nessun hub singolo supera il 70% della capacità del tunnel, l'assegnazione è considerata valida.

A causa di un tale evento sull'hub (o in seguito all'aggiunta di ulteriori Edge alla rete), i cluster potrebbero raggiungere un punto in cui un singolo hub ha superato il 70% della capacità consentita del tunnel. Se si verificano queste condizioni, e almeno un altro hub si trova a meno del 70% della capacità del tunnel, viene eseguita automaticamente la ridistribuzione uniforme indipendentemente dal fatto che sia attivato il ribilanciamento in Orchestrator. La maggior parte degli Edge manterrà la propria assegnazione esistente data l'assegnazione matematica predittiva utilizzando gli ID logici, e gli Edge assegnati ad altri hub in seguito a failover o ribilanciamento dell'utilizzo precedente saranno ribilanciati per garantire il ripristino automatico del cluster a una distribuzione uniforme.

Che cosa succede quando un hub supera il punteggio massimo consentito per il cluster?

A differenza della percentuale del tunnel (una misura diretta della capacità), sulla quale si può intervenire immediatamente, il punteggio del cluster viene aggiornato solo ogni 30 secondi e il gateway non è in grado di calcolare automaticamente il punteggio del cluster corretto dopo aver effettuato una riassegnazione degli Edge. Nella configurazione del cluster, viene specificato un parametro di ribilanciamento automatico per indicare se il gateway deve tentare dinamicamente di spostare il carico degli Edge per ciascun hub in base alle esigenze.

Se il ribilanciamento automatico è disattivato e in un hub il punteggio del cluster è superiore a 70 (ma la capacità del tunnel non supera il 70%), non viene eseguita alcuna azione.

Se è attivato il ribilanciamento automatico e uno o più hub superano un punteggio del cluster pari a 70, il gateway riassegnerà un Edge al minuto all'hub con il punteggio del cluster corrente più basso finché tutti gli hub presentano un punteggio inferiore a 70 oppure non sono disponibili ulteriori riassegnazioni.

Nota: Il ribilanciamento automatico è disattivato per impostazione predefinita.

Che cosa succede quando due VMware SD-WAN Gateway effettuano assegnazioni di hub diverse?

Come è nella natura di un pannello di controllo distribuito, ogni gateway effettua una determinazione individuale dell'assegnazione del cluster. Nella maggior parte dei casi, i gateway utilizzeranno la stessa formula matematica e quindi arriveranno alla stessa assegnazione per tutti gli Edge. Tuttavia, nei casi come il ribilanciamento basato sul punteggio del cluster, questo non può essere assicurato.

Se un Edge non è attualmente connesso a un hub in un cluster, accetterà l'assegnazione da qualsiasi gateway che risponde. Ciò garantisce che gli Edge non vengano mai lasciati non assegnati in uno scenario in cui alcuni gateway sono inattivi e altri sono attivi.

Se un Edge è connesso a un hub in un cluster e riceve un messaggio che indica che deve scegliere un hub alternativo, questo messaggio viene elaborato in ordine di "preferenza del gateway". Ad esempio, se il super gateway è connesso, l'Edge accetterà solo le riassegnazioni dal super gateway. Le assegnazioni in conflitto richieste da altri gateway verranno ignorate. Allo stesso modo, se il super gateway non è connesso, l'Edge accetterà solo riassegnazioni dal super gateway alternativo. Per i gateway partner (dove non esistono super gateway), la preferenza del gateway si basa sull'ordine dei gateway partner configurati per quell'Edge specifico.
Nota: Quando si utilizzano gateway partner, è necessario assegnare gli stessi gateway sia agli hub in un cluster che agli Edge spoke. In caso contrario, potrebbe verificarsi uno scenario in cui un Edge spoke non è in grado di ricevere assegnazioni di hub perché l'Edge spoke è connesso a un gateway che non è a sua volta connesso agli hub in un cluster.

Che cosa succede quando un VMware SD-WAN Gateway diventa inattivo?

Quando un SD-WAN Gateway diventa inattivo, gli Edge possono essere riassegnati se il gateway che è diventato inattivo era quello preferito e il gateway preferito successivo ha fornito un'assegnazione diversa. Ad esempio, il super gateway ha assegnato un hub A a questo Edge mentre il super gateway alternativo ha assegnato l'hub B allo stesso Edge.

Il super gateway che si disattiva attiverà l'Edge per eseguire il failover sull'Hub B, poiché il super gateway alternativo è ora il gateway preferito per le informazioni di connettività.

Quando il super gateway viene ripristinato, l'Edge richiederà nuovamente l'assegnazione di un hub da questo gateway. Per evitare che l'Edge torni nuovamente all'hub A nello scenario precedente, la richiesta di assegnazione dell'hub include l'hub attualmente assegnato (se presente). Quando il gateway elabora la richiesta di assegnazione, se all'Edge al momento è stato assegnato un hub nel cluster e tale hub presenta un punteggio del cluster inferiore a 70, il gateway aggiorna la propria assegnazione locale in modo che corrisponda all'assegnazione esistente senza passare attraverso la relativa logica di assegnazione. In questo modo, il super gateway, in fase di ripristino, assegnerà l'hub attualmente connesso e impedirà un failover ingiustificato per i relativi Edge assegnati.

Che cosa succede se un hub in un cluster perde le route dinamiche?

Come indicato in precedenza, gli hub segnalano agli SD-WAN Gateway il numero di route dinamiche acquisite tramite BGP ogni 30 secondi. Se le route vengono perse per un solo hub in un cluster, perché vengono erroneamente ritirate o perché l'associazione con il router adiacente BGP non riesce, gli SD-WAN Gateway eseguono il failover degli Edge spoke in un altro hub nel cluster che dispone di una tabella di routing intatta.

Poiché gli aggiornamenti vengono inviati ogni 30 secondi, il numero di route viene calcolato nel momento in cui l'aggiornamento viene inviato a SD-WAN Gateway. La logica di ribilanciamento di SD-WAN Gateway viene eseguita ogni 60 secondi. Ciò significa che gli utenti possono aspettarsi che il failover impieghi 30-60 secondi nel caso improbabile di perdita totale di un router adiacente BGP sul lato LAN. Per assicurarsi che tutti gli hub abbiano la possibilità di aggiornare di nuovo i gateway in seguito a tale evento, il ribilanciamento può essere eseguito al massimo una volta ogni 120 secondi. Questo significa che gli utenti possono aspettarsi che il failover impieghi 120 secondi per un secondo errore successivo.

Nota: Le route ricevute da BGP su IPSec/GRE non vengono contabilizzate per il rilevamento degli errori sul lato LAN. Quando la sessione BGP su IPSec/GRE diventa inattiva, il problema non viene rilevato da un errore sul lato LAN e pertanto non attiva il failover del cluster.

Come è possibile configurare il routing negli hub del cluster?

Poiché il gateway può indicare agli spoke di connettersi a qualsiasi hub membro del cluster, è necessario eseguire il mirroring della configurazione del routing in tutti gli hub. Ad esempio, se gli spoke devono raggiungere un prefisso BGP 192.168.2.1 dietro gli hub, tutti gli hub nel cluster devono annunciare 192.168.2.1 con gli stessi attributi della route.

I tag della community uplink BGP devono essere utilizzati nella distribuzione del cluster. Configurare i nodi del cluster in modo che impostino il tag della community uplink durante la ridistribuzione delle route ai peer BGP.

Che cosa succede se un hub in un cluster non riesce?

SD-WAN Gateway attenderà che i tunnel vengano dichiarati inattivi (7 secondi) prima di eseguire il failover degli Edge spoke. Questo significa che gli utenti possono prevedere che il failover impieghi 7-10 secondi (in base a RTT) quando un'istanza di SD-WAN Hub o tutti i relativi link WAN associati non vengono eseguiti correttamente.