Qu'est-ce que Gluster fait exactement?
Je joue avec Glist pour les 2 derniers jours et je posais des questions ici et sur leur système de questions. Je ne comprends vraiment pas certaines choses. Je vois des gens dire des choses comme
Configurez des briques répliquées entre les serveurs (puisque vous n'utilisez que 3, répliquée serait plus sûre), et chaque serveur verra les fichiers de tous les autres serveurs comme étant "local" - même si un serveur échoue, les fichiers ont été répliqués à les autres serveurs.
ou
GLUSTER maintiendra la synchronisation des fichiers entre les volumes (briques) et disposera de capacités de "auto-guérison" qui traiteront toutes les incohérences dues à un serveur étant hors ligne.
Depuis que je MOUNT un volume à distance du serveur au client Comment gonfler la défaillance du nœud serveur, celui que les volumes sont montés de? D'après ce que j'ai essayé le dossier sur le client où le volume a été monté devient inaccessible et que je dois utiliser umount pour le débloquer. Et après cela, il n'y a pas de contenu du serveur.
C'est, fondamentalement, ce que je ne vois pas couvert dans aucune explication: Que se passe-t-il lorsque le nœud serveur échoue et qu'il soit possible de répliquer vraiment le contenu, comme l'unisson ou RSYNC?
Nous avons récemment commencé à rechercher des recherches sur Glusterfs pour notre propre usage afin que cette question soit intéressante pour moi. Gluster utilise ce qu'on appelle les "traducteurs" sur le client FUSE pour gérer la manière 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.
Celui que vous demandez sur spécifiquement s'appelle le traducteur automatique de réplication de fichiers ou AFR, et est couvert en détail ici:
http://www.gluster.com/community/documentation/index.php/unStanding_afr_translator
En regardant le code source, il apparaît que les données sont réellement écrites aux nœuds simultanément, bien mieux que rsync!
En ce qui concerne la récupération d'une situation d'échec, une note intéressante que j'ai trouvée. Le système GLUSTER est différent de CEPH en ce sens qu'il n'est pas activement conscient des changements d'état de réplication et doit être "déclenché". Donc, si vous perdez un nœud de votre cluster, vous devez consulter chaque fichier pour que GLUSTER soit conforme à sa réplication:
Je n'ai pas pu trouver une bonne page décrivant les mécanismes de scénario de défaillance en interne, comme comment le client détecte les choses sont cassées. Toutefois, le téléchargement du code source et la recherche via le client, il apparaît que divers délai d'expiration utilisent pour les commandes et une sonde. On dirait que la plupart d'entre eux ont des marques pour TODO et ne sont pas actuellement configurables, à l'exception de la modification du code source, ce qui peut être une préoccupation pour vous si le temps de convergence est essentiel.
Lorsque le client fait face au serveur échoue (c'est-à-dire le serveur dont l'IP/DNS a été utilisé par le client pour monter le système de fichiers), le volume total devient hors ligne à ce client, il ne peut pas lire/écrire sur le volume.
Toutefois, si le client l'a monté à l'aide d'IP/DNS d'un autre serveur, le volume sera toujours en ligne pour ce client. Cependant, les écritures de lecture/écrit ne vont pas à l'instance échouée/écrasée.