Cette section fournit une présentation détaillée du fonctionnement de la fonctionnalité de clustering d'un dispositif SD-WAN Edge.

Voici les concepts importants qui décrivent la fonctionnalité de clustering d'un dispositif SD-WAN Edge :

  • Vous pouvez utiliser le clustering de dispositifs Edge sur les Hubs comme suit :
    • Pour permettre une plus grande capacité de tunnel pour un Hub qu'un dispositif Edge spécifique servant de Hub peut fournir.
    • Pour distribuer les dispositifs Edge spoke à distance entre plusieurs Hubs et réduire les conséquences de tout incident pouvant se produire.
  • Le score de cluster est un calcul mathématique de l'utilisation globale du système comme suit :
    Les trois facteurs d'utilisation mesurés sont l'utilisation du CPU, l'utilisation de la mémoire et la capacité du tunnel.
    • Chaque mesure d'utilisation est traitée comme un pourcentage d'une valeur maximale de 100 %.
    • La capacité du tunnel repose sur la capacité nominale d'un modèle matériel donné ou d'une configuration de dispositif Edge virtuel.
    • Tous les trois pourcentages d'utilisation sont calculés en moyenne pour parvenir à un score de cluster basé sur des entiers (1-100).
    • Bien que le débit ne soit pas pris en compte directement, l'utilisation du CPU et de la mémoire reflète indirectement le débit et le volume de flux sur un Hub donné.
    • Par exemple, sur un dispositif Edge 2000 :
      • Utilisation du CPU = 20 %
      • Utilisation de la mémoire = 30 %
      • Tunnels connectés = 600 (sur une capacité de 6 000) = 10 %
      • Score de cluster : (20 + 30 + 10)/3 = 20
  • Un score de cluster supérieur à 70 est considéré comme « surcapacité ».
  • Un « ID logique » est un UUID de 128 bits qui identifie de façon unique un élément à l'intérieur du réseau VMware.
    • Par exemple, chaque dispositif Edge est représenté par un ID logique et chaque cluster est représenté par un ID logique.
    • Bien que l'utilisateur fournisse les noms du dispositif Edge et du cluster, les ID logiques sont garantis comme uniques et sont utilisés pour l'identification interne des éléments.
  • Par défaut, la charge est répartie uniformément entre les Hubs. Par conséquent, il est nécessaire que tous les dispositifs Edge qui font partie d'un cluster soient du même modèle et de la même capacité.
Chaque membre du cluster dispose de son propre adressage IP pour les interfaces WAN et LAN. Tous les dispositifs VMware SD-WAN Edge du cluster Hub doivent exécuter un protocole de routage dynamique, comme eBGP, avec les périphériques de couche 3 côté LAN avec un numéro de système autonome (ASN) unique pour chaque membre du cluster. Le routage dynamique côté LAN des clusters garantit l'acheminement du trafic du DC vers un site Spoke particulier via le membre du cluster Edge approprié.
Important : Les dispositifs Edge du Hub d'un cluster ne se connectent ni ne communiquent entre eux via des tunnels ou des protocoles de routage. Ils agissent en tant que dispositifs Edge indépendants pour les fonctions de plan de données. Ils dépendent de l'appairage BGP côté LAN vers le commutateur principal pour gérer le trafic site distant vers site distant lorsque les dispositifs Edge de site distant sont connectés à différents dispositifs Edge de Hub dans le cluster.

Comment les clusters de dispositifs Edge sont-ils suivis par VMware SD-WAN Gateway ?

Après qu'un Hub est ajouté à un cluster VMware SD-WAN, le Hub désinstalle et recrée des tunnels sur toutes les instances de Gateway qui lui sont attribuées et indique à chaque instance de Gateway que le Hub a été attribué à un cluster et qu'il fournit un ID logique de cluster.

Pour le cluster, le dispositif SD-WAN Gateway suit les éléments suivants :
  • ID logique
  • Nom
  • Si le rééquilibrage automatique est activé
  • Liste des objets du Hub pour les membres du cluster

