Sezione precedente - Passaggi di costruzione di GlusterFS
Questo articolo descrive due problemi di GlusterFS che potresti incontrare e fornisce i passaggi per risolverli:
- Riparazione dei volumi replicati
- Risolvere un problema di split brain
Guarisci i volumi replicati
Quando qualsiasi mattone in un volume replicato va offline, il glusterd i demoni sui nodi rimanenti tengono traccia di tutti i file non replicati sul brick offline. Quando il brick offline diventa nuovamente disponibile, il cluster avvia un processo di riparazione, replicando i file aggiornati su quel brick. L'inizio di questo processo può richiedere fino a 10 minuti, in base all'osservazione.
È possibile visualizzare le informazioni sui file da replicare eseguendo il comando seguente:
gluster volume heal volumeName info
È possibile visualizzare le informazioni sui file replicati durante il processo di guarigione. È inoltre possibile visualizzare le informazioni sui file modificati in modo indipendente sul nodo offline (split-brain) o sui file la cui replica non è riuscita per qualsiasi motivo. Aggiungi le seguenti opzioni al comando precedente:
gluster volume heal volumeName info healed
gluster volume heal volumeName info heal-failed
gluster volume heal volumeName info split-brain
Puoi anche forzare la guarigione manualmente invocando il comando seguente. Se usi l'argomento facoltativo full , vengono sincronizzati anche tutti i file che non sono contrassegnati come da correggere.
gluster volume heal volumeName
Facoltativo:
gluster volume heal volumeName full
Risolvi un problema di split brain
Un cervello diviso il problema si verifica quando uno dei nodi replicati va offline (o viene disconnesso dal cluster) e un file su uno dei suoi brick viene aggiornato. Dopo che il nodo si è unito nuovamente al cluster GlusterFS, il processo di riparazione non riesce a causa del conflitto causato da due diverse versioni del file.
Nell'esempio seguente, questo problema viene attivato manualmente e quindi risolto. Il nodo chiamato gluster4 viene disconnesso e uno dei file archiviati sul suo mattone viene modificato:
[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
This is version 1 of the file
[root@gluster4 ~]# ifdown eth2
##Wait just a little bit for the other nodes to see it disconnected
[root@gluster1 ~]# gluster peer status | grep -A2 glus4
Hostname: glus4
Uuid: 734aea4c-fc4f-4971-ba3d-37bd5d9c35b8
State: Peer in Cluster (Disconnected)
[root@gluster4 ~]# echo "This is new content" >> /var/lib/gvol0/brick4/testfile.txt
[root@gluster4 ~]# cat /var/lib/gvol0/brick4/testfile.txt
This is version 1 of the file
This is new content
[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
This is version 1 of the file
[root@gluster4 ~]# ifup eth2
##Wait just a little bit for the other nodes to see it reconnected
[root@gluster1 ~]# gluster peer status | grep -A2 glus4
Hostname: glus4
Uuid: 734aea4c-fc4f-4971-ba3d-37bd5d9c35b8
State: Peer in Cluster (Connected)
Ora il processo di guarigione è attivato:
gluster volume heal gvol0 full
gluster volume heal gvol0 info split-brain
Gathering list of split brain entries on volume gvol0 has been successful
Brick glus1:/var/lib/gvol0/brick1
Number of entries: 1
at path on brick
-----------------------------------
2014-05-16 19:55:19 /testfile.txt
Brick glus2:/var/lib/gvol0/brick2
Number of entries: 0
Brick glus3:/var/lib/gvol0/brick3
Number of entries: 0
Brick glus4:/var/lib/gvol0/brick4
Number of entries: 0
[root@gluster1 ~]# cat /mnt/gluster/gvol0/testfile.txt
cat: /mnt/gluster/gvol0/testfile.txt: Input/output error
[root@gluster4 ~]# cat /mnt/gluster/gvol0/testfile.txt
cat: /mnt/gluster/gvol0/testfile.txt: Input/output error
Nota che il testfile.txt è elencato, il che significa che GlusterFS non sa quale versione del file è quella corretta. È importante risolvere questo problema perché può confondere i client e provocarne l'arresto anomalo.
Ogni mattone GlusterFS ha una cartella nascosta, glusterfs , che contiene un ID GlusterFS (GFID) esadecimale di ciascun file come collegamento hardcoded. Nel nostro esempio, gluster4 è una replica del nodo gluster1. L'esempio seguente mostra i GFID di testfile.txt su gluster1 e gluster4:
[root@gluster1 ~]# getfattr -m . -d -e hex /var/lib/gvol0/brick1/testfile.txt
# file: var/lib/gvol0/brick1/testfile.txt
trusted.afr.gvol0-client-0=0x000000000000000000000000
trusted.afr.gvol0-client-1=0x000000000000000000000000
trusted.afr.gvol0-client-2=0x000000000000000000000000
trusted.afr.gvol0-client-3=0x000000000000000000000000
trusted.gfid=0xa702251de4c547e2ba2f96b896a43718
[root@gluster4 ~]# getfattr -m . -d -e hex /var/lib/gvol0/brick4/testfile.txt
# file: var/lib/gvol0/brick4/testfile.txt
trusted.afr.gvol0-client-0=0x000000000000000000000000
trusted.afr.gvol0-client-1=0x000000000000000000000000
trusted.afr.gvol0-client-2=0x000000000000000000000000
trusted.afr.gvol0-client-3=0x000000000000000000000000
trusted.gfid=0xa702251de4c547e2ba2f96b896a43718
Su uno dei nodi, il file stesso, nonché il file GFID associato (in questo caso, a702251d-e4c5-47e2-ba2f-96b896a43718), devono essere eliminati dal mount sottostante. Solo allora il processo di guarigione può essere riattivato. È fondamentale capire quale copia del file desideri salvare. Se possibile, salva una copia completa del file in una posizione al di fuori di GlusterFS, elimina il file da tutti i nodi, avvia un processo di guarigione e copia nuovamente il file sul punto di montaggio. Questo metodo è più forza bruta, ma funziona se il processo di guarigione non riesce ancora a correggere correttamente il file tramite la replica.
[root@gluster4 ~]# rm -vf /var/lib/gvol0/brick1/.glusterfs/a7/02/a702251d-e4c5-47e2-ba2f-96b896a43718
[root@gluster4 ~]# rm -vf /var/lib/gvol0/brick1/testfile.txt
[root@gluster4 ~]# gluster volume heal gvol0 full
[root@gluster1 ~]# cat /var/lib/gvol0/brick1/testfile.txt
This is version 1 of the file
[root@gluster4 ~]# cat /var/lib/gvol0/brick4/testfile.txt
This is version 1 of the file
Sezione successiva - GlusterFS HA e bilanciamento del carico