Cluster Incus OS : rôles, quorum et haute disponibilité

Un cluster Incus OS répartit son état dans une base de données distribuée. Pour rester disponible malgré la panne d'un nœud, cette base élit un quorum et assigne des rôles à ses membres. Ce guide explique comment lire ces rôles, comment Incus garde le quorum, comment régler la haute disponibilité (nombre de voters et de stand-by), et comment évacuer puis restaurer un nœud pour une maintenance sans coupure. Public visé : administrateurs qui exploitent un cluster Incus OS de trois nœuds ou plus.

Ce que vous allez apprendre

Comment Incus réplique son état et pourquoi le quorum compte.
Les rôles de membre : voter, stand-by, client, leader.
Lire les rôles de votre cluster et les régler (max_voters, max_standby).
Tolérance aux pannes : offline_threshold et auto-réparation.
Évacuer et restaurer un membre pour une maintenance.

Prérequis

Un cluster Incus OS de trois nœuds. Voir Incus OS sans interface pour le montage et Cluster Incus pour les concepts généraux.
Un client Incus de confiance avec un remote vers un membre du cluster.

Toutes les commandes ci-dessous s'exécutent depuis le poste d'administration, via un remote pointant sur un membre (ici node1:). Le cluster répond de façon cohérente quel que soit le membre interrogé.

Comment Incus réplique son état

Incus stocke sa configuration, ses instances et ses réseaux dans une base répliquée (Cowsql, dérivée de SQLite) synchronisée par l'algorithme Raft. Chaque changement doit être confirmé par une majorité des membres qui votent, ce qu'on appelle le quorum. Tant que la majorité répond, le cluster accepte les écritures ; si elle est perdue, le cluster passe en lecture seule pour protéger la cohérence.

C'est pour cette raison qu'un cluster se monte avec au moins trois membres. Avec trois membres qui votent, le cluster survit à la perte d'un d'entre eux : il reste deux voix sur trois, soit une majorité. À deux membres seulement, la panne d'un seul fait perdre le quorum, d'où la recommandation constante des trois nœuds.

Les rôles de membre

Tous les membres n'ont pas le même rapport à la base. Incus attribue des rôles qui déterminent qui vote, qui réplique et qui se contente de consommer :

Rôle	Réplique la base	Vote (quorum)	Peut devenir leader
database (voter)	oui	oui	oui
database-leader	oui	oui	c'est le leader actuel
database-standby	oui	non	non, mais promu voter si un voter tombe
database-client	non	non	non

Le leader est le voter qui coordonne les écritures et surveille la santé des autres. Les stand-by répliquent la base en silence, prêts à être promus voters si l'un d'eux disparaît. Les client ne portent pas la base du tout : ils accèdent à distance et servent surtout à héberger des instances. Ce dernier rôle est la clé pour ajouter de la capacité sans alourdir le consensus, sujet du guide étendre un cluster avec des nœuds distants.

Lire les rôles de son cluster

La commande incus cluster list donne une vue synthétique des membres et de leurs rôles :

incus cluster list node1:

+-------+-----------------------------+-----------------+--------+-------------------+
| NAME  |             URL             |      ROLES      | STATUS |      MESSAGE      |
+-------+-----------------------------+-----------------+--------+-------------------+
| node1 | https://192.168.10.131:8443 | database        | ONLINE | Fully operational |
| node2 | https://192.168.10.132:8443 | database-leader | ONLINE | Fully operational |
|       |                             | database        |        |                   |
| node3 | https://192.168.10.133:8443 | database        | ONLINE | Fully operational |
+-------+-----------------------------+-----------------+--------+-------------------+

Ici les trois membres votent (database), et node2 est le leader actuel. Pour le détail d'un membre, incus cluster show expose son domaine de panne, ses groupes et son appartenance ou non à la base :

incus cluster show node1:node4

roles: []
failure_domain: default
groups:
- default
database: false
status: Online

Un membre dont roles est vide et database vaut false est un database-client : il fait partie du cluster et héberge des instances, mais reste hors du consensus.

Régler la haute disponibilité

Deux réglages globaux pilotent la répartition des rôles. Le nombre de voters (cluster.max_voters, 3 par défaut) et le nombre de stand-by (cluster.max_standby, 2 par défaut). Incus assigne automatiquement les rôles selon ces limites, dans l'ordre voter puis stand-by, puis client pour le reste.

L'effet est immédiat et observable. Sur un cluster où un quatrième membre était database-client parce que les stand-by étaient désactivés, rétablir la valeur par défaut le fait basculer aussitôt :

incus config set node1: cluster.max_standby 2
incus cluster list node1: -f csv | grep node4

node4,https://192.168.10.134:8443,database-standby,x86_64,default,,ONLINE,Fully operational

Le membre est passé de client à stand-by dès qu'un emplacement s'est libéré. À l'inverse, fixer cluster.max_standby à 0 force les membres au-delà des trois voters à rester client. C'est ce levier qui décide si un nœud supplémentaire renforce la résilience de la base (stand-by) ou apporte seulement de la capacité de calcul (client).

