Chapitre 26. La haute disponibilité : actif, standbys, bascules

Objectifs pédagogiques¶

Décrire la mécanique active-standby et son unification avec l'élection Raft. Suivre le trajet d'une requête arrivée sur n'importe quel nœud. Lire les codes de santé en cluster et concevoir une sonde. Analyser une bascule des deux côtés. Expliquer le descellement par nœud. Situer les performance standbys. Exécuter l'étape 4 du fil rouge.

Prérequis¶

Chapitres 24 et 25, chapitre 4 (les codes de santé, qui prennent ici tout leur sens), chapitre 23 (le Transit Seal que les nouveaux nœuds consomment), chapitre 18 (le comportement des applications pendant une indisponibilité).

Cours¶

26.1 Un actif, des standbys¶

Dans un cluster Vault, un seul nœud sert : l'actif exécute les requêtes, tient les moteurs, fait courir les baux. Les autres sont standbys, descellés, à jour de réplication, prêts, mais ils ne traitent rien.

Ce n'est pas une paresse d'implémentation mais une conséquence directe du chapitre 24 : toutes les écritures doivent passer par le leader Raft pour qu'il n'existe qu'une histoire. Et avec le stockage intégré, le leader Raft et le nœud actif ne font qu'un : la même élection désigne les deux, une seule mécanique de bascule à comprendre.

La haute disponibilité de Vault est donc une haute disponibilité de relève, pas de partage de charge. Les standbys n'ajoutent pas de capacité, ils achètent du temps de survie.

26.2 Le trajet d'une requête¶

Que se passe-t-il quand un client frappe à la porte d'un standby ? Par défaut, le standby transmet : il relaie la requête à l'actif par le port de cluster et rend la réponse au client, qui n'a rien vu.

La conséquence pratique est précieuse : tous les nœuds sont des portes d'entrée valides, y compris quand ils sont standbys.

Le mode alternatif est la redirection : le standby répond d'aller voir l'actif, en s'appuyant sur l'adresse d'API que chaque nœud déclare. Il suppose des clients capables de suivre, et le fil rouge ne l'emploie pas.

La transmission a son prix, honnête : un saut réseau de plus, et une dépendance, puisqu'un standby ne peut transmettre que si le port de cluster vers l'actif est ouvert. Elle a surtout une limite que le chapitre 28 lèvera : trois portes valides, ce sont trois adresses à connaître côté clients. L'entrée unique sera l'affaire du répartiteur de la partie IX.

26.3 Les codes de santé, version cluster¶

Le chapitre 4 a donné les codes ; le cluster leur donne leur emploi.

Code	Signification
200	actif descellé
429	standby descellé, sain mais ne servant pas
473	performance standby, édition Enterprise
501	nœud non initialisé
503	nœud scellé

La conséquence d'ingénierie est immédiate : une sonde se conçoit, elle ne se devine pas. Une sonde qui traite le code standby comme une erreur déclarera morts deux nœuds sains sur trois. Une sonde qui interroge la racine au lieu du point de santé ne mesure rien.

Le point de santé accepte des paramètres pour dire à la sonde ce qu'elle veut savoir : une option fait répondre positivement un standby, la question devenant « es-tu un nœud sain » au lieu de « es-tu l'actif ». Le chapitre 28 écrira les deux sondes du répartiteur avec ce vocabulaire.

Dès maintenant, la supervision interroge les trois nœuds et attend le motif 200, 429, 429. Tout autre motif est une information : deux codes actifs n'existent pas, trois codes standby non plus, et un code de scellement dit qu'un nœud a redémarré sans se desceller.

26.4 La bascule¶

Subie : l'actif meurt. Les followers cessent d'entendre ses battements de cœur, le délai d'élection expire, un candidat lève la main et obtient la majorité. Nouvel actif en quelques secondes.

Ce que la bascule garantit, par les garde-fous du chapitre 24 : aucune écriture acquittée n'est perdue, le nouvel élu ayant par construction tout le journal engagé. Ce qu'elle ne garantit pas, et qu'il faut dire aux équipes applicatives : les requêtes en vol échouent, et le client ne sait pas si l'écriture a été engagée juste avant ou perdue juste après.

La doctrine cliente en découle : réessayer. Les lectures toujours, les écritures avec discernement, en relisant avant de réécrire et en tolérant le doublon bénin. C'est exactement ce que les intégrations sérieuses font d'elles-mêmes. Vue de billing, une bascule bien architecturée est quelques secondes d'erreurs retentées, pas un incident.

Volontaire : la cession de la main fait passer l'actif en standby, avec une élection dans l'instant. C'est le geste de politesse des maintenances, à répéter en laboratoire jusqu'à ce qu'il soit ennuyeux.

