Clustering

Un cluster regroupe plusieurs machines (nœuds) qui coopèrent pour se comporter comme un système unique, plus disponible et/ou plus puissant que n’importe lequel de ses nœuds pris isolément. C’est le mécanisme concret qui met en œuvre la haute disponibilité au niveau applicatif ou système, au-delà du simple basculement réseau (VRRP).

Trois grandes familles de clusters

• Cluster de disponibilité (failover cluster) : vise avant tout la continuité de service — si un nœud tombe, un autre reprend le service, avec un minimum de coupure. Typique pour un serveur de fichiers, une base de données critique.
• Cluster de calcul (HPC — High Performance Computing) : vise la puissance de calcul cumulée en répartissant une charge de travail entre de nombreux nœuds — simulation scientifique, rendu, entraînement de modèles.
• Cluster de répartition de charge (load balancing) : plusieurs nœuds actifs traitent des requêtes en parallèle, avec un répartiteur en frontal — le modèle typique d’une ferme de serveurs web.

Le problème central : le quorum

Dès qu’un cluster comporte plusieurs nœuds capables chacun de prendre des décisions, il doit résoudre un problème fondamental : que se passe-t-il si les nœuds ne peuvent plus se voir entre eux ? Sans règle claire, chaque groupe de nœuds isolés pourrait se croire seul survivant et continuer à agir — le fameux split-brain.

Le quorum est la règle qui tranche : un sous-ensemble de nœuds ne peut agir en tant que cluster que s’il représente une majorité stricte du nombre total de nœuds (ou dispose d’un arbitre désigné). Avec 3 nœuds, il faut au moins 2 nœuds d’accord pour former un quorum ; avec 2 nœuds seulement, aucune majorité stricte n’est possible en cas de coupure entre eux — d’où l’usage fréquent d’un witness/arbitre (un troisième nœud léger, ou un service de quorum dans le cloud) pour départager un cluster à deux nœuds.

Pourquoi un nombre impair de nœuds

Un cluster à 3 ou 5 nœuds tolère la perte d’un nœud (ou deux pour 5) tout en gardant un quorum clair et sans ambiguïté possible. Un cluster à 4 nœuds coûte plus cher qu’à 3 pour un gain de résilience souvent nul en pratique (une coupure 2-2 ne dégage aucune majorité) — les architectures de clustering (etcd, Consul, la plupart des bases de données distribuées) recommandent presque toujours un nombre impair.

Stockage partagé ou répliqué

Un cluster de disponibilité doit résoudre la question des données : soit tous les nœuds accèdent au même stockage partagé (SAN, voir Multipath), soit chaque nœud a sa propre copie répliquée en continu vers les autres (réplication synchrone ou asynchrone selon la tolérance à la perte de données récente en cas de panne brutale).

Cas d’usage courants

• Bases de données : PostgreSQL (Patroni), MySQL (Group Replication), ou des bases nativement distribuées (Cassandra, CockroachDB).
• Systèmes de fichiers/orchestration : Kubernetes lui-même repose sur un cluster etcd pour stocker son état avec quorum.
• Virtualisation : VMware vSphere HA/DRS, Proxmox VE en cluster, qui redémarrent automatiquement une VM sur un autre nœud physique en cas de panne matérielle.

Point de vigilance

Un cluster mal dimensionné en capacité (chaque nœud tournant déjà proche de sa limite) ne survit pas réellement à la perte d’un nœud : les nœuds restants héritent de sa charge et peuvent s’effondrer à leur tour en cascade. Dimensionner un cluster HA suppose de prévoir la capacité en tenant compte de la perte d’au moins un nœud, pas seulement la capacité nominale à pleine disponibilité.