Qu'est-ce que la haute disponibilité des Sockets (HA)

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.

Vue d'ensemble de la haute disponibilité de Socket pour un site

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.

Haute disponibilité de Socket et différents modèles de Socket

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.

Comprendre la haute disponibilité de Socket et le basculement

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.

  1. 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).

  2. 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.  

  3. Le Socket secondaire envoie un message GARP aux réseaux LAN pour accélérer la convergence de niveau 2.

  4. 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 :

image.png

Élément

Description

1

Rôle HA du Socket - Principal ou Secondaire

2

Statut HA du Socket - Maître ou Veille

3

HA Statut - Prêt ou Non-Prêt

4

Conditions spécifiques pour le statut HA global

  • Connecté - Connectivité WAN du Socket

    • GreenCheck.png- Les Sockets principal et secondaire ont au moins un tunnel opérationnel connecté au Cato Cloud

    • Red_X.png- Le Socket n'a pas de tunnels opérationnels connectés au Cato Cloud

  • Keepalive - État du canal keepalive HA entre les Sockets

    • GreenCheck.png- Le Socket secondaire reçoit des messages keepalive HA du Socket principal

    • Red_X.png- Le Socket secondaire ne reçoit pas de messages keepalive HA du Socket principal

  • Version compatible - Les Sockets principal et secondaire exécutent des versions OS de Socket compatibles

    • GreenCheck.png- Les deux Sockets exécutent une version compatible (même majeure) de Socket, par exemple 14.0.13986 et 14.0.12764

    • Red_X.png- Les Sockets ont des versions majeures différentes de Socket, par exemple 14.0.13986 et 13.0.48732

    Remarque : Le basculement HA Socket a lieu même si les Sockets exécutent des versions majeures différentes. Cependant, le site pourrait rencontrer des problèmes de fonctionnalité si la version secondaire de Socket ne prend pas en charge les fonctionnalités qui sont prises en charge pour la version principale de Socket.

    Par exemple, si le Socket principal exécute la version 18.0 et que le Socket secondaire exécute la version 15.0, en cas de basculement, les fonctionnalités qui ont été publiées avec les versions 16 à 18 ne fonctionneront pas tant que le Socket secondaire est actif.

Échantillon de basculement Socket HA

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.

Socket_HA_Regular.png
Socket_HA_Failure.png

Condition de split-brain de Socket HA

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.

Trafic du site pendant la condition de split-brain

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) :

    1. Le PoP détecte que le Socket secondaire est maintenant le Maître.

    2. 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) :

    1. 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.

Connectivité de Socket HA vers le Cloud Cato

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 :

PhysicalLogicalTopology.png

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.

WAN_Connectivity_Router_Switch.png

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.

Connectivité LAN et Socket HA

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 :

  1. Port LAN unique

  2. Ports LAN multiples

  3. Agrégation de lien LAN (option recommandée)

  4. 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.

Socket HA avec un seul port LAN

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 :

Commutateur_HA_LAN.png

Socket HA avec plusieurs ports LAN

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.

LAN_VRRP.png

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 :

  1. La Socket secondaire cesse de recevoir les messages keepalive HA de la Socket principale pendant une période de trois secondes.

  2. 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.

Socket HA avec agrégation de liens LAN (Configuration recommandée)

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 :

SocketHA_LAG.png

Port dédié pour le trafic de Keepalive HA

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.

Direct_HA_Link.png

Voici les configurations de port dédié :

  1. 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.

  2. 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 :                                                             

    1. 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.

    2. 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 :

Socket_HA_-_Direct_Port_for_HA_Traffic.png
Socket_HA_-_via_Switch_Port_for_HA.png

Conditions de basculement pour la haute disponibilité de Socket

La section décrit les conditions qui causent un basculement de la Socket principale à la Socket secondaire.

Basculement en raison d'une défaillance du Socket principal

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

Basculement en raison d'une défaillance de Keepalive

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.

Socket_HA_LAN_Failure.png

Les problèmes de connectivité Internet causent-ils un basculement du Socket ?

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.

Surveillance de la haute disponibilité de Socket

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.

Affichage du statut HA de Socket

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

Événements de basculement de Socket HA

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.

Basculement.png

Définition des notifications par e-mail pour le basculement de haute disponibilité de Socket

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 :

Alerte_Basculement_Socket.png

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.

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 15 sur 17

0 commentaire