Dépannage des Azure HA vSocket

Vue d'ensemble

Cet article fournit des informations sur les problèmes de déploiement courants de Azure vSocket HA et propose des étapes de dépannage pour les résoudre. Ce guide vise à aider à identifier et à surmonter les obstacles potentiels pendant et après le déploiement de la solution HA, soit via le script HA, soit via le Marketplace.

Symptômes

Lors du déploiement de Azure vSocket HA, vous pourriez rencontrer les symptômes suivants :

• Échec du script HA
  • Échec de l'exécution du script create_ha_settings dans le déploiement manuel.
  • Problèmes de déploiement du vSocket secondaire via Marketplace.
• Échec du basculement HA
  • Tests API HA échoués depuis le WebUI de Socket.
  • Échec du basculement HA entraînant le non-routage du trafic vers le vSocket secondaire.
• Statut HA non prêt
  • CMA indique que le statut HA du Site n'est pas prêt

Causes possibles

Les causes les plus fréquentes d'échec de déploiement de HA incluent :

• Utilisation de DNS non publics dans Azure.
• Interface de gestion ne disposant pas d'accès à Internet.
• Autorisations de compte Azure insuffisantes.
• Paramètres du groupe de sécurité et de routage restrictifs dans Azure.
• Échec de l'attribution de l'adresse IP flottante à l'interface LAN.
• Problèmes de connectivité LAN.

Résolution du problème

Dépannage de l'échec du script HA

Le script Azure HA (create_ha_settings) et le déploiement du vSocket secondaire via le Marketplace vérifient que l'abonnement Azure possède deux vSockets valides, puis assignent les rôles d'identité qui créent le mécanisme HA et de basculement. Si l'exécution du script échoue, suivez ces étapes de dépannage :

Vérification des journaux d'activité

• Dans Azure, les journaux d'activité stockent tous les événements qui se sont produits à l'intérieur de chaque ressource Azure. Consultez ces journaux si le déploiement échoue et qu'un des rôles n'est pas attribué. Accédez à la VM ou au NIC et sélectionnez le journal d'activité
  

Vérification des restrictions de dénomination Azure 

• Lors de la saisie du nom vSocket dans le script, assurez-vous que le nom ne contient pas d'espaces ni de caractères restreints comme expliqué dans Règles de dénomination et restrictions.
• If a naming issue occurs during deployment, the following error will be shown in the Error log

  La valeur du paramètre disk.name est invalide. (Code: InvalidParameter, Target: disk.name)

Vérification de la configuration DNS Azure

• Assurez-vous que le DNS par défaut Azure est configuré à la fois pour le VNET et les NIC associés. Si le DNS par défaut n'est pas configuré dans Azure dans le VNET et le NIC, la création de rôles échouera.
• Pour vérifier quelle est la configuration DNS de Azure, voir Correction des problèmes de configuration DNS 
  

Vérification des permissions Azure

• Pour exécuter avec succès le script HA, assurez-vous que l'utilisateur Azure dispose des permissions de propriétaire. Allez dans Groupe de Ressources > Contrôle d'Accès IAM > Voir Mon Accès, et vérifiez que le compte utilisateur est défini sur Propriétaire ou un rôle supérieur. Consultez Rôles intégrés Azure.
  
  
  

Vérification de l'attribution de rôles Azure 

• Run the steps provided in Verifying Azure Role Assignment to confirm that the identity role listed in the resource group is assigned to the LAN NICs, LAN subnet, and both vSocket VMs.

Re-exécution du script HA

• En dernier recours, le script HA (create_ha_settings) peut être ré-exécuté une fois les étapes précédentes vérifiées.
• Assurez-vous de renouveler le jeton Azure et de supprimer l'identité managée Azure si elle a été créée lors de la première exécution du script.

Dépannage de l'échec du basculement HA

Si le script HA s'exécute correctement mais que le basculement vSocket HA ne se produit pas comme prévu (par exemple, le trafic n'est pas routé vers le vSocket secondaire), suivez ces étapes :

Exécution du test API HA

• Depuis le webUI vSocket, exécutez l'outil de test API depuis les deux vSockets qui valide que l'Appel API à Azure peut être effectué avec succès. Tous les erreurs de permissions ou d'attributions de IP flottantes peuvent être vues ici.
  

Vérification du journal d'activité

• Dans Azure, les journaux d'activité stockent tous les événements qui se sont produits à l'intérieur de chaque ressource Azure. Consultez ces journaux pour identifier si l'IP flottante n'a pas pu être poussée au NIC LAN ou si le test API n'a pas réussi. Accédez au NIC et sélectionnez le journal d'activité
  

Ping de l'IP flottante

• Depuis le WebUI vSocket, utilisez l'outil Ping, sélectionnez l'interface LAN, et pinguez l'adresse IP flottante. Si ce test échoue, continuez avec Vérification de l'attribution de IP flottante
  

Vérification de l'attribution de IP flottante

• Pour acheminer le trafic vers le vSocket maître, Azure assigne l'IP flottante au NIC LAN du vSocket maître actuel. Go to the primary vSocket VM LAN NIC > IP Configuration and verify that the Floating IP exists as "Secondary". Si ce n'est pas le cas, continuez avec les étapes suivantes.

Vérification de l'attribution de rôles Azure 

• During Azure vSocket deployment, the HA Identity Role is created and stored in Azure Managed Identities.
• Seul un rôle assigné par l'utilisateur doit être assigné à chaque ressource. Si une politique ajoute des identités assignées par le système dans Azure, les vSockets doivent en être exclus.

