Ce billet fait suite à la série relative à la fiabilité lancée par mon billet de blog de juillet qui mettait en évidence plusieurs initiatives en cours visant à améliorer la disponibilité des plateformes, dans le cadre de notre engagement à fournir un ensemble de services cloud de confiance. Aujourd'hui, j'aimerais revenir sur les investissements que nous avons réalisés en termes de technologies de mise à jour sans impact et à faible impact, notamment les mises à jour correctives à chaud, la maintenance avec préservation de la mémoire et la migration dynamique. Au cours de l'année passée, nous avons déployé des dizaines de correctifs de sécurité et de fiabilité pour l’infrastructure hôte, beaucoup d’entre eux ont été implémentés sans impact ni temps d'arrêt pour les clients. Le billet qui suit a été rédigé par John Slack de notre équipe de systèmes d’exploitation de base, responsable de programme pour plusieurs des technologies de mise à jour présentées ci-dessous. » - Mark Russinovich, directeur technique, Azure
Ce billet a été co-rédigé par Apurva Thanky, Cristina del Amo Casado et Shantanu Srivastava des équipes d’ingénierie en charge de ces technologies.
Nous mettons régulièrement à jour l'infrastructure hôte pour améliorer la fiabilité, le niveau de performance et la sécurité de la plateforme. Bien que les objectifs de ces mises à jour de « maintenance » varient, ils impliquent généralement la mise à jour des composants logiciels de l’environnement d’hébergement ou la désactivation de matériel. Il y a encore cinq ans, le seul moyen d’appliquer certaines de ces mises à jour consistait à redémarrer entièrement l’hôte. Cette approche entraînait l'arrêt des machines virtuelles des clients pendant plusieurs minutes. Depuis, nous avons investi dans diverses technologies afin de réduire l’impact de ces mises à jour sur les clients. Aujourd’hui, la plupart des mises à jour du système d’exploitation hôte sont déployées avec une transparence absolue et sans impact sur les clients grâce aux correctifs à chaud. Dans les cas peu fréquents où la mise à jour ne peut être corrigée à chaud, nous avons recours à des technologies de mise à jour à faible impact sur la mémoire afin de déployer cette mise à jour.
Même avec ces technologies, nous sommes parfois tenus de procéder à une maintenance plus percutante (retrait de matériel défaillant ou désactivation de matériel ancien). Dès lors, nous utilisons une combinaison de migration dynamique, de notifications dans les machines virtuelles et de maintenance planifiée fournissant des contrôles client.
Grâce aux investissements continus réalisés dans ce domaine, la plupart des activités de maintenance n'ont aucun impact sur les machines virtuelles hébergées sur l’infrastructure concernée. Nous rédigeons ce billet à des fins de transparence sur les différentes techniques utilisées pour limiter au maximum l'impact des mises à jour Azure.
Plan A : Mises à jour correctives à chaud
L'application de mises à jour correctives « à chaud » au niveau des fonctions offre la possibilité d’apporter des modifications ciblées à l’exécution du code, sans temps d’arrêt pour les machines virtuelles clientes. Pour ce faire, tous les nouveaux appels de fonction d'un hôte sont redirigés vers une version mise à jour de cette fonction, ce qui relève d'une technologie de mise à jour « sans impact ». Dans la mesure du possible, nous utilisons des mises à jour correctives à chaud pour appliquer les mises à jour à l'hôte, évitant ainsi tout impact sur les machines virtuelles exécutées sur cet hôte. Nous utilisons les mises à jour correctives à chaud Azure depuis 2017. Depuis, nous avons élargi la portée des mises à jour correctives à chaud. À titre d'exemple, nous avons mis à jour le système d’exploitation hôte pour permettre à l’hyperviseur d’être corrigé à chaud en 2018. Aujourd'hui, nous nous penchons sur l'application de mises à jour correctives à chaud aux microprogrammes. Il s’agit là d’un domaine sur lequel le secteur ne s'est pas encore pleinement concentré. La mise à jour des microprogrammes a toujours impliqué des redémarrages de serveur, mais nous savons que cela peut être particulièrement pénible pour les clients. Nous travaillons en collaboration avec les fabricants de matériel pour utiliser nos propres microprogrammes afin de pouvoir les corriger à chaud et les mettre à jour de manière incrémentielle.
Certaines mises à jour importantes de l’hôte contiennent des modifications qui ne peuvent pas être appliquées à l’aide de mises à jour correctives à chaud au niveau des fonctions. Dès lors, nous nous efforçons d’utiliser la maintenance avec préservation de la mémoire.
Plan B : Maintenance avec préservation de la mémoire
La maintenance avec préservation de la mémoire implique la « mise en pause » des machines virtuelles invitées (tout en conservant leur mémoire dans la RAM), la mise à jour du serveur hôte, puis la reprise des machines virtuelles et la synchronisation automatique de leurs horloges. Nous utilisons la maintenance avec préservation de la mémoire pour Azure depuis 2018. Nous y avons apporté trois améliorations importantes. Premièrement, nous avons développé des variantes moins percutantes en matière de maintenance avec préservation de la mémoire ciblée pour les composants hôtes pouvant être utilisés sans redémarrage de l'hôte. Deuxièmement, nous avons réduit la durée de mise en pause au niveau du client. Troisièmement, nous avons étendu le nombre de types de machines virtuelles pouvant être mises à jour dans le cadre d'une maintenance avec préservation de la mémoire. Nous poursuivons nos efforts dans ce domaine, mais pour diverses raisons techniques, plusieurs variantes de maintenance avec préservation de la mémoire se révèlent toujours incompatibles avec certaines offres de machines virtuelles spécialisées comme les machines virtuelles de série M, N ou H.
Dans les rares cas où il nous faut procéder à une maintenance plus impactante (redémarrage de l’hôte, redéploiement des machines virtuelles notamment), nous informons nos clients et leur offrons la possibilité de procéder à cette maintenance au moment le plus opportun pour leurs charges de travail.
Plan C : Maintenance libre-service
La maintenance libre-service consiste à fournir aux clients et partenaires une fenêtre de temps durant laquelle ils peuvent choisir de lancer une maintenance impactante sur leurs machines virtuelles. Cette phase libre-service initiale dure en général un mois et permet aux organisations de procéder à la maintenance selon leurs propres calendriers, afin de limiter au maximum les interruptions pour les utilisateurs. À la fin de cette fenêtre de libre-service, une phase de maintenance planifiée commence, phase au cours de laquelle Azure procède automatiquement à la maintenance. Lors de ces deux phases, les clients bénéficient d’une visibilité totale sur les machines virtuelles mises à jour ou non, dans Azure Service Health ou en formulant une requête dans PowerShell/CLI. Azure propose la maintenance libre-service depuis 2018. Nous constatons généralement que les administrateurs tirent parti de la phase de libre-service plutôt que d’attendre qu’Azure procède automatiquement à la maintenance de leurs machines virtuelles.
De plus, lorsque le client est propriétaire de la machine hôte, moyennant Azure Dedicated Host ou des machines virtuelles isolées, nous proposons depuis peu un contrôle de maintenance de toutes les mises à jour de plateforme avec impact non nul. Cela comprend les mises à jour sans redémarrage ne nécessitant que quelques secondes de pause. Elles sont particulièrement utiles pour les machines virtuelles exécutant des charges de travail ultra-sensibles ne pouvant supporter la moindre interruption, même de quelques secondes. Les clients peuvent choisir quand appliquer ces mises à jour à impact non nul dans une fenêtre de 35 jours. Cette fonctionnalité est disponible en préversion publique et de plus amples informations sont disponibles dans ce billet de blog.
Il arrive parfois que les technologies de mise à jour sur place ne soient pas viables, par exemple lorsqu’un hôte affiche des signes de dégradation matérielle. Dans de tels cas, le mieux consiste à déplacer la machine virtuelle vers un autre hôte, par le biais d'un contrôle client via une maintenance planifiée, ou d’une migration dynamique.
Plan D : Migration dynamique
La migration dynamique implique le déplacement d’un d'une machine virtuelle client en cours d’exécution d’un hôte « source » vers un hôte de « destination ». Dans un premier temps, la migration dynamique déplace l'état local de la machine virtuelle (y compris la RAM et le stockage local) de la source vers la destination, alors même que la machine virtuelle est toujours en cours d’exécution. Une fois l'état local déplacé, la machine virtuelle invitée fait l'objet d'une courte pause (généralement inférieure à cinq secondes). Au terme de cette pause, la machine virtuelle reprend son exécution sur l'hôte de destination. Azure utilise la migration dynamique à des fins de maintenance depuis 2018. Aujourd'hui, lorsque les algorithmes d’Azure Machine Learning prédisent une défaillance matérielle imminente, la migration dynamique permet de déplacer les machines virtuelles invitées vers différents hôtes et ce, de façon préemptive.
Entre autres sujets, les opérations de maintenance planifiée et IA ont été traitées lors de la récente session Ignite 2019 d'Igal Figlin « Création d’applications résilientes dans Azure ». Regardez l'enregistrement ici pour plus d’informations sur ces sujets, et savoir comment tirer parti des différents services résilients fournis par Azure pour créer des applications résilientes par nature.