Cosa fa esattamente Gluster?

Ho giocato con Gluster negli ultimi 2 giorni e ho fatto domande qui e sul loro sistema di domande. Davvero non capisco alcune cose. Vedo persone che dicono cose del genere

Imposta mattoni replicati tra i server (dato che stai usando solo 3, replicato sarebbe più sicuro) e ogni server vedrà i file di tutti gli altri server come "locali" - anche se un server fallisce, i file sono stati replicati in gli altri server.

o

Gluster manterrà la sincronizzazione dei file tra volumi (mattoni) e ha funzionalità di "autoriparazione" che gestiranno eventuali incoerenze dovute alla disconnessione di un server.

Dal momento che monto un volume remoto dal server ai client come fa il gluster a gestire il fallimento del nodo del server, quello da cui sono montati i volumi? Da quello che ho provato la cartella sul client in cui è stato montato il volume diventa inaccessibile e devo usare umount per sbloccarlo. E dopo non ci sono contenuti dal server.

Questo è, fondamentalmente, ciò che non vedo trattato in nessuna spiegazione: cosa succede quando il nodo del server fallisce e se è possibile replicare veramente il contenuto, come fa unison o rsync?

Di recente abbiamo iniziato a ricercare GlusterFS per il nostro utilizzo, quindi questa domanda è stata interessante per me. Gluster utilizza i cosiddetti "traduttori" sul client FUSE per gestire la modalità di archiviazione dei dati. Esistono diversi tipi di traduttori qui descritti:

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

Quello di cui stai chiedendo in particolare si chiama Automatic File Replication Translator 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 vengano effettivamente scritti simultaneamente sui nodi, molto meglio di rsync!

Per quanto riguarda il recupero da una situazione di fallimento, ho trovato una nota interessante. Il sistema Gluster è diverso da Ceph in quanto non è attivamente consapevole delle modifiche allo stato della replica e deve essere "attivato". Quindi, se perdi un nodo nel tuo cluster, devi cercare ogni file in modo che Gluster si assicuri che venga 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 descriva internamente i meccanismi dello scenario di errore, come il modo in cui il client rileva che le cose sono rotte. Tuttavia, scaricando il codice sorgente e guardando attraverso il client sembra che ci siano vari timeout che utilizza per i comandi e un probe che fa ogni tanto su altri sistemi nel cluster. Sembra che la maggior parte di questi abbia marchi TODO e non siano attualmente configurabili se non attraverso la modifica del codice sorgente, il che potrebbe essere un problema per te se il tempo di convergenza è critico.

Con solo 2 nodi replicati, il gluster non è molto diverso da uno script rsync automatico. Le cose iniziano davvero ad essere interessanti solo quando hai 4 o più nodi di archiviazione: i tuoi computer client vedono un pool di spazio, ma i file costituenti sono distribuiti su tutti i nodi di archiviazione (mattoni). Ciò significa che se i 4 server dispongono di 10 TB di spazio locale, i computer client possono visualizzare un singolo spazio dei nomi di 20 TB (replicato o 40 TB di spazio di archiviazione non protetto).

Ho visto un breve singhiozzo - forse circa 30 secondi - su una macchina client quando prova IO dopo che un mattone di memoria diventa non disponibile. Dopo il singhiozzo, tuttavia, IO continuerà normalmente fino a quando ci sono server online che conservano ancora un set completo dei dati del volume.

Stai descrivendo un comportamento 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 fallisce (cioè il server il cui IP / DNS è stato utilizzato dal client per montare il filesystem), l'intero volume diventa offline a quel client, cioè non può leggere / scrivere sul volume.

Tuttavia, se il client lo ha montato utilizzando IP / DNS di un altro server, il volume sarà comunque online per quel client. Tuttavia, le letture / scritture non andranno all'istanza non riuscita / arrestata in modo anomalo.