Dépannage AWS HA vSocket

Vue d'ensemble

Ce guide fournit un cadre de dépannage détaillé pour résoudre les problèmes courants rencontrés lors du déploiement de la haute disponibilité (HA) de vSocket AWS. Que ce soit pour un déploiement manuel ou via AWS Marketplace, ces étapes visent à aider à identifier et à résoudre efficacement les problèmes potentiels.

Symptômes

Les problèmes courants dans les déploiements HA de vSocket AWS peuvent inclure :

• Échec du basculement HA
  • Tests API HA échoués depuis le WebUI de vSocket.
  • Échec du basculement HA, entraînant le non-transfert du trafic vers le vSocket secondaire.
• Statut HA non prêt
  • CMA affiche le statut HA du site comme "Non prêt"

Causes possibles

Les échecs de déploiement HA sont souvent dus aux raisons suivantes :

• Utilisation de DNS non public dans AWS.
• Interface de gestion sans accès Internet.
• Mauvaise configuration du rôle IAM.
• Configuration restrictive du groupe de sécurité et du routage dans AWS.
• Échec de l'attribution de l'interface réseau appropriée à la table de routage LAN.
• Problèmes de connectivité LAN.

Dépannage du problème

Dépannage de l'échec du basculement HA

Si le trafic n'est pas redirigé vers le vSocket secondaire pendant le basculement, considérez les étapes de dépannage suivantes :

Exécution du test API HA

• Depuis le WebUI de vSocket, exécutez l'outil de test API pour les deux vSockets.
• Cet outil valide que l'appel API vers AWS peut être effectué avec succès.
• Toutes les erreurs liées aux permissions ou aux mises à jour de la table de routage peuvent être vues ici.
  

Vérification de la configuration DNS AWS

• Vérifiez que le serveur DNS AWS par défaut est configuré pour le VPC associé. 
• Pour vérifier la configuration DNS AWS, voir Résolution des problèmes de configuration DNS 
• Si un serveur DNS personnalisé (par exemple, un serveur DNS privé) est configuré, assurez-vous qu'il peut résoudre les domaines publics. Vérifiez qu'il peut résoudre le FQDN ec2.<région>.amazonaws.com (par exemple, ec2.us-east-1.amazonaws.com), qui est utilisé par l'API.
• Le groupe de sécurité associé à l'interface MGMT doit permettre les requêtes DNS vers 8.8.8.8 et 8.8.4.4, même si le serveur DNS AWS par défaut est configuré.

Vérification de la table de routage LAN

• Pour acheminer le trafic vers le vSocket principal, AWS attribue l'interface réseau LAN du vSocket principal actuel à la table de routage LAN.
• Allez à VPC > Tables de routage et sélectionnez la table de routage LAN. Sous l'onglet Routes, vérifiez que l'interface réseau LAN du vSocket principal est la passerelle (cible) de la route par défaut. Si ce n'est pas le cas, continuez avec les étapes suivantes.
• Notez que la modification manuelle de la table de routage LAN peut être une solution rapide si la NIC cible n'a pas été changée lors du basculement.

Vérification du rôle IAM

• Lors du déploiement vSocket AWS, le rôle IAM HA est créé et associé aux deux vSockets, principal et secondaire.
• Sous la page de détails de chaque instance, confirmez que le bon rôle IAM est attribué.

• Cliquez sur le lien du rôle IAM et, sous l'onglet des permissions, vérifiez que la politique IAM contient la déclaration correcte, comme montré ci-dessous.

Note : En cas de rôle IAM manquant, une fois le rôle ajouté, les sockets doivent être redémarrés pour que les rôles ajoutés prennent effet.

Vérification des paramètres IMDS

• Assurez-vous que les deux vSockets utilisent des paramètres IMDS correspondants (optionnels ou requis). Pour plus d'informations, consultez la documentation AWS.

• À partir de la version vSocket 20.0.18221, IMDSv2 est pris en charge.
• Pour modifier les paramètres IMDS, sélectionnez l'instance et, sous actions, cliquez sur Paramètres de l'instance > Modifier les options des métadonnées de l'instance.

Vérification du groupe de sécurité réseau.

• Assurez-vous que le groupe de sécurité réseau ne bloque pas le trafic sortant vers l'interface de gestion.
• Sous EC2 > Interfaces réseau, trouvez le groupe de sécurité associé à l'interface de gestion.
  
• Vérifiez que les règles sortantes du groupe de sécurité permettent les ports 80, 443, et 53. Dans ce cas, tout le trafic sortant est autorisé.
  
  

Vérification du routage de l'interface MGMT pour le trafic Internet.

• Si le trafic de l'interface MGMT est acheminé via un pare-feu tiers dans AWS, vérifiez que les connexions sortantes UDP/53, TCP/80 et TCP/443 sont autorisées.
• Depuis la page des interfaces réseau, cliquez sur l'ID de la sous-réseau de l'interface MGMT.
  
• Sur la page de la sous-réseau, sélectionnez l'onglet Table de routage. La capture d'écran ci-dessous montre la route par défaut pointant vers la passerelle Internet, donc un pare-feu ne bloque pas le trafic.
  
