Chapitre 24. Raft : le consensus et le stockage intégré

Objectifs pédagogiques¶

Situer le stockage intégré face aux backends externes. Énoncer le problème que le consensus résout. Expliquer Raft : rôles, journal répliqué, termes, élections, engagement à la majorité. Calculer un quorum et défendre trois nœuds. Écrire la configuration complète d'un nœud. Décrire ce que chaque nœud détient et ce qu'il faut en conclure.

Prérequis¶

Chapitre 4 (le cycle de requête et le port de cluster), chapitre 5 (la consigne mémoire, qui revient ici en configuration), chapitre 7 (le fichier de configuration, qui s'enrichit).

Cours¶

24.1 Pourquoi un stockage intégré¶

Historiquement, Vault ne stockait rien lui-même : il écrivait son chiffré dans un backend externe, et sa haute disponibilité reposait sur celle de ce backend. L'architecture fonctionnait, au prix d'un deuxième système distribué à installer, sécuriser, superviser et sauvegarder. Un cluster pour protéger un cluster.

Le stockage intégré, généralisé depuis la série 1.4, a renversé la pratique : chaque nœud embarque sa copie des données et les nœuds se répliquent entre eux par Raft. Plus de dépendance externe, une seule surface à durcir, et une propriété de sécurité qui tombe naturellement : ce que Raft réplique est le chiffré du chapitre 6, et aucun backend tiers n'a plus l'occasion de voir quoi que ce soit.

C'est le choix par défaut moderne, celui du fil rouge depuis le chapitre 7 : le mono-nœud d'Astrea était déjà un cluster Raft d'une seule voix, et cette partie lui en donne deux de plus.

24.2 Le problème que le consensus résout¶

Répliquer paraît simple : trois serveurs, trois copies. La difficulté n'est pas la copie, c'est l'accord, et deux scénarios suffisent à la faire sentir.

Premier scénario : deux clients écrivent presque en même temps sur deux nœuds différents. Quelle version gagne, et comment les trois copies convergent-elles vers la même histoire ?

Second scénario, le pire : le réseau se coupe en deux et chaque moitié continue d'accepter des écritures. À la reconnexion, il existe deux passés incompatibles. C'est l'accident dont un système de secrets ne se relève pas : deux keyrings divergents, deux histoires de tokens.

Le consensus rend ces scénarios impossibles par construction. À tout instant il n'existe qu'une seule histoire des écritures, et une écriture n'est réputée faite que lorsqu'une majorité de nœuds l'a durablement acceptée. Le prix est assumé : quand la majorité n'est pas joignable, le système préfère s'arrêter d'écrire plutôt que de diverger. Pour un coffre-fort, c'est le bon côté du dilemme.

24.3 Raft, compris pour de bon¶

Raft organise le consensus autour d'une idée simple : un journal répliqué, tenu par un chef élu. À tout moment, un nœud occupe l'un de trois rôles.

Le leader, unique, reçoit toutes les écritures. Il les ajoute à son journal, une suite ordonnée et numérotée d'opérations, les diffuse aux autres, et déclare une entrée engagée dès qu'une majorité l'a écrite sur disque. C'est alors, et alors seulement, que l'écriture est acquittée au client et appliquée à l'état.

Les followers répliquent le journal du leader et attestent leurs écritures. Ils savent aussi que le leader vit, parce qu'il le leur prouve en continu par des battements de cœur.

Le candidat est un rôle de transition. Quand un follower cesse d'entendre le leader au-delà d'un délai tiré au hasard, pour éviter les candidatures simultanées, il ouvre une élection : il incrémente le terme, l'horloge logique de Raft qui départage les histoires, sollicite les votes, et devient leader s'il obtient la majorité.

Deux garde-fous font la sûreté de l'ensemble. Un nœud ne vote qu'une fois par terme. Et il ne vote jamais pour un candidat dont le journal est en retard sur le sien. Le nouveau leader a donc, par construction, toutes les entrées engagées : une bascule ne perd jamais une écriture acquittée.

24.4 L'arithmétique du quorum¶

La majorité de N nœuds est N divisé par deux, plus un, et toute l'ingénierie du cluster tient dans cette ligne.

Nœuds	Majorité	Pertes tolérées	Verdict
2	2	0	pire qu'un mono-nœud, pour deux fois le prix
3	2	1	le choix standard
4	3	1	la tolérance de trois, le coût de quatre
5	3	2	pour qui doit survivre à deux pertes simultanées

La règle est donc un nombre impair, dimensionné par les pertes à tolérer, et par la géographie. Raft échange des battements de cœur et des votes en permanence : il veut des liens à faible latence. Étirer un cluster sur des sites distants dégrade tout, élections intempestives et écritures lentes ; la réponse aux distances n'est pas d'étirer Raft mais de répliquer entre clusters, l'affaire de l'édition Enterprise.

Astrea choisit trois. La tolérance d'une panne couvre le risque dimensionnant, une machine ou un hyperviseur, et la perte de site relèvera du plan de reprise. Décision consignée, avec son critère de révision.

24.5 Configurer un nœud¶

Le fichier du chapitre 7 s'enrichit de sa dimension cluster.

# /etc/vault.d/vault.hcl -- vault-core-02, extrait cluster
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-core-02"          # identite STABLE du noeud dans le cluster

  retry_join {
    leader_api_addr     = "https://10.10.20.11:8200"
    leader_ca_cert_file = "/etc/vault.d/tls/astrea-ca.pem"
  }
  retry_join {
    leader_api_addr     = "https://10.10.20.13:8200"
    leader_ca_cert_file = "/etc/vault.d/tls/astrea-ca.pem"
  }
}

