Cet article traite des configurations de haute disponibilité (HA) et des conditions de basculement pour les sites utilisant une paire de Sockets physiques de Cato.
Pour améliorer la résilience du site, Cato recommande fortement de déployer chaque site avec une paire de Sockets qui fonctionnent en mode haute disponibilité (HA). Ce mode de fonctionnement assure la continuité du service pour le site en cas de défaillance d'un seul Socket. Pendant un basculement, le Cato Cloud maintient l'état des flux et il y a un impact minimal sur l'expérience utilisateur.
Sites HA supportés par Socket
Cato prend en charge le HA Socket pour les environnements suivants :
-
Site Socket physique
-
Site vSocket AWS
-
Site vSocket Azure
Cet article explique comment fonctionne le HA pour un site Socket physique. Pour plus d'informations sur la configuration de Socket HA en quelques clics, voir Utilisation de Sockets dans un déploiement HA.
-
Pour plus d'informations sur AWS vSocket HA, voir Configuration de la HA pour AWS vSockets
-
Pour plus d'informations sur Azure vSocket HA, voir Configuration de la haute disponibilité pour Azure vSockets
Les sites HA Socket peuvent utiliser deux Sockets du même type, X1500, X1600, X1600 LTE, ou X1700. Cependant, vous ne pouvez pas utiliser différents types de Sockets, donc un site avec un Socket X1600 et un Socket X1700 n'est pas pris en charge.
Vous ne pouvez pas utiliser un Socket X1600 et un Socket X1600 LTE dans le même site HA.
Dans un déploiement HA de Socket, deux Sockets de Cato sont assignés à un site. Le premier Socket assigné au site est identifié comme le Socket principal, le second est le Socket secondaire. Les Sockets fonctionnent en mode HA Actif / Veille. Pendant le fonctionnement normal d’un site, le Socket principal a le statut HA Master, tandis que le Socket secondaire a le statut HA Standby. Seul le Socket avec le statut HA Master gère le trafic.
-
Le Socket secondaire (en veille) surveille en permanence l'état (vivacité) du Socket maître en écoutant les messages périodiques de keepalive envoyés par le Socket principal. Les messages de Keepalive sont envoyés via l'interface désignée avec la destination définie sur LAN & VRRP ou VRRP (voir ci-dessous Connectivité LAN et Socket HA).
-
Une fois que le Socket secondaire (en veille) détecte que le Socket principal est en panne, il change son état HA en maître et commence à gérer le trafic. Cela se produit après trois secondes de messages keepalive HA manqués.
-
Le Socket secondaire envoie un message GARP aux réseaux LAN pour accélérer la convergence de niveau 2.
-
Lorsque le Socket principal se rétablit et retrouve sa fonctionnalité normale, il devient préventivement le maître et le Socket secondaire retourne au statut de veille.
L'image suivante montre la page de configuration du HA pour les Sockets X1500 dans l'application de gestion Cato dans Réseau > Sites > {site name} > Configuration du site > Socket :
Les diagrammes suivants montrent un exemple de problème dans le Socket principal qui provoque un basculement vers le Socket secondaire. Lorsque le Socket secondaire découvre que le Socket principal est en panne, il change alors son statut en Maître. Le Cato Cloud transfère les flux de trafic vers les liens WAN dans le Socket secondaire.
|
|
Une condition de séparation du cerveau se produit lorsque les deux Sockets ont le rôle de Maître en même temps. Cela peut se produire en raison d'un problème de connectivité LAN entre les Sockets qui crée une situation où les messages keepalive HA n'atteignent pas le Socket secondaire.
Vous pouvez identifier une condition de séparation du cerveau en vérifiant la page Socket (montrée ci-dessus) dans l'application de gestion Cato.
-
Les Sockets principal et secondaire seront affichés avec le statut Maître (élément 2)
-
La condition de Keepalive (dans l'élément 4) sera affichée comme Échec et cela provoque que le Statut HA (élément 3) soit affiché comme NON PRÊT
Une fois le problème de connectivité LAN résolu, le Socket secondaire identifie que le Socket principal est le Maître et le Socket secondaire retourne au statut de veille.
Le processus suivant s'assure que pendant une condition de séparation du cerveau, seul le Socket secondaire gère le trafic pour le site (même s'il y a une condition de séparation du cerveau).
-
Pour le trafic descendant (du PoP vers le site) :
-
Le PoP détecte que le Socket secondaire est maintenant le Maître.
-
Le PoP définit le métrique préféré pour les tunnels du Socket secondaire.
Le trafic descendant est maintenant uniquement routé vers le Socket secondaire.
-
-
Pour le trafic montant (du site vers le PoP) :
-
Lorsque le Socket secondaire change d'état HA de veille à Maître, il envoie un message GARP au LAN pour mettre à jour les tables ARP et MAC indiquant qu'il est maintenant le Maître.
Le trafic montant du LAN est maintenant uniquement routé vers le Socket secondaire.
-
Les Sockets principal et secondaire établissent des tunnels DTLS vers le même PoP du Cato Cloud sur chacun des ports WAN. Dans la direction Montante, seul le Socket Maître envoie le trafic vers le PoP. Dans la direction Descendante, le PoP utilise uniquement les tunnels du Socket Maître pour envoyer le trafic vers le site. En cas d'événement de basculement HA Socket, le Socket secondaire devient le nouveau Maître et le PoP transfère le trafic des tunnels du Socket principal défaillant vers les tunnels du Socket secondaire. Le PoP maintient l'état du flux et l'état NAT pour s'assurer que toutes les applications utilisateur continuent de fonctionner pendant et après le basculement.
Ci-dessous figurent des topologies physiques et logiques d'exemple pour le HA Socket :
Pour une connectivité WAN, une performance et une fonctionnalité HA optimales, Cato nécessite une disposition symétrique (miroir) des câbles pour les deux Sockets. Par exemple, si le port WAN1 du Socket principal est connecté à ISP1 et le port WAN2 est connecté à ISP2, le Socket secondaire doit avoir les mêmes ports connectés aux mêmes ISPs que le Socket principal.
Ces topologies symétriques peuvent inclure des connexions directes aux routeurs ISP ou l'utilisation d'une pile de commutateurs.
Remarque
Remarque : L'utilisation d'une topologie asymétrique peut créer des problèmes et n'est pas officiellement soutenue par Cato. Par exemple, où le port WAN1 du Socket principal est connecté à ISP1, et le port WAN1 du Socket secondaire est connecté à ISP2.
Cato exige que les Sockets principal et secondaire aient une disposition symétrique (en miroir) des câbles pour la connectivité LAN. Par exemple, le port LAN 1 pour les Sockets principal et secondaire est connecté au commutateur LAN (ou les ports LAN 1 et 2 pour les configurations avec plusieurs ports LAN).
Cette section traite des options de connectivité LAN suivantes pour le HA Socket :
-
Port LAN unique
-
Ports LAN multiples
-
Agrégation de lien LAN (option recommandée)
-
Port dédié pour les messages keepalive HA
Certaines de ces options nécessitent des configurations supplémentaires du site dans l'application de gestion Cato. Par exemple, le port LAN est configuré pour LAN & VRRP ou VRRP.
Il existe des configurations qui utilisent un port LAN unique pour connecter les Sockets principal et secondaire au commutateur LAN. Avec cette configuration, le même numéro de port doit être utilisé sur les deux Sockets. Le trafic utilisateur et les messages keepalive HA passent sur un lien unique. Cette topologie ne fournit pas de redondance de lien LAN.
Le schéma suivant montre une topologie HA de Socket avec un seul port LAN sur chaque Socket connecté à un commutateur :
Cette section discute du moment où les Sockets principales et secondaires sont connectées aux commutateurs LAN via deux ports LAN indépendants ou plus. Avec cette configuration, les mêmes ports doivent être utilisés sur les deux Sockets pour la connectivité LAN.
Par défaut, le port LAN avec le numéro le plus bas est utilisé à la fois pour le trafic keepalive HA et pour le trafic utilisateur. Les ports LAN restants transportent uniquement le trafic utilisateur.
Vous pouvez choisir n'importe quel port LAN pour le trafic keepalive HA en changeant la Destination du port de LAN à LAN & VRRP. La capture d'écran suivante montre le port 3 pour le trafic utilisateur LAN et le port 4 pour le trafic keepalive HA et le trafic utilisateur.
Pour plus d'informations sur le changement de port LAN pour le trafic de Keepalive HA, voir Utilisation de Sockets dans un déploiement HA. Cette topologie ne fournit pas de redondance de lien LAN.
Le basculement HA du Socket (où la Socket secondaire devient le Maître) ne se produit que lorsque les deux conditions suivantes sont réunies :
-
La Socket secondaire cesse de recevoir les messages keepalive HA de la Socket principale pendant une période de trois secondes.
-
Le port LAN & VRRP sur la Socket secondaire est en état CONNECTÉ.
Si le port LAN de la Socket Secondaire est DÉCONNECTÉ, il ne deviendra pas le Maître pour éviter une condition de split-brain possible.
Les Sockets principales et secondaires sont connectées aux commutateurs LAN via deux ports LAN ou plus regroupés dans une agrégation de lien (LAG). Avec cette configuration, les mêmes ports doivent être utilisés sur les deux Sockets pour la connectivité LAN. Cette topologie offre une redondance des liens LAN à la fois pour le trafic utilisateur et pour les messages keepalive HA. Si l'un des ports membres du LAG tombe en panne, les autres ports membres continueront à transporter le trafic utilisateur et le trafic keepalive HA.
Cette topologie fournit à la fois la résilience de lien et la résilience de Socket et est considérée comme une pratique exemplaire.
Pour en savoir plus sur la LAG LAN, voir Configuration de l'agrégation de liens pour un Socket.
Le schéma suivant est un exemple de topologie de connectivité LAN pour Socket HA utilisant un LAG LAN avec une pile de commutateurs :
Dans cette configuration, vous isolez le trafic keepalive HA du trafic LAN. Vous pouvez allouer un seul port (ports LAN, WAN ou USB) uniquement pour le trafic keepalive HA tout en utilisant un ou plusieurs ports LAN restants pour le trafic LAN.
Pour définir le port LAN dédié au trafic keepalive HA, réglez la Destination du port à VRRP. Ensuite, réglez l'option HA link between sockets à Direct ou Via Switch.
Voici les configurations de port dédié :
-
Direct (câble de type back-to-back entre les Sockets) - Avec cette configuration, si la Socket secondaire cesse de recevoir les messages keepalive HA, elle devient le Maître, quel que soit l'état du port VRRP.
-
Via Switch - Avec cette configuration, le port VRRP sur les deux Sockets est connecté à un commutateur. Le comportement de basculement dépend de l'état du port VRRP de la Socket secondaire :
-
Lorsque l'état du port de la Socket secondaire est connecté mais qu'elle ne reçoit pas de messages keepalive - la Socket secondaire devient le Maître.
La Socket secondaire suppose que l'état est causé par une défaillance de la Socket principale.
-
Lorsque l'état du port de la Socket secondaire est Déconnecté - la Socket Secondaire ne devient pas le Maître (en supposant qu'il s'agit d'un problème local entre elle-même et le commutateur.
La Socket secondaire suppose que la Socket principale fonctionne correctement et ne devient pas le Maître pour éviter une condition de split-brain possible.
-
Voici des schémas des configurations de port dédié direct et via switch :
|
|
La section décrit les conditions qui causent un basculement de la Socket principale à la Socket secondaire.
Ce scénario de basculement est causé par une défaillance de la Socket principale. La Socket est considérée comme étant dans un état d'arrêt pour l'une de ces raisons :
-
Défaillance générale de la Socket ou perte de puissance
-
Connectivité LAN (pas de keepalive pendant plus de trois secondes)
-
Pas de connectivité Internet pendant plus de dix secondes
Il existe également un scénario de basculement causé lorsque la Socket secondaire ne reçoit pas de messages keepalive de la Socket principale pendant une période de trois secondes.
Lorsque la Socket secondaire découvre que la Socket principale est en panne, elle change alors son statut en Maître. Le Cato Cloud transfère les flux de trafic vers les liens WAN dans la Socket secondaire. Le schéma suivant illustre ce scénario.
Les Sockets utilisent un mécanisme de sondage pour déterminer l'état de la connectivité Internet. Si la Socket principale détermine que la connectivité Internet est hors service sur tous les liens Internet (liens Cato) pendant plus de 10 secondes, elle cesse alors de transmettre les messages keepalive HA. Cela provoque un basculement vers la Socket secondaire.
Remarque
Note : Il est possible qu'une situation où la Socket principale a une connectivité Internet, cependant, tous les tunnels DTLS sont dans un état DÉCONNECTÉ. Puisque les Sockets ont des mécanismes de récupération Internet et WAN, cette situation ne déclenche pas un basculement vers la Socket secondaire. Ces mécanismes de récupération permettent à la Socket de se reconnecter à un autre PoP dans le Cloud Cato.
Cette section discute des différentes pages de l'Application de Gestion Cato que vous pouvez utiliser pour surveiller le statut et les événements pour le HA des Sockets.
Il existe différentes pages dans l'Application de Gestion Cato qui montrent le statut de la HA de la Socket pour un site.
Nom de la Page |
Description |
Chemin |
---|---|---|
Sites |
Montre tous les sites du compte. La colonne HA Status montre le statut de la HA pour chaque site. |
Réseau > Sites |
Socket |
Montre les détails de la HA de la Socket pour un site. Voir ci-dessus Comprendre la haute disponibilité de Socket et le basculement. |
Network > Sites > <nom du site> > Configuration du Site > Socket |
Analyse réseau |
Montre les données réseau pour un site et le HA Status. |
Network > Sites > <nom du site> > Surveillance du Site > Network Analytics |
Chaque fois qu'un basculement de Socket survient, lorsque la Socket secondaire est active pendant plus de 35 secondes, un événement Socket Fail-Over est généré. Par exemple, si la Socket principale effectue une mise à niveau vers une nouvelle version de Socket et si le processus de mise à niveau prend 20 secondes, un événement Socket Fail-Over n'est pas généré car la Socket secondaire n'était active que pendant 20 secondes.
Vous pouvez voir l'événement dans l'Application de Gestion Cato sur la page Accueil > Événements. Voici un exemple d'événement montrant un basculement de la Socket principale à la Socket secondaire.
Vous pouvez utiliser la page de Règles de Santé des Liens (Network > Link Health Rules) pour créer une Règle de Santé de Connectivité afin d'envoyer des notifications par email pour les événements de basculement de Socket HA. Les notifications par email sont envoyées à tous les destinataires dans la Liste de Diffusion que vous configurez dans l'Application de Gestion Cato. La Liste de Diffusion peut inclure des adresses email qui ne sont pas définies pour les utilisateurs et les administrateurs dans l'Application de Gestion Cato.
Ceci est un exemple de Règle de Santé de Connectivité pour le basculement de Socket :
Pour plus d'informations sur la configuration d'une règle de santé de connectivité, voir Travailler avec des règles de santé des liens.
0 commentaire
Vous devez vous connecter pour laisser un commentaire.