• Ouvrez la Table de routage associée et vérifiez que toutes les sous-réseaux MGMT sont listées comme sous-réseaux associés. Dans le cas d'une zone de disponibilité double, deux sous-réseaux MGMT existeront, un pour chaque vSocket, comme expliqué dans Création d'une sous-réseau pour les interfaces LAN de vSocket secondaire.
• Sur l'onglet Carte des ressources du VPC, toutes les sous-réseaux associées et leurs configurations de routage sont représentées visuellement pour une référence facile.
• Confirmez qu'une IP élastique est associée à l'interface MGMT. Cela peut être vu depuis l'onglet réseau de l'instance. L'interface MGMT peut être identifiée par son indice de dispositif de 0. Les interfaces WAN et LAN doivent être associées aux indices de dispositif 1 et 2, respectivement.

Vérification des logs CloudTrail

• Activez AWS CloudTrail pour enregistrer les appels API vers AWS afin de déboguer les modifications échouées de la table de routage LAN lors du basculement HA.
• Vous pouvez suivre le processus pour créer un journal, définir le bucket S3 pour stocker les journaux et sélectionner les événements de gestion qui incluent l'activité API. Voir Création d'un journal.
  

Dépannage du statut HA non prêt

Si CMA indique que le statut HA n'est pas prêt et que les deux vSockets sont opérationnels, les deux vSockets prendront le rôle de maître (scénario split-brain). Cela peut se produire en raison de :

• Les deux vSockets exécutent différentes versions de firmware
• Les messages Keepalive HA ne parviennent pas au vSocket secondaire

Il est recommandé de vérifier les pages WebUI des deux vSockets pour confirmer le statut HA de chacun d'eux. Un scénario split-brain se manifestera si les vSockets primaire et secondaire sont tous deux dans un rôle de maître. Le WebUI affichera le rôle actuel en haut de la page principale de surveillance.

Vérification des versions de firmware

Pour satisfaire aux critères de version compatible, les deux vSockets doivent exécuter la même version PRINCIPALE, par exemple v17.xx.yy ou v18.xx.yy. Les vSockets effectuent une mise à niveau initiale après leur premier déploiement. Si l'un des vSockets ne parvient pas à se mettre à jour, ce problème doit être résolu. Soumettez un ticket de support pour signaler ce problème.

Vérification des Keepalives HA

Les paquets Keepalive utilisent le port UDP/20480 pour AWS vSocket et seront envoyés uniquement du vSocket principal au vSocket en veille. La condition de "cerveau divisé" survient lorsque les deux vSockets ont le rôle de Master, ce qui peut se produire en raison de problèmes de connectivité LAN entre les vSockets, créant une situation où les messages Keepalive HA n'atteignent pas le vSocket secondaire. 

Effectuez les vérifications suivantes pour confirmer la connectivité LAN :

• Vérifiez si le groupe de sécurité réseau bloque le port UDP/20480. Un moyen rapide de vérifier les règles NSG est d'aller à chaque interface réseau LAN dans AWS et de vérifier les règles entrantes et sortantes comme expliqué dans Vérifiez si le groupe de sécurité réseau bloque le trafic sortant.
• Confirmez que les deux interfaces LAN sont associées à des sous-réseaux LAN différents.
• Effectuez une capture de paquets depuis le WebUI des deux vSockets et identifiez si le vSocket secondaire reçoit les keepalives envoyés par le primaire.

Résolution des problèmes découverts

Correction des problèmes de configuration DNS

• Pour corriger les problèmes de configuration DNS, vérifiez que le serveur DNS AWS par défaut est configuré pour le VPC.
• Dans les détails du VPC, trouvez le jeu d'options DHCP configuré pour celui-ci.
• Ouvrez le jeu d'options DHCP et vérifiez que le serveur de noms de domaine défini est AmazonProvidedDNS.
• Il n'est pas possible de changer les serveurs de noms de domaine existants. Pour cela, créez un nouveau jeu d'options DHCP, qui utilisera AmazonProvidedDNS par défaut.

Désenregistrer et redéployer un vSocket AWS

• Si après avoir suivi toutes les étapes de dépannage ci-dessus, le basculement HA continue d'échouer, il est possible de désenregistrer et de redéployer un ou les deux vSockets. Consultez Redéployer des sites vSocket à haute disponibilité
• Il est important de supprimer la machine virtuelle mais de conserver les interfaces réseau, les IP publiques associées et le rôle IAM avant de redéployer un vSocket.
• En outre, n'oubliez pas de réattacher le bon rôle IAM au vSocket en sélectionnant l'instance de vSocket > Sécurité > Attacher un rôle IAM et en assignant le rôle AWS-HA.

Création de dossiers pour le support Cato

Soumettez un ticket de support avec les résultats des étapes de dépannage ci-dessus. Veuillez inclure les informations suivantes dans le ticket :

• Une description claire du problème, y compris tous les messages d'erreur.
• Configuration DNS dans le VPC.
• Résultats des tests API.
• Captures d'écran de la table de routage LAN et des rôles IAM configurés.
• Si possible, fichiers journaux CloudTrail au moment de l'échec du basculement.