api_addr     = "https://10.10.20.12:8200"   # comment ME joindre pour l'API
cluster_addr = "https://10.10.20.12:8201"   # comment ME joindre entre noeuds

disable_mlock = true                         # consigne ch.5 : integrated storage

L'identité du nœud est stable pour la vie de la machine et unique absolument : deux nœuds au même identifiant sont une corruption d'annuaire en attente.

Les jonctions disent au nœud qui aller trouver pour rejoindre. Plusieurs blocs, un par pair possible, parce qu'un seul point de jonction est un point de défaillance de plus. Et la jonction est vérifiée : la référence à l'autorité valide le certificat du nœud visé, aujourd'hui le matériel de laboratoire, demain la chaîne interne.

Les deux adresses se distinguent une fois pour toutes. L'une est l'adresse à laquelle ce nœud se déclare joignable pour l'API, et elle servira aux redirections du chapitre 26. L'autre est son adresse de trafic inter-nœuds, le port de cluster où circulent réplication, votes et transmission de requêtes, sous un TLS que Vault gère lui-même. Rien à provisionner, mais un flux à autoriser au pare-feu entre les nœuds, et seulement entre eux.

La consigne mémoire, enfin, applique le chapitre 5, avec sa contrepartie non négociable : l'échange désactivé sur la machine.

24.6 Ce que chaque nœud détient¶

Chaque nœud détient une copie complète du coffre : tout le stockage chiffré par la barrière, plus le journal Raft. Il faut en tirer trois conséquences, dans cet ordre.

La bonne : n'importe quel nœud survivant suffit à reconstruire le service. C'est la définition de la redondance.

La sérieuse : chaque disque est le coffre. Voler le disque du troisième nœud vole exactement autant que celui du premier : un bloc chiffré, certes, mais le bloc entier. La doctrine du chapitre 5 se multiplie par le nombre de nœuds, et le principe des copies passées s'applique à chaque disque retiré.

La structurante : rejoindre le cluster, c'est recevoir cette copie. La réplication livre du chiffré, et le lire exige de desceller, donc d'atteindre le seal. La sécurité de l'adhésion repose ainsi sur deux gardiens connus, le pare-feu et la garde du seal, et sur une vigilance nouvelle : la liste des pairs se lit et se surveille.

Exemple : la note de dimensionnement d'Astrea¶

Extrait du dossier d'architecture, section « pourquoi trois ».

Le risque dimensionnant est la perte d'une machine ou d'un hôte de virtualisation, événement plausible chaque année. Trois nœuds l'absorbent sans interruption.

Cinq nœuds toléreraient deux pertes simultanées, un scénario qui relève, à l'échelle d'Astrea, du sinistre de site. Or un sinistre de site emporte aussi le réseau, l'alimentation et la base : la réponse n'est pas deux voix de plus dans la même salle, c'est le plan de reprise de la partie XI.

Deux et quatre sont écartés par l'arithmétique. L'étirement géographique est écarté par la nature de Raft.