• Ce rôle est attribué aux différentes ressources virtuelles attachées au vSocket. Les composants de l'infrastructure Azure qui utilisent le rôle sont :

  • Interface réseau (NIC) LAN pour chaque vSocket
  • Le sous-réseau LAN associé aux NICs LAN
  • Les deux VMs vSocket
• L'attribution de rôle pour les NICs peut être vérifiée sous Contrôle d'accès > Attributions de rôles et doit être assignée à la fois aux NICs LAN primaire et secondaire.
  
• The role assignment for the LAN subnet can be checked under VNET > Subnet, then select the LAN subnet and click Manage users > Role Assignments. 
  
• Pour chaque VM de vSocket, le rôle d'identité peut être vérifié sous Sécurité > Identité > Attribué par l'utilisateur comme vous pouvez le voir dans la capture d'écran ci-dessous. Aucun rôle assigné par le système ne doit être attribué à la VM.
• Si le rôle d'identité HA n'est pas installé sur l'une des ressources ci-dessus, le processus de déploiement peut avoir échoué à le faire. Vous pouvez exécuter à nouveau le script de HA Cato si le rôle manque dans l'une des ressources impliquées. Alternativement, le vSocket secondaire Azure peut être réinstallé, ce qui installera les rôles d'identité HA manquants.

Vérification que l'interface de gestion dispose d'accès DNS et Internet

• Vérifiez que l'interface de gestion a accès à Internet et peut se connecter au serveur DNS configuré.

• Vérifiez la résolution DNS pour management.azure.com depuis le portail Azure. L'appel d'API HA utilise ce FQDN.

  • Allez dans Machine virtuelle > vSocket > Exécuter commande > ExécuterShellScript
  • Entrez dig management.azure.com dans la boîte de texte
  • Cliquez sur Exécuter
• La sortie de dig sera affichée dans le portail avec une réponse DNS.
  
  
• S'il n'y a pas de résolution DNS, consultez Résolution des problèmes de configuration DNS.
• Depuis la même page, essayez d'atteindre n'importe quelle ressource Internet pour confirmer l'accès à Internet. Par exemple, ping -c 4 8.8.8.8 Si le ping échoue, continuez avec les étapes suivantes.
  

Vérifiez si le Groupe de Sécurité de Réseau bloque le trafic sortant.

• Une façon rapide de vérifier est d'aller à l'interface réseau MGMT dans Azure et de cliquer sur "Règles de sécurité effectives" en bas à gauche de l'écran.
• La capture d'écran ci-dessous montre qu'aucun NSG n'est assigné, donc le trafic sortant n'est pas bloqué.

Vérifiez le Routage de l'Interface MGMT pour le Trafic Internet.

• Si le trafic de l'interface MGMT est routé via un pare-feu tiers dans Azure, vérifiez que les connexions sortantes UDP/53 et TCP/443 sont autorisées.
• La table de routage peut être consultée sur la page de l'interface de gestion dans Azure en cliquant sur l'option "Routes effectives".
• La capture d'écran ci-dessous montre la route pour le trafic Internet en utilisant Internet comme "Type de prochain saut", donc un pare-feu ne bloque pas le trafic.
  

Vérification du Prochain Saut de la Table de Routage

• Confirmez que la table de routage LAN pointe vers l'IP flottante. Changez l'adresse IP du prochain saut en conséquence si nécessaire.

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). Il pourrait y avoir deux problèmes associés :

• 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 MAJEURE, par exemple v17.xx.yy ou v18.xx.yy. Les vSockets effectuent une mise à niveau initiale après leur première 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 Azure vSocket et seront envoyés uniquement du vSocket Maître 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. Une manière rapide de vérifier les règles NSG est d'aller à chaque interface réseau LAN dans Azure et de cliquer sur "Règles de sécurité effectives" en bas à gauche de l'écran.
• Confirmez que les deux interfaces LAN sont associées à la même sous-réseau LAN.
• Effectuez une capture de paquets depuis le WebUI des deux vSockets et identifiez si les keepalives envoyés par le primaire sont reçus par le vSocket secondaire.

Résolution des problèmes découverts

Renouvellement de token Azure

• Si Azure Cloud Shell est utilisé pour déployer le script HA, ouvrez une nouvelle session et ré-authentifiez-vous. Cela renouvellera le token utilisé pour interroger l'API.
  

Correction des problèmes de configuration DNS

• Pour corriger la configuration DNS Azure et la régler à la valeur par défaut, allez à Réseau virtuel > Serveurs DNS  et à Interface réseau > Serveurs DNS, et assurez-vous que vous utilisez l'option Défaut ou un serveur DNS public. Éteignez la VM pour effectuer tout changement lié au DNS puis rallumez-la.
  
  

Désenregistrement et redéploiement d'un vSocket Azure

• Si après avoir suivi toutes les étapes de dépannage ci-dessus, le script HA ou le basculement HA continue d'échouer, il est possible de désenregistrer et redéployer un ou les deux vSockets. Consultez Redéployer les Sites vSocket de Haute Disponibilité
• Il est important de suivre les directives et de supprimer la Machine Virtuelle, interfaces réseau, IPs publiques associées et Identité Gérée avant de redéployer un vSocket.
• Si seule l'instance primaire de vSocket est redéployée, vous devez exécuter le script HA dédié (create_ha_settings) pour lier les deux instances de vSocket pour le HA.

Soumission de cas au support de 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 incluant tout message d'erreur.
• Résultats du test DNS pour management.azure.com
• Résultats du test API.
• Captures d'écran de l'IP flottante assignée et des rôles d'identité configurés.
• Captures d'écran du journal d'activité Azure incluant toute erreur trouvée.