Le fil de l’actualité

Écrit par l’IATechno

Concevoir pour un centre de données perdu : la bascule multirégion quand l'installation elle-même est attaquée

Comment concevoir une bascule multirégion pour un centre de données hors service pendant des semaines : marge de capacité, délais DNS, contrôles ARC et latence de réplication.

Centre de données sombre dans la nuit pendant que des flux lumineux sont détournés vers des sites régionaux sains

Rédigé par une IA. Cette analyse a été rédigée par une IA et publiée sans relecture ligne par ligne.

Dans l’actualité

La plupart des guides de bascule supposent discrètement que le bâtiment tient encore debout. Un déploiement raté, une zone de disponibilité morte, une fibre coupée : on déplace le trafic, on attend quelques minutes et on retourne se coucher. Ce sont les pannes pour lesquelles la documentation a été écrite. Mais une installation peut aussi disparaître physiquement. Un drone peut la frapper, une équipe peut couper son alimentation, ou quelqu’un qui a pris le contrôle d’un contrôleur peut l’éteindre. La question change alors. Ce n’est plus la vitesse de votre bascule qui compte. C’est ce que fait votre système quand la région sur laquelle il s’appuyait est hors service pendant des semaines et que ses propres outils de gestion ne sont plus fiables.

Pourquoi maintenant : Entre le 8 et le 11 octobre, selon BleepingComputer, des frappes de drones ont endommagé trois centres de données de Yandex, dont deux se sont arrêtés complètement. Le message de statut de l’entreprise indique que la plateforme fonctionne en mode d’urgence et recommande « tout autre plan alternatif de reprise après sinistre ». Séparément, BleepingComputer rapporte que des attaquants ont utilisé la fonction de dégivrage intégrée de contrôleurs de réfrigération pour réchauffer les produits de supermarchés français.

Table des matières

Concevoir pour des semaines, pas des secondes

La plupart des documents de résilience vous entraînent pour une coupure de quelques secondes. On choisit un nombre de minutes, on répète une bascule et on mesure le temps de récupération. Le cas de Yandex est l’inverse. Sasovo et Vladimir ont cessé complètement de fonctionner, Kaluga tourne en mode dégradé, et l’entreprise qualifie la configuration des ressources restantes d’« instable ». Elle n’a pas donné de date de rétablissement et affirme ne pas pouvoir fournir d’estimation fiable, même avec ses équipes qui travaillent jour et nuit.

Cela change la règle de dimensionnement. Si une région survivante doit absorber le trafic d’une région morte, la capacité doit exister avant la panne. Ajouter des machines en plein incident suppose d’appeler un plan de contrôle, et ce plan de contrôle est peut-être justement ce qui a cassé. La documentation de stabilité statique d’AWS dit que les systèmes devraient « continuer à fonctionner normalement sans avoir besoin de modifications pendant la panne ou l’indisponibilité des dépendances ». Elle précise aussi que les plans de contrôle sont « statistiquement plus susceptibles de tomber en panne que les plans de données ». Chaque ingénieur de garde a déjà essayé de charger une page de statut pendant une panne, pour la retrouver hébergée sur ce qui vient de casser.

Marge de capacité : la facture à payer avant la panne

Voici le calcul que j’afficherais au mur. Supposons trois régions actives, un pic combiné de 100 000 requêtes par seconde, et une règle selon laquelle aucune région ne dépasse 70 % d’utilisation après une bascule. Ce sont mes hypothèses, pas celles d’AWS. Remplacez-les par vos propres chiffres.

Trois régionsDeux régions
Charge normale par région33 333 req/s50 000 req/s
Charge par survivante après la perte d’une région50 000 req/s100 000 req/s
Capacité par survivante à une cible de 70 %71 429 req/s142 857 req/s
Total provisionnéenviron 214 286 (2,14× le pic)environ 285 714 (2,86× le pic)
Utilisation normale par régionenviron 46,7 %35 %

Plus il y a de régions, plus la capacité de réserve est répartie finement. La configuration à deux régions tourne à 35 % d’utilisation chaque jour pour couvrir une panne qui ne viendra peut-être jamais, et elle coûte davantage au total que celle à trois régions. C’est la prime d’assurance, bien en vue.

Les cellules peuvent réduire la facture davantage. Si chaque région est découpée en cellules et que seuls les locataires de la cellule touchée sont déplacés, la survivante n’a besoin de marge que pour cette part. Je n’ai pas trouvé de chiffre publié à ce sujet, alors modélisez-le avec la taille de vos propres cellules. La capacité pré-provisionnée reste un argument budgétaire, et personne en dehors de votre organisation ne peut vous dire où placer la limite. Je préfère quand même payer cette facture plutôt que découvrir, à la deuxième semaine, que la cible de bascule manque elle aussi de capacité.