Décision : trois nœuds, même zone réseau, trois hôtes de virtualisation distincts, la tolérance de panne ne valant que si les pannes sont indépendantes. Critère de révision daté. La note tient en une page, et c'est sa force.

Sécurité : le cluster comme surface¶

Le port de cluster n'appartient qu'aux nœuds. Réplication, votes et transmission ne concernent ni les clients ni l'administration. Le pare-feu l'autorise entre les trois adresses et refuse le reste : un port de cluster exposé est une porte de service ouverte sur la salle des coffres.

Trois nœuds, trois coffres. Chaque machine réformée, chaque instantané d'hyperviseur, chaque disque parti en garantie se traite comme une copie complète et datée du coffre, ouvrable par le matériel de scellement de son époque.

L'adhésion se gagne et se surveille. Rejoindre exige d'atteindre l'API d'un pair, d'être accepté, puis de desceller pour lire. Aucun de ces gardiens n'est optionnel, et la liste des pairs se relit à chaque revue.

L'indépendance des pannes se construit. Trois nœuds sur le même hôte, la même baie ou la même alimentation ont l'arithmétique de trois et la réalité d'un seul. Le placement physique fait partie du dossier de sécurité.

Erreurs fréquentes¶

Un cluster à deux ou quatre nœuds. L'impair n'est pas une esthétique, c'est l'arithmétique de la majorité (section 24.4).

Étirer Raft entre sites distants. Élections intempestives et écritures au rythme du lien le plus lent. Les distances se traitent par réplication entre clusters (section 24.4).

Une identité de nœud dupliquée ou changeante. L'annuaire du cluster se corrompt ou accumule des fantômes. L'identifiant est stable, unique, consigné (section 24.5).

Une seule jonction déclarée. Le jour où ce pair-là est mort, aucun nœud ne peut plus rejoindre : la redondance du cluster ne protège pas sa propre porte d'entrée (section 24.5).

Réutiliser un répertoire de données d'un ancien cluster. Le nœud arrive avec une histoire, et la greffe produit des conflits difficiles à diagnostiquer. Un nœud neuf part d'un répertoire vide (sections 24.5, 25.2).

Oublier la contrepartie de la consigne mémoire. Verrou désactivé et échange désactivé vont par paire ; l'un sans l'autre écrit potentiellement des secrets sur disque, hors barrière (section 24.5).

Mise en pratique : dimensionner et configurer¶

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

Pour trois contextes, une équipe de dix personnes avec un Vault de laboratoire, Astrea, et un groupe exigeant la tolérance de deux pannes simultanées, proposez le nombre de nœuds, le placement, et la phrase de justification qui irait au dossier.
Écrivez le fichier de configuration complet du troisième nœud, en réutilisant tout ce que les chapitres 7 et 23 ont établi.
L'auditeur demande ce que contient exactement le disque du deuxième nœud, et ce qu'un voleur peut en faire. Rédigez la réponse en six phrases, chapitres à l'appui.

Questions de compréhension¶

Qu'apporte le stockage intégré par rapport à un backend externe, et quelle propriété de sécurité tombe naturellement avec lui ?
Décrivez les deux scénarios que le consensus rend impossibles, et le prix assumé de cette garantie.
Expliquez les trois rôles de Raft et le cycle d'une écriture, de la réception à l'acquittement.
À quoi sert le terme, et quels sont les deux garde-fous qui protègent les écritures engagées ?
Donnez la formule de la majorité et l'analyse de deux, trois, quatre et cinq nœuds.
Pourquoi Raft ne s'étire-t-il pas entre sites, et quelle est la bonne réponse aux distances ?
Distinguez les deux adresses annoncées, et dites qui gère le TLS du port de cluster.
Énoncez ce que chaque nœud détient et les trois conséquences qui en découlent.

Synthèse¶

Le stockage intégré fait de chaque nœud un porteur complet du coffre, et de Raft leur accord : un journal unique tenu par un leader élu, où une écriture n'existe qu'engagée par la majorité, et un système qui préfère s'arrêter d'écrire plutôt que de diverger. L'arithmétique commande l'architecture : l'impair, dimensionné par les pertes à tolérer, des liens à faible latence, des pannes rendues indépendantes par le placement. Quelques lignes suffisent à la configuration, toutes décisives. Et la sécurité tient en une phrase : chaque disque est le coffre, chiffré mais entier, et l'adhésion se garde par le pare-feu, le seal et la surveillance des pairs.