Fullmoon System

GlusterFS ou DRBD : réplication, cohérence et choix d'une architecture HA

EdwardMoon

GlusterFS et DRBD répliquent tous deux des données par le réseau, mais ne sont pas interchangeables. GlusterFS est un système de fichiers distribué présentant un espace de noms commun à plusieurs bricks. DRBD réplique un périphérique bloc sous le système de fichiers. Définissez d'abord les modalités d'accès exigées par l'application pour choisir la bonne technologie.

Cet article dépasse le raccourci « GlusterFS pour les fichiers, DRBD pour les bases ». Il compare acquittement des écritures, montages concurrents, partitions réseau, quorum, fencing, réparation et responsabilités de bascule, avec des commandes d'inspection et des critères de choix.

GlusterFS ou DRBD : réplication distribuée de fichiers et réplication synchrone de périphériques blocs
À gauche, réplication distribuée de fichiers ; à droite, réplication de blocs et témoin de quorum.

Différences d'architecture

Critère GlusterFS Replica DRBD 9
Couche répliquée Fichiers, répertoires et métadonnées Blocs modifiés d'un périphérique
Chemin des entrées-sorties Les clients/FUSE communiquent avec plusieurs bricks Un module noyau transmet les entrées-sorties blocs aux pairs
Système de fichiers au-dessus de la réplication GlusterFS fournit lui-même l'espace de noms partagé Nécessite ext4, XFS ou un système de fichiers de cluster correctement configuré
Accès typique Montage simultané par plusieurs clients Mode single-primary actif/passif courant
Mise à l'échelle Distribue des ensembles de répliques pour augmenter capacité et clients DRBD 9 accepte plusieurs pairs mais n'est pas un système de fichiers distribué
Unité de récupération Réparation par fichier et résolution du split-brain Resynchronisation de blocs à partir d'un bitmap des blocs modifiés

La distinction en pratique

  • Si plusieurs serveurs doivent lire et écrire simultanément dans la même arborescence, évaluez le partage de fichiers GlusterFS.
  • Si un service doit reprendre sur un autre nœud avec son périphérique bloc local répliqué, évaluez DRBD single-primary.
  • Dans les deux cas, la réplication n'est pas une sauvegarde : suppressions, rançongiciels et erreurs logiques peuvent aussi se propager.

Acquittement des écritures et latence

Sur un volume répliqué GlusterFS, la couche AFR cliente envoie les opérations aux bricks de l'ensemble de répliques. Une réparation peut être nécessaire après une panne. Si plusieurs partitions réseau modifient le même fichier, le split-brain peut empêcher le choix automatique d'une copie de référence. Augmenter le nombre de répliques ne suffit pas à définir le quorum.

Le protocole C de DRBD est synchrone : il acquitte l'opération à la couche supérieure après confirmation des écritures locales et distantes. Il réduit le RPO lors de la perte d'un nœud, mais le temps aller-retour réseau et la latence des deux stockages affectent l'application. Les protocoles A et B acquittent différemment : DRBD n'est donc pas toujours synchrone.

Des blocs identiques ne prouvent pas que les transactions de la base ou le système de fichiers sont sains. Testez séparément la persistance des caches après une coupure électrique, la journalisation du système de fichiers, le comportement de fsync dans l'application et la récupération après incident.

Ce que signifie réellement l'accès concurrent

GlusterFS permet à plusieurs clients de monter un volume, mais les applications ne doivent pas utiliser directement les répertoires de bricks comme chemin de partage. Passez par le protocole client Gluster pour préserver les métadonnées de cohérence et de réparation AFR.

Avec DRBD single-primary, la conception habituelle monte ext4 ou XFS sur un seul Primary. DRBD prend aussi en charge dual-primary, mais les montages concurrents exigent un système de fichiers de cluster avec verrouillage distribué, tel que GFS2 ou OCFS2, et du fencing. Monter un XFS ordinaire sur les deux nœuds peut le corrompre.

Quorum et split-brain

Replica 2 ne peut pas maximiser simultanément cohérence et disponibilité lors d'une partition réseau. La documentation Gluster décrit Replica 3 ou les volumes avec arbitre et quorum client pour réduire le split-brain. Un arbitre n'est pas une troisième copie complète : ses métadonnées aident à déterminer quelle copie fait autorité.

Contrôler GlusterFS en lecture seule

sudo gluster peer status
sudo gluster volume list
sudo gluster volume info <VOLNAME>
sudo gluster volume status <VOLNAME> detail

Examiner les listes de réparation et de split-brain

sudo gluster volume heal <VOLNAME> info summary
sudo gluster volume heal <VOLNAME> info
sudo gluster volume heal <VOLNAME> info split-brain

Choisir une brick source sur la seule taille ou date de modification peut écraser des données valides. Identifiez la copie de référence avec le responsable applicatif, sécurisez une sauvegarde, puis appliquez une récupération par fichier.

Examiner les options de quorum actuelles

sudo gluster volume get <VOLNAME> cluster.quorum-type
sudo gluster volume get <VOLNAME> cluster.quorum-count
sudo gluster volume get <VOLNAME> cluster.server-quorum-type
sudo gluster volume get <VOLNAME> all | grep -Ei 'quorum|arbiter'

Rôles, protocoles et quorum DRBD 9

