Name: Le Socle du Fer — Semaine 14 — Haute Disponibilité et Sauvegarde
Author: Amine RAITI

RATIO

LE SOCLE DU FER · SUPPORT DE COURS · SEMAINE 14

◆◆◆

HAUTE DISPONIBILITÉ
ET SAUVEGARDE
Semaine 14 sur 26 · Bloc 5 — OS Bare Metal
8h théorie · 27h pratique

◆

◆ OBJECTIFS PÉDAGOGIQUES DE LA SEMAINE

1. Comprendre les notions de RPO et RTO
2. Configurer un cluster simple à deux nœuds sur l'hyperviseur
3. Tester la bascule automatique d'une VM en cas de panne d'un nœud
4. Mettre en place une stratégie de sauvegarde GFS (Grand-Père, Père, Fils)
5. Automatiser les sauvegardes et tester la restauration

◆◆◆

⚠ AVERTISSEMENT — PÉRENNITÉ DES VERSIONS CITÉES

Les mécanismes de cluster et de HA évoluent avec les versions des hyperviseurs. Ce support présente les concepts génériques ; le formateur adapte les procédures spécifiques à l'outil en cours.

◆

Amine RAITI · Architecte Infrastructure & SRE
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine
Opération Dindon

RATIO

PLAN DE COURS · 8H

FIL CONDUCTEUR THÉORIQUE

◆

14.1 · RPO, RTO et notion de continuité de service2h

— RPO (Recovery Point Objective) : quelle est la perte de données maximale acceptable ?
— RTO (Recovery Time Objective) : combien de temps peut-on tolérer d'être hors service ?
— Ces deux paramètres définissent la stratégie de sauvegarde et de HA à mettre en place — faire calculer aux apprenants le RPO et RTO d'un scénario métier fourni

14.2 · Cluster et haute disponibilité3h

— Principe du cluster : plusieurs hôtes physiques partageant un pool de ressources, avec basculement automatique des VMs en cas de panne d'un hôte
— Notion de quorum : pourquoi un nombre impair de nœuds est recommandé (rappel de la logique de vote de S3 — Boole appliqué à la décision de cluster)
— Stockage partagé ou réplication synchrone comme prérequis du HA

14.3 · Stratégies de sauvegarde3h

— Différence sauvegarde complète / incrémentale / différentielle — avantages et inconvénients de chacune
— Stratégie GFS (Grand-père, Père, Fils) : rotation des jeux de sauvegarde sur des périodes journalières, hebdomadaires et mensuelles
— Règle 3-2-1 : 3 copies, 2 supports différents, 1 copie hors site

RATIO

TP1 · CLUSTER ET BASCULE AUTOMATIQUE · 14H

Matériel : deux nœuds physiques ou deux machines virtuelles jouant le rôle de nœuds d'hyperviseur, stockage partagé (NFS ou Ceph minimal si disponible) ou réplication selon la version de l'hyperviseur utilisé.

(3h) Configuration du cluster deux nœuds : ajout du second nœud au cluster, vérification du quorum, exploration de l'interface de gestion du cluster.

(3h) Migration d'une VM d'un nœud à l'autre (live migration si le stockage partagé est disponible, sinon migration à froid) — observer le comportement de la VM pendant la migration.

(4h) Test de bascule en cas de panne : couper volontairement le réseau ou l'alimentation d'un nœud, observer la réaction du cluster (délai de détection, bascule automatique de la VM sur le nœud survivant).

(2h) Analyse des événements enregistrés dans les journaux du cluster pendant la panne simulée et la récupération, identification du délai réel de basculement.

(2h) Rédaction d'un tableau documentant le RPO et RTO observés pendant le test, comparaison avec les objectifs fixés au départ.

CORRIGÉ TP1

Résultats attendus du test de bascule : le délai de détection de la panne d'un nœud est typiquement de quelques secondes à quelques minutes selon la configuration du cluster (heartbeat timeout). La VM doit redémarrer automatiquement sur le nœud survivant, avec un RTO effectif correspondant à ce délai de détection + le temps de démarrage de la VM.

Point pédagogique sur le RPO : en cas de panne sans stockage partagé, les données non sauvegardées depuis la dernière snapshot ou sauvegarde sont perdues — le RPO est donc directement lié à la fréquence des sauvegardes, pas à la configuration HA seule.

RATIO

TP2 · STRATÉGIE DE SAUVEGARDE AUTOMATISÉE · 13H

Matériel : hyperviseur configuré au TP1, espace de stockage externe (NAS ou disque dédié).

(3h) Configuration du stockage de sauvegarde externe sur l'hyperviseur, vérification de la connectivité et de l'espace disponible.

(3h) Planification d'une sauvegarde automatique quotidienne de la VM de test, avec rétention configurée selon la stratégie GFS (7 sauvegardes journalières, 4 hebdomadaires, 3 mensuelles).

(3h) Test de restauration complète depuis une sauvegarde : supprimer une VM, la restaurer depuis la sauvegarde la plus récente, vérifier l'intégrité du système restauré.

(2h) Test de restauration depuis une sauvegarde plus ancienne (simuler la récupération d'un état antérieur à une corruption de données), documenter la perte de données effective (RPO réel).

(2h) Rédaction du plan de sauvegarde final documentant la stratégie mise en place, les délais de rétention, et les procédures de restauration testées.

CORRIGÉ TP2

Plan de sauvegarde attendu : le document doit préciser explicitement le RPO (quelle est la perte de données maximale si une restauration est nécessaire, en fonction de la fréquence des sauvegardes), le RTO (combien de temps prend la restauration complète, mesuré pendant le TP), et la durée totale de rétention des sauvegardes.

◆ FICHE DE SYNTHÈSE — AUTO-ÉVALUATION SEMAINE 14

1. Je sais définir RPO et RTO et les calculer pour un scénario donné.

2. Je sais configurer un cluster deux nœuds sur un hyperviseur.

3. Je sais migrer une VM d'un nœud à l'autre.

4. Je sais tester et mesurer le délai de bascule automatique.

5. Je sais expliquer la stratégie de sauvegarde GFS.

6. Je sais planifier des sauvegardes automatiques avec rétention.

7. Je sais restaurer une VM depuis une sauvegarde et valider son intégrité.

8. Je sais documenter un plan de sauvegarde avec RPO et RTO mesurés.