Un portique, sa charge et sa cadence

Sur un terminal à conteneurs, on ne choisit pas un portique parce qu'il est impressionnant. On le choisit sur trois chiffres : la charge qu'il lève, la portée qu'il couvre au-dessus du navire, et le nombre de mouvements qu'il tient par heure.

Un portique surdimensionné coûte le même loyer mensuel qu'un portique bien choisi. Il ne décharge pas plus vite pour autant, parce que le goulot est ailleurs : dans les camions qui n'arrivent pas assez vite au pied de la grue.

La machine virtuelle est le portique du cloud. C'est la brique la plus ancienne, celle qui reste quand rien d'autre ne convient, et celle qu'on dimensionne le plus mal. On la crée en quelques clics, on garde la taille proposée par défaut, on garde le disque proposé par défaut, et six mois plus tard elle figure en tête de la facture sans que personne sache expliquer pourquoi.

Le billet précédent a tranché la question de qui exploite. Celui-ci suppose la réponse acquise : on a choisi la machine virtuelle, il reste à la concevoir.

Quatre décisions suffisent à déterminer ce qu'elle sait faire et ce qu'elle coûte. La famille de taille fixe le ratio entre processeur et mémoire. Les disques commandent la durabilité et le débit. L'image détermine ce qui se trouve dedans au premier démarrage, donc la vitesse à laquelle on peut la reconstruire. Reste le mécanisme de mise à l'échelle, qui décide de ce qui se passe quand la charge double.

