Présentation
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 ne disposant pas d'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
IMPORTANT :
Avant de commencer à dépanner, assurez-vous que tous les prérequis pour le déploiement de HA vSocket sur AWS sont vérifiés. Voir Déploiement manuel d'un site AWS vSocket, Déploiement d'un site vSocket depuis AWS Marketplace et Configuration de HA pour AWS vSockets
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 nom de domaine complet ec2.<region>.amazonaws.com (ex., ec2.us-east-1.amazonaws.com), 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 autorisations, vérifiez que la politique IAM contient la bonne déclaration, comme indiqué ci-dessous.
Note : En cas de rôle IAM manquant, une fois que le rôle est ajouté, les prises 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é autorisent 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 montre que le statut HA n'est pas prêt et que les deux vSockets sont actifs et fonctionnels, les deux vSockets prendront le rôle de Maître (scénario de split-brain). Cela peut se produire en raison de :
Les deux vSockets exécutent différentes versions de firmware
Les messages HA Keepalive n'atteignent pas le 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 de split-brain se manifestera si les deux vSockets primaire et secondaire sont en 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 HA Keepalives
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 split-brain se produit lorsque les deux vSockets ont le rôle de Maître, ce qui peut se produire en raison de problèmes de connectivité LAN entre les vSockets créant une situation où les messages HA Keepalive ne parviennent pas au vSocket secondaire.
Exécutez les vérifications suivantes pour confirmer la connectivité LAN :
Vérifiez si le Groupe de Sécurité de Réseau bloque le port UDP/20480. Un moyen rapide de vérifier les règles NSG est d'aller sur 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.
Confirmer 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ésoudre les 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 les Sites vSocket de 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.
Ouverture de dossiers auprès de Cato Support
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 tout message d'erreur.
Configuration DNS dans le VPC.
Résultats du test 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.