Che cosa fa esattamente Gluster?

Ho giocato con gluster negli ultimi 2 giorni e ho fatto domande qui e sul loro sistema di domande. Non capisco davvero alcuna delle cose. Vedo gente che dice cose simili

Impostare i mattoni replicati tra i server (dal momento che utilizzi solo 3, la replica sarà più sicura) e each server vedrà i file di tutti gli altri server come "locale" – anche se un server non riesce, i file sono stati replicati gli altri server.

o

Gluster manterrà la sincronizzazione dei file tra i volumi (mattoni) e dispone di funzionalità "self-healing" che si occupano di eventuali incongruenze dovute a un server che non è in linea.

Dal momento che montano un volume remoto dal server al client, come funziona il mancato gestire il nodo del server, quello sui quali vengono montati i volumi? Da quello che ho provato la cartella del client where il volume è stato montato diventa inaccessibile e devo usare umount per sbloccarlo. E dopo che non c'è alcun contenuto dal server.

Questo è fondamentalmente quello che non vedo coperto in qualsiasi spiegazione: cosa succede quando il nodo del server non riesce e se è ansible replicare veramente il contenuto, come unison o rsync?

  • Perché Puppet (quasi) non riesce sempre a scrivere sul mio file system Gluster?
  • Come abbassare Gluster FS giù il timeout del peer / ridurre l'impatto pari?
  • Alternativa a GlusterFS
  • 4 Solutions collect form web for “Che cosa fa esattamente Gluster?”

    Recentemente abbiamo iniziato a ricercare GlusterFS per il nostro uso, quindi questa domanda è stata interessante per me. Gluster utilizza i cosiddetti "traduttori" sul client FUSE per gestire come memorizzare i dati. Ci sono diversi tipi di traduttori che sono qui descritti:

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

    Quello su cui si chiede specificamente si chiama Automatic Translator File Replication o AFR, ed è trattato in dettaglio qui:

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

    Guardando il codice sorgente sembra che i dati siano effettivamente scritti in nodes contemporaneamente, molto meglio di rsync!

    Per quanto riguarda il recupero da una situazione di fallimento c'è una nota interessante che ho trovato. Il sistema Gluster è diverso da Ceph in quanto non è triggersmente consapevole delle modifiche di stato della replica e deve essere 'innescato'. Quindi, se si perde un nodo nel cluster, è necessario cercare each file in modo che Gluster possa assicurarsi che sia replicato:

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

    Non sono riuscito a trovare una buona pagina che descrive internamente i meccanismi dello scenario di guasto, come il modo in cui il cliente rileva che le cose sono rotte. Tuttavia, scaricando il codice sorgente e guardando attraverso il client appare che ci sono diversi timeout che utilizza per i comandi e una sonda che fa each tanto ad altri sisthemes del cluster. Sembra che la maggior parte di essi abbia marchi TODO e non sia attualmente configurabile, ad exception della modifica del codice sorgente, che può essere una preoccupazione per se il tempo di convergenza è critico.

    Con appena 2 nodes replicanti, il gluster non è molto diverso da uno script rsync automatico. Le cose iniziano solo ad essere interessanti una volta che hai 4 o più nodes di archiviazione – le macchine client vedono un pool di spazio, ma i file costituenti vengono distribuiti in tutti i nodes di archiviazione (mattoni). Ciò significa che se i tuoi 4 server dispongono di 10 TB di spazio locale, le macchine client possono vedere un solo spazio di nomi di 20 TB (replicato o 40 TB di memory non protetta).

    Ho visto un breve singhiozzo – forse 30 secondi o giù di lì – su una macchina client quando provoca IO dopo che un mattone di stoccaggio non è disponibile. Dopo il singhiozzo, tuttavia, IO continuerà normalmente finché ci sono server in linea che ancora detengono un set completo dei dati del volume.

    Stai descrivendo un comportmento inaspettato – consulterei #gluster su irc.freenode.net o gluster-users@gluster.org o http://community.gluster.org/

    -John Mark Gluster Community Guy

    Quando il server di fronte al client non riesce (vale a dire il server il cui IP / DNS è stato utilizzato dal client per montare il file system) l'integer volume diventa in linea in quel client, cioè non può leggere o scrivere sul volume.

    Tuttavia se il client lo montò utilizzando IP / DNS di altri server, il volume sarà ancora in linea per quel client. Tuttavia le letture / scritture non passano all'istanza fallita / interrotta.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.