Résoudre les problèmes d’intégrité des ressources et de disponibilité entrante

Article
02/20/2024

Cet article est destiné à vous guider dans l’investigation des problèmes impactant la disponibilité de l’adresse IP du front-end et des ressources back-end de votre équilibreur de charge.

La vérification Resource Health (RHC) pour Load Balancer est utilisée pour déterminer l’intégrité de votre équilibreur de charge. Elle analyse la métrique Disponibilité du chemin des données sur un intervalle de deux minutes pour déterminer si les points de terminaison d’équilibrage de charge, l’adresse IP du front-end et les combinaisons de ports frontaux avec règles d’équilibrage de charge sont disponibles.

Remarque : RHC n’est pas pris en charge pour la référence SKU De base de Load Balancer

Le tableau ci-dessous décrit la logique RHC utilisée pour déterminer l’état d’intégrité de votre équilibreur de charge.

État d’intégrité des ressources	Description
Disponible	Votre ressource d’équilibreur de charge standard est intègre et disponible.
Détérioré	Votre équilibreur de charge standard présente des événements lancés par la plateforme ou l’utilisateur qui nuisent aux performances. La métrique Disponibilité du chemin de données a fait état d’une intégrité inférieure à 90 %, mais supérieure à 25 % pendant au moins deux minutes. La détérioration des performances observée est de niveau modéré à grave.
Indisponible	Votre ressource d’équilibreur de charge standard n’est pas saine. La métrique Disponibilité du chemin des données a fait état d’une intégrité inférieure à 25 % pendant au moins deux minutes. Vous observez une détérioration des performances significative ou un défaut de disponibilité pour la connectivité entrante. Des événements utilisateur ou plateforme peuvent être à l’origine de cette indisponibilité.
Inconnu	L’état d’intégrité de votre ressource d’équilibreur de charge standard n’a pas été mis à jour ou n’a pas reçu d’informations de disponibilité du chemin des données au cours des 10 dernières minutes. Cet état est transitoire et présentera un état correct dès que des données seront reçues.

À propos des métriques que nous utilisons

Les deux métriques à utiliser sont Disponibilité du chemin d’accès aux données et État de la sonde d’intégrité, et il est important d’en comprendre la signification pour obtenir des insights justes.

Disponibilité du chemin des données

La métrique de disponibilité du chemin de données est générée par un test ping TCP toutes les 25 secondes sur tous les ports front-end sur lesquels des règles NAT de trafic entrant et d’équilibrage de charge sont configurées. Ce test ping TCP est routé vers une des instances back-end (sondées) saines. Si le service reçoit une réponse au test ping, il s’agit d’une réponse positive et la somme de la métrique est itérée une fois. En l’absence de réponse, aucune itération ne se produit. Le décompte de cette métrique est de 1/100 du nombre total de tests ping TCP par période d’échantillonnage. Par conséquent, il est préférable de prendre en compte la moyenne, qui indique la somme/le décompte moyen de la période. Les données montrent la métrique de disponibilité du chemin agrégée par moyenne, ce qui donne un pourcentage du taux de réussite des tests ping TCP sur l’adresse IP et le port du front-end pour chacune de vos règles NAT de trafic entrant et d’équilibrage de charge.

État de la sonde d’intégrité

La métrique d’état de la sonde d’intégrité est générée par un test ping du protocole défini dans la sonde d’intégrité. Ce test ping est envoyé à chaque instance dans le pool back-end et sur le port défini dans la sonde d’intégrité. Pour les sondes HTTP et HTTPS, un test ping réussi passe par une réponse HTTP 200 OK, tandis qu’avec les sondes TCP, toutes les réponses sont considérées réussies. Les réussites ou échecs consécutifs de chaque sonde déterminent l’intégrité de l’instance back-end et déterminent si le pool principal affecté est en mesure de recevoir le trafic. Comme pour la disponibilité du chemin des données, nous utilisons l’agrégation moyenne, qui indique la moyenne des tests ping réussis/totaux pendant l’intervalle d’échantillonnage. Cette valeur d’état de la sonde d’intégrité indique l’intégrité du back-end isolé de l’équilibreur de charge en sondant les instances back-end sans envoyer de trafic via le front-end.

Important

L’état de la sonde d’intégrité est échantillonné toutes les minutes. Cela peut occasionner de légères fluctuations dans une valeur sinon stable. Par exemple, s’il existe deux instances back-end, une en service et l’autre hors service, le service de sonde d’intégrité peut capturer sept échantillons pour l’instance saine et six pour l’instance non saine. Ainsi, une valeur auparavant stable de 50 passe à 46,15 pendant une minute.

Diagnostiquer les équilibrages de charge dégradés et indisponibles

