Projet Flash : utiliser Azure Resource Health pour surveiller la disponibilité de la machine virtuelle Azure

Article
02/21/2024

Azure Resource Health est une solution proposée par Flash. Flash est le nom interne d’un projet dédié à l’élaboration d’un mécanisme robuste, fiable et rapide destiné à permettre aux clients de surveiller l’intégrité des machines virtuelles.

Cet article traite de l’utilisation d'Azure Resource Health pour surveiller la disponibilité des machines virtuelles Azure. Pour obtenir une vue d’ensemble générale des solutions Flash, consultez la vue d’ensemble de Flash.

Pour obtenir une documentation propre aux autres solutions proposées par Flash, choisissez parmi les articles suivants :

Azure Resource Health

Il offre des contrôles de santé immédiats et conviviaux pour les ressources individuelles par l’intermédiaire du portail. Les clients peuvent accéder rapidement au panneau Intégrité des ressources sur le portail et passer en revue un enregistrement historique de 30 jours des vérifications d’intégrité, ce qui en fait un excellent outil pour la résolution des problèmes rapides et simples. La fonctionnalité Azure Resource Health existante vous aide à diagnostiquer et à obtenir un support pour les problèmes de service qui affectent vos ressources Azure. Il rend compte de l'état actuel et passé de vos ressources, en indiquant les plages de temps pendant lesquelles chacune de vos ressources a été indisponible.

Mais nous savons que nos clients et partenaires souhaitent obtenir la compréhension des causes des problèmes techniques sous-jacents et améliorer la façon dont ils peuvent recevoir des communications sur ces problèmes, afin d'alimenter les processus de surveillance, d'expliquer les problèmes à d'autres parties prenantes et, en fin de compte, d'éclairer les décisions commerciales.

Causes racines des problèmes de machine virtuelle dans Azure Resource Health

Nous avons récemment livré une amélioration de l'expérience de santé des ressources qui permettra d'améliorer les informations que nous partageons avec les clients sur les défaillances des machines virtuelles et de fournir plus de contexte sur la cause profonde qui a conduit au problème. Désormais, en plus de recevoir une notification rapide lorsque la disponibilité d'une machine virtuelle est affectée, les clients peuvent s'attendre à ce qu'une cause fondamentale soit ajoutée ultérieurement, une fois que notre système automatisé d'analyse des causes fondamentales (RCA) aura identifié le composant défaillant de la plateforme Azure à l'origine de la défaillance de la machine virtuelle. Prenons un exemple pour voir comment ce processus fonctionne dans la pratique :

À l'instant T1, un rack de serveurs est mis hors ligne en raison d'un problème de réseau, ce qui entraîne la perte de connectivité des machines virtuelles sur le rack. Des améliorations récentes de la fiabilité liées à l’architecture réseau seront partagées dans un prochain billet de blog sur l’avancement de la fiabilité, regardez cet espace !

À l’instant T2, la surveillance interne d'Azure reconnaît qu'elle n'est pas en mesure d'atteindre les machines virtuelles sur le rack et commence à atténuer le problème en redéployant les machines virtuelles concernées sur un nouveau rack. Pendant ce temps, une annotation est envoyée à l'état des ressources pour informer les clients que leur machine virtuelle est actuellement touchée et indisponible.

À l’instant T3, la télémétrie de la plateforme provenant du commutateur du haut du rack, de la machine hôte et des systèmes de surveillance internes est corrélée dans notre moteur RCA afin de dériver la cause première de la panne. Une fois calculée, la RCA est ensuite publiée dans l'état des ressources, accompagnée de suggestions sur la résilience de l'architecture que les clients peuvent mettre en œuvre pour minimiser la probabilité d'un impact à l'avenir.

Si la fonctionnalité de notification initiale des temps d'arrêt date de plusieurs années, la publication d'une déclaration des causes profondes est une nouveauté. Entrons maintenant dans les détails de la manière dont nous déduisons ces causes racines.

Moteur d’analyse de la cause racine

Examinons de plus près l'exemple précédent et détaillons le fonctionnement et la technologie du moteur RCA. Au cœur de notre moteur RCA pour machines virtuelles est Azure Data Explorer (ADX), un service Big Data optimisé pour l’analytique de télémétrie des journaux de volume élevé. Azure Data Explorer permet d'analyser facilement des téraoctets de données télémétriques provenant d'appareils et de services de la plateforme Azure, de les réunir et d'interpréter les flux d'informations corrélés afin de déterminer la cause première de différents scénarios de défaillance. Il s’agit en fin de compte d’un processus d’ingénierie des données en plusieurs étapes :

Phase 1 : détection des temps d’arrêt

La première phase de l'analyse des causes racines consiste à définir l'élément déclencheur de l'analyse. Pour les Machines virtuelles Microsoft Azure, nous voulons déterminer les causes racines chaque fois qu'une machine virtuelle redémarre de manière inattendue, de sorte que le déclencheur est une machine virtuelle qui passe d'un état de fonctionnement à un état d'arrêt. L'identification de ces transitions à partir de la télémétrie de la plate-forme est simple dans la plupart des scénarios, mais plus compliquée dans certains types de pannes d'infrastructure où la télémétrie de la plate-forme peut être perdue en raison d'une défaillance de l'appareil ou d'une perte de puissance. Pour gérer ces catégories de défaillances, d'autres techniques sont nécessaires, comme le suivi de la perte de données en tant qu'indication possible d'une transition de la disponibilité de la machine virtuelle. Azure Data Explorer excelle à ce moment de l’analyse de séries, et vous trouverez des techniques plus détaillées autour de ce processus dans la Communauté technique Microsoft : calcul des temps d’arrêt à l’aide des fonctions Windows et séries chronologiques dans Azure Data Explorer.

