Le second poste d'amarrage

Le quai loué au port n'a qu'un poste d'amarrage. Un portique, une voie de sortie, une armoire électrique. Tant que tout fonctionne, c'est le montage le moins cher et le plus simple à exploiter.

Le jour où l'armoire grille, le navire attend au large. Pas dix minutes : le temps qu'un technicien arrive, diagnostique, remplace. Pendant ce temps, la cargaison reste à bord et les pénalités courent.

L'exploitant propose deux réponses, à deux prix. Un second poste d'amarrage dans un autre bassin du même port, avec sa propre alimentation et son propre accès routier. Ou un accord avec le port jumeau, à cinquante kilomètres, capable de recevoir le navire si tout le port s'arrête.

Azure vend exactement ces deux réponses, plus une troisième, plus fine, à l'intérieur du quai lui-même. Ce billet les prend dans l'ordre, après avoir posé l'arithmétique qui dit de laquelle tu as réellement besoin.

La haute disponibilité ne se décide pas ressource par ressource. Elle se calcule sur la chaîne entière, sinon on paie de la redondance là où elle ne change rien au résultat.

Disponibilité, RTO et RPO

Le contrat de concession du quai ne promet pas que rien n'arrivera jamais. Il annonce un taux d'ouverture annuel, un délai d'intervention, et ce qu'on accepte de perdre de la cargaison en cours de manutention. Trois engagements distincts, sur trois sujets distincts.

Côté informatique, ce sont les trois nombres que tout le monde mélange.

Nombre La question à laquelle il répond Qui le décide Ce qui le fixe techniquement
Disponibilité quelle part du temps le service répond le fournisseur pour ses briques, toi pour l'assemblage l'architecture de l'ensemble
RTO combien de temps on accepte d'être arrêté le métier le mécanisme de bascule
RPO combien de données on accepte de perdre le métier le mode de réplication

Les confondre coûte de l'argent dans les deux sens. Exiger un RPO nul sur toutes les données impose une réplication synchrone partout, donc une latence d'écriture plancher et une facture qui suit. À l'inverse, accepter un RTO de quatre heures sur un service de paiement revient à écrire noir sur blanc qu'on renonce à une demi-journée de chiffre d'affaires.

Un dernier point, souvent passé sous silence. L'engagement de service du fournisseur, son SLA, est un contrat commercial assorti d'un crédit sur la facture. Ce crédit ne rachète pas la journée d'arrêt, il rembourse une fraction de ce que tu as payé pendant qu'elle durait.

Le SLA du fournisseur indemnise, il ne répare pas. RTO et RPO sont des décisions métier : tant que personne ne les a écrites, l'équipe technique les choisit à sa place, sans le savoir.

L'arithmétique du SLA

Le taux d'ouverture affiché par le port ne dit rien en pourcentage. Converti en heures de fermeture par an, il devient discutable, donc utile.

Engagement Indisponibilité par an Par mois Ce que ça impose côté conception
99 % 3,65 jours 7,3 heures une astreinte et une reprise manuelle
99,9 % 8,76 heures 43,8 minutes de la redondance dans la région, une bascule outillée
99,95 % 4,38 heures 21,9 minutes plusieurs zones, des sondes qui testent vraiment
99,99 % 52,6 minutes 4,4 minutes une bascule automatique, aucun humain dans le chemin
99,999 % 5,26 minutes 26 secondes plusieurs sites actifs en permanence

Regarde la dernière ligne. Vingt-six secondes par mois, c'est moins que le temps de lire une alerte sur un téléphone. À ce niveau, la moindre intervention humaine consomme à elle seule le budget de l'année.

Vient ensuite le calcul que personne ne fait avant la mise en production. Une application n'est pas un composant, c'est une chaîne de composants en série, et les disponibilités se multiplient.

Chaîne en série, valeurs prises pour l'exemple :

  passerelle applicative   99,95 %
  hébergement applicatif   99,95 %
  base de données          99,99 %
  compte de stockage       99,90 %

0,9995 x 0,9995 x 0,9999 x 0,999 = 0,997 90
soit 99,79 %

Indisponibilité = 0,21 % de 525 600 min = 1 103 min = 18,4 h par an

Quatre briques irréprochables produisent une application à deux neufs et demi, soit près de dix-neuf heures d'arrêt annuel. Aucune des quatre n'a failli à son engagement.

