TP 11. Monter un cluster Raft

Énoncé de travail pratique

Les commandes ne figurent pas dans les énoncés : elles se construisent à partir du chapitre déclencheur indiqué ci-dessous. Le laboratoire et le livret de corrections ne sont pas encore publiés. Voir les limites du livrable

Chapitre déclencheur : 26. Durée : 2 h 30.

Objectifs

Étendre un serveur unique en cluster de trois nœuds, observer le consensus au travail, provoquer une bascule et la mesurer, comprendre le descellement par nœud, et pratiquer l'entrée et la sortie d'un membre.

Prérequis

TP 10 terminé. Chapitres 24 à 26 lus.

Environnement

Ce travail pratique se déroule sur un cluster jetable sous Shamir, distinct du core du fil rouge : l'objectif est d'observer les cérémonies par nœud, ce que le Transit Seal rend justement invisible. La dernière étape rejoue l'extension sur le core, sous Transit Seal, pour mesurer la différence.

Étapes

1. Le premier nœud. Montez un cluster jetable d'un seul nœud sous Shamir, initialisé et descellé.

2. Le deuxième. Configurez core-jetable-02 avec son identifiant propre et ses jonctions vers les autres. Démarrez-le, constatez qu'il rejoint, puis constatez qu'il est scellé. Descellez-le avec les parts du cluster, et observez la différence entre « rejoindre » et « être descellé ».

3. L'erreur à ne pas commettre. Sur un troisième nœud, initialisez-le avant de le faire rejoindre. Observez ce qui se produit, expliquez-le, puis remettez-le à zéro et faites-le rejoindre correctement.

4. Observer le cluster. Listez les pairs et lisez l'état de l'autopilote. Identifiez le leader, les votants, et le délai de stabilisation.

5. Les codes de santé. Interrogez la santé des trois nœuds et relevez le motif obtenu. Expliquez la valeur retournée par chacun.

6. La bascule volontaire. Faites céder la main au leader et observez l'élection. Mesurez la durée.

7. La bascule subie. Tuez brutalement le processus du leader. Mesurez le temps jusqu'à l'élection d'un nouveau leader, observez le motif de santé, et notez ce que voit un client qui écrivait au moment de la coupure.

8. Sortie et retour. Retirez proprement un nœud du cluster, éteignez-le, puis reconstruisez-le et faites-le revenir. Vérifiez l'ordre : que se passe-t-il si l'on éteint avant de retirer ?

9. La différence. Sur le core du fil rouge, ajoutez core-02 et core-03 sous Transit Seal, avec un token de seal par nœud. Comparez le nombre d'interventions humaines nécessaires avec celui des étapes 2 et 3.

Résultats attendus

Un cluster de trois votants sur le laboratoire jetable, un motif de santé conforme, une bascule volontaire et une bascule subie mesurées, une entrée et une sortie propres, et l'extension du core réalisée sans aucune saisie de part.

Erreurs possibles et diagnostic

Le nœud rejoint puis disparaît de la liste : identifiant dupliqué avec un autre membre. Le nœud ne rejoint jamais : les jonctions pointent une adresse d'API inaccessible, ou le certificat du pair n'est pas vérifiable. Le cluster perd son leader en boucle : trois nœuds sur un hôte contraint en ressources, ce qui est un enseignement en soi. Après la sortie mal ordonnée, l'arithmétique semble fausse : le membre éteint mais non retiré compte encore comme votant.

Questions

1. Que gardent exactement les parts de Shamir dans un cluster : le nœud, le cluster, ou autre chose ? Justifiez par ce que vous avez observé à l'étape 2.
2. Un client écrivait au moment de la bascule subie. Que sait-il de son écriture, et que doit-il faire ?
3. Combien de cérémonies aurait exigé le redémarrage complet du cluster jetable, et combien en a exigé le core ? Quelle conclusion pour l'exploitation ?