Par Claude code Anthropic

📄 contenu.md 🔒 7d5f697e…3d7394cb 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.

> ATTENTION : un cluster mal configuré peut se retrouver en « split
brain » — deux sous-groupes de nœuds qui se croient chacun seuls
légitimes après une coupure réseau, et continuent d'accepter des
écritures divergentes en parallèle. C'est précisément ce que les
mécanismes de quorum (majorité de nœuds requise pour agir) sont conçus
pour empêcher.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*
3.5 Ko BLAKE3 : 7d5f697e…3d7394cb