Pour chaque objet de Hub du cluster, la passerelle suit les éléments suivants :

  • ID logique
  • Nom
  • Ensemble de statistiques, mis à jour toutes les 30 secondes via un message périodique envoyé à partir du Hub à chaque passerelle attribuée, notamment :
    • Utilisation actuelle du CPU du Hub
    • Utilisation actuelle de la mémoire du Hub
    • Nombre actuel de tunnels sur le Hub
    • Nombre actuel de routes BGP sur le Hub
  • Score actuel du cluster calculé en fonction de la formule fournie ci-dessus.

Un Hub est supprimé de la liste des objets du Hub lorsque la passerelle n'a reçu aucun paquet du dispositif Edge Hub pendant plus de sept secondes.

Comment les dispositifs Edge sont-ils attribués à un hub spécifique d'un cluster ?

Dans une topologie de Hub et de spoke traditionnelle, SD-WAN Orchestrator fournit au dispositif Edge l'ID logique du Hub auquel il doit être connecté. Le dispositif Edge demande à ses passerelles attribuées des informations de connectivité pour cet ID logique de Hub : c'est-à-dire, les adresses IP et les ports que le dispositif Edge utilise pour se connecter à ce Hub.

Du point de vue du dispositif Edge, ce comportement est identique lors de la connexion à un cluster. Orchestrator informe le dispositif Edge que l'ID logique du Hub auquel il doit se connecter correspond à l'ID logique du cluster plutôt qu'à l'ID logique du Hub individuel. Le dispositif Edge suit la même procédure d'envoi d'une demande de connexion au Hub aux passerelles et attend les informations de connectivité en réponse.

Il existe deux divergences par rapport au comportement de base du Hub à ce stade :

  • Numéro de divergence 1 (Divergence Number One) : la passerelle doit choisir le Hub à attribuer.
  • Numéro de divergence 2 (Divergence Number Two) : en raison du numéro de divergence 1, le dispositif Edge peut recevoir différentes attributions de ses diverses passerelles.

Le numéro de divergence 1 a été initialement traité en utilisant le score de cluster pour attribuer le Hub le moins chargé d'un cluster à un dispositif Edge. Bien qu'en pratique il s'agisse d'une solution logique, cette solution est loin d'être idéale en réalité, car un événement de réattribution classique peut impliquer des centaines, voire des milliers de dispositifs Edge et le score de cluster n'est mis à jour que toutes les 30 secondes. En d'autres termes, si le Hub 1 dispose d'un score de cluster de 20 et si le Hub 2 dispose d'un score de cluster de 21, pendant 30 secondes, tous les dispositifs Edge choisissent le Hub 1, ce qui peut le surcharger et déclencher des réattributions supplémentaires.

Au lieu de cela, la passerelle tente d'abord une distribution mathématique équitable, ignorant ainsi le score de cluster. Les ID logiques du dispositif Edge, qui ont été créés par un générateur de nombres aléatoires sécurisés sur Orchestrator, disposeront (selon un nombre suffisant de dispositifs Edge) d'une distribution égale de valeurs. Cela signifie que l'utilisation de l'ID logique permet de calculer une distribution de parts égales.

  • ID logique de dispositif Edge modulo le nombre de Hubs dans le cluster = indice de Hub attribué
  • Par exemple :
    • Quatre dispositifs Edge disposant d'ID logiques se terminant par 1, 2, 3, 4
    • Cluster disposant de 2 Hubs
    • 1 % 2 = 1, 2 % 2 = 0, 3 % 2 = 1, 4 % 2 = 0 (Remarque : « % » permet d'indiquer l'opérateur modulo)
    • L'indice de Hub 0 est attribué aux dispositifs Edge 2 et 4
    • L'indice de Hub 1 est attribué aux dispositifs Edge 1 et 3

    Cela est plus cohérent qu'une attribution de type tourniquet, car cela signifie que le même Hub aura tendance à être attribué chaque fois aux dispositifs Edge. Cela rend l'attribution et le dépannage plus prévisibles.

Note : Lorsqu'un Hub redémarre (par exemple, en raison d'une maintenance ou d'une panne), il est déconnecté de la passerelle et supprimé du cluster. Cela signifie que les dispositifs Edge seront toujours distribués équitablement après le redémarrage de tous les dispositifs Edge (en raison de la logique décrite ci-dessus), mais qu'ils seront distribués inégalement suite à n'importe quel événement du Hub, entraînant ainsi une perte de connectivité.

Que se passe-t-il lorsqu'un Hub dépasse sa capacité de tunnel maximale autorisée ?