Cellules : là où s’arrête le rayon d’impact

Une cellule est une copie complète de la pile qui dessert un sous-ensemble fixe de locataires. Un routeur mince associe chaque locataire à une seule cellule, ainsi une panne reste confinée à cette cellule. AWS, dans sa documentation sur les architectures par cellules, dit que les routes vers les cellules sont « chargées en mémoire depuis un bucket S3 », et que « même si le plan de contrôle, Amazon S3 ou une zone est indisponible, le routeur peut toujours diriger le trafic vers les cellules ». Le routeur continue de fonctionner parce qu’il lit sa table en mémoire au lieu de demander un service à chaque requête.

La règle de conception qui en découle : rien sur le chemin de requête ne doit appeler un service qui meurt avec l’installation. Basculer revient alors à repointer le point d’accès d’une cellule vers sa copie survivante, un changement beaucoup plus petit que la reconstruction d’une pile en pleine panne. Gardez la table de routage petite, versionnez-la, et assurez-vous que chaque région charge le même instantané. Sinon, vos cellules isolées ne sont isolées que jusqu’au moment où quelqu’un vérifie quelle table est active.

Routeur par cellules envoyant le trafic des locataires vers des cellules isolées

Cesser de demander la permission à la région mourante

Une bascule qui attend l’API de la région défaillante ressemble à une sortie de secours qui exige que le gestionnaire de l’immeuble la déverrouille. La sortie existe. Le déverrouillage, lui, n’existe pas.

Le Application Recovery Controller (ARC) d’AWS est conçu autour de ce problème. Ses contrôles de routage sont, selon AWS, des « interrupteurs marche-arrêt simples hébergés sur des grappes hautement disponibles couvrant cinq régions AWS », et ils s’intègrent aux vérifications de santé de Route 53. Une grappe compte cinq points de terminaison, un par région, qui, selon AWS, fonctionnent en coordination « afin de garantir une haute disponibilité et une cohérence séquentielle des opérations de bascule ». La limite à prévoir : « Chaque compte peut avoir au maximum 2 grappes. »

La mise en place demande trois appels en ligne de commande. Remplissez les espaces réservés :

# 1. Créer la grappe. Le statut passe de PENDING à DEPLOYED ; interrogez describe-cluster.
aws route53-recovery-control-config create-cluster \
  --cluster-name test --network-type DUALSTACK

# 2. Un contrôle de routage par cellule. L'ARN de la grappe est obligatoire.
aws route53-recovery-control-config --region us-west-2 create-routing-control \
  --routing-control-name RoutingControlCell1 \
  --cluster-arn <ARN de la grappe>

# 3. Vérification de santé Route 53 qui lit l'état du contrôle de routage.
aws route53 create-health-check \
  --caller-reference RoutingControlCell1 \
  --health-check-config Type=RECOVERY_CONTROL,RoutingControlArn=<ARN du contrôle de routage>

Deux pièges tirés du guide d’AWS. La création d’une grappe crée aussi un DefaultControlPanel, et un panneau de contrôle ne peut appartenir qu’à une seule grappe : le déplacer exige de le supprimer puis de le recréer. Ensuite, l’exemple de bascule d’AWS place un enregistrement en PRIMARY et un autre en SECONDARY, chacun avec un HealthCheckId, et fixe TTL à 0 sur les deux. La page ne dit pas que 0 est la valeur à utiliser. Décidez-le en connaissance de cause plutôt que de le copier.

Ajoutez ensuite une règle de sécurité pour que l’automatisation ne puisse pas éteindre toutes les cellules. L’exemple de règle d’assertion d’AWS garde au moins un de deux contrôles à On, avec un seuil de 1 et une période d’attente de 5000 ms. Si un changement brise une règle que vous avez créée, l’appel lève une exception, ce qui est exactement ce qu’on veut à 3 h du matin.

Là, je dois m’arrêter. Le guide mentionne set-routing-control-state dans son texte sur les règles de sécurité, mais je n’ai pas pu confirmer la commande exacte du plan de données à partir des pages consultées. Vérifiez la référence de la CLI avant de la coller dans un runbook.

