GlusterFS pour dé-pinner mes Postgres ? Le calcul qui dit non

Un troisième nœud rejoint le cluster. Forcément, l’envie revient : arrêter d’épingler les bases de données à un seul hôte. Aujourd’hui les Postgres sont pinnés sur le worker NVMe via un label — parce qu’un volume local est lié à son nœud. Ça sent le hack. GlusterFS (stockage répliqué) semblait la sortie élégante. J’ai chiffré. Réponse : non.

Pourquoi on épingle (et pourquoi ce n’est pas “nul”)

Swarm n’orchestre pas le stockage : pas de CSI, pas de scheduler topology-aware. Un volume local vit sur son nœud — si la tâche est replanifiée ailleurs, elle trouve un volume vide. Donc stateful ⇒ épinglé. Kubernetes ne fait pas mieux avec un local PV (node-affinity = épinglé, sauf à déployer Longhorn/Ceph). « Pinner », ce n’est pas un défaut de l’orchestrateur, c’est la gravité des données.

Le chiffrage GlusterFS

Topologie réaliste : deux bricks data (les nœuds NVMe) + un arbiter (anti-split-brain). Le NAS Synology ? Il ne peut pas être une brick (DSM est un appliance fermé). Et surtout, le tueur, c’est la latence de commit :

	NVMe local	GlusterFS (GbE + FUSE)
latence d’un COMMIT (fsync WAL)	~0,1–0,5 ms	~3–15 ms
amplification d’écriture	×1	×2 (réseau)

×10 à ×50 sur les écritures transactionnelles. Une base de données fait du petit write synchrone à chaque commit ; un système de fichiers réseau distribué est optimisé pour l’inverse (gros fichiers, débit). DB sur FS réseau = anti-pattern reconnu. En prime : un nouveau domaine de panne partagé (un split-brain Gluster impacte tout le volume).

La vraie réponse : la réplication, pas le FS réseau

Pour survivre à la mort d’un nœud sans perdre/bloquer les bases, le bon outil c’est la réplication streaming Postgres : primary sur un nœud, hot standby sur l’autre. Chaque nœud garde sa copie sur son NVMe local (le WAL est expédié par Postgres lui-même, pas par un FS partagé). On garde donc la vitesse locale et la donnée existe sur deux machines. En asynchrone, l’impact sur le primary est ~nul (RPO de quelques secondes).

Le pin ne disparaît pas — mais il ne fait plus mal, parce que la donnée n’est plus coincée sur un seul disque.

La leçon

“Pinner” n’est pas un échec, c’est la gravité des données. La solution à la HA stateful n’est pas d’abandonner l’orchestrateur ni de coller un FS réseau sous une base — c’est de répliquer au bon niveau (la base elle-même), ou d’ajouter du stockage réseau seulement pour ce qui le tolère (données froides, pas du Postgres chaud).

Le NAS, du coup, ne sera pas une brick Gluster mais un bon vieux NFS pour le froid (logs longue durée, staging de backups). Et les bases resteront sur NVMe — bientôt répliquées plutôt qu’épinglées-et-priées.