Lycée Notre-Dame de la Providence — Avranches BTS SIO — DOCUMENTS · SISR 2 · © G. HOMMET
QR code d'accès à cette page

La haute disponibilité (HA)

La haute disponibilité (HA)

Cours ponctuel — Bloc 2 - SISR 2 Prérequis conseillés : les fiches "Le cluster Proxmox VE", "Ceph" et "Le quorum dans un cluster"

1. Définition

La haute disponibilité (High Availability, HA) désigne l'ensemble des mécanismes visant à maintenir un service accessible malgré la panne d'un composant de l'infrastructure, idéalement sans intervention humaine et avec une interruption de service minimale, voire nulle.

💡 À retenir : la haute disponibilité ne signifie pas "zéro panne" (ce qui est impossible), mais "reprise automatique et rapide en cas de panne", de façon à minimiser l'impact perçu par les utilisateurs finaux.

2. Haute disponibilité vs migration à chaud : ne pas confondre

Migration à chaud (live migration) Haute disponibilité (HA)
Déclenchement Décidée manuellement par un administrateur Automatique, en réaction à une panne détectée
État du nœud source Fonctionnel (opération planifiée, ex. maintenance) En panne ou injoignable
Objectif Éviter une coupure lors d'une opération planifiée Réagir à un incident imprévu
⚠️ Piège classique : confondre les deux mécanismes. La migration à chaud suppose que le nœud source fonctionne encore normalement (juste avant une maintenance planifiée, par exemple). La haute disponibilité intervient au contraire précisément parce que le nœud ne répond plus.

3. Les prérequis techniques de la haute disponibilité

La haute disponibilité automatique ne peut pas fonctionner sans plusieurs briques déjà étudiées :

  1. Un cluster (plusieurs nœuds coordonnés — voir la fiche dédiée)
  2. Un quorum fonctionnel (pour que la décision de redémarrage ailleurs soit prise en toute sécurité — voir la fiche dédiée)
  3. Un stockage partagé (type Ceph — voir la fiche dédiée), pour que le disque de la VM soit immédiatement accessible depuis le nœud de secours, sans copie préalable
🔑 Point clé : la haute disponibilité n'est pas une fonctionnalité isolée que l'on active d'un simple clic — c'est l'aboutissement de plusieurs mécanismes (cluster + quorum + stockage partagé) qui doivent tous être correctement en place au préalable.

4. Le déroulé d'un basculement HA (exemple Proxmox)

  1. Un nœud du cluster (nœud A) cesse de répondre (panne matérielle, coupure réseau...)
  2. Les autres nœuds, via le mécanisme de quorum, confirment collectivement que le nœud A est bien injoignable — et non que c'est eux-mêmes qui ont un problème de communication
  3. Le quorum étant maintenu par le reste du cluster, celui-ci est autorisé à agir
  4. Les VM configurées en haute disponibilité, qui tournaient sur le nœud A, sont redémarrées automatiquement sur un autre nœud disposant de ressources suffisantes
  5. Comme le stockage est partagé (Ceph), la VM redémarre avec ses données intactes, sans copie préalable nécessaire
⚠️ À bien comprendre : ce basculement implique un redémarrage de la VM (pas une continuité parfaite comme lors d'une migration à chaud). Il y a donc une interruption de service, mais brève et automatique, plutôt qu'une panne prolongée nécessitant une intervention manuelle.

5. Le fencing : garantir qu'un seul exemplaire tourne à la fois

Avant de redémarrer une VM ailleurs, il est indispensable de s'assurer que le nœud en panne ne continue pas, de son côté, à exécuter la même VM (ce qui créerait deux instances actives sur les mêmes données — le même problème que le split-brain vu dans la fiche sur le quorum). Ce mécanisme de garantie s'appelle le fencing.

🎯 Bonne pratique : dans une infrastructure de production critique, un mécanisme de fencing matériel (ex. coupure d'alimentation à distance du nœud suspecté en panne, via une carte de gestion type IPMI) est plus fiable qu'une simple confirmation logicielle, car il élimine tout doute sur l'état réel du nœud.

6. Configurer un groupe HA (vue d'ensemble Proxmox)

Dans l'interface Proxmox, la haute disponibilité se configure via :

  1. La création d'un groupe HA, définissant quels nœuds peuvent accueillir les VM protégées et avec quelle priorité
  2. L'ajout des ressources (VM ou conteneurs) à protéger dans ce groupe
  3. La définition, pour chaque ressource, du comportement souhaité (démarrage automatique, nombre de tentatives de redémarrage...)

7. Ce que la haute disponibilité ne protège PAS

⚠️ Limite importante à connaître : la haute disponibilité protège contre la panne d'un nœud physique. Elle ne protège pas contre une erreur applicative à l'intérieur de la VM elle-même, une corruption de données, ou une erreur humaine (suppression accidentelle d'un fichier). Ces risques nécessitent des sauvegardes régulières, qui restent indispensables même avec la HA en place.

8. Glossaire

Terme Définition
HA (High Availability) Ensemble de mécanismes assurant la reprise automatique d'un service après panne
Fencing Mécanisme garantissant qu'un nœud en panne ne continue pas à exécuter une ressource redémarrée ailleurs
Groupe HA Regroupement Proxmox définissant quels nœuds peuvent accueillir des ressources protégées
IPMI Interface de gestion matérielle à distance, utilisable pour un fencing matériel fiable

9. Vérifiez vos connaissances

1. Quelle est la principale différence entre migration à chaud et haute disponibilité ?

2. Quels sont les 3 prérequis techniques indispensables à la haute disponibilité automatique ?

3. Que garantit le mécanisme de fencing ?

4. La haute disponibilité protège-t-elle contre une suppression accidentelle de fichier à l'intérieur d'une VM ?

5. Lors d'un basculement HA, la VM redémarrée conserve-t-elle ses données ?