Un dernier mot de vigilance : des bascules répétées sans cause volontaire sont un symptôme, jamais un bruit de fond. Un actif à bout de ressources, un réseau qui perd des battements de cœur, une horloge qui dérive. La supervision compte les élections, et plus d'une par mois hors maintenance ouvre un ticket.

26.5 Le descellement par nœud¶

Voici la règle que le mono-nœud masquait : le seal est par nœud. Chaque membre a sa mémoire, donc sa clé racine à faire renaître. Un nœud qui redémarre rejoint le cluster scellé, et un standby scellé n'est ni une relève ni une voix utile : c'est un code d'erreur qui attend.

Sous Shamir, l'arithmétique devient cruelle : trois nœuds, c'est trois cérémonies à chaque campagne de redémarrage, le coût du chapitre 20 multiplié par la taille du cluster.

C'est ici que l'étape 3 paie comptant. Sous Transit Seal, chaque nœud se descelle seul, à chaque redémarrage, y compris les trois d'un coup après une coupure générale, dans l'ordre du chapitre 23.

Un raffinement d'exploitation ferme la section : chaque nœud consomme le gardien sous son propre token de seal, trois tokens frères sur la même policy. L'audit du gardien dit alors qui descelle, et une compromission de machine se révoque sans toucher les deux autres. C'est l'imputabilité et la révocation fine de la partie IV, appliquées aux machines.

26.6 Enterprise : les performance standbys¶

L'édition Enterprise change la nature des standbys : les performance standbys servent eux-mêmes les lectures, seules les écritures remontant à l'actif. La haute disponibilité de relève devient une mise à l'échelle horizontale de la lecture, précieuse pour les charges dominées par les lectures, et leur code de santé dédié permet aux répartiteurs de les inclure dans le trafic.

En édition Community, la règle reste entière : un seul nœud sert, et la capacité se dimensionne sur l'actif seul.

26.7 L'étape 4 du fil rouge¶

[Laboratoire]. L'extension, déroulée.

Préparation : les deux nouveaux nœuds provisionnés sur des hôtes distincts, installation du chapitre 7 rejouée par la gestion de configuration ; sur le gardien, deux tokens de seal frères créés, policy inchangée. Configuration : le fichier de la section 24.5 pour chacun, identité propre, jonctions vers les deux autres, strophe de seal avec le token du nœud.

# Sur vault-core-02 (puis 03) :
sudo systemctl start vault
vault status            # Sealed: false -- le gardien a fait son office, sans personne
vault operator raft list-peers    # le noeud apparait, follower, puis Voter: true

Rien d'autre : pas d'initialisation, pas de cérémonie, pas de parts. La jonction déclarée, le descellement automatique, la stabilisation, la voix. C'est la démonstration en trois commandes de tout ce que les parties VII et VIII ont construit ensemble.

Recette de sortie, dans la fenêtre : trois votants, le motif de santé nominal relevé par la supervision, et le test qui ne se délègue pas, la bascule provoquée, chronomètre en main.

Exemple : le test de bascule¶

L'exercice se fait en production réelle, fenêtre annoncée : il ne vaut que sincère.

État initial. Le premier nœud est leader, motif de santé nominal, billing en charge avec son tableau de bord affiché.

Panne provoquée. Pas une cession volontaire mais un arrêt brutal du processus, la panne vraie. La supervision voit le nœud muet en six secondes ; l'élection aboutit en neuf, le troisième nœud devenant leader, terme incrémenté.

Côté client. Quatre requêtes en erreur, toutes retentées avec succès à la seconde suivante. Zéro ticket, zéro alerte applicative. Le bail d'une instance, en cours de renouvellement pendant la fenêtre, a été renouvelé au second essai : la marge de renouvellement du chapitre 18 existait pour cela.

Retour. Le nœud redémarré se descelle automatiquement, rejoint, se stabilise, retrouve sa voix. Il revient follower : personne ne détrône un actif sain pour des raisons sentimentales.

Débrief. Bascule en neuf secondes, impact client nul, et deux améliorations notées : le tableau de bord mettait six secondes à voir la panne, sonde resserrée ; une instance de préproduction pointait un nœud en dur au lieu du nom de service, corrigée.

Dernière ligne du registre : « La tolérance de panne n'est plus une propriété du dossier d'architecture. C'est un chronomètre : neuf secondes. »

