TP 15. Perdre un cluster et le retrouver

É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 : 35. Durée : 3 h.

Objectifs

Exécuter les quatre procédures de reprise : remplacement d'un nœud, récupération d'un quorum perdu, restauration sur le cluster d'origine, reconstruction d'un cluster neuf depuis un snapshot. Mesurer les durées, puis réaccorder le monde après la restauration.

Prérequis

TP 14 terminé, snapshots disponibles et vérifiés. Chapitre 35 lu.

Étapes

1. Remplacer un nœud. Détruisez le conteneur d'un nœud sans prévenir le cluster. Constatez l'état, retirez le pair, reconstruisez, faites rejoindre, vérifiez. Chronométrez.

2. Provoquer la perte du quorum. Arrêtez deux nœuds sur trois. Constatez précisément ce qui fonctionne encore et ce qui ne fonctionne plus : lectures, écritures, connexions, renouvellements, et le comportement de app-01.

3. Réparer par la patience. Redémarrez les deux nœuds arrêtés et constatez le retour du quorum sans perte. Notez le temps total.

4. Forcer. Recommencez la perte de quorum, mais cette fois détruisez définitivement les deux nœuds. Sauvegardez le répertoire de données du survivant, puis conduisez la récupération par écriture de la configuration de pairs. Vérifiez les quatre conditions du chapitre 35 avant d'agir, et consignez ce que vous acceptez de perdre.

5. Ramener à trois. Reconstruisez deux nœuds et rejoignez.

6. Restaurer sur place. Détruisez volontairement un montage entier, puis restaurez le snapshot de la veille sur le cluster d'origine. Avant de restaurer, prenez un snapshot de l'état courant : l'énoncé insiste, et la correction expliquera pourquoi.

7. Reconstruire ailleurs. Détruisez l'ensemble du cluster. Réunissez d'abord le matériel : gardien disponible, clé de sauvegarde sortie du coffre, snapshot déchiffré et vérifié. Montez ensuite trois nœuds neufs, initialisez-les, restaurez avec l'option nécessaire, et constatez le descellement. Chronométrez chaque phase séparément.

8. Réaccorder le monde. Déroulez la liste de contrôle d'après restauration : côté Vault, côté cibles, côté clients. Cherchez en particulier les comptes de base sans bail correspondant et traitez-les. Comparez le nombre d'écarts trouvés à ce que vous attendiez.

9. Consigner. Rédigez le compte rendu : durées par phase, écarts trouvés, corrections de procédure. Indiquez quelle phase a été la plus lente, et si elle correspondait à votre estimation initiale.

Résultats attendus

Quatre procédures exécutées et chronométrées, un cluster reconstruit à partir d'un fichier et d'un gardien, une liste de réaccord complète dont les écarts sont traités, et un compte rendu comportant au moins une correction de procédure.

Erreurs possibles et diagnostic

La récupération de quorum ne change rien : le fichier de configuration de pairs a été écrit dans le mauvais répertoire, ou le service a été démarré avant son écriture. Le cluster reconstruit refuse de se desceller : le gardien n'est pas celui de l'époque du snapshot, ce qui est l'échec attendu si l'étape 7 a été abordée dans le désordre. La restauration réussit mais les applications échouent : leurs tokens ont disparu avec l'état restauré, ce qui est normal et fait partie de la liste de réaccord. Des comptes traînent côté base : ce sont les orphelins annoncés, et leur traitement fait partie de la reprise.

Questions

1. Quelle phase a consommé le plus de temps, et que faudrait-il changer pour la réduire ? Votre réponse est-elle technique ou organisationnelle ?
2. À l'étape 4, qu'avez-vous accepté de perdre exactement, et pouviez-vous le savoir précisément ?
3. Après l'étape 7, un credential émis la veille fonctionne-t-il encore ? Justifiez en distinguant ce que sait Vault et ce que sait la base.