Le raccourci mental tient en une ligne et suffit largement en réunion.

Sur des composants très disponibles, les indisponibilités s'additionnent.

0,05 + 0,05 + 0,01 + 0,10 = 0,21 %

La redondance joue dans l'autre sens. Deux exemplaires en parallèle ne tombent ensemble que si les deux tombent.

Deux instances en parallèle, 99,9 % chacune, pannes indépendantes :
indisponibilité combinée = 0,001 x 0,001 = 0,000 001   soit 99,9999 %

Ce résultat repose sur une hypothèse qu'il faut regarder en face : les pannes sont indépendantes. Deux machines identiques, dans la même baie, avec la même image et la même configuration, ne sont pas deux chances indépendantes. C'est un exemplaire recopié deux fois. Rendre les pannes indépendantes, c'est précisément le rôle des trois échelles qui suivent.

Sur une chaîne en série, le composant le plus faible fixe le résultat. C'est lui qu'on redonde en premier, pas celui qui est le plus facile à redonder.

Les trois échelles de redondance

Le port double ses moyens à trois échelles différentes. Deux portiques sur le même quai, un second bassin avec sa propre alimentation, le port jumeau à cinquante kilomètres. Trois protections qui ne couvrent pas les mêmes sinistres et ne se paient pas au même prix.

