Qu'est-ce que Socket HA

Cet article traite des configurations de Haute Disponibilité (HA) et des conditions de basculement pour les sites utilisant une paire de Prises Cato physiques.

Vue d'ensemble de la Haute Disponibilité Socket pour un site

Pour améliorer la résilience des sites, Cato recommande fortement de déployer chaque site avec une paire de Prises fonctionnant en mode Haute Disponibilité (HA). Ce mode de fonctionnement assure la continuité du service pour le site en cas de défaillance d'une seule Prise. Pendant un basculement, le Cloud Cato maintient l'état des flux et l'impact sur l'expérience utilisateur est minimal.

Sites HA Socket Pris en Charge

Cato prend en charge HA Socket pour les environnements suivants :

• Site Socket physique

• Site AWS vSocket

• Site Azure vSocket

Cet article explique comment HA fonctionne pour un site Socket physique. Pour en savoir plus sur la mise en place de Socket HA en quelques clics, voir Utilisation des Sockets dans un déploiement HA.

• Pour plus de détails sur AWS vSocket HA, voir Configuration de HA pour AWS vSockets

• Pour plus de détails sur Azure vSocket HA, voir Configuration de la haute disponibilité pour Azure vSockets

Haute Disponibilité Socket et Différents Modèles de Socket

Les sites HA Socket peuvent utiliser deux Sockets du même type de Socket X1500, X1600, X1600 LTE, X1600 WiFi ou X1700. Cependant, vous ne pouvez pas utiliser différents types de Socket, donc un site avec une Prise X1600 et une Prise X1700 n'est pas pris en charge.

• Vous pouvez utiliser sur le même site HA :

  • N'importe lequel des deux modèles de Socket X1500 A/B/C

  • Modèles de Socket X1700A et X1700B

  • Uniquement modèles de Socket X1700C

• Vous ne pouvez pas utiliser une Prise X1600 LTE et une Prise X1600 WiFi sur le même site HA

Comprendre la haute disponibilité et le basculement Socket

Dans un déploiement HA Socket, deux Prises Cato sont attribuées à un site. La première Prise attribuée au site est identifiée comme la Prise principale, la deuxième est la Prise secondaire. Les prises fonctionnent en mode HA Actif / Sauvegarde. Pendant le fonctionnement normal d'un site, la Prise principale a le statut HA Maître, tandis que la Prise secondaire a le statut HA Sauvegarde. Seule la Prise avec le statut HA Maître gère le trafic.

1. La Prise secondaire (Sauvegarde) surveille en permanence l'état (vivacité) de la Prise Maître en écoutant les messages de survie périodiques que la Prise principale envoie. Les messages de survie 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 la Prise secondaire (Sauvegarde) détecte que la Prise principale est défaillante, elle change son état HA en Maître et commence à gérer le trafic. Cela se produit après trois secondes de messages de survie HA manqués.  

3. La Prise secondaire envoie un message GARP aux réseaux LAN pour accélérer la convergence du niveau 2.

4. Lorsque la Prise principale récupère et retrouve son fonctionnement normal, elle redevient préventivement Maître et la Prise secondaire revient au statut en veille.

L'image suivante montre la page de configuration HA pour les Prises X1500 dans l'application de gestion Cato dans Réseau > Sites > {nom du site} > Configuration du site > Socket :

Exemple de Basculement HA Socket

Les diagrammes suivants montrent un exemple de problème sur la Prise principale qui provoque un basculement vers la Prise secondaire. Lorsque la Prise secondaire découvre que la Prise principale est défaillante, elle change alors son statut en Maître. Le Cloud Cato transfère les flux de trafic vers les liens WAN dans la Prise secondaire.

Socket HA et Condition de Cerveau Divisé

Une condition de cerveau divisé se produit lorsque les deux Prises 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 Prises qui crée une situation où les messages de survie HA n'atteignent pas la Prise secondaire.

Vous pouvez identifier une condition de cerveau divisé en vérifiant la page Socket (ci-dessus) dans l'application de gestion Cato.