Ces quatre décisions ne sont pas indépendantes. Un disque très rapide sur une petite machine reste plafonné par les limites d'entrées-sorties de la machine, et une mise à l'échelle horizontale n'a aucun sens si l'image met quinze minutes à démarrer.
flowchart TD W["Charge de travail
à héberger"] --> T["1. La famille de taille
ratio processeur et mémoire"] T --> D["2. Les disques
durabilité, débit, latence"] D --> I["3. L'image
ce qui est déjà dedans"] I --> S["4. La mise à l'échelle
une plus grosse ou plusieurs"] S --> F["Facture mensuelle
et conduite quotidienne"] T -.->|"quota de processeurs virtuels"| L["Contraintes de placement
région, zone, taille disponible"] D -.->|"plafond d'entrées-sorties"| L S -.->|"domaines d'erreur et zones"| L classDef entree fill:#ede9e1,stroke:#8a4d16,color:#1f2428; classDef decision fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef sortie fill:#d89253,stroke:#8a4d16,color:#2c3338; class W entree; class T,D,I,S decision; class F,L sortie;

Windows et Linux sont traités ensemble ici. Sur la majorité de ces décisions, le système invité ne change rien. Ce qui diffère réellement a sa propre section.

Lire une taille avant de la choisir

Le catalogue du loueur de portiques ne dit pas « gros » et « petit ». Il donne une référence par modèle, et cette référence encode la charge admissible, la portée et les options installées. Qui sait la lire choisit en trente secondes.

Azure fonctionne de la même façon. Les tailles sont regroupées par familles, chacune correspondant à un profil de charge, et pas à un niveau de gamme.

Famille Ce qu'elle privilégie Charges qui la rendent évidente
Usage général Un ratio équilibré entre processeurs et mémoire Serveurs web, environnements de test, petites bases
Optimisé pour le calcul Beaucoup de processeur pour peu de mémoire Serveurs d'applications, traitement par lot, nœuds de calcul
Optimisé pour la mémoire Beaucoup de mémoire pour peu de processeurs Bases relationnelles, caches en mémoire, analyse en mémoire
Optimisé pour le stockage Un disque local rapide et volumineux Magasins non relationnels, moteurs d'indexation, gros traitements locaux
Accéléré par GPU Un ou plusieurs accélérateurs graphiques Entraînement et inférence, rendu, postes de travail graphiques distants
Calcul haute performance Interconnexion à faible latence entre nœuds Simulation numérique, calcul parallèle fortement couplé

La désignation se lit de gauche à droite. Prenons Standard_D4ds_v5 : Standard est le niveau de tarification, D la famille d'usage général, 4 le nombre de processeurs virtuels, d la présence d'un disque temporaire local, s la compatibilité avec le stockage Premium, et v5 la génération.

Les lettres additionnelles portent l'essentiel de l'information. Un a désigne un processeur AMD, un p une architecture ARM, un l une variante à mémoire réduite et un m une variante à mémoire accrue. Deux tailles affichant le même nombre de processeurs peuvent ainsi être très éloignées sur la mémoire embarquée et sur le prix.

Deux pièges reviennent systématiquement.

Le premier est la famille à rafale, celle qui accumule des crédits de processeur quand la charge est faible et les dépense quand elle monte. Elle est excellente pour une charge réellement intermittente, et catastrophique pour une charge continue : une fois les crédits épuisés, la machine retombe sur sa performance de base, souvent une fraction de ce que l'équipe croyait avoir acheté.

Le second est le nombre de processeurs facturé par un éditeur tiers. Azure propose des tailles à processeurs virtuels contraints, où l'on conserve la mémoire, le nombre de disques et la bande passante d'une grande taille en n'exposant qu'une partie des cœurs. La licence se calcule sur les cœurs actifs, la machine garde sa mémoire. C'est un levier sérieux sur les bases de données commerciales.

Reste ce qui n'apparaît sur aucune fiche produit. Toutes les tailles ne sont pas disponibles dans toutes les régions ni dans toutes les zones. Les quotas de processeurs virtuels s'appliquent par famille et par région, et se demandent avant d'en avoir besoin. Enfin, changer la taille d'une machine impose un redémarrage, et parfois une libération complète si la taille visée n'existe pas sur le matériel qui l'héberge actuellement.

On ne choisit pas une taille, on choisit un ratio. La bonne question est le rapport entre processeur et mémoire dont la charge a besoin, pas le nombre de cœurs qui rassure.

Le catalogue à jour se lit dans la documentation des tailles de machines virtuelles Azure.

Les disques

Au pied du portique, deux surfaces cohabitent et ne servent pas au même usage. Le terre-plein reçoit les conteneurs le temps du transbordement, et il est vidé au rythme des navires. L'entrepôt, lui, garde ce qui doit rester.

Confondre les deux fait perdre une cargaison. Sur Azure, la même confusion fait perdre une base de données.

Un disque managé est une ressource à part entière : il a son cycle de vie, sa réplication, son chiffrement et sa facture, indépendamment de la machine à laquelle il est rattaché. Cinq types existent.

Type Ce qu'il apporte Performance liée à la capacité Disque système Cache hôte
Ultra La latence la plus basse, débit et entrées-sorties ajustables sans redémarrage Non, réglage indépendant Non Non pris en charge
SSD Premium v2 Une latence très basse à un tarif inférieur à Ultra Non, réglage indépendant Non Non pris en charge
SSD Premium Une performance garantie par palier, avec un mécanisme de rafale Oui, par palier de capacité Oui Oui
SSD Standard Des entrées-sorties modérées et régulières Oui, par palier Oui Oui
HDD Standard Le coût le plus bas pour de la donnée peu sollicitée Oui, par palier Oui Oui

La disponibilité des deux premiers dépend de la région et du mode de déploiement retenu. Cela se vérifie avant de bâtir une conception dessus, pas après.

Quatre disques, quatre rôles

Disque Ce qu'il porte Survit à une libération de la machine Le piège
Système Le système d'exploitation et sa configuration Oui Y ranger la donnée applicative pour aller vite
De données La donnée applicative, les journaux, les bases Oui Dépasser le plafond d'entrées-sorties de la machine
Temporaire Fichier d'échange, cache local, fichiers de travail Non Le prendre pour du stockage durable
Système éphémère Le système, stocké sur l'hôte lui-même Non L'utiliser pour un nœud qui porte un état

Le disque temporaire mérite qu'on s'arrête. Il apparaît en D: sous Windows et sous /mnt sur la plupart des images Linux, il est rapide, il est gratuit, et son contenu disparaît à la première libération de la machine, à la première maintenance de l'hôte et au premier redéploiement. Son usage légitime s'arrête au fichier d'échange et aux fichiers temporaires d'un moteur de base de données.

Le disque système éphémère joue sur le même principe, appliqué au système entier : le disque vit sur l'hôte, ne coûte rien en stockage, et se réinitialise en quelques secondes. C'est le bon choix pour un nœud sans état qui se reconstruit depuis une image, et le mauvais choix pour tout le reste.

Le plafond que personne ne regarde

Chaque taille de machine impose son propre plafond d'entrées-sorties et de débit, ainsi qu'un nombre maximal de disques attachables. La somme des performances des disques ne franchit jamais ce plafond.

Attacher un disque très rapide à une petite machine ne donne donc pas un système rapide, il donne une facture de disque rapide et la performance de la machine. Le dimensionnement se fait sur le couple, jamais sur un seul des deux.

Le cache et le chiffrement

La mise en cache hôte se règle par disque et modifie sensiblement le comportement. ReadOnly accélère une charge dominée par la lecture, un fichier de données par exemple. None s'impose sur un disque dominé par l'écriture séquentielle, un journal de transactions typiquement. ReadWrite est la valeur par défaut du disque système et se justifie rarement ailleurs.

# un disque de données SSD Premium, avec cache en lecture seule
az vm disk attach \
  --resource-group rg-app-prod \
  --vm-name vm-app-01 \
  --name disk-app-data-01 \
  --new --size-gb 512 --sku Premium_LRS \
  --caching ReadOnly

Le chiffrement au repos par des clés gérées par la plateforme est actif par défaut et ne se désactive pas. Au-dessus, trois options se cumulent selon l'exigence : des clés gérées par le client via un ensemble de chiffrement de disque adossé à un coffre, le chiffrement sur l'hôte qui couvre aussi le disque temporaire et le cache, et le chiffrement dans le système invité pour les cas qui l'imposent.

Une réservation ou un plan d'économies porte sur le calcul. Le disque continue de se facturer à plein tarif, y compris quand la machine est éteinte et libérée. La première économie sur une machine inutilisée est donc de supprimer ses disques, pas de l'arrêter.

Les paliers de performance et leurs limites exactes figurent dans la documentation des types de disques managés.

Les images

Le constructeur livre le portique avec une configuration standard. L'exploitant y ajoute son marquage, ses capteurs, son paramétrage de sécurité, et il archive cette configuration pour que le portique du quai suivant soit strictement identique.

Une image de machine virtuelle est cette configuration archivée. Trois formes coexistent sur Azure, et le passage de l'une à l'autre marque la maturité d'une équipe.

La place de marché fournit les images de base, publiées par Microsoft, par les éditeurs de distributions ou par des tiers. Elles se référencent par éditeur, offre, référence et version.

Le mot latest y est piégeux. Il rend le déploiement non reproductible : deux exécutions du même modèle à quinze jours d'intervalle produisent deux machines différentes. En production, on fige la version.

L'image personnalisée est la capture d'une machine préparée à la main. Elle vit dans une seule région, ne porte pas de versions et ne se réplique pas. Elle dépanne, elle ne se conçoit pas.

La galerie de calcul Azure est la réponse sérieuse. On y déclare une définition d'image, puis des versions numérotées de cette définition. Chaque version se réplique vers les régions choisies, avec un nombre de réplicas ajustable par région, ce qui décide combien de machines peuvent être créées en parallèle sans que le déploiement s'étrangle. La galerie se partage entre abonnements, ce qui permet à une équipe socle de fournir des images à toutes les autres.

# retrouver la référence exacte d'une image de la place de marché
az vm image list --publisher Canonical --all --output table

# déployer depuis une version figée de la galerie
az vm create \
  --resource-group rg-app-prod \
  --name vm-app-01 \
  --size Standard_D4ds_v5 \
  --image "/subscriptions/<id>/resourceGroups/rg-images/providers/Microsoft.Compute/galleries/galApp/images/app-base-ubuntu/versions/1.4.0"

Restent deux détails techniques qui changent la donne. Une image destinée à produire plusieurs machines doit être généralisée, avec sysprep sous Windows et la déprovision de l'agent sous Linux, faute de quoi les identifiants machine seront dupliqués. Et la génération de machine virtuelle retenue conditionne l'accès aux fonctions de démarrage sécurisé, qui reposent sur un microprogramme UEFI.

Une image versionnée transforme la réparation. On ne corrige plus une machine malade, on la remplace par une instance neuve construite depuis une version connue. C'est ce qui rend la mise à l'échelle horizontale de la section suivante réellement praticable.

Windows et Linux

Deux constructeurs de portiques, deux contrats de pièces détachées, un même quai. Le geste d'exploitation est identique, la facture et l'outillage ne le sont pas.

Windows Server Linux
Licence Incluse dans le tarif horaire, ou apportée via l'avantage hybride Azure Gratuite selon la distribution, ou tarif éditeur inclus pour les distributions commerciales
Accès distant Bureau à distance SSH
Configuration au démarrage Extension de script personnalisé, configuration d'état souhaité cloud-init sur les images qui le prennent en charge, extension de script personnalisé
Agent invité Service d'agent de machine virtuelle Azure Agent waagent
Disque temporaire Lecteur D: Monté sur /mnt
Correctifs Azure Update Manager, application automatique des correctifs invités Azure Update Manager, selon les distributions prises en charge

L'avantage hybride Azure est le levier le plus rentable et le plus souvent oublié. Il permet de réutiliser des licences Windows Server et SQL Server déjà détenues, ainsi que des abonnements Red Hat Enterprise Linux et SUSE Linux Enterprise Server, en ne payant plus que la partie calcul. Sur un parc Windows conséquent, l'écart se chiffre en dizaines de pour cent.

Une machine arrêtée depuis le système invité continue de facturer. Une machine arrêtée et libérée ne facture ni le calcul ni la licence embarquée, mais continue de facturer ses disques et ses adresses IP réservées. La nuance n'est pas cosmétique : c'est elle qui décide de l'efficacité d'une planification d'extinction sur les environnements hors production.

Sur les correctifs, la question n'est pas l'outil mais la stratégie. Soit on applique les correctifs sur des machines vivantes, et il faut un mécanisme d'orchestration, des fenêtres de maintenance et un ordre de passage. Soit on reconstruit depuis une image corrigée, et il faut que l'application supporte le remplacement d'une instance à chaud. Les deux se défendent, le mélange non assumé des deux se paie.

Ce qui diffère vraiment entre Windows et Linux sur Azure tient à la licence, à l'outillage de configuration et au protocole d'accès. Les tailles, les disques et la mise à l'échelle sont identiques.

Détail d'exploitation qui n'en est pas un : ni le port du bureau à distance ni le port SSH n'ont vocation à être ouverts sur Internet. Un hôte Bastion ou un accès autorisé à la demande fait le même travail sans exposer la surface.

Mettre à l'échelle

Quand le trafic double sur un quai, l'exploitant a deux options. Remplacer le portique par un modèle plus puissant, opération lourde qui immobilise le quai. Ou en installer un second à côté, et répartir les navires entre les deux.

La verticale et l'horizontale, exactement.

La verticale

Changer la taille d'une machine est simple, immédiat dans le principe, et limité par trois choses. L'opération impose un redémarrage, donc une interruption. La taille visée doit être disponible sur le matériel qui héberge la machine, sinon il faut la libérer d'abord. Et il existe une taille maximale, au-delà de laquelle il n'y a plus rien.

La verticale reste le bon geste pour une base de données monolithique ou un logiciel tiers qui ne sait pas fonctionner en plusieurs exemplaires. Elle ne règle jamais la disponibilité : une machine plus grosse reste une machine unique.

L'horizontale

Le groupe de machines virtuelles identiques crée et détruit des instances à partir d'un modèle commun. Deux modes d'orchestration existent, et ils ne se ressemblent que de loin.

Orchestration uniforme Orchestration flexible
Nature de l'instance Une instance du groupe, pas une ressource machine virtuelle ordinaire Une ressource machine virtuelle standard
Hétérogénéité Non, un modèle unique pour tout le groupe Oui, tailles et images peuvent être mélangées
Domaines d'erreur Gérés par le groupe Déclarés explicitement à la création
Outillage applicable Les opérations propres au groupe Tout ce qui s'applique à une machine virtuelle
Positionnement Les conceptions déjà en place Les nouvelles conceptions

Le groupe s'inscrit dans le pool arrière d'un répartiteur, et c'est la sonde de santé qui décide de ce qui reçoit du trafic. Ajouter une instance ne sert à rien si la sonde n'attend pas qu'elle soit réellement prête.

Deux mécanismes complètent l'ensemble et se configurent le premier jour. L'extension d'intégrité applicative, qui remonte l'état réel de l'application plutôt que celui du système. Et la réparation automatique des instances, qui remplace une instance déclarée en mauvaise santé sans intervention humaine.

Les règles de mise à l'échelle automatique

Le moteur de mise à l'échelle automatique évalue une métrique agrégée sur une fenêtre de temps, la compare à un seuil et déclenche une action. Il faut toujours deux règles, une pour ajouter et une pour retirer, sinon le groupe monte et ne redescend jamais.

sequenceDiagram participant AM as Azure Monitor participant R as Règle automatique participant G as Groupe identique participant LB as Répartiteur AM->>R: moyenne processeur sur 10 minutes R->>R: seuil franchi et action déclenchée R->>G: ajouter 2 instances G->>G: provisionnement depuis la version de référence G->>LB: inscription dans le pool arrière LB->>G: sonde de santé G-->>LB: instance prête à recevoir du trafic Note over R: période de refroidissement avant toute nouvelle action

Le réglage des seuils se calcule, il ne se devine pas. Posons le cas classique du battement.

Règle de sortie : ajouter une instance quand la moyenne du processeur dépasse 70 % sur dix minutes. Règle d'entrée : en retirer une quand elle passe sous 60 %. Le groupe tourne à trois instances, moyenne stabilisée à 60 %.

La charge totale vaut 3 × 60 = 180 points. Le retrait déclenché, les deux instances restantes se partagent la même charge : 180 / 2 = 90 %. On dépasse aussitôt le seuil de sortie, une instance est rajoutée, et le cycle recommence indéfiniment.

La condition à respecter s'écrit simplement : le seuil d'entrée multiplié par N / (N − 1) doit rester sous le seuil de sortie. À trois instances et 70 % en sortie, cela impose un seuil d'entrée inférieur à 70 × 2 / 3 ≈ 46 %. On règle donc la réduction à 40 %, et le battement disparaît.

# le paramétrage de mise à l'échelle sur un groupe identique
az monitor autoscale create \
  --resource-group rg-app-prod \
  --resource vmss-app-prod \
  --resource-type Microsoft.Compute/virtualMachineScaleSets \
  --name autoscale-app-prod \
  --min-count 2 --max-count 10 --count 3

# sortie : deux instances de plus au-dessus de 70 % sur 10 minutes
az monitor autoscale rule create \
  --resource-group rg-app-prod \
  --autoscale-name autoscale-app-prod \
  --condition "Percentage CPU > 70 avg 10m" \
  --scale out 2

# entrée : une instance de moins sous 40 %, seuil calculé pour éviter le battement
az monitor autoscale rule create \
  --resource-group rg-app-prod \
  --autoscale-name autoscale-app-prod \
  --condition "Percentage CPU < 40 avg 10m" \
  --scale in 1

La période de refroidissement ne corrige pas un mauvais seuil, elle ralentit seulement le battement. Et le choix de la métrique compte autant que le seuil : sur une charge pilotée par une file d'attente, le nombre de messages en attente par instance est un bien meilleur signal que le processeur, qui reste bas pendant que le retard s'accumule.

Le placement se décide au même moment, sur deux points. La répartition du groupe sur plusieurs zones de disponibilité, qui protège d'une panne d'infrastructure locale. Et l'usage d'instances à prix réduit et interruptibles pour les charges qui tolèrent une éviction, avec une politique d'éviction choisie explicitement.

La mise à l'échelle automatique ne rattrape pas une application qui ne supporte pas d'avoir plusieurs exemplaires. L'état en mémoire, le fichier écrit en local et la tâche planifiée qui doit tourner une seule fois cassent avant le premier passage à deux instances.

Les modes d'orchestration et la syntaxe complète des règles sont détaillés dans la documentation des groupes de machines virtuelles identiques et dans celle de la mise à l'échelle automatique d'Azure Monitor.

Scénario B : Windows Azure, le 29 février 2012

Un parc de portiques identiques a une qualité rare : la pièce de rechange va sur n'importe lequel, et la procédure est la même partout. Il a aussi un défaut qui ne se voit qu'une fois : si le lot sort d'usine avec la même faiblesse, elle se déclare partout au même instant.

C'est exactement ce qui est arrivé à Windows Azure le 29 février 2012, et Microsoft l'a documenté publiquement dans un rapport signé Bill Laing, Summary of Windows Azure Service Disruption on Feb 29th, 2012.

Le mécanisme de départ tient en une ligne de calcul de date. Au démarrage d'une machine virtuelle, l'agent invité génère un certificat de transfert destiné à sécuriser sa communication avec l'agent de l'hôte. La date de fin de validité de ce certificat était calculée en ajoutant un an à la date du jour.

Le 29 février 2012, cette opération produisait le 29 février 2013. Cette date n'existe pas. La création du certificat échouait, et l'agent invité n'arrivait jamais à s'initialiser.

La suite est un enchaînement de mécanismes de protection qui se sont retournés. L'agent de l'hôte attend l'agent invité pendant vingt-cinq minutes ; passé ce délai, il réinitialise le système de la machine et la redémarre. Après trois délais dépassés d'affilée sur une machine vierge, la plateforme conclut à un défaut matériel, marque le serveur pour investigation humaine et redéploie ailleurs les machines qu'il portait. Où le même calcul de date échouait de la même façon.

Le nombre de serveurs marqués a franchi le seuil au-delà duquel la gestion de grappe suspend les opérations de gestion de service, précisément pour éviter d'aggraver une situation qu'elle ne comprend pas. Les clients concernés ne pouvaient plus déployer ni modifier leurs services.

Le second temps de l'incident est le plus instructif. Sept grappes avaient commencé une montée de version de l'agent d'hôte quand le défaut les a frappées, et se trouvaient donc à moitié à jour. Pour les réparer, Microsoft a choisi de les ramener à l'agent d'hôte antérieur en n'emportant que l'agent invité corrigé. Le paquet ainsi fabriqué autour de l'ancien agent d'hôte embarquait le composant réseau écrit pour le nouveau, et les deux étaient incompatibles. Le test préalable, mené sur un seul serveur, n'avait pas vérifié la connectivité. Toutes les machines virtuelles de ces sept grappes, y compris celles qui allaient bien, ont perdu le réseau : une panne ajoutée à la réparation d'une panne.

Le rétablissement complet s'est étalé sur la journée suivante. Microsoft a annoncé dans le même rapport un crédit de 33 % accordé à tous les clients des services concernés pour le mois de facturation touché, indépendamment de l'impact réellement subi.

Un parc de machines virtuelles construit depuis une image unique porte la même faiblesse sur toutes ses instances, au même instant. La redondance ne protège de rien face à un défaut partagé, et le mécanisme de reprise automatique peut le propager plus vite qu'un humain ne l'aurait fait.

Trois conséquences directes pour la conception d'un parc. L'image et sa version sont un point de défaillance commun, ce qui justifie de déployer une nouvelle version par vagues plutôt que partout. La réparation automatique doit avoir une limite, un compteur, un frein. Et le mécanisme de correction se teste sur la population réelle, y compris sur les machines qui ne sont pas exactement à la version attendue.

Points clés

  • Une taille est un ratio, pas un nombre de cœurs. La famille fixe le rapport entre processeur et mémoire ; les lettres de la désignation portent le reste. Les tailles à processeurs virtuels contraints réduisent la facture de licence sans sacrifier la mémoire.
  • Le plafond d'entrées-sorties appartient à la machine, pas au disque. Un disque rapide sur une petite taille donne une facture rapide et la performance de la taille. Le disque temporaire n'est pas du stockage durable, et le disque continue de se facturer quand la machine est libérée.
  • Une image versionnée dans une galerie change la nature de la réparation. On remplace une instance par une version connue au lieu de soigner une machine malade, ce qui rend la mise à l'échelle horizontale praticable.
  • Les seuils de mise à l'échelle automatique se calculent. À trois instances et 70 % en sortie, un seuil d'entrée doit rester sous 70 × 2 / 3 ≈ 46 %, sinon le groupe entre en battement permanent.
  • Un parc identique partage ses défauts. Le 29 février 2012 l'a montré : même image, même agent, même erreur au même instant, et un mécanisme de reprise qui propage au lieu de contenir.

Dans la série

Palier 2 : Construire les terminaux. Domaine : Calcul.

Pour aller plus loin