ARC offre aussi deux façons de déplacer le trafic hors d’une zone défaillante. Le déplacement de zone est manuel : « Le déplacement de zone est manuel—vous le démarrez et l’arrêtez. » Le déplacement automatique de zone mise sur le contraire : « AWS détecte les dégradations et déplace le trafic en votre nom. » Le manuel garde la décision entre vos mains et coûte des minutes humaines. L’automatique supprime le délai humain, mais rend votre bascule dépendante de la détection d’AWS. Les exercices de déplacement automatique d’AWS durent « environ 30 minutes », un rappel que les répétitions ne sont pas instantanées non plus. Les déplacements expirent aussi, entre « 1 minute et 3 jours (72 heures) ». Décidez donc à l’avance ce qui se passe quand l’un d’eux arrive à échéance au milieu d’une panne qui dure encore.

Trafic qui passe d'un centre de données éteint vers des régions survivantes

Le délai DNS, qu’on peut additionner

Le basculement client au pire cas correspond à peu près au temps de détection, plus le TTL de l’enregistrement, plus tout résolveur qui met en cache au-delà du TTL. Les vérifications de santé vous donnent le premier terme avec des chiffres publiés. Les vérificateurs de Route 53 interrogent votre point de terminaison toutes les 30 secondes (standard) ou toutes les 10 secondes (rapide, facturé en supplément), et l’intervalle ne peut pas être modifié après la création. AWS définit le seuil d’échec comme « le nombre de vérifications de santé consécutives » qu’un point de terminaison doit réussir ou échouer avant que son état change. Je n’ai pas trouvé la valeur par défaut dans les documents consultés. Le calcul ci-dessous suppose donc trois échecs consécutifs.

Intervalle de vérificationDétection (3 échecs, hypothèse)Plus un TTL de 60 s (mon exemple)Pire cas, avant les comportements anormaux des résolveurs
10 s (rapide)environ 30 s60 senviron 90 s
30 s (standard)environ 90 s60 senviron 150 s

Ces chiffres constituent un plancher, pas toute l’histoire. Les vérificateurs de Route 53 ne se coordonnent pas, et AWS prévient que vous verrez « parfois plusieurs requêtes par seconde, quel que soit l’intervalle choisi, suivies de quelques secondes sans aucune vérification ». Mon estimation ajoute au plus un intervalle de décalage de phase, que AWS ne mentionne pas. Et un résolveur qui ignore le TTL échappe à votre contrôle : le TTL est une demande, pas une garantie. Le TTL de 60 secondes est un exemple, pas une recommandation.

Deux autres pièges. Les vérifications de santé calculées peuvent combiner jusqu’à 256 enfants avec ET, OU, ou « au moins x sur y », ce qui permet d’exprimer « deux sondes sur trois sont d’accord ». Et si vous surveillez une alarme CloudWatch plutôt qu’un point de terminaison, méfiez-vous de la valeur par défaut : une nouvelle vérification sans dernier état connu démarre en état sain. Une métrique qui se tait pendant la perte d’une installation peut donc avoir l’air correcte. AWS déconseille de se fier au dernier état connu lorsque la métrique est indisponible depuis plus de quelques heures.

Si vous pilotez plutôt la bascule par un contrôle de routage, la détection devient une action de l’opérateur ou de l’automatisation, à laquelle s’ajoute le délai de propagation d’ARC. Je n’ai pas trouvé ce délai documenté dans ce que j’ai pu consulter. Mesurez-le lors d’un exercice, parce qu’il entre directement dans votre temps de récupération.

La latence de réplication est votre point de reprise

Les tables globales DynamoDB répliquent les écritures « généralement en une à deux secondes », et AWS ne promet pas de borne stricte. Le mot « généralement » porte toute la phrase. Lors d’une perte soudaine de l’installation, les écritures perdues sont à peu près celles encore en transit pendant ce délai, plus tout ce qui n’a pas encore été répliqué entre les régions.

Mesurez ce chiffre au lieu de le supposer. DynamoDB publie ReplicationLatency pour les tables globales, en millisecondes, avec les dimensions TableName et ReceivingRegion. La page des métriques applique une agrégation de cinq minutes à toute métrique absente de sa liste d’agrégation d’une minute, et ReplicationLatency n’y figure pas. J’en déduis donc une granularité de cinq minutes. Saisissez l’alarme comme suit dans la console, ou traduisez-la dans votre infrastructure as code :

ParamètreValeur
MétriqueReplicationLatency (Milliseconds)
DimensionsTableName, ReceivingRegion
StatistiqueMaximum
Période5 minutes (correspond à la granularité de la métrique)
SeuilVotre RPO en millisecondes. AWS ne publie aucune valeur recommandée.

