Que fait exactement Gluster?

12

Je joue avec Gluster depuis 2 jours et je pose des questions ici et sur leur système de questions. Je ne comprends vraiment pas certaines choses. Je vois des gens qui disent des trucs comme

Configurez des briques répliquées entre les serveurs (puisque vous n'utilisez que 3, la réplication serait plus sûre), et chaque serveur verra les fichiers de tous les autres serveurs comme étant «locaux» - même si un serveur tombe en panne, les fichiers ont été répliqués vers les autres serveurs.

ou

Gluster maintiendra la synchronisation des fichiers entre les volumes (briques) et dispose de capacités d'auto-réparation qui gèreront toutes les incohérences dues à la mise hors ligne d'un serveur.

Étant donné que je monte un volume distant du serveur vers le (s) client (s), comment gluster gère-t-il la défaillance du nœud de serveur, celui à partir duquel les volumes sont montés? D'après ce que j'ai essayé, le dossier sur le client où le volume a été monté devient inaccessible et je dois utiliser umount pour le débloquer. Et après cela, il n'y a plus de contenu du serveur.

C'est, fondamentalement, ce que je ne vois pas dans les explications: que se passe-t-il lorsque le nœud du serveur tombe en panne et s'il est possible de vraiment répliquer le contenu, comme le fait l'unisson ou le rsync?

high-availability glusterfs cbaltatescu
la source

Réponses:

8

Nous avons récemment commencé à rechercher GlusterFS pour notre propre usage, donc cette question était intéressante pour moi. Gluster utilise ce qu'on appelle des «traducteurs» sur le client FUSE pour gérer la façon dont vous stockez les données. Il existe plusieurs types de traducteurs qui sont décrits ici:

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

Celui que vous demandez spécifiquement s'appelle le traducteur automatique de réplication de fichiers ou AFR, et est traité en détail ici:

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

En regardant le code source, il apparaît que les données sont en fait écrites simultanément sur les nœuds, bien mieux que rsync!

En ce qui concerne la récupération après une situation d'échec, j'ai trouvé une note intéressante. Le système Gluster est différent de Ceph en ce qu'il n'est pas activement au courant des changements d'état de réplication et doit être «déclenché». Donc, si vous perdez un nœud dans votre cluster, vous devez rechercher chaque fichier afin que Gluster s'assure qu'il est répliqué:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

Je n'ai pas pu trouver une bonne page décrivant les mécanismes de scénario de défaillance en interne, comme la façon dont le client détecte que les choses sont cassées. Cependant, en téléchargeant le code source et en parcourant le client, il semble qu'il existe divers délais d'expiration qu'il utilise pour les commandes et une sonde qu'il fait de temps en temps aux autres systèmes du cluster. Il semble que la plupart d'entre eux ont des marques TODO et ne sont pas actuellement configurables, sauf par le biais de la modification du code source, ce qui peut vous inquiéter si le temps de convergence est critique.

polynôme
la source
J'avais moi-même découvert l'AFR, cependant, lors de son utilisation, je n'ai pas pu écrire sur le client, uniquement sur le serveur. Est-ce une conséquence de la logique derrière cela, ou est-ce quelque chose que je dois examiner?
cbaltatescu
2
C'est probablement un problème de configuration (ce n'est pas par conception).
polynôme
3

Avec seulement 2 nœuds répliqués, gluster n'est pas très différent d'un script rsync automatique. Les choses ne commencent vraiment à être intéressantes qu'une fois que vous avez 4 nœuds de stockage ou plus - vos machines clientes voient un pool d'espace, mais les fichiers constitutifs sont répartis sur tous les nœuds de stockage (briques). Cela signifie que si vos 4 serveurs disposent de 10 To d'espace local, vos machines clientes peuvent voir un seul espace de noms de 20 To (répliqué ou 40 To de stockage non protégé).

J'ai vu un bref hoquet - peut-être 30 secondes environ - sur un ordinateur client lorsqu'il essaie d'E / S après qu'une brique de stockage ne soit plus disponible. Après le hoquet, cependant, les E / S continueront normalement tant qu'il y aura des serveurs en ligne qui détiennent toujours un ensemble complet des données de volume.

techieb0y
la source
slideshare.net/Gluster/… présentation du directeur technique de Gluster sur son fonctionnement.
polynôme
1
Le truc, c'est qu'il ne fait PAS ce que fait rsync. Rsync fournit une copie des données sur l'autre machine. Gluster, lorsque le maître (dans une configuration serveur-client à 2 nœuds) échoue ne laisse rien derrière ou que je n'ai pas pu comprendre, d'où la question.
cbaltatescu
2
Si vous n'avez que 2 nœuds et que l'un des nœuds est un client (ne stockant aucune donnée localement), la perte du `` maître '' avec les données entraînerait l'indisponibilité et le blocage des E / S sur le client. Vous avez besoin d'au moins 2 serveurs avec un volume configuré pour la réplication, plus vos clients.
techieb0y
0

Lorsque le serveur face au client tombe en panne (c'est-à-dire le serveur dont l'IP / DNS a été utilisé par le client pour monter le système de fichiers), le volume entier devient hors ligne sur ce client, c'est-à-dire qu'il ne peut pas lire / écrire sur le volume.

Cependant, si le client l'a monté en utilisant IP / DNS d'un autre serveur, le volume sera toujours en ligne pour ce client. Cependant, la lecture / écriture n'ira pas vers l'instance ayant échoué / planté.

Harit Vishwakarma
la source