Si tu as un peu de temps, aurais-tu l'amabilité de détailler stp? (j'ai du mal à digérer la documentation de glusterfs qui est volumineuse et uniquement anglophone ^ ^ )
Un "split brain" arrive quand les 2 noeuds d'un cluster actif-actif sont toujours UP mais c'est le lien réseau entre les 2 (qui leur sert pour les synchro) est rompu. On se retrouve dans ce cas avec potentiellement des données neuves (mais différentes) sur les 2 noeuds à la fois car chaque noeud se croit maître du cluster et avec une impossibilité pour les réconcilier.
Pour régler ce problème, il y a plusieurs méthodes :
- le STONITH ("Shoot The Other Node In The Head") qui part du principe que tu disposes d'un système de monitoring externe capable de prendre la décision d'arrêter aussi vite que possible un des 2 noeuds le temps que le système de syncho soit de nouveau UP. Solution de bourrin, pas toujours très efficace et assez risquée au final car si le monitoring se trouve lui-même isolé, c'est la merde.
- Ne pas faire de cluster actif-actif mais actif-passif comme la plupart des bases de données relationnelles le conseillent. La bascule se fait de préférence manuellement après diagnostique de la situation. C'est lent, pas automatique mais l'intégrité des données est garantie du moment que les admins font bien leur boulot et suivent les procédures.
- Mettre en place un 3e noeud (ou plus du moment que le total est impair) et laisser le cluster procéder à une élection d'un nouveau maitre en cas de panne d'un noeud. Celui qui dispose de la majorité+1 (le "quorum") est le nouveau maitre. Celui qui est minoritaire se place de lui-même en isolement le temps de revoir ses petits copains.
GlusterFS fonctionne avec 3 noeuds. D'autres font pareil comme MongoDB pour donner un exemple très connu mais on pourrait en trouver des tas d'autres encore...
[^] # Re: GlusterFS
Posté par Nico C. . En réponse au journal Système de fichiers clusterisé - OCFS2, GFS2, GlusterFS, autres. Évalué à 10. Dernière modification le 26 juin 2017 à 18:45.
Un "split brain" arrive quand les 2 noeuds d'un cluster actif-actif sont toujours UP mais c'est le lien réseau entre les 2 (qui leur sert pour les synchro) est rompu. On se retrouve dans ce cas avec potentiellement des données neuves (mais différentes) sur les 2 noeuds à la fois car chaque noeud se croit maître du cluster et avec une impossibilité pour les réconcilier.
Pour régler ce problème, il y a plusieurs méthodes :
- le STONITH ("Shoot The Other Node In The Head") qui part du principe que tu disposes d'un système de monitoring externe capable de prendre la décision d'arrêter aussi vite que possible un des 2 noeuds le temps que le système de syncho soit de nouveau UP. Solution de bourrin, pas toujours très efficace et assez risquée au final car si le monitoring se trouve lui-même isolé, c'est la merde.
- Ne pas faire de cluster actif-actif mais actif-passif comme la plupart des bases de données relationnelles le conseillent. La bascule se fait de préférence manuellement après diagnostique de la situation. C'est lent, pas automatique mais l'intégrité des données est garantie du moment que les admins font bien leur boulot et suivent les procédures.
- Mettre en place un 3e noeud (ou plus du moment que le total est impair) et laisser le cluster procéder à une élection d'un nouveau maitre en cas de panne d'un noeud. Celui qui dispose de la majorité+1 (le "quorum") est le nouveau maitre. Celui qui est minoritaire se place de lui-même en isolement le temps de revoir ses petits copains.
GlusterFS fonctionne avec 3 noeuds. D'autres font pareil comme MongoDB pour donner un exemple très connu mais on pourrait en trouver des tas d'autres encore...