Haute disponibilité et tolérance aux pannes

La panne matérielle de 2h du matin

Un site marchand fait tourner son API de paiement sur une seule machine virtuelle. À 2h du matin, le serveur physique qui l'héberge tombe en panne, silencieusement et complètement, comme finit toujours par le faire du matériel, quel que soit le logo sur la baie. L'instance disparaît, et le paiement avec elle, jusqu'à ce qu'une personne d'astreinte s'en aperçoive et relance une instance de remplacement. Cette instance isolée était un point unique de défaillance : 1 ressource dont la seule panne suffisait à emporter tout le système avec elle. Supprimer des points uniques de défaillance comme celui-ci est le sujet du reste de cette leçon, et il s'avère qu'il existe 2 niveaux différents de « supprimé », pas 1 seul.

Rappel : les briques que vous avez déjà

Vous disposez déjà des 2 outils qui rendent cette suppression possible. Les zones de disponibilité vous donnent des emplacements physiquement séparés où répartir vos instances, pour qu'une mauvaise nuit dans 1 centre de données n'emporte pas tout d'un coup. Un load balancer se place devant ces instances, vérifie la santé de chacune, et n'envoie du trafic qu'à celles qui répondent encore. Combinez les 2, des instances réparties sur plusieurs zones derrière un load balancer, et une panne comme celle de 2h du matin cesse d'être catastrophique. Ce qu'elle devient ensuite, un simple accroc ou rien du tout, dépend de la quantité de capacité de secours qui tournait déjà au moment de la panne.

La haute disponibilité : rester en ligne malgré une brève interruption

Les déploiements Amazon RDS Multi-AZ illustrent bien ce schéma. Une instance de base de données principale traite toutes les lectures et écritures, pendant qu'une instance de secours dans une autre zone de disponibilité reste synchronisée en continu en arrière-plan, prête mais inactive. Si l'instance principale tombe en panne, RDS le détecte, promeut l'instance de secours, et redirige l'enregistrement DNS de la base vers elle, en général entre 60 et 120 secondes, sans perte de données. Pendant ces 60 à 120 secondes, en revanche, les connexions à la base sont coupées ou mises en attente.

C'est la haute disponibilité : le système récupère automatiquement et rapidement, mais la récupération elle-même reste un écart visible, quoique bref. La plupart des applications n'ont besoin que de ce niveau. Une minute d'erreurs de connexion pendant une panne de zone rare est un problème très différent de la panne totale subie par le site marchand à instance unique.

La tolérance aux pannes : rester en ligne sans la moindre interruption

Revenons à l'API de paiement, mais repensée. Disons qu'elle a besoin de 6 instances actives pour tenir sa charge normale. Réparties sur 2 zones de disponibilité, 3 instances par zone, c'est déjà hautement disponible : perdez 1 zone, et les 3 instances survivantes maintiennent le paiement en ligne, mais à moitié capacité jusqu'au lancement de nouvelles instances derrière elles. Réparties sur 3 zones de disponibilité à la place, 3 instances par zone, 9 au total, la perte de n'importe quelle zone laisse encore 6 instances actives, exactement la capacité dont le paiement a besoin. Rien ne change pour l'utilisateur. C'est la tolérance aux pannes : le système n'a jamais réellement manqué de capacité, parce que les instances « de secours » tournaient déjà et servaient déjà du trafic avant que la panne ne survienne.

La comparaison tient toute la distinction en 1 image : une conception hautement disponible a assez de redondance pour survivre à une panne, et une conception tolérante aux pannes a assez de redondance pour que survivre à cette panne ne produise aucune baisse à surmonter. La tolérance aux pannes se rapproche d'un pneu increvable qui garde une voiture roulant à pleine vitesse à travers une crevaison, plutôt que d'une roue de secours qui remet la voiture en route après un arrêt pour la changer, ce à quoi ressemble la fenêtre de récupération de la haute disponibilité. Poussez l'analogie plus loin que ce point précis, et elle se brise : une roue de secours ne coûte presque rien tant qu'elle n'est pas utilisée, alors qu'une capacité tolérante aux pannes vous facture chaque heure où elle reste inactive, en attendant une panne qui n'arrivera peut-être jamais.

Là où la redondance doit s'étendre : toutes les couches, pas seulement le calcul

Un système n'est disponible qu'à hauteur de sa couche la moins redondante. Répartir la couche de calcul sur plusieurs zones ne sert à rien si la base de données, le load balancer, ou le DNS reste un point unique de défaillance en dessous.

Les fournisseurs cloud construisent leurs load balancers gérés et leurs vérifications de santé DNS pour être déjà redondants, si bien que les couches qu'une équipe doit typiquement concevoir explicitement restent le calcul et la base de données.

Actif-actif contre actif-passif

Les 2 schémas de redondance ci-dessus portent des noms, et la différence entre eux revient plus loin dans ce sujet. L'actif-actif signifie que chaque réplique sert du trafic en même temps, comme un load balancer répartit les requêtes sur toutes les instances de calcul saines dès maintenant, pas seulement quand quelque chose tombe en panne. L'actif-passif signifie qu'1 seul côté fait le travail pendant que l'autre reste synchronisé et inactif, prêt à prendre le relais, comme se comporte une instance de secours RDS Multi-AZ.

Aucun schéma n'est meilleur en soi. Les couches de calcul sont en général actif-actif parce que répartir des requêtes sans état sur de nombreuses instances identiques reste simple. Les bases de données sont plus souvent actif-passif parce que rendre chaque réplique simultanément accessible en écriture pose des questions de cohérence difficiles qu'un seul écrivain actif évite.

Idée reçue : « multi-AZ » ne veut pas automatiquement dire « tolérant aux pannes »

Il est tentant d'entendre « déployé sur plusieurs zones de disponibilité » et de considérer la question de fiabilité comme réglée. Elle n'est réglée qu'à moitié. Le multi-AZ garantit qu'une panne dans 1 zone n'emportera pas toutes les instances. Il ne dit rien sur le fait que la capacité survivante suffise ou non à maintenir toute votre charge sans baisse. Une équipe qui répartit 6 instances sur 2 zones a réellement amélioré sa disponibilité par rapport à un déploiement mono-zone, mais elle ne s'est pas rendue tolérante aux pannes pour autant, et supposer le contraire est exactement l'écart qui se révèle sous forme de manque de capacité imprévu lors du prochain incident de zone.

Repères d'examen : lire un scénario haute disponibilité contre tolérance aux pannes

Le piège à repérer : un scénario qui décrit une bonne configuration multi-AZ et demande si elle est tolérante aux pannes. Vérifiez le calcul de capacité, pas seulement le nombre de zones, avant de répondre.

Où cela vous mène

Les 2 schémas partent du même geste, supprimer un point unique de défaillance, puis divergent sur la quantité de capacité de secours que vous acceptez de faire tourner et de payer en permanence. La haute disponibilité tolère une fenêtre de récupération courte et automatique ; la tolérance aux pannes élimine cette fenêtre en gardant la capacité redondante déjà active. La plupart des applications n'ont besoin que de la première. La prochaine leçon passe de rester en ligne pendant une panne à une question liée mais distincte : une fois que vous savez de combien de capacité un système a besoin, qui décide d'en ajouter, et quand en retirer ?