La logique d'attribution des dispositifs Edge tente de répartir équitablement les dispositifs Edge entre tous les Hubs disponibles. Toutefois, après un événement (tel qu'un redémarrage) sur le Hub, la distribution Edge ne sera plus égale.

Note : En général, la passerelle tente lors de l'attribution initiale de distribuer équitablement les dispositifs Edge entre les Hubs. Une distribution inégale n'est pas considérée comme un état non valide. Si les attributions sont inégales, mais qu'aucun Hub individuel ne dépasse 70 % de la capacité de tunnel, l'attribution est considérée comme valide.

En raison de cet événement sur le Hub (ou en ajoutant des dispositifs Edge supplémentaires au réseau), les clusters peuvent atteindre un point où un Hub individuel a dépassé 70 % de sa capacité de tunnel autorisée. Si cela se produit et si au moins un autre Hub dispose d'une capacité de tunnel inférieure à 70 %, la redistribution de parts égales est effectuée automatiquement, que le rééquilibrage soit activé ou non sur Orchestrator. La plupart des dispositifs Edge conservent leur attribution existante en raison de l'attribution mathématique prédictive à l'aide d'ID logiques et les dispositifs Edge qui ont été attribués à d'autres Hubs, en raison des basculements ou du rééquilibrage d'utilisation précédent, seront rééquilibrés pour s'assurer que le cluster revient automatiquement à une distribution égale.

Que se passe-t-il lorsqu'un Hub dépasse le score de cluster maximal autorisé ?

Contrairement au pourcentage de tunnel (mesure directe de la capacité), qui peut être traité immédiatement, le score de cluster n'est mis à jour que toutes les 30 secondes et la passerelle ne peut pas calculer automatiquement le score du cluster ajusté après avoir effectué une réattribution du dispositif Edge. Dans la configuration du cluster, un paramètre Rééquilibrage automatique (Auto Rebalance) est fourni pour indiquer si la passerelle doit tenter de déplacer dynamiquement la charge du dispositif Edge pour chaque Hub, si nécessaire.

Si le paramètre Rééquilibrage automatique (Auto Rebalance) est désactivé et qu'un Hub dépasse un score de cluster de 70 (mais pas la capacité du tunnel de 70 %), aucune mesure n'est prise.

Si le paramètre Rééquilibrage automatique (Auto Rebalance) est activé et si un ou plusieurs Hubs dépassent un score de cluster de 70, la passerelle réattribue un dispositif Edge par minute au Hub avec le score de cluster actuel le plus bas jusqu'à ce que tous les Hubs soient inférieurs à 70 ou qu'il n'y ait plus de réattributions possibles.

Note : Le paramètre Rééquilibrage automatique (Auto Rebalance) est désactivé par défaut.

Que se passe-t-il lorsque deux dispositifs VMware SD-WAN Gateway fournissent différentes attributions de hub ?

Comme c'est le cas d'un plan de contrôle distribué, chaque passerelle effectue une détermination individuelle de l'attribution du cluster. Dans la plupart des cas, les passerelles utilisent la même formule mathématique et parviennent donc à la même attribution pour tous les dispositifs Edge. Toutefois, dans des cas tels que le rééquilibrage basé sur le score de cluster, cela ne peut pas être garanti.

Si un dispositif Edge n'est pas actuellement connecté à un Hub dans un cluster, il accepte l'attribution de n'importe quelle passerelle qui répond. Cela garantit que les dispositifs Edge ne soient jamais non attribués dans un scénario où certaines passerelles sont inactives et d'autres sont actives.

Si un dispositif Edge est connecté à un Hub dans un cluster et s'il obtient un message indiquant qu'il doit choisir un autre Hub, ce message est traité dans l'ordre de « préférence des passerelles. » Par exemple, si la superpasserelle est connectée, le dispositif Edge n'accepte que les réattributions de la superpasserelle. Les attributions en conflit demandées par d'autres passerelles sont ignorées. De même, si la superpasserelle n'est pas connectée, le dispositif Edge n'accepte que les réattributions de la superpasserelle secondaire. Pour les passerelles de partenaires (où il n'existe aucune superpasserelle), la préférence de passerelle est basée sur l'ordre de passerelles de partenaires configurées pour ce dispositif Edge spécifique.
Note : Lors de l'utilisation de passerelles de partenaires, les mêmes passerelles doivent être attribuées aux Hubs d'un cluster et aux dispositifs Spoke Edge. Sinon, un scénario peut survenir dans lequel un dispositif Spoke Edge ne peut pas recevoir d'attributions du Hub, car ce dispositif est connecté à une passerelle qui n'est pas non plus connectée aux Hubs d'un cluster.

