Récupération WAN fournit une résilience si vos sites Socket ne peuvent pas communiquer à travers le cloud de Cato. Elle utilise des tunnels VPN directs entre les sites Socket sur Internet pour préserver le trafic WAN en cas de problèmes de connectivité importants avec le Cato Cloud. Par défaut, chaque Socket maintient des tunnels avec d'autres Sockets à l'aide de keepalives, assurant une récupération rapide et une résilience.
Par défaut, tous les sites Socket (sauf ceux en Chine) forment également un full mesh de tunnels Off-Cloud, échangeant en continu des sondes de connectivité avec chaque autre site. Bien qu'adapté pour les petits et moyens déploiements, ce comportement génère un trafic inutile et augmente la charge CPU dans les environnements à grande échelle.
Passer à un design hub & spoke réduit le nombre de tunnels et de sondes, maintenant une performance et une efficacité optimales.
Pour les comptes avec des centaines ou des milliers de sites Socket, la topologie Off-Cloud full-mesh par défaut peut entraîner :
-
Utilisation élevée du CPU et consommation de ressources sur les Sockets (par exemple, modèles X1500) à cause de la maintenance de nombreux tunnels site-à-site et keepalives.
-
Augmentation de l'utilisation de la bande passante à cause des sondes de connectivité site-à-site, ce qui peut être particulièrement problématique pour les sites avec une bande passante limitée ou des liaisons cellulaires.
Pour garantir que ces types de comptes restent évolutifs, efficaces et stables à mesure qu'ils grandissent, ils devraient envisager de passer à une topologie hub & spoke.
Lorsque la topologie hors-cloud pour votre compte est modifiée de full mesh à hub & spoke, nous désignons les centres de données ou le siège social comme sites hub et les autres sites comme spokes.
-
Les sites hub se connectent à tous les hubs et spokes
-
Sites spoke connectent uniquement aux hubs, avec ce changement de routage :
-
Les routes spécifiques des spokes ne sont pas annoncées aux autres sites spoke
-
Ce changement réduit considérablement le nombre de tunnels site-à-site et de sondes de connectivité.
-
Les changements seront implémentés pendant des fenêtres de maintenance convenues préalablement avec les clients
-
Les déploiements peuvent se produire par phases graduelles, en commençant par un petit nombre de sites pour valider le comportement attendu
-
Impact attendu :
-
Tous les sites continueront de communiquer via le Cato Cloud, quel que soit leur rôle
-
La récupération WAN hors-cloud continuera de fonctionner entre les spokes et les hubs, mais pas entre les spokes
-
-
Impact potentiel dans le pire des cas :
-
Si les hubs ne sont pas correctement configurés, les spokes peuvent temporairement perdre la récupération WAN hors-cloud entre eux
-
Résolution : Identifier le(s) site(s) affecté(s) et les reconfigurer en tant que hubs
-
- Approchez votre représentant de compte Cato et faites-leur savoir que vous souhaitez changer vers une topologie hub et spoke pour la récupération WAN.
-
Assurez-vous que vos centres de données et sites de siège sont correctement identifiés dans le CMA.
Pour plus d'informations, voir Utilisation du CMA pour ajouter des sites.
-
Pendant la fenêtre de maintenance convenue à l'avance :
-
Soyez disponible pour confirmer la connectivité du site
-
Signalez immédiatement tout problème de connectivité inattendu
-
-
Après le changement :
-
Vérifiez que les applications critiques et les connexions inter-sites fonctionnent comme prévu
-
0 commentaire
Vous devez vous connecter pour laisser un commentaire.