Une ressource DRBD porte le rôle Primary ou Secondary. Single-primary est courant en HA, mais DRBD 9 n'est pas limité à deux nœuds : une ressource peut être répliquée sur plusieurs hôtes. Plus de nœuds complexifie aussi connexions, métadonnées, resynchronisation et quorum : distinguez possibilités prises en charge et pertinence opérationnelle.

Vérifier l'état DRBD et la progression de réplication

sudo drbdadm status
sudo drbdsetup status --statistics
cat /proc/drbd
journalctl -k -b | grep -i drbd

Simuler avant d'appliquer une modification

sudo drbdadm -d adjust <RESOURCE>
sudo drbdadm dump <RESOURCE>

DRBD ne promeut pas seul le Secondary survivant et ne démarre pas l'application. Pacemaker, DRBD Reactor ou une procédure manuelle stricte doit coordonner arrêt du service, démontage, changement de rôle, remontage, VIP et application.

Examiner le quorum et les rôles

sudo drbdsetup status --verbose --statistics
sudo drbdadm status <RESOURCE>

# Si vous utilisez également Pacemaker
sudo crm_mon -1Arf
Lorsque la communication entre deux nœuds est rompue, le réseau seul ne permet pas de déterminer quelle copie restante fait autorité. Concevez ensemble l'arbitrage par nœud sans disque et le quorum DRBD 9, le fencing/STONITH Pacemaker et des chemins d'alimentation et de réseau indépendants.

Pourquoi les bascules diffèrent

Étape GlusterFS DRBD
Détection de panne Le client détecte la perte de connexion à une brick Détecte les changements de connexion au pair ou d'état disque
Autorisation des écritures Quorum client AFR et état du volume Rôle, état disque et quorum DRBD
Transition du chemin de données Le client communique avec les bricks restantes Un gestionnaire de cluster promeut, monte et démarre les services
Récupération Réparation par fichier et résolution du split-brain Resynchronisation de blocs et réintégration des rôles
Composants externes nécessaires Serveurs volfile redondants fonctionnels et supervision Généralement un gestionnaire de cluster et du fencing

La bascule de chemin GlusterFS et celle de service DRBD sont différentes. La première modifie les entrées-sorties d'un client de fichiers distribué ; la seconde déplace, selon un ordre défini, le système de fichiers et l'application au-dessus du périphérique bloc.

Choisir selon la charge de travail

Le tableau compare les besoins d'accès. Avant adoption, vérifiez séparément le support de sécurité GlusterFS de la communauté ou du fournisseur, et la compatibilité des modules/outils DRBD avec le noyau hôte. Une adéquation fonctionnelle ne suffit pas pour la production sans paquets maintenables.

Besoin À envisager d'abord Motif et réserves
Plusieurs nœuds web partageant des fichiers téléversés GlusterFS Adapté aux accès concurrents, mais tester petits fichiers et réparation
Base unique en actif/passif sur système de fichiers local DRBD Évaluer protocole C et gestionnaire de cluster, puis comparer à la réplication native de la base
Stockage objet extensible horizontalement Reconsidérer les deux Un stockage compatible S3 peut mieux répondre aux modalités d'accès
Migration à chaud de VM DRBD sous conditions Exige dual-primary, système de fichiers de cluster et fencing, ou une intégration de virtualisation dédiée
Gros fichiers de distribution en lecture seule GlusterFS ou stockage objet Comparer aussi caches, CDN et pipelines de distribution
Sauvegardes et conservation à long terme Aucun ne suffit seul Exige sauvegardes indépendantes, versionnement, immutabilité et récupération hors site

Questions à résoudre avant le choix

  1. Plusieurs nœuds doivent-ils écrire simultanément dans le même système de fichiers, ou un seul écrivain suffit-il ?
  2. Quels RPO et RTO sont acceptables, et la charge tolère-t-elle la latence synchrone ?
  3. En cas de partition réseau, faut-il privilégier disponibilité ou cohérence ?
  4. Existe-t-il un troisième chemin de vote indépendant et un fencing adapté ?
  5. Les performances ont-elles été mesurées en fonctionnement nominal, en écriture dégradée et pendant la resynchronisation ?
  6. Disposez-vous de sauvegardes indépendantes et de tests réels contre suppression, corruption et rançongiciel ?

Points à vérifier en exploitation

  • Séparer les liens de réplication du trafic de service et surveiller latence, pertes de paquets et bande passante.
  • Tester le service lors de pannes de nœuds, pertes de liens, redémarrages et resynchronisations, au-delà du cas nominal.
  • Alerter sur les réparations en attente et le split-brain GlusterFS, ainsi que sur les rôles, disques, connexions et quorum DRBD.
  • Exclure des procédures courantes les forçages rendant les deux côtés inscriptibles.
  • Conserver des sauvegardes immuables hors site avec rétention définie, indépendamment de la réplication, et vérifier régulièrement la restauration.

Documentation officielle et guides associés

Conclusion

Choisissez GlusterFS ou DRBD selon le partage de fichiers ou la bascule de blocs exigés. GlusterFS fournit un espace de noms distribué et la réparation ; DRBD fournit la réplication de blocs et des transitions de rôle explicites. Dans les deux cas, la haute disponibilité exige un modèle complet de panne incluant quorum, fencing, observabilité et sauvegardes indépendantes.