📄 contenu.md 🔒 1ca4678f…f8b4feb5 Se connecter pour télécharger ← Retour
# 10. Haute disponibilité et clustering

Cette section présente les concepts génériques de tolérance aux pannes
distribuée — indépendants de toute implémentation particulière — qui
sous-tendent la plupart des architectures de clustering Linux.

## Le problème de fond : éviter le point unique de défaillance

Un système en haute disponibilité (HA) élimine tout **point unique de
défaillance** (SPOF, *Single Point of Failure*) en dupliquant chaque
composant critique sur plusieurs nœuds, de sorte que la panne d'un seul
nœud n'interrompe pas le service global.

## Heartbeat et détection de panne

Chaque nœud d'un cluster émet périodiquement un signal de vie
(*heartbeat*) aux autres nœuds. L'absence de signal au-delà d'un délai
configuré déclenche une suspicion de panne — mais la détection de panne
distribuée est intrinsèquement ambiguë : un nœud silencieux est-il
réellement en panne, ou simplement injoignable temporairement (partition
réseau) ? C'est exactement le problème que résout le mécanisme de quorum.

## Quorum — éviter le split-brain

Un cluster **partitionné** en deux groupes qui continueraient chacun à agir
comme s'ils étaient seuls légitimes (*split-brain*) peut provoquer une
corruption de données (deux nœuds qui pensent tous deux être le nœud
actif principal). Le **quorum** impose qu'un groupe de nœuds ne puisse agir
comme le cluster légitime que s'il représente une **majorité stricte** du
nombre total de nœuds configurés — un cluster à 5 nœuds partitionné en
groupes de 3 et 2 ne laisse que le groupe de 3 opérer, l'autre se met en
lecture seule ou s'arrête, par construction incapable d'obtenir la
majorité. D'où la recommandation classique d'un nombre **impair** de nœuds
votants, pour éviter tout partage à parts égales.

## Élection de leader

Dans de nombreuses architectures, un seul nœud à la fois assume un rôle de
coordinateur (*leader*), les autres agissant en suiveurs (*followers*). Un
**algorithme de consensus distribué** (la famille Raft étant la plus
répandue pour sa lisibilité, Paxos étant l'algorithme historique de
référence académique) garantit qu'à tout instant, au plus un nœud peut
légitimement se considérer leader — via un mécanisme de vote à majorité et
de mandat borné dans le temps (*term*), après lequel une nouvelle élection
peut avoir lieu si le leader courant devient injoignable.

## Bascule automatique (failover)

Quand un nœud actif tombe, un mécanisme de **bascule** (*failover*)
promeut automatiquement un nœud de secours pour reprendre le service —
l'objectif de conception central étant de minimiser la fenêtre
d'indisponibilité perçue par le client. Deux stratégies principales :

- **Actif/passif** : un seul nœud sert le trafic à la fois, le ou les
  autres restent en veille chaude prêts à basculer.
- **Actif/actif** : plusieurs nœuds servent simultanément (avec un
  équilibrage de charge en amont), la perte d'un nœud réduit la capacité
  sans interrompre le service — au prix d'une coordination plus complexe
  pour garder les données cohérentes entre nœuds actifs.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*
3.1 Ko BLAKE3 : 1ca4678f…f8b4feb5