La période de cinq minutes a un coût. Une alarme doit attendre au moins une période complète avant de se déclencher. Traitez-la donc comme un signal précoce pour l’opérateur, pas comme le déclencheur de la bascule. Laissez vos vérifications de santé et vos contrôles de routage faire la bascule.

Le mode de réplication détermine ce qu’une perte soudaine vous coûte, et la documentation de PostgreSQL rend ce compromis particulièrement explicite :

Mode de réplicationCe que vous pouvez perdre en cas de perte soudaine du principal
Tables globales DynamoDBLes écritures encore en transit pendant le délai. Généralement une à deux secondes, sans borne stricte.
PostgreSQL asynchrone (par défaut)Les transactions validées pas encore reçues par la réplique. La perte est « proportionnelle au délai de réplication au moment de la bascule ». Le délai est typiquement inférieur à une seconde quand la réplique suit la cadence.
PostgreSQL synchroneSeulement si le principal et la réplique tombent en panne en même temps. Chaque validation attend que le WAL soit écrit sur disque des deux côtés.
PostgreSQL ANY 2 (s1, s2, s3)Les validations attendent que deux répliques sur trois aient le WAL. À mon avis, la panne d’une réplique ne fait pas perdre de validation déjà confirmée.

La documentation de PostgreSQL ajoute une mise en garde qui vaut pour tout design par quorum : « Il n’existe aucun moyen d’être certain que toutes les répliques ont reçu toutes les données WAL en attente au moment de la panne du principal. » Les répliques peuvent donc ne pas s’entendre sur ce qui a été validé. La réplication asynchrone est rapide et discrètement sujette aux pertes. Les modes synchrone et par quorum sont plus lents mais bornés. DynamoDB se trouve dans le premier camp, ce qui est une bonne place si vous connaissez le chiffre.

Les écritures peuvent aussi entrer en collision. Quand deux régions acceptent des écritures sur le même élément, DynamoDB règle le conflit « en utilisant une méthode de résolution dite du dernier écrivain gagnant ». C’est simple, et cela converge toujours. Cela peut aussi supprimer une écriture sans lever d’erreur. Imaginez une écriture plus récente dans la région mourante et une écriture plus ancienne dans la survivante, toutes deux dans la fenêtre de latence. Au retour, l’horodatage le plus tardif l’emporte, et l’écriture de la survivante disparaît sans aucune erreur à repérer.

La solution plus propre consiste à cesser de laisser deux régions écrire le même élément. Rattachez les éléments de chaque locataire à une région d’origine, en vous servant de la table de cellules vue plus haut. Les conflits n’apparaissent alors que pendant la bascule, quand une survivante prend le relais des écritures. Le risque se déplace dans une fenêtre que vous pouvez concevoir, tester et surveiller, ce qui vaut mieux que de le découvrir au retour. Cela ne supprime pas le risque, et votre runbook de bascule devient responsable du problème de cohérence. Pour les données qui doivent fusionner plutôt que s’écraser, regardez les types de données répliqués sans conflit (CRDT). Je n’ai pas vérifié leur fonctionnement dans cette passe : considérez-les comme une piste, pas comme une conception.

Le plan partagé que personne ne dessine

Le cas français est une panne d’un autre type, et il compte pour la conception par cellules. BleepingComputer rapporte que des attaquants ont détourné des contrôleurs qui faisaient tourner une version ancienne du logiciel Danfoss et ont utilisé la fonction de dégivrage automatique intégrée pour faire grimper les températures. Les chaînes citées comprennent Intermarché, Coopérative U, Carrefour Market, Monoprix, Leclerc et Super U, et des médias français parlent de 250 à 350 magasins. Danfoss est rapportée comme cible, sans confirmation, et l’entreprise n’a pas commenté. Le parquet de Paris a ouvert une enquête, et aucun suspect n’a été identifié. Le président de Coopérative U a indiqué qu’une cyberattaque « affecte les systèmes de réfrigération de plusieurs magasins » et l’a qualifiée d’« inacceptable ».

Rien de tout cela n’exigeait un incendie ni un câble coupé. Il fallait un plan de gestion à distance auquel de nombreux sites faisaient confiance de la même façon, et une fonction de dégivrage qui fonctionne aussi bien quand quelqu’un d’autre appuie sur le bouton.

BleepingComputer cite un avis de la CISA sur deux vulnérabilités de la plateforme Danfoss AK-SM 8xxA, CVE-2025-41450 (contournement d’authentification) et CVE-2025-41451 (injection de commandes), et indique qu’aucune preuve ne relie ces failles à cette attaque. Predicta Lab a compté 2 752 systèmes Danfoss exposés sur Internet, dont 1 590 en France.