Tolérance aux pannes et auto-réparation

Un membre qui cesse de répondre est marqué hors ligne au bout d'un délai réglé par cluster.offline_threshold, dont la valeur par défaut est 20 secondes (minimum 10). Ce seuil doit rester cohérent avec la qualité du réseau : un lien lent ou saturé peut faire passer un membre sain pour défaillant.

Par défaut, Incus se contente de marquer le membre hors ligne. En réglant cluster.healing_threshold sur une valeur non nulle (il vaut 0, donc désactivé, par défaut), on active l'auto-réparation : une fois le membre considéré hors ligne, ses instances sont automatiquement évacuées vers d'autres nœuds. C'est utile pour un parc où l'on veut un redémarrage automatique des charges, à condition d'avoir un stockage partagé comme CephFS pour que les données suivent.

Cette auto-réparation reste un mécanisme d'infrastructure, pas un équivalent Kubernetes : Incus déplace des machines (VM et conteneurs système), il ne surveille pas la santé d'un processus applicatif à l'intérieur et ne le relance pas. Pour du redémarrage au niveau applicatif, l'application doit porter sa propre logique (par exemple systemd avec Restart=, ou un orchestrateur applicatif installé au-dessus).

Le point le plus délicat de l'auto-réparation est le split-brain. Lors d'une partition réseau partielle, le leader peut déclarer un nœud hors ligne et évacuer ses instances, alors que ce nœud tourne toujours et continue d'écrire sur le stockage partagé. Au retour du lien, deux copies de la même instance ont écrit sur les mêmes volumes, ce qui provoque une corruption (blocs orphelins, inodes détruits, détectables à l'e2fsck). Incus a durci ce comportement (correction remontée dans l'issue lxc/incus#1032, intégrée à Incus 6.4), mais le risque ne disparaît qu'avec un fencing matériel.

Évacuer et restaurer un membre

Avant une maintenance (mise à jour matérielle, remplacement), on évacue un membre : Incus arrête ou migre ses instances vers d'autres nœuds, puis le met en état EVACUATED. Le quorum n'est pas affecté tant qu'une majorité de voters reste en ligne.

Évacuer le membre visé.
Fenêtre de terminal
```
incus cluster evacuate node1:node4
```
La sortie détaille chaque instance déplacée, par exemple Migrating "wl-node4" to "node2".
Vérifier que le membre est en maintenance et que ses instances ont migré.
Fenêtre de terminal
```
incus cluster list node1: -c ns
incus list node1: -c ns,L
```
Le membre apparaît EVACUATED et ses instances tournent désormais sur d'autres nœuds.
Restaurer le membre une fois la maintenance terminée.
Fenêtre de terminal
```
incus cluster restore node1:node4
```
Incus le repasse ONLINE et rapatrie les instances qui lui appartenaient.

Ce cycle évacuation puis restauration est le geste de base de l'exploitation d'un cluster : il permet d'intervenir sur un nœud sans coupure de service, les charges étant temporairement portées par les autres membres.

Dépannage

Symptôme	Cause probable	Solution
Le cluster refuse les écritures	Quorum perdu (trop de voters hors ligne)	Remettre en ligne assez de voters ; en dernier recours, `incus cluster recover`
Un membre sain passe `OFFLINE`	`offline_threshold` trop bas pour le réseau	Augmenter `cluster.offline_threshold`
Un nouveau membre reste `database-client`	`cluster.max_standby` à 0 ou emplacements pleins	Augmenter `max_standby` si l'on veut qu'il réplique
Les instances ne migrent pas à l'évacuation	Stockage local non partagé	Utiliser un stockage partagé (CephFS) pour la mobilité

À retenir

Incus réplique son état par Raft ; il faut une majorité de voters pour écrire (quorum).
Trois voters permettent de survivre à la perte d'un membre ; c'est le socle recommandé.
Les rôles : voter (vote), stand-by (réplique, promu au besoin), client (héberge sans voter), leader (coordonne).
cluster.max_voters (3) et cluster.max_standby (2) décident de la répartition, avec effet immédiat.
cluster.offline_threshold (20 s) et cluster.healing_threshold (0, désactivé) gouvernent la détection et l'auto-réparation.
L'auto-réparation agit sur les machines, pas sur les processus : ce n'est pas l'auto-healing applicatif de Kubernetes.
N'activez l'auto-réparation qu'avec un fencing (BMC/PDU) pour éviter le split-brain et la corruption du stockage partagé.
Évacuer puis restaurer un membre permet la maintenance sans coupure.

Prochaines étapes

Étendre un cluster : workers distants Ajouter des nœuds database-client pour la capacité de calcul.

Incus OS sans interface Monter le cluster de base, sans shell.

Stockage partagé CephFS Rendre les instances mobiles entre nœuds.

Mises à jour A/B et rollback Mettre à jour le cluster sans coupure.