flowchart LR P1["Panne d'un serveur
ou d'une baie"] --> E1["Domaines d'erreur
et de mise à jour"] P2["Perte d'un centre
de données"] --> E2["Zones de disponibilité"] P3["Perte de la région
entière"] --> E3["Seconde région"] E1 --> S["Service rendu"] E2 --> S E3 --> S E1 -.-> L1["Ne couvre pas
la perte du site"] E2 -.-> L2["Ne couvre pas
la perte de la région"] E3 -.-> L3["Ne couvre pas
une erreur répliquée"] classDef panne fill:#a0413e,stroke:#8a4d16,color:#f5f2ec; classDef echelle fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef limite fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef sortie fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; class P1,P2,P3 panne; class E1,E2,E3 echelle; class L1,L2,L3 limite; class S sortie;

Domaines d'erreur et de mise à jour

Un domaine d'erreur regroupe le matériel qui partage une alimentation et un équipement réseau, en pratique une baie. Un domaine de mise à jour regroupe les machines redémarrées ensemble lors d'une maintenance planifiée de la plateforme.

Placer des machines virtuelles dans un groupe à haute disponibilité demande à Azure de les répartir sur plusieurs domaines des deux types. Un groupe de machines virtuelles identiques fait la même chose sans qu'on ait à le demander.

Cette échelle protège d'une panne matérielle locale et d'un redémarrage de maintenance. Elle ne protège de rien à l'échelle du bâtiment.

Zones de disponibilité

Une zone de disponibilité est un ou plusieurs centres de données physiquement séparés dans la même région, avec alimentation, refroidissement et réseau indépendants. Les régions qui les prennent en charge en comptent au moins trois, reliées entre elles par un réseau à faible latence.

La distinction qui compte au moment de déployer : une ressource zonale est épinglée à une zone que tu choisis, et la répartition est à ta charge ; une ressource redondante inter-zones est répartie par le service lui-même.

La latence entre zones d'une même région reste assez basse pour envisager une réplication synchrone, ce qui n'est pas le cas entre régions. C'est cette propriété qui fait des zones l'échelle la plus intéressante en rapport protection sur complexité.

Paires de régions

Une région est un ensemble de centres de données dans un périmètre de latence donné. Azure associe la plupart de ses régions par paires, situées dans la même zone géographique à quelques exceptions documentées près.

Ce qu'une paire apporte concrètement : les mises à jour de plateforme sont appliquées séquentiellement plutôt que simultanément sur les deux régions, certaines fonctionnalités de réplication géographique visent la région appairée par défaut, et en cas de sinistre large, le rétablissement est priorisé de façon à ce qu'une région de chaque paire redevienne disponible.

Attention au raccourci : toutes les régions ne sont pas appairées, et le choix d'une seconde région n'est pas obligatoirement celui de la région appairée. La contrainte de résidence des données tranche souvent avant la contrainte technique.

Échelle Contre quoi elle protège Ce qu'elle ne couvre pas Surcoût
Domaines d'erreur et de mise à jour panne matérielle locale, maintenance planifiée perte du centre de données nul
Zones de disponibilité perte d'un centre de données de la région perte de la région, erreur de configuration propagée modéré, trafic inter-zones et instances supplémentaires
Seconde région perte de la région entière erreur ou suppression répliquée vers la copie élevé, capacité et exploitation en double
Chaque échelle protège d'une classe de panne, et d'une seule. Passer à la suivante coûte plus cher que la précédente et ne dispense jamais d'elle.

Ce qui est redondé entre zones, et ce qui ne l'est pas

L'exploitant du port ne double pas tout de la même manière. Certains équipements sont redondés d'office et facturés dans les droits de quai. D'autres se commandent au moment de la concession, et pas après. D'autres n'existent qu'en un exemplaire, à toi de louer le second.

Le catalogue Azure se lit exactement comme ça, et c'est la deuxième famille qui piège tout le monde.

Catégorie Ce que ça veut dire Le piège
Acquise le service répartit lui-même ses instances sur les zones de la région supposer que c'est vrai pour tout le catalogue
À demander la redondance de zone est une option, souvent posée à la création la recette est montée sans, puis recopiée telle quelle en production
Inexistante la ressource appartient à une zone, la répartition est à ta charge machine, disque et adresse restent dans la zone tombée

Concrètement, voici où se joue la décision selon la famille de ressource.

Famille de ressource Où se joue la redondance de zone
Machines virtuelles zone choisie à la création, ou groupe identique réparti sur plusieurs zones
Disques managés zonaux par nature, avec des types à redondance de zone selon les régions
Comptes de stockage mode de redondance choisi à la création du compte
Bases managées option de redondance de zone, selon le niveau de service retenu
Hébergement applicatif option de redondance de zone, avec un nombre minimal d'instances
Entrée réseau régionale niveau de service standard requis pour une adresse et un répartiteur répartis
Routage mondial pas de notion de zone, ces services sont répartis par construction

Le cas des disques mérite une ligne à lui. Un disque managé zonal ne s'attache qu'à une machine virtuelle de la même zone : recréer la machine ailleurs ne suffit pas, il faut aussi que la donnée existe ailleurs. Certains types de disques proposent une redondance de zone qui lève cette contrainte, dans les régions où elle est disponible.

Deux vérifications valent la peine avant de figer un plan de déploiement. La région cible propose-t-elle bien des zones, et la taille de machine visée est-elle disponible dans celles que tu veux utiliser ?

# Régions prenant en charge les zones de disponibilité
az account list-locations --query "[?availabilityZoneMappings != null].name" --output table

# Tailles de machine disponibles en zones dans une région donnée
az vm list-skus --location westeurope --zone --output table

Plusieurs de ces options se posent à la création et se changent mal ensuite, quand elles se changent. C'est le genre de détail qui transforme une amélioration de fiabilité en projet de migration.

Pour chaque ressource du schéma, une seule question : cette redondance est-elle acquise, à demander, ou inexistante ? Les trois réponses existent dans le même déploiement.

Une région ou deux

Le port jumeau à cinquante kilomètres se loue de trois façons. Un quai vide dont on possède le plan. Un quai équipé, avec une équipe réduite qui tourne au ralenti. Un quai qui travaille tous les jours et prend sa part du trafic.

Ces postures ont des noms différents côté informatique, et surtout des RTO qui n'ont rien à voir. Le tableau y ajoute le point de départ, la sauvegarde seule, qui ne prépare aucune bascule.

Posture RTO typique RPO typique Ce qui tourne côté secondaire Coût
Sauvegarde seule jours la fréquence de sauvegarde rien faible
Veille froide heures le retard de réplication l'infrastructure décrite en code, rien d'allumé faible
Veille tiède dizaines de minutes minutes une pile réduite, prête à monter en charge moyen
Actif et actif minutes ou moins proche de zéro sur ce qui est répliqué en continu la totalité élevé

Quatre sujets décident du choix, et aucun n'est technique en premier lieu.

L'état à répliquer. Les bases de données viennent en tête, mais l'inventaire réel est plus long : les fichiers déposés par les utilisateurs, les secrets, les images de conteneurs, la configuration applicative et les certificats. Tout ce qui n'est pas répliqué est à recréer à la main pendant l'incident.

La bascule du trafic. Un service de routage mondial, en tête de chaîne, envoie les requêtes vers la région qui répond. La bascule du trafic ne bascule pas les données pour autant : envoyer les écritures vers la région de repli alors que la base primaire est encore ailleurs donne au mieux une latence multipliée, au pire un refus d'écriture.

La cohérence des données. La réplication entre régions est asynchrone dans l'immense majorité des cas, physique de la distance oblige. Il faut donc décider à l'avance ce qu'on fait des écritures acquittées dans la région perdue et jamais arrivées dans l'autre, puis comment on revient quand la région primaire réapparaît.

Le coût réel. Ce n'est pas la capacité qui fait mal, c'est le fait de maintenir deux fois la même chose au même niveau : deux jeux de règles réseau, deux versions déployées, deux configurations qui divergent lentement. Et un point rarement anticipé : déclarer une région secondaire ne réserve aucune capacité. Le jour d'une panne régionale, ta demande de capacité arrive en même temps que celle de tous les autres locataires.

flowchart LR C["Client"] --> R["Routage mondial
Front Door ou Traffic Manager"] R --> A["Région primaire
pile complète"] R -.->|bascule| B["Région secondaire"] A --> DA["Données primaires"] DA -.->|réplication| DB["Copie secondaire"] B --> DB ID["Identité, DNS, coffre,
registre d'images"] --> A ID --> B classDef client fill:#f5f2ec,stroke:#8a4d16,color:#1a1a1a; classDef actif fill:#b5651d,stroke:#8a4d16,color:#f5f2ec; classDef repli fill:#d89253,stroke:#8a4d16,color:#2c3338; classDef socle fill:#2c3338,stroke:#8a4d16,color:#f5f2ec; class C client; class R,A,DA actif; class B,DB repli; class ID socle;

Le choix des services de routage et de leurs sondes est traité dans Répartition de charge et sécurité réseau, et c'est là que se joue la moitié du RTO.

La seconde région ne double pas la facture, elle double la surface d'exploitation. Une veille tiède réellement entretenue vaut mieux qu'un actif et actif dont la moitié dérive depuis six mois.

Les dépendances qu'on oublie

Le second bassin a ses grues, son alimentation et sa voie d'accès. Mais le poste de douane, le registre des scellés et le lecteur de badges sont restés dans le premier. Le jour de la bascule, les navires arrivent et le personnel n'entre pas.

C'est la panne de bascule la plus fréquente, et elle ne se voit sur aucun schéma d'architecture, parce que ces briques sont dessinées à côté du cadre.

Dépendance Symptôme le jour de la bascule Parade
Identité et annuaire l'application démarre et n'authentifie personne vérifier que le chemin d'authentification ne traverse aucune ressource de la région perdue
Résolution de noms le trafic bascule, les noms internes pointent toujours vers la région morte zones privées liées aux deux réseaux, durées de vie courtes sur les enregistrements de bascule
Registre d'images aucun conteneur ne démarre dans la région de repli géoréplication du registre, ou second registre alimenté par la chaîne de livraison
Coffre de secrets l'application démarre sans configuration coffre joignable depuis les deux régions, avec le point de terminaison privé et la zone DNS qui vont avec
Chaîne de livraison impossible de redéployer pendant l'incident agents et artefacts hébergés hors du périmètre protégé
Supervision on bascule sans rien voir espace de travail hors de la région protégée, ou dupliqué

La méthode pour les trouver est simple et ingrate. Tu prends le démarrage à froid de l'application, étape par étape, et à chaque appel sortant tu demandes où vit la ressource contactée. Les surprises arrivent vite, en général au troisième appel.

Le coffre de secrets et les points de terminaison privés font l'objet du billet Sécuriser ses applications : Key Vault, identités managées, chiffrement ; leur régionalité est exactement ce qui les rend structurants ici.

Une architecture multi-région se juge sur son démarrage à froid, pas sur son schéma. Tout ce qui n'est pas joignable depuis la région de repli est un point de défaillance unique déguisé.

Éprouver la bascule

Les ports organisent des exercices de déroutement. Pas une réunion, pas une note de service : un navire réellement envoyé vers l'autre bassin, avec chronomètre.

Trois niveaux d'exercice existent, et ils sont cumulables. Le test de basculement sans interruption, qui monte la pile de repli dans un réseau isolé pendant que la production continue. La bascule contrôlée, annoncée, jouée en production dans une fenêtre choisie. Et l'injection de fautes, avec Azure Chaos Studio, qui permet d'arrêter des instances ou de dégrader le réseau sur un périmètre et une durée bornés.

Le retour arrière est la partie qu'on saute, et c'est la plus risquée. La région primaire réapparaît avec des données figées à l'instant de la panne, et les réinjecter aveuglément écrase ce que la région de repli a écrit depuis.

Une cadence réaliste vaut mieux qu'une cadence ambitieuse jamais tenue : un exercice par trimestre sur le périmètre critique, et un compte rendu qui liste ce qui a manqué. La sauvegarde, qui répond à d'autres pannes que celles traitées ici, est le sujet du billet suivant.

Une bascule jamais jouée n'est pas une bascule, c'est une intention documentée. Le seul chiffre de RTO qui vaille est celui qu'un chronomètre a mesuré.

Scénario B : la région South Central US, 4 septembre 2018

Le 4 septembre 2018, de violents orages frappent le sud du Texas, à proximité des centres de données de la région Azure South Central US. L'analyse des causes racines publiée ensuite par Microsoft dans l'historique des états de service Azure décrit un enchaînement mécanique.

Les perturbations électriques sur le réseau d'alimentation provoquent des variations de tension. Une partie d'un centre de données bascule sur ses groupes électrogènes, mais les mêmes variations arrêtent les systèmes de refroidissement mécaniques, malgré les protections en place.

Le bâtiment tient d'abord grâce à la réserve thermique prévue dans la conception du refroidissement. Une fois cette réserve épuisée, la température dépasse les seuils de sécurité et un arrêt automatique des équipements se déclenche pour préserver le matériel et l'intégrité des données. Dans certaines parties du bâtiment, la température monte assez vite pour que du matériel soit endommagé avant d'avoir pu s'arrêter proprement, en particulier des serveurs de stockage.

La remise en service s'étale sur une durée très longue à l'échelle d'un incident cloud, parce qu'il faut d'abord rétablir le refroidissement, puis évaluer le matériel équipement par équipement, puis récupérer les données présentes sur les serveurs endommagés.

Le détail qui intéresse directement ce billet est ailleurs dans le rapport. L'impact déborde très largement le périmètre physique touché, parce que des services de gestion présentés comme mondiaux s'appuyaient sur des composants hébergés dans cette seule région. Des clients sans aucune ressource déployée dans South Central US se retrouvent gênés dans leurs opérations de gestion.

Trois enseignements, transposables tels quels.

Une redondance à l'intérieur d'un bâtiment ne protège pas de la perte de ce bâtiment, et une réserve thermique se compte en minutes, pas en heures. Un incident physique produit des durées de rétablissement sans commune mesure avec un incident logiciel : on ne redémarre pas un serveur dont l'électronique a fondu. Et surtout, une étiquette « mondial » sur un service ne dit rien de l'endroit où vivent ses dépendances.

La question à poser sur chaque brique de ton architecture n'est pas « ce service est-il redondé », mais « où vivent les composants dont il dépend pour démarrer ». La réponse est souvent une seule région.

Points clés

  • La disponibilité d'une application est le produit de celles de ses composants : quatre briques entre 99,9 % et 99,99 % donnent environ 99,79 %, soit plus de dix-huit heures d'arrêt par an.
  • Trois échelles de redondance, trois classes de panne : domaines d'erreur pour le matériel local, zones pour la perte d'un centre de données, seconde région pour la perte de la région.
  • La redondance de zone est acquise pour certains services, à demander pour beaucoup d'autres, et inexistante pour les ressources zonales. Ces choix se posent souvent à la création.
  • Le coût d'une seconde région n'est pas la capacité, c'est l'exploitation en double et la dérive de configuration entre les deux.
  • Ce qui casse une bascule, ce sont les dépendances hors cadre : identité, résolution de noms, registre d'images, coffre de secrets, chaîne de livraison, supervision.

Dans la série

Palier 3 : Faire tourner le port. Domaine : Continuité.

Pour aller plus loin