Que se passe-t-il lorsqu'un dispositif VMware SD-WAN Gateway tombe en panne ?

En cas de panne du dispositif SD-WAN Gateway, les dispositifs Edge peuvent être réattribués si la passerelle préférée était celle qui est tombée en panne et si la passerelle préférée suivante a fourni une attribution différente. Par exemple, la superpasserelle a attribué le Hub A à ce dispositif Edge, tandis que la superpasserelle secondaire a attribué le Hub B au même dispositif Edge.

La superpasserelle qui est tombée en panne va déclencher le basculement du dispositif Edge vers le Hub B, car la superpasserelle secondaire est désormais la passerelle préférée pour les informations de connectivité.

Lors de la récupération de la superpasserelle, le dispositif Edge demande à nouveau une attribution de Hub à partir de cette passerelle. Pour empêcher le dispositif Edge de rebasculer vers le Hub A du scénario ci-dessus, la demande d'attribution du Hub comprend le Hub actuellement attribué (le cas échéant). Lorsque la passerelle traite la demande d'attribution, si un Hub est actuellement attribué au dispositif Edge dans le cluster et si le score de cluster du Hub est inférieur à 70, la passerelle met à jour son attribution locale pour qu'elle corresponde à l'attribution existante sans passer par sa logique d'attribution. Cela garantit que, lors de la récupération, la superpasserelle affecte le Hub actuellement connecté et empêche un basculement gratuit pour les dispositifs Edge qui lui sont attribués.

Que se passe-t-il si un Hub d'un cluster perd ses routes dynamiques ?

Comme indiqué ci-dessus, les Hubs signalent toutes les 30 secondes aux dispositifs SD-WAN Gateway le nombre de routes dynamiques qu'ils ont appris via BGP. Si des routes sont perdues pour un seul Hub d'un cluster, en raison d'un retrait erroné ou d'un échec du BGP Neighborship, les instances de SD-WAN Gateway basculent les dispositifs Edge en mode spoke vers un autre Hub du cluster disposant d'une table de routage intacte.

À mesure que les mises à jour sont envoyées toutes les 30 secondes, le nombre de routes est basé sur l'heure d'envoi de la mise à jour à SD- WAN Gateway. La logique de rééquilibrage de SD-WAN Gateway se produit toutes les 60 secondes, ce qui signifie que les utilisateurs peuvent s'attendre à un basculement de 30 à 60 secondes dans le cas improbable de perte totale d'un BGP Neighbor côté LAN. Pour vous assurer que tous les hubs ont la possibilité de mettre à jour à nouveau les passerelles après un événement de ce type, le rééquilibrage est limité à un maximum d'une fois toutes les 120 secondes. Cela signifie que les utilisateurs peuvent s'attendre à un basculement de 120 secondes pour une seconde panne successive.

Comment configurer le routage sur les Hubs de cluster ?

Comme la passerelle peut demander aux spokes de se connecter à n'importe quel Hub membre du cluster, la configuration de routage doit être mise en miroir sur tous les Hubs. Par exemple, si les spokes doivent atteindre un préfixe BGP 192.168.2.1 derrière les Hubs, tous les Hubs du cluster doivent annoncer 192.168.2.1 avec exactement les mêmes attributs de route.

Vous devez utiliser les balises de communauté de liaison montante BGP dans le déploiement du cluster. Configurez les nœuds de cluster pour définir la balise de communauté de liaison montante lors de la redistribution des routes vers les homologues BGP.

Que se passe-t-il en cas de panne d'un Hub dans un cluster ?

Le dispositif SD-WAN Gateway attend que les tunnels soient déclarés inactifs (7 secondes) avant de basculer sur les dispositifs Edge en mode spoke. Cela signifie que les utilisateurs peuvent s'attendre à un basculement de 7 à 10 secondes (selon RTT) en cas de panne d'un Hub SD-WAN ou de tous ses liens WAN associés.