• Les Prises principale et secondaire seront affichées comme statut Maître (élément 2)

• La condition Keepalive (dans l'élément 4) sera affichée comme Échouée et cela entraîne que l'état Statut HA (élément 3) soit affiché comme PAS PRÊT

Après que le problème de connectivité LAN est résolu, la Prise secondaire identifie que la Prise principale est le Maître et la Prise secondaire revient au statut en veille.

Site Trafic Pendant la Condition de Cerveau Divisé

Le processus suivant s'assure que pendant une condition de cerveau divisé, seule la Prise secondaire gère le trafic pour le site (même s'il y a une condition de cerveau divisé).

• Pour le trafic descendant (du PoP vers le site) :

  1. Le PoP détecte que la Prise secondaire est maintenant la Maître.

  2. Le PoP définit la métrique préférée pour les tunnels Socket secondaire.

     Le trafic descendant est maintenant uniquement acheminé vers la Prise secondaire.

• Pour le trafic montant (du site vers le PoP) :

  1. Lorsque la Prise secondaire change l'état HA de Sauvegarde à Maître, elle envoie un message GARP au LAN pour mettre à jour les tableaux ARP et MAC indiquant qu'elle est maintenant la Maître.

     Le trafic montant depuis le LAN est maintenant uniquement acheminé vers la Prise secondaire.

Connectivité Socket HA vers le Cloud Cato

Les deux Prises principales et secondaires établissent des tunnels DTLS vers le même PoP Cloud Cato sur chacun des ports WAN. Dans la direction montante, seule la Prise Maître envoie le trafic vers le PoP. Dans la direction descendante, le PoP utilise uniquement les tunnels de la Prise Maître pour envoyer le trafic vers le site. En cas d'événement de basculement HA Socket, la Prise secondaire devient le nouveau Maître, et le PoP transfère le trafic des tunnels de la Prise principale défaillante aux tunnels de la Prise secondaire. Le PoP maintient l'état des flux et l'état NAT pour s'assurer que toutes les applications utilisateur continuent de fonctionner pendant et après le basculement.

Le déploiement par défaut utilise des routeurs entre la Prise et le FAI. Cependant, il est possible de personnaliser le déploiement du site pour connecter la Prise au PoP sans routeur - veuillez contacter votre représentant Cato officiel pour plus d'informations.

Ci-dessous, des topologies physiques et logiques pour le Socket HA :

Pour une connectivité WAN optimale, des performances et des fonctionnalités HA, Cato recommande une disposition de câblage symétrique (en miroir) pour les deux Prises. Par exemple, si le port WAN1 de la Prise principale est connecté à ISP1 et le port WAN2 est connecté à ISP2, la Prise secondaire doit avoir les mêmes ports connectés aux mêmes FAI que la Prise principale.

Ces topologies symétriques peuvent inclure des connexions directes aux routeurs FAI ou utiliser une pile de commutateurs.

Note :

Pour les configurations HA standard, Cato recommande d'utiliser une disposition symétrique pour les Prises principale et secondaire.
Lors de l'utilisation de LTE, il y a des scénarios où vous pouvez vouloir utiliser des cartes SIM de différents opérateurs pour assurer une meilleure couverture ou n'utiliser qu'une carte SIM sur la Prise secondaire.

Connectivité LAN et Socket HA

Cato exige que les deux Prises principale et secondaire aient une disposition de câblage symétrique (en miroir) pour la connectivité LAN. Par exemple, le port LAN 1 pour les deux Prises principale 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 Socket HA :

1. Port LAN unique

2. Ports LAN multiples

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

4. Port dédié aux messages de survie 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 Port LAN Unique

Il existe des configurations qui utilisent un seul port LAN pour connecter les Prises principale et secondaire au commutateur LAN. Avec cette configuration, le même numéro de port doit être utilisé sur les deux Prises. Le trafic utilisateur et les messages de survie HA circulent sur un seul lien. Cette topologie ne fournit pas de redondance de lien LAN.

Le basculement HA Socket (où la Prise secondaire devient Maître) ne se produit que lorsque ces deux conditions sont remplies :

