« Notre objectif est de donner aux organisations les moyens de faire fonctionner leurs charges de travail de manière fiable sur Azure. Fidèles à notre principe directeur, nous investissons en permanence dans l’évolution de la plateforme Azure afin que celle-ci résiste aux erreurs, non seulement pour stimuler la productivité des entreprises, mais aussi pour offrir une expérience client sans faille. Le mois dernier, j’ai publié un billet de blog décrivant plusieurs initiatives en cours qui visent à améliorer continuellement cet espace, dans le cadre de notre engagement à fournir un ensemble de services cloud approuvés. Aujourd’hui, je souhaite aborder le projet Tardigrade, une initiative de résilience de plateforme qui améliore la haute disponibilité de nos services même dans les rares cas d’erreurs spontanées survenant sur la plateforme. Le billet ci-après a été rédigé par Pujitha Desiraju et Anupama Vedapuri qui dirigent ces efforts au sein de notre équipe de base de la plateforme de calcul. » Mark Russinovich, directeur technique, Azure

---

Ce billet a été co-écrit par Jim Cavalaris, ingénieur logiciel principal, Azure Compute. 

 

Connu sous le nom de code « projet Tardigrade », cet effort s’inspire de la créature microscopique à huit pattes, le tardigrade, également connu sous le nom d’ourson d’eau. Pratiquement impossibles à tuer, les tardigrades parviennent toujours à survivre même quand ils sont exposés à des conditions extrêmes. C’est exactement ce que nous envisageons pour nos serveurs du point de vue de la résilience, d’où le nom de projet Tardigrade. Semblable à la survie d’un tardigrade dans un large éventail de conditions extrêmes, ce projet implique la création de mécanismes de résilience et d’auto-réparation sur plusieurs couches de la plateforme, allant du matériel aux logiciels, le tout dans le but de protéger au maximum vos machines virtuelles.

Comment cela fonctionne-t-il ?

Le projet Tardigrade est une vaste initiative de résilience de plateforme qui utilise de nombreuses stratégies d’atténuation afin de garantir que vos machines virtuelles ne sont pas affectées par un comportement imprévisible de l’hôte. Il s’agit notamment de permettre aux composants de s’auto-réparer et de se remettre rapidement des défaillances potentielles afin de ne pas impacter vos charges de travail. Même dans les rares cas de défaillances critiques de l’hôte, notre priorité est de préserver et de protéger vos machines virtuelles contre ces événements spontanés afin de garantir le fonctionnement transparent de vos charges de travail.

Un exemple de workflow de récupération est présenté ci-après, pour l’événement rare dans lequel une opération de machine virtuelle initiée par un client échoue en raison d’une erreur sous-jacente sur le serveur hôte. Pour mener à bien le fonctionnement de la machine virtuelle défaillante, ainsi que pour empêcher de manière proactive que le problème ne risque de s’étendre à d’autres machines virtuelles sur le serveur, le service de récupération Tardigrade est averti et commence à exécuter les opérations de basculement.

Les phases suivantes décrivent brièvement le workflow de récupération Tardigrade :

Phase 1 :

Cette étape n’a aucun impact sur l’exécution des machines virtuelles des clients. Elle recycle simplement tous les services fonctionnant sur l’hôte. Dans les rares cas où le service défaillant ne parvient pas à redémarrer, nous passons à la phase 2.

Phase 2 :

Notre service de diagnostic fonctionne sur l’hôte pour collecter systématiquement tous les journaux/vidages pertinents afin de garantir que nous pouvons diagnostiquer précisément la raison de l’échec de la phase 1. Cette analyse complète nous permet de déterminer les causes profondes du problème et d’éviter qu’il ne se reproduise.

Phase 3 :

À un niveau élevé, nous rétablissons l’état d’intégrité du système d’exploitation avec un impact minimal sur le client afin d’atténuer le problème de l’hôte. Au cours de cette phase, nous préservons les états respectifs de chaque machine virtuelle en mémoire vive, après quoi nous commençons à réinitialiser le système d’exploitation dans un état sain. Tandis que le système d'exploitation se réinitialise rapidement, les applications en cours d’exécution sur toutes les machines virtuelles hébergées sur le serveur « se figent » brièvement, car l’exécution de l’UC est temporairement suspendue. Cette expérience s’apparente à une connexion réseau temporairement perdue mais reprise rapidement grâce à la logique de nouvelle tentative. Après la réinitialisation réussie du système d’exploitation, les machines virtuelles utilisent leur état stocké et reprennent leur activité normale sans nécessiter de redémarrage.

Par cette approche, nous garantissons que la défaillance d’un seul composant de l’hôte n’affecte pas l’ensemble du système, ce qui prémunit mieux les machines virtuelles des clients contre les défaillances imprévues de l’hôte. Cela permet également de reprendre rapidement après les formes les plus extrêmes de défaillances critiques (comme les défaillances de noyau et les problèmes de microprogrammes) tout en conservant l’état de machine virtuelle qui vous intéresse.

À l’avenir

Actuellement, nous utilisons le workflow de récupération Tardigrade décrit précédemment pour détecter rapidement les défaillances potentielles des hôtes logiciels du parc Azure et reprendre l’activité le plus vite possible. En parallèle, nous améliorons constamment nos capacités techniques et nous développons des scénarios de défaillance de l’hôte différents, combattus grâce à cette initiative de résilience.

Nous cherchons également à explorer les dernières innovations en matière d’apprentissage automatique afin d’exploiter les fonctionnalités proactives du projet Tardigrade. Par exemple, nous prévoyons d’utiliser l’apprentissage automatique pour prévoir le plus tôt possible d’autres types de défaillances de l’hôte. Par exemple, pour détecter les modèles d’utilisation anormale des ressources de l’hôte susceptibles d’avoir un impact sur la charge de travail de celui-ci. Nous utiliserons également l’apprentissage automatique pour aider à recommander des actions de réparation appropriées (comme les étapes de récupération Tardigrade, la migration en direct dans la mesure du possible, etc.), optimisant les options de récupération dans l’ensemble du parc Azure.

Alors que les clients continuent à transférer des charges de travail critiques sur la plateforme Microsoft Azure, nous apprenons et nous apportons des améliorations constamment afin de pouvoir continuer à répondre aux attentes des clients concernant les interruptions dues à des défaillances imprévues. La fiabilité est et reste un principe fondamental de nos engagements approuvés en matière de cloud, au même titre que la conformité, la sécurité, la confidentialité et la transparence. Dans tous ces domaines, nous savons que la confiance des clients se gagne et doit être maintenue, non seulement en disant mais aussi en faisant ce qui est juste. La résilience de la plateforme telle qu’elle est pratiquée par le projet Tardigrade renforce déjà la disponibilité des machines virtuelles en garantissant que les problèmes d’hôte sous-jacents n’affectent pas vos machines virtuelles.

Nous continuerons à partager les améliorations apportées à ce projet et à d’autres projets similaires, afin d’être aussi transparents que possible sur la façon dont nous améliorons constamment la fiabilité de la plateforme pour donner à votre organisation les moyens de se développer.