Cas 4. Alcyon : deux salles et un engagement de disponibilité
Contexte¶
Alcyon est un courtier en assurances dont la plateforme de souscription fonctionne en continu. L'engagement contractuel porte sur 99,95 % de disponibilité annuelle, soit environ quatre heures et demie tolérées par an, toutes causes confondues. L'entreprise dispose de deux salles machines distantes de douze kilomètres, reliées par une fibre dédiée offrant une latence aller-retour d'environ deux millisecondes. L'édition Enterprise n'est pas dans le budget de l'exercice, ce qui est un fait à intégrer plutôt qu'une préférence à discuter.
Vault sert d'abord les credentials de base et le chiffrement applicatif : son indisponibilité empêche tout démarrage d'instance et tout renouvellement, donc entame directement le budget de la plateforme.
Contraintes¶
Deux salles, pas trois. Une latence faible, qui autorise techniquement un cluster réparti. Un engagement chiffré qui laisse peu de marge : une seule reprise manuelle d'une heure consomme le quart du budget annuel. Une astreinte existe, mais son délai d'intervention nominal est de trente minutes, ce qui interdit de fonder la disponibilité sur une action humaine rapide.
Risques principaux¶
Le risque central est arithmétique, et il surprend régulièrement : deux salles ne font pas un quorum.
Un cluster de trois nœuds réparti en deux et un survit à la perte de la salle qui en héberge un, et s'arrête si l'on perd celle qui en héberge deux. Un cluster de cinq nœuds réparti en trois et deux présente exactement le même défaut, décalé. Aucune répartition sur deux emplacements ne survit automatiquement à la perte de la majorité, parce que le consensus refuse, à juste titre, de laisser une minorité décider seule qu'elle constitue le cluster.
S'y ajoutent deux risques classiques : la redondance du point d'entrée, laissée en suspens au chapitre 28 et qui devient ici une exigence ; et la tentation d'étirer le quorum en croyant acheter de la disponibilité alors qu'on achète surtout des modes de panne.
Architecture proposée¶
Trois emplacements de vote, dont un très léger. Les deux salles hébergent chacune deux nœuds, et un cinquième est placé dans un troisième emplacement : un hébergement souverain de faible capacité, un local technique du siège, une machine chez un fournisseur si la politique le permet. Sa fonction n'est pas de servir mais de voter. Avec cinq nœuds répartis en deux, deux et un, la perte d'une salle entière laisse trois votants, donc la majorité, et le cluster continue sans intervention humaine. Cette machine peut être modeste, sa charge se limitant à la réplication.
L'entrée est redondée par VRRP : une adresse virtuelle portée entre deux répartiteurs, un par salle, chacun configuré comme au chapitre 28 (passage en aveugle, sonde attendant le code 200, vérification du certificat des nœuds). L'outil de bascule surveille à la fois la présence du pair et la santé du répartiteur local, de sorte qu'un répartiteur vivant dont le service est mort cède l'adresse au lieu de la retenir. Ce cas décrit l'architecture retenue ; le mode opératoire du déploiement n'entre pas dans son périmètre.
Le descellement est automatique, faute de quoi l'astreinte de trente minutes deviendrait le facteur limitant de chaque redémarrage. Selon la politique d'Alcyon, il s'appuie sur un service de clés externe ou sur un couple de serveurs de descellement, auquel cas ceux-ci sont eux-mêmes redondés, un par salle, chacun scellé par Shamir avec ses propres porteurs.
Un cluster de secours est enfin maintenu dans la seconde salle, alimenté par les snapshots, prêt à être promu si l'impensable survient. Ce n'est pas de la réplication, la fraîcheur se compte en minutes ou en heures, et son rôle est de couvrir la perte simultanée des deux salles principales de vote.
Choix techniques argumentés¶
Le troisième emplacement est le choix qui fait la valeur du cas. Il coûte une petite machine et il transforme la topologie : sans lui, toute perte de salle majoritaire impose une décision humaine sous pression, avec la reconfiguration forcée et son risque de perte d'écritures ; avec lui, la bascule est automatique et le budget d'indisponibilité est préservé.
Cinq nœuds plutôt que trois : le cluster tolère alors deux pertes, ce qui autorise une maintenance planifiée sur un nœud pendant qu'une panne survient sur un autre. Avec trois nœuds, toute maintenance consomme la totalité de la tolérance.
VRRP est retenu là où Astrea l'avait différé, parce que l'engagement chiffré change l'arbitrage : chez Astrea, une reconstruction en quelques minutes restait compatible avec l'objectif ; ici, elle en consommerait une part significative.
Alternatives écartées¶
Étirer un cluster de trois nœuds sur deux salles : la répartition deux et un donne l'illusion de la redondance et s'arrête à la perte de la salle majoritaire. C'est l'architecture la plus fréquemment rencontrée sur le terrain, et la plus trompeuse.
Deux clusters indépendants avec bascule applicative : les secrets divergent, les baux et les tokens ne sont pas partagés, et les applications doivent gérer deux sources de vérité. En édition Community, il n'existe pas de mécanisme de réplication pour maintenir la cohérence ; cette voie transfère la complexité vers les applications, où elle coûte plus cher.
La réplication de reprise de l'édition Enterprise : c'est la réponse conceptuellement juste, un secondaire à jour promu en quelques minutes avec un RPO proche de zéro, et elle sort du budget de l'exercice. La note d'architecture le consigne explicitement, avec la recommandation de rouvrir l'arbitrage au budget suivant.
Compromis assumés¶
Le troisième emplacement introduit une dépendance de plus, à surveiller comme les autres : sa perte ne coupe rien mais ramène la topologie au cas dégradé de deux salles. Il est également le seul nœud dont la latence peut être médiocre, ce qui influence les écritures s'il devient leader : la configuration l'empêche autant que possible, et la supervision surveille l'identité de l'actif.
Le cluster de secours n'est pas une réplication : sa fraîcheur se compte en minutes, sa promotion est manuelle, et son existence ne doit pas laisser croire à une protection qu'elle n'offre pas. Ce point est écrit en tête de sa fiche pour éviter le malentendu le plus courant en salle de crise.
Stratégie de récupération¶
| Perte | Effet | Traitement |
|---|---|---|
| Un nœud | aucun | automatique |
| Une salle | aucun, tolérance restante nulle | automatique, reconstruction prioritaire |
| Le troisième emplacement | aucun effet immédiat | alerte, gel des maintenances |
| Les deux salles | service interrompu | promotion manuelle du secours, RTO d'une heure |
| Le matériel de scellement | scénario sans reprise | prévention par redondance et dispersion des parts |
Le scénario des deux salles consomme à lui seul l'essentiel du budget annuel, ce que la direction accepte par écrit.
Questions de discussion¶
- Le troisième emplacement est refusé par la direction, qui juge l'idée inélégante. Rédigez la démonstration chiffrée de ce que coûte son absence, en indisponibilité annuelle attendue.
- Comparez, sur cinq critères, le cluster de secours alimenté par snapshots et la réplication de reprise de l'édition Enterprise. Quel argument emporterait la décision selon vous, et pour quelle organisation ?
- Un nœud du troisième emplacement devient leader et les écritures ralentissent. Quelles causes envisagez-vous, et quelles mesures proposez-vous pour rendre ce cas improbable ?