1. La Prise secondaire arrête de recevoir les messages de survie HA de la Prise principale pendant une période de trois secondes.

2. Le port LAN sur la Prise secondaire (qui est utilisé pour les messages de survie HA) est dans l'état CONNECTÉ.

Si le port LAN de la Prise secondaire est DÉCONNECTÉ, il ne deviendra pas Maître pour éviter une possible condition de cerveau divisé.

Le diagramme suivant montre une topologie de Socket HA avec un seul port LAN sur chaque Prise connecté à un commutateur :

Socket HA avec Ports LAN Multiples

Cette section traite du cas où les Prises principale et secondaire sont connectées aux commutateurs LAN via deux ou plusieurs ports LAN indépendants. Avec cette configuration, les mêmes ports doivent être utilisés sur les deux Prises pour la connectivité LAN.

Par défaut, le port LAN avec le numéro le plus bas est utilisé à la fois pour le trafic de survie HA et pour le trafic utilisateur. Les ports LAN restants ne transportent que le trafic utilisateur.

Vous pouvez choisir n'importe quel port LAN pour le trafic de survie HA en changeant la Destination du port de LAN vers LAN & VRRP.  La capture d'écran suivante montre le port 3 pour le trafic utilisateur LAN et le port 4 pour le trafic de survie HA et le trafic utilisateur.

Pour plus de détails sur le changement du port LAN pour le trafic Keepalive HA, consultez Utilisation des Sockets dans un Déploiement HA. Cette topologie ne fournit pas de redondance de lien LAN.

Le basculement HA du Socket (où le Socket secondaire devient le Maître) ne se produit que lorsqu'une des conditions suivantes est remplie :

1. Le Socket secondaire cesse de recevoir les messages Keepalive HA du Socket principal pendant trois secondes.

2. Le port LAN & VRRP sur le Socket secondaire est en état CONNECTÉ.

Si le port LAN du Socket secondaire est DÉCONNECTÉ, il ne deviendra pas le Maître pour éviter une condition de cerveau divisé.

Socket HA avec Agrégation de Liens LAN (Configuration Recommandée)

Les Sockets principal et secondaire sont connectés aux commutateurs LAN via deux ou plusieurs ports LAN groupés dans une agrégation de liens (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 échoue, les autres ports membres continueront de transporter le trafic utilisateur et le trafic Keepalive HA.

Cette topologie offre à la fois une résilience des liens et une résilience du Socket et est considérée comme une meilleure pratique.

Pour en savoir plus sur le LAG LAN, consultez Configurer l'Agrégation de Liens pour un Socket.

Le diagramme suivant est un exemple de topologie de connectivité LAN Socket HA utilisant un LAG LAN avec une pile de commutateurs :

Port dédié pour le trafic Keepalive HA

Dans cette configuration, vous isolez le trafic Keepalive HA du trafic LAN. Vous pouvez allouer un seul port (LAN, WAN ou ports USB) uniquement pour le trafic Keepalive HA tout en utilisant un ou plusieurs des ports LAN restants pour le trafic LAN.

Pour définir le port LAN dédié au trafic Keepalive HA, définissez la Destination du port sur VRRP. Ensuite, définissez l'option Lien HA entre sockets sur Direct ou Via Commutateur.

Ce sont les configurations de ports dédiés :

1. Direct (câble de boucle entre les Sockets) – Avec cette configuration, si le Socket secondaire cesse de recevoir les messages Keepalive HA, il devient le Maître indépendamment de l'état du port VRRP.

2. Via Commutateur – 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 du Socket secondaire :

   1. Lorsque l'état du port du Socket secondaire est Connecté mais qu'il ne reçoit pas de messages Keepalive, le Socket secondaire devient le Maître.

      Le Socket secondaire suppose que l'état est causé par une défaillance du Socket principal.

   2. Lorsque l'état du port du Socket secondaire est Déconnecté, le Socket secondaire ne devient pas le Maître (supposant qu'il s'agit d'un problème local entre lui-même et le commutateur).

      Le Socket secondaire suppose que le Socket principal fonctionne correctement, et il ne devient pas le Maître pour éviter une condition de cerveau divisé.

