Aller au contenu

Chapitre 25. Exploiter un cluster Raft

Objectifs pédagogiques

Lire l'état d'un cluster. Faire entrer un nœud proprement, sans commettre l'erreur fatale de l'initialisation. Faire sortir un nœud dans le bon ordre et traiter son disque. Configurer l'autopilot et situer les capacités Enterprise. Superviser la croissance du stockage. Conduire une mise à jour glissante.

Prérequis

Chapitre 24 (le vocabulaire, que ce chapitre manipule), chapitre 21 (les copies passées, dont les disques sortants relèvent), chapitre 8 (l'initialisation, pour comprendre pourquoi on ne la refait jamais).

Cours

25.1 Lire le cluster

Deux commandes forment le tableau de bord, à connaître avant tout geste.

[Laboratoire]

vault operator raft list-peers
# Node             Address              State       Voter
# vault-core-01    10.10.20.11:8201     leader      true
# vault-core-02    10.10.20.12:8201     follower    true
# vault-core-03    10.10.20.13:8201     follower    true

vault operator raft autopilot state
# Healthy: true ; Voters: 3 ; ... par noeud : last contact, index, stabilisation

La liste des pairs est l'annuaire : qui est membre, qui mène, qui vote. La colonne des votants est décisive, car seul leur nombre entre dans l'arithmétique de la majorité ; un membre non votant réplique sans compter.

L'état de l'autopilot est le bulletin de santé : verdict global, et par nœud le dernier contact, le retard de journal, l'état de stabilisation. C'est lui qu'on lit quand quelque chose est lent, avant d'inventer des hypothèses.

Ces deux sorties se relèvent aussi à froid, dans le registre après chaque changement de topologie. La supervision alertera sur toute variation du nombre de votants, l'événement qu'on ne veut jamais découvrir par hasard.

25.2 Faire entrer un nœud

L'entrée a deux voies : la déclarative, où le nœud frappe aux portes listées jusqu'à ce qu'on lui ouvre, et la manuelle, à la demande. Et une règle absolue qui prime tout : un nœud qui rejoint ne s'initialise jamais.

L'initialisation crée un cluster neuf, avec une clé racine neuve et une histoire vide. Exécutée sur une machine destinée à rejoindre, elle fabrique un second cluster parallèle et vide, avec son propre seal, que le premier ne reconnaîtra pas. C'est l'erreur classique du débutant pressé, et des heures de confusion.

La séquence correcte compte trois temps. Le service démarre avec sa configuration, jonctions incluses. Le nœud rejoint : il est accepté et reçoit l'amorce de réplication. Puis il se descelle, et c'est ici que les deux mondes divergent.

Sous seal automatique, le descellement est immédiat et sans personne : le nœud demande au gardien de déchiffrer, la réplication se déroule, l'affaire est pliée. Sous Shamir, le nœud rejoint scellé, et il faut le desceller avec les clés du cluster : le quorum existant saisit ses parts sur ce nœud aussi. Les parts ne sont pas par machine, elles gardent la clé racine du cluster, la même partout.

Dernier temps, commun : la stabilisation. L'autopilot observe le nouveau venu pendant un délai avant de lui accorder le droit de vote. On ne compte pas une voix qu'on n'a pas encore entendue tenir.

25.3 Faire sortir un nœud

La sortie a un ordre, et l'inverser coûte cher : d'abord retirer du cluster, ensuite éteindre.

[Production]

vault operator raft remove-peer vault-core-02

Le retrait dit au cluster de cesser de compter cette voix : la majorité se recalcule sur les membres restants, et l'on sait alors que le cluster ne tolère plus de panne jusqu'au remplacement.

Éteindre d'abord, c'est laisser un fantôme : le cluster attend toujours la voix d'un mort. À trois nœuds il tient, mais il croit tolérer une panne qu'il ne tolère plus, et le fantôme pollue l'annuaire jusqu'au nettoyage.

Puis vient le disque, et le chapitre 21 en a écrit la règle avant même que le cluster n'existe : le répertoire de données d'un nœud sorti est une copie complète et datée du coffre, ouvrable par le matériel de scellement de son époque. Il se détruit de façon attestée, ou se conserve sous le régime des sauvegardes, jamais au cas où sur une étagère.

La machine réinstallée pourra revenir un jour : répertoire vide, même identité logique, jonction, stabilisation. Un retour est une entrée comme une autre.

25.4 L'autopilot

Note de version : l'autopilot accompagne le stockage intégré depuis la version 1.7. L'édition Community en porte le socle, l'édition Enterprise les automatismes avancés.

[Laboratoire]

vault operator raft autopilot get-config
vault operator raft autopilot set-config \
  -cleanup-dead-servers=true \
  -dead-server-last-contact-threshold=10m \
  -min-quorum=3 \
  -server-stabilization-time=10s

Quatre paramètres, quatre décisions. Le nettoyage des serveurs morts retire de l'annuaire un membre silencieux au-delà du seuil de dernier contact : le fantôme de la section précédente disparaît seul. C'est précieux, et c'est une lame : réglé trop court, il éjecterait un nœud simplement lent ou en maintenance.

D'où son garde-fou obligatoire, le plancher de quorum : l'autopilot ne nettoiera jamais en dessous de ce nombre de votants. Pour Astrea, trois : le nettoyage automatique ne peut pas rétrécir le cluster sous sa taille nominale, et le retrait en dessous redevient un geste humain, délibéré.

La stabilisation est le délai d'observation avant droit de vote.

L'édition Enterprise ajoute au même autopilot les mises à jour automatisées, où le cluster orchestre lui-même le remplacement progressif des nœuds, et les zones de redondance, qui répartissent les votants par zone de panne avec des remplaçants. Deux automatismes que l'édition Community exécute à la main.

25.5 La croissance du stockage

Le répertoire de données vit, et sa vie se comprend en deux objets.

Le journal Raft : chaque écriture engagée s'y ajoute, et il croîtrait sans fin si Vault ne le compactait par des instantanés internes automatiques. Ce sont des états complets pris périodiquement, qui permettent de tronquer le journal antérieur. Mécanique interne, à ne pas confondre avec les snapshots de sauvegarde du chapitre 33, qui sont un geste d'exploitation.

La base de données elle-même, dont la taille suit le contenu réel. Et ce qui fait gonfler un Vault n'est presque jamais KV : ce sont les objets à cycle de vie, les baux par milliers d'un moteur dynamique mal calibré, les certificats stockés d'une PKI sans entretien, les tokens de service qui ne meurent jamais.

La supervision du disque est donc double : l'espace, avec une alerte assez tôt pour agir puisqu'un cluster qui remplit ses disques s'arrête d'écrire, et la cause, par le compte de baux et de certificats. La courbe qui monte dit quel chapitre relire.

Un dernier réflexe : après une purge massive, l'espace ne revient pas toujours immédiatement au système de fichiers, la base réutilisant ses pages libérées. On juge la tendance, pas l'instant.

25.6 Mettre à jour un cluster

La mise à jour glissante est la récompense du cluster : le service ne s'arrête plus pour les versions. L'ordre est une règle courte : les standbys d'abord, l'actif en dernier, et l'actif ne se met à jour qu'après avoir cédé la main proprement.

[Production]

# Sur chaque standby, l'un apres l'autre :
#   arret du service, binaire remplace, demarrage, descellement (automatique au fil rouge),
#   attente : list-peers le montre follower, autopilot state le dit sain.
# Puis, sur l'actif :
vault operator step-down     # cede le leadership -- une election immediate suit
# ... et la meme sequence de mise a jour, devenu standby.

Trois disciplines encadrent la valse.

Un nœud à la fois, avec la santé constatée avant le suivant. Pendant qu'un nœud est arrêté, le cluster est à deux voix : il tient, mais ne tolère plus rien. On ne double jamais la fenêtre de fragilité.

Le mélange de versions est un état de passage, pas un régime. La fenêtre où cohabitent deux versions se traverse, elle ne s'habite pas, et les notes de version se lisent avant, certains sauts exigeant des étapes.

Le retour se prépare : binaire précédent conservé, et pour les sauts majeurs, la sauvegarde du chapitre 33 prise avant le premier nœud. Une mise à jour dont on ne sait pas revenir n'est pas une mise à jour, c'est un pari.

Exemple : le remplacement d'un nœud défaillant

La séquence consignée, à partir d'une alerte de supervision sur un disque système mort.

Constat. La liste des pairs montre le nœud follower silencieux, l'autopilot compte deux voix saines sur trois. Le cluster sert normalement, tolérance de panne consommée.

Décision. Pas d'attente du nettoyage automatique : le plancher de quorum le bloque, comme prévu, le retrait sous la taille nominale étant un geste humain. Retrait explicite du pair, annuaire propre à deux votants, registre.

Reconstruction. Machine reconstruite par la gestion de configuration, chapitre 7 déroulé, répertoire vide, même identité, token de seal propre. Démarrage, jonction, descellement automatique par le gardien, réplication.

Retour. Stabilisation écoulée, trois votants, autopilot sain.

Clôture. Le disque défaillant part en destruction attestée : c'était une copie complète du coffre, et la ligne de registre le rappelle en toutes lettres.

Trente-huit minutes, zéro interruption de service, zéro cérémonie. C'est la phrase que le registre souligne, parce qu'elle paie d'un coup les parties VII et VIII.

Sécurité : l'exploitation comme surface

Le retrait de pair est un pouvoir. Retirer des voix, c'est pouvoir rétrécir un cluster jusqu'à la fragilité. Ces chemins rejoignent les chemins de pouvoir du chapitre 11 : périmètre restreint, audit, revue.

Le nettoyage automatique se borne. Sans plancher bien réglé, une partition réseau un peu longue ferait éjecter des nœuds sains par l'automate. L'automate range, il ne décide pas de la taille.

Chaque sortie de nœud est une sortie de coffre. Disque, image de machine virtuelle, instantané d'hyperviseur pris avant intervention : autant de copies complètes datées, à détruire ou à traiter au régime des sauvegardes.

La fenêtre de mise à jour est une fenêtre de fragilité. Un nœud arrêté, c'est la tolérance de panne consommée. Les mises à jour se font en heures calmes, un nœud à la fois, et jamais en même temps qu'une autre opération risquée.

Erreurs fréquentes

Initialiser un nœud qui devait rejoindre. Le geste crée un cluster parallèle vide avec sa propre clé racine : deux mondes qui s'ignorent (section 25.2).

Éteindre avant de retirer. Le fantôme reste au compte des voix : l'annuaire ment, la tolérance affichée est fausse (section 25.3).

Jeter un disque de nœud sans destruction. Il est chiffré, oui, et c'est une copie complète du coffre, ouvrable par le matériel de son époque (section 25.3).

Un nettoyage automatique sans plancher. L'automate rétrécit le cluster un jour de réseau lent. Les deux paramètres se règlent ensemble (section 25.4).

Commencer la mise à jour par l'actif. Une bascule subie en plein remplacement de binaire, au moment le plus fragile (section 25.6).

Enchaîner les nœuds sans constater la santé. Deux nœuds arrêtés pour aller vite sur un cluster de trois : plus de majorité, arrêt total, et la mise à jour devient l'incident (section 25.6).

Mise en pratique : trois runbooks d'exploitation

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

  1. Rédigez le runbook de remplacement d'un nœud défaillant : constats initiaux, décision, retrait, reconstruction, retour, vérifications, sort du matériel, avec les commandes et les lignes de registre.
  2. Proposez la configuration autopilot d'Astrea avec une justification par paramètre, y compris le scénario que chaque réglage prévient.
  3. Écrivez le plan de mise à jour vers la version mineure suivante : préparation, ordre, vérifications entre nœuds, critères d'abandon et de retour arrière.

Questions de compréhension

  1. Que lisent respectivement les deux commandes du tableau de bord, et pourquoi la colonne des votants est-elle décisive ?
  2. Énoncez la règle absolue de l'entrée d'un nœud, et ce que produit sa violation.
  3. En quoi le descellement d'un nœud entrant diffère-t-il selon le seal, et que gardent les parts exactement ?
  4. Pourquoi la sortie a-t-elle un ordre, et que devient la majorité après un retrait sur un cluster de trois ?
  5. Quel est le double statut du disque d'un nœud sorti, et quels traitements sont acceptables ?
  6. Décrivez les quatre paramètres du socle autopilot et le couple qui se règle ensemble.
  7. Qu'est-ce qui fait réellement grossir le stockage, et que ne faut-il pas confondre avec les snapshots de sauvegarde ?
  8. Restituez l'ordre et les trois disciplines d'une mise à jour glissante.

Synthèse

Exploiter le cluster, c'est d'abord le lire, l'annuaire des votants et le bulletin de santé, puis maîtriser trois gestes à l'ordre strict. L'entrée : rejoindre et jamais initialiser, desceller avec les clés du cluster ou par le gardien, laisser la stabilisation accorder la voix. La sortie : retirer puis éteindre, et traiter le disque comme la copie complète et datée qu'il est. La mise à jour : standbys d'abord, cession de la main, actif en dernier, santé constatée entre chaque. L'autopilot range l'annuaire dans les limites de son plancher, et la croissance du stockage se supervise par ses causes.