Architecture : le cluster du fil rouge à l'étape 4¶

                    clients (billing, nocturne, CI, admin)
                      vault.astrea.lab -> vault-core-01 (entree provisoire, etape 5 partie IX)
                        |            (toute porte est valide : les standbys transmettent)
        +---------------+---------------+---------------------+
        v                               v                     v
  vault-core-01 (.11)           vault-core-02 (.12)     vault-core-03 (.13)
  ACTIF   sys/health 200        STANDBY  429            STANDBY  429
        ^                               ^                     ^
        +===== 8201 : raft (replication, votes) + transmission des requetes =====+
                 TLS interne gere par Vault ; pare-feu : 8201 entre noeuds seulement

  seal "transit" (un token par noeud : seal-vault-core-01/02/03)
        -> vault-transit-01 (10.10.10.11) -- Shamir 3/2, a froid
  recovery keys 5/3 du core (ex-parts, ch. 23) : generate-root, rekey, migrations
  ordre de reprise generale : transit-01 (ceremonie) puis les trois cores, seuls

Sécurité : la relève sous contrôle¶

La provocation d'élections est un pouvoir. Forcer des bascules à répétition est un déni de service élégant : le chemin porte la capability de chemin protégé, se réserve et s'audite. Le compteur d'élections est aussi un détecteur d'abus.

Trois tokens de seal, trois révocations possibles. La compromission d'un nœud se répond en révoquant son token, sans priver les deux autres de leur gardien.

Le motif de santé est une signature. Le motif nominal est l'empreinte du régime sain, et la supervision alerte sur toute autre combinaison, dont l'équipe connaît la lecture par cœur.

La bascule s'exerce en vrai. Un cluster dont la tolérance de panne n'a jamais été constatée chronomètre en main la découvrira un jour de vraie panne, avec les surprises de l'exemple mais sans la fenêtre annoncée.

Erreurs fréquentes¶

Une sonde qui traite le code standby en erreur. Deux nœuds sains déclarés morts, et des bascules de répartiteur fantômes au chapitre 28 (section 26.3).

Croire que les standbys ajoutent de la capacité. L'actif sature et le cluster bascule en boucle sous la charge. En édition Community, la capacité est celle de l'actif (sections 26.1, 26.6).

Oublier qu'un nœud redémarré peut être scellé. Sous Shamir, le standby attend une cérémonie que personne n'a vue passer : la relève n'existe plus, silencieusement (section 26.5).

Un seul token de seal pour trois nœuds. Couper le gardien d'un nœud compromis couperait les trois (section 26.5).

Des clients codés sur l'adresse d'un nœud. L'instance qui pointe une adresse en dur traverse mal les bascules et très mal l'étape 5 (sections 26.2, 26.7).

Tester la bascule par cession volontaire seulement. La cession est propre par construction ; la panne vraie teste les délais, les sondes et les clients (section 26.4).

Mise en pratique : la relève sous toutes ses coutures¶

Sur papier ; réponses commentées en fin de partie.

Concevez les deux sondes du futur répartiteur : celle qui identifie l'actif, celle qui mesure la santé de chaque nœud. Endpoint, paramètres, interprétation de chaque code, périodicité.
Rédigez le runbook de la maintenance de l'actif : ordre, commandes, constats entre chaque étape, critères d'abandon.
Analysez, du point de vue de billing, trois événements : une bascule de neuf secondes, un actif saturé qui répond en trois secondes, la perte de deux nœuds sur trois. Pour chacun, ce que voit l'application, ce qu'elle doit faire, ce que l'équipe doit faire.

Questions de compréhension¶

Pourquoi un seul nœud sert-il, et qu'unifie le stockage intégré dans la mécanique de bascule ?
Décrivez la transmission de requêtes : trajet, port, conséquence pratique, prix, et l'alternative avec son exigence.
Donnez le motif de santé nominal d'un cluster de trois, et l'interprétation de trois motifs anormaux.
Que garantit une bascule aux écritures acquittées, que ne garantit-elle pas, et quelle doctrine cliente en découle ?
Qu'est-ce que le flapping, et pourquoi n'est-il jamais un bruit de fond ?
Énoncez la règle du seal par nœud et ses conséquences sous chaque type de seal.
Pourquoi un token de seal par nœud, et quel double bénéfice cette granularité apporte-t-elle ?
Que changent les performance standbys, et sur quoi se dimensionne un cluster Community ?
Qu'est-ce qui rend l'entrée des nouveaux nœuds si simple à l'étape 4, et quelle dette reste au registre ?

Synthèse¶

La haute disponibilité de Vault est une relève : un actif, le leader Raft lui-même, sert tout, des standbys descellés attendent, et toute porte du cluster est valide parce que les standbys transmettent. Les codes de santé en sont la langue, et les sondes se conçoivent dans cette langue. La bascule élit en secondes sans perdre une écriture acquittée ; les requêtes en vol échouent et se réessaient, et le flapping est toujours un symptôme. Le seal étant par nœud, le Transit Seal transforme les redémarrages du cluster en non-événements, chaque machine sous son token révocable seul. L'étape 4 est faite et prouvée au chronomètre. L'entrée unique manque encore. Déclenche le TP 11 (énoncé en partie XV).