Ce sont des diagrammes des configurations de port dédiées directes et via un commutateur :

Conditions de basculement pour la haute disponibilité du Socket

Cette section décrit les conditions qui provoquent un basculement du Socket principal vers le Socket secondaire.

Basculement dû à une défaillance du Socket principal

Ce scénario de basculement est causé par une défaillance du Socket principal. Le Socket est considéré comme étant en état de désactivation pour l'une de ces raisons :

• Défaillance générale du Socket ou perte de courant

• Connectivité VRRP (pas de Keepalive pendant plus de trois secondes)
  Une perte de connectivité côté LAN ne déclenche pas un basculement sauf si des publicités VRRP sont échangées sur le lien LAN.

• Pas de connectivité Internet pendant plus de dix secondes

Basculement dû à une défaillance du Keepalive

Il existe également un scénario de basculement causé lorsque le Socket secondaire ne reçoit pas de messages Keepalive du Socket principal pendant trois secondes.

Lorsque le Socket secondaire découvre que le Socket principal est en panne, il change alors son statut pour devenir Maître. Le Cloud Cato transfert les flux de trafic vers les liens WAN dans le Socket secondaire. Le diagramme suivant montre ce scénario.

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

Les Sockets utilisent un mécanisme de sonde pour déterminer l'état de connectivité Internet. Si le Socket principal détermine que la connectivité Internet est désactivée sur tous les liens Internet (liens Cato) pendant plus de 10 secondes, il cesse alors de transmettre les messages Keepalive HA. Cela provoque un basculement vers le Socket secondaire.

Note :

Il est possible qu'une situation où le Socket principal ait une connectivité Internet, cependant, tous les tunnels DTLS sont en état DÉCONNECTÉ. Parce que les Sockets ont des mécanismes de récupération Internet et WAN, cette situation ne déclenche pas un basculement vers le Socket secondaire. Ces mécanismes de récupération permettent au Socket de se reconnecter à un autre PoP dans le Cloud Cato.

Surveillance de la haute disponibilité du 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 du HA Socket.

Afficher le statut HA Socket

Il existe différentes pages dans l'Application de Gestion Cato qui montrent le statut du HA Socket pour un site.

Événements de Basculement HA Socket

Chaque fois qu'un basculement de Socket se produit, lorsque le Socket secondaire est actif pendant plus de 35 secondes, alors un événement Socket Fail-Over est généré. Par exemple, si le Socket principal est mis à niveau vers une nouvelle version de Socket, et que le processus de mise à niveau prend 20 secondes, alors un événement Socket Fail-Over n'est pas généré car le Socket secondaire n'était actif que pendant 20 secondes.

Vous pouvez voir l'événement dans l'Application de Gestion Cato dans la page Accueil > Événements. Voici un exemple d'événement montrant un basculement du principal vers le Socket secondaire.

Définir les notifications pour le basculement de la haute disponibilité du Socket

Vous pouvez utiliser la page des règles de santé des liens (Réseau > Règles de santé des liens) pour créer une règle de santé de la connectivité afin d'envoyer des notifications pour les événements de basculement du HA Socket.

Les notifications sont envoyées à tous les destinataires définis dans le groupe d'abonnement que vous configurez dans le CMA. A Groupe d'Abonnement peut inclure différents objectifs de notification, tels que :  

• Listes de diffusion avec des adresses e-mail (y compris des adresses non associées aux utilisateurs ou administrateurs Cato)

• Intégrations de webhook comme Slack ou Jira

• Systèmes de notification tiers

Cela vous permet de gérer toutes les destinations de notification à partir d'un seul emplacement et de les appliquer de manière cohérente sur plusieurs règles.

Voici un échantillon de règle de santé de la connectivité pour le basculement du Socket :

Pour plus d'informations sur la configuration d'une règle de santé de la connectivité, consultez Travailler avec les règles de santé des liens.