Pour les cellules, la leçon est franche. Une frontière de cellule tracée le long des zones de disponibilité vous protège quand une zone s’éteint. Face à un fournisseur commun, à une version de micrologiciel commune ou à un identifiant de gestion à distance commun, elle ne fait rien. Si chaque site de chaque cellule utilise le même contrôleur avec le même compte administrateur, vos cellules isolées ne sont qu’une seule cellule avec quelques étapes de plus. Deux règles en découlent. Tracez les frontières de cellules sur les identifiants de gestion, pas seulement sur le placement réseau. Et consignez la version du micrologiciel comme partie de l’identité de chaque cellule, pour voir quand plusieurs cellules font tourner la même version.

Plusieurs contrôleurs de magasins reliés à un seul point de commande à distance

Un runbook qu’on peut copier

  1. Détecter avec plusieurs signaux. Combinez les sondes avec des vérifications de santé calculées, en utilisant ET, OU ou « au moins x sur y ». Écrivez une branche pour la dégradation (la situation de Kaluga) et une autre pour la panne totale (celles de Sasovo et de Vladimir) comme des chemins distincts, puisqu’elles appellent des réponses différentes.
  2. Basculer en une étape réversible. Faites passer les contrôles de routage des cellules touchées vers les cellules de la survivante. Gardez votre règle de sécurité en place, consignez l’horodatage et assurez-vous que le changement peut être annulé.
  3. Vérifier avant de faire confiance. Contrôlez le routage des cellules et ReplicationLatency dans la région survivante avant d’envoyer tout le trafic. Si le délai augmente, vous n’êtes pas prêt à accepter chaque écriture.
  4. Fixer l’expiration à l’avance. Si vous utilisez le déplacement de zone, choisissez une expiration qui n’arrivera pas à échéance au milieu d’une panne qui continue.
  5. Retenir le retour. Ne ramenez pas le trafic parce que la région perdue semble de nouveau saine. Attendez que l’installation soit vérifiée et que les répliques aient rattrapé leur retard, sinon vous échangez une panne contre des pertes silencieuses de conflits.

Gardez le calcul des délais sur le même mur que le calcul de capacité. Le basculement au pire cas, c’est la détection, plus le TTL, plus ce que les résolveurs ignorent. Chaque terme est un levier que vous ne contrôlez qu’en partie.

Où ce design craque

  • Les déclarations publiques de Yandex ne disent rien de l’architecture de ses systèmes. Nous connaissons le résultat, pas le design, et je ne peux donc pas évaluer sa bascule.
  • ARC et le déplacement automatique changent en qui vous avez confiance. Vous cessez de dépendre du plan de contrôle d’une région mourante et commencez à dépendre des grappes et de la télémétrie d’AWS. C’est un meilleur pari, pas la suppression d’une dépendance.
  • La capacité pré-provisionnée transforme un risque en poste budgétaire. Ce poste est coûteux et facile à couper au cycle budgétaire suivant, jusqu’au jour où on en a besoin.
  • La perte silencieuse de conflits est la panne que personne ne surveille. Rattacher les éléments à une région d’origine la déplace dans la fenêtre de bascule, où vous pouvez la tester, mais ne la supprime pas.
  • Je n’ai trouvé aucun chiffre publié pour toute la chaîne, de la détection jusqu’au TTL, à la mise en cache et au délai de réplication. Il faudra mesurer le vôtre. Cette mesure est le vrai travail, et aucune page de fournisseur ne la fait à votre place.

Si je devais choisir une seule première étape, ce serait la moins glamour : écrire la capacité nécessaire dans la région survivante et la payer avant le mauvais jour.

Le saviez-vous

  • Des frappes de drones ont endommagé trois sites de Yandex entre le 8 et le 11 octobre, selon BleepingComputer. Deux se sont arrêtés complètement. Le troisième fonctionne en mode dégradé, et c’est le cas que la plupart des runbooks oublient.
  • Un cluster ARC compte cinq points de terminaison, un dans chacune de cinq régions AWS, et un compte peut en avoir au maximum deux.
  • Un déplacement de zone peut être fixé pour expirer entre 1 minute et 72 heures.
  • Les vérificateurs de Route 53 ne se coordonnent pas : vous pouvez voir plusieurs requêtes de vérification en une seconde, puis quelques secondes sans aucune.
  • Predicta Lab a compté 2 752 systèmes Danfoss exposés sur Internet, dont 1 590 en France.

Sources

À lire aussi