Phase 2 : analyse des corrélations

Une fois qu'un événement déclencheur est défini (dans ce cas, une machine virtuelle passant à un état non sain), la phase suivante est l'analyse de corrélation. Dans cette étape, nous utilisons la présence de l'événement déclencheur pour corréler les données télémétriques provenant de différents points de la plateforme Azure :

Hôte Azure : panneau physique hébergeant les machines virtuelles.
TOR : le commutateur de réseau en haut du rack.
Stockage Azure : le service qui héberge des disques virtuels pour les machines virtuelles Azure.

Chacun de ces systèmes possède ses propres flux de télémétrie qui doivent être analysés et mis en corrélation avec l'événement déclencheur du temps d'arrêt de la VM. Pour ce faire, il faut avoir la compréhension du graphe de dépendance d'une machine virtuelle et les systèmes sous-jacents susceptibles de provoquer la défaillance d'une machine virtuelle, puis réunir les données télémétriques de santé de tous ces systèmes dépendants, en les filtrant sur les événements qui se sont produits à proximité du moment de la transition de la machine virtuelle. Le langage de requête intuitif et puissant d'Azure Data Explorer permet d’offrir des modèles documentés tels que la jonction de fenêtres temporelles pour la corrélation des flux de télémétrie temporelles ensemble. À la fin de ce processus de corrélation, nous disposons d'un ensemble de données qui représente les transitions de temps d'arrêt des machines virtuelles avec la télémétrie de plate-forme corrélée de tous les systèmes dépendants qui pourraient causer ou avoir des informations utiles pour déterminer ce qui a conduit à la défaillance de la machine virtuelle.

Phase 3 : attribution de la cause racine

L’étape suivante du processus est l’attribution. Maintenant que nous avons rassemblé toutes les données pertinentes dans un seul ensemble de données, les règles d'attribution sont appliquées pour interpréter les informations et les traduire en une déclaration de cause fondamentale orientée vers le client. Si vous revenez à notre exemple initial de défaillance d'un TOR, après notre analyse de corrélation, nous pourrions avoir de nombreux éléments d'information intéressants à interpréter. Par exemple, les systèmes qui surveillent les hôtes Azure peuvent avoir des journaux indiquant qu'ils ont perdu la connectivité avec les hôtes pendant cette période. Nous pouvons également avoir des signaux liés à des problèmes de connectivité des disques virtuels et des signaux explicites de l'appareil TOR concernant la défaillance. Tous ces éléments d'information sont maintenant passés en revue et le signal explicite de défaillance du réseau TOR est considéré comme la cause première, en priorité par rapport aux autres signaux. Ce processus de hiérarchisation et les règles qui le sous-tendent sont élaborés avec des experts du domaine et modifiés au fur et à mesure de l'évolution de la plateforme Azure. L’apprentissage automatique et les mécanismes de détection d’anomalies s’assoient sur ces causes racines attribuées, afin d’aider à identifier les opportunités d’amélioration de ces règles de classification et à détecter les changements de modèle dans le taux de ces défaillances pour revenir dans des pipelines de déploiement sécurisés.

Phase 4 : publication du RCA

La dernière étape consiste à publier les causes racines dans Azure Resource Health, où elles deviennent visibles pour les clients. La publication est effectuée par une application Azure Functions simple, qui interroge régulièrement les données de cause racine traitées dans Azure Data Explorer et émet les résultats vers le serveur principal d’intégrité des ressources. Étant donné que les flux d'informations peuvent arriver avec différents retards, les RCA peuvent parfois être mises à jour au cours de ce processus pour refléter l'arrivée de meilleures sources d'informations conduisant à une cause racine plus spécifique que celle publiée à l'origine.

À l’avenir

Identifier et communiquer la cause racine de tout problème à nos clients et partenaires n'est qu'un début. Nos clients peuvent être amenés à prendre ces RCA et à les partager avec leurs clients et leurs collègues. Nous souhaitons nous appuyer sur ce travail pour faciliter l'identification et le suivi des RCA des ressources, ainsi que leur diffusion. Pour ce faire, nous travaillons sur des modifications du backend afin de générer des identifiants de suivi uniques par ressource et par temps d'arrêt que nous pourrons vous communiquer, afin que vous puissiez facilement faire correspondre les temps d'arrêt à leurs RCA. Nous travaillons également sur de nouvelles fonctionnalités pour faciliter l'envoi de RCA par e-mail, et éventuellement l'abonnement à des RCA pour vos machines virtuelles. Cette fonction permettra de s'inscrire aux RCA directement dans votre boîte de réception après un événement d'indisponibilité, sans que vous ayez à faire quoi que ce soit d'autre.

Étapes suivantes

Pour en savoir plus sur les solutions proposées, passez à l'article de solution correspondant :

Pour une présentation générale de la façon de surveiller les machines virtuelles Azure, consultez Surveiller les machines virtuelles Azure et la référence sur la surveillance des machines virtuelles Azure.

Partager via