Comme indiqué dans l’article sur l’intégrité des ressources, un équilibreur de charge détérioré indique une disponibilité du chemin des données comprise entre 25 % et 90 %. Un équilibreur de charge non disponible indique une disponibilité du chemin des données inférieure à 25 % sur une période de deux minutes. Vous pouvez suivre ces mêmes étapes pour analyser la défaillance indiquée dans les alertes d’état de la sonde d’intégrité ou de disponibilité du chemin des données que vous avez configurées. Nous allons nous pencher sur le cas où la vérification de l’intégrité de nos ressources révèle que notre équilibreur de charge était indisponible avec une disponibilité du chemin des données de 0 % (service indisponible).

Pour commencer, accédons à la vue de mesures détaillée de notre page des insights d’équilibreur de charge dans le Portail Azure. Accédez à la vue depuis la page de ressources de l’équilibreur de charge ou le lien situé dans le message d’intégrité des ressources. Accédons ensuite à l’onglet Disponibilité front-end et back-end et analysons une fenêtre de trente minutes de la période où l’état détérioré ou indisponible est apparu. Si nous constatons que la disponibilité du chemin des données est de 0 %, nous savons qu’un problème bloque le trafic pour l’ensemble de nos règles NAT de trafic entrant et d’équilibrage de charge, et nous pouvons voir combien de temps ce problème a duré.

Le prochain élément auquel nous devons nous intéresser est la métrique d’état de la sonde d’intégrité afin de déterminer si le chemin des données est indisponible, car nous ne disposons d’aucune instance back-end saine pour gérer le trafic. S’il y a au moins une instance back-end saine pour l’ensemble de nos règles d’équilibrage de charge et de trafic entrant, nous savons que ce n’est pas notre configuration qui est à l’origine de l’indisponibilité de nos chemins de données. Ce scénario indique un problème de plateforme Azure. Bien que les problèmes de plateforme soient rares, une alerte automatisée est envoyée à notre équipe pour résoudre rapidement tous les problèmes de plateforme.

Diagnostiquer les échecs de la sonde d’intégrité

Supposons que nous vérifions l’état de la sonde d’intégrité et que nous découvrons que toutes les instances sont présentées comme étant non saines. Cette découverte explique la raison pour laquelle notre chemin de données est indisponible, car le trafic ne peut aller nulle part. Nous devons parcourir la liste de vérification suivante pour exclure les erreurs de configuration :

Vérifiez l’utilisation du processeur de vos ressources pour déterminer si elles sont soumises à une charge élevée.
- Vous pouvez vérifier cela en affichant la métrique Pourcentage CPU de la ressource via la page Mesures. Découvrez comment Résoudre les problèmes d’utilisation élevée du processeur pour les machines virtuelles Azure.
Si une sonde HTTP ou HTTPS est utilisée, vérifier si l’application est saine et réactive.
- Vérifiez que l’application est opérationnelle en accédant directement aux applications via l’adresse IP privée ou l’adresse IP publique au niveau de l’instance associée à votre instance back-end.
Passer en revue les groupes de sécurité réseau appliqués aux ressources back-end. Vérifier qu’il n’existe pas de règles dont la priorité est supérieure à celle de AllowAzureLoadBalancerInBound et qui bloqueraient la sonde d’intégrité.
- Pour ce faire, vous pouvez accéder aux paramètres réseau de vos groupes de machines virtuelles identiques ou de Virtual Machine Scale Sets.
- Si vous constatez que ce problème de groupe de sécurité réseau est bien la cause, déplacez la règle d’autorisation existante ou créez une règle de haute priorité pour autoriser le trafic AzureLoadBalancer.
Vérifier le système d’exploitation. Vérifiez que les machines virtuelles écoutent le port de la sonde et examinez leurs règles de pare-feu du système d’exploitation pour vous assurer qu’elles ne bloquent pas le trafic de la sonde en provenance de l’adresse IP 168.63.129.16.
- Vous pouvez vérifier les ports d’écoute en exécutant netstat -a dans une invite de commandes Windows ou netstat -l à partir d’un terminal Linux.
Vérifiez que vous utilisez le protocole approprié. Par exemple, une sonde utilisant HTTP pour sonder un port à l’écoute d’une application non HTTP échoue.
Le Pare-feu Azure ne doit pas être placé dans le pool back-end d’équilibreurs de charge. Consultez Intégrer un pare-feu Azure avec Azure Standard Load Balancer pour intégrer correctement le Pare-feu Azure avec l’équilibreur de charge.

Si, après avoir parcouru cette liste de vérification, les échecs de la sonde d’intégrité persistent, il est possible que des problèmes de plateforme rares affectent le service de sonde de vos instances. Dans ce cas, vous pouvez compter sur Azure : une alerte automatisée est envoyée à notre équipe pour résoudre rapidement tous les problèmes de plateforme.

Share via