Sección anterior - Pasos de compilación de GlusterFS
Este artículo describe dos problemas de GlusterFS que puede encontrar y brinda pasos para resolverlos:
- Recuperación de volúmenes replicados
- Solucionar un problema de cerebro dividido
Reparar volúmenes replicados
Cuando cualquier ladrillo en un volumen replicado se desconecta, el glusterd los demonios en los nodos restantes realizan un seguimiento de todos los archivos que no se replican en el ladrillo fuera de línea. Cuando el bloque fuera de línea vuelve a estar disponible, el clúster inicia un proceso de recuperación y replica los archivos actualizados en ese bloque. El inicio de este proceso puede demorar hasta 10 minutos, según la observación.
Puede ver información sobre qué archivos replicar ejecutando el siguiente comando:
gluster volume heal volumeName info
Puede ver información sobre los archivos replicados durante el proceso de recuperación. También puede ver información sobre archivos modificados de forma independiente en el nodo fuera de línea (split-brain) o archivos que fallaron en la replicación por cualquier motivo. Agregue las siguientes opciones al comando anterior:
gluster volume heal volumeName info healed
gluster volume heal volumeName info heal-failed
gluster volume heal volumeName info split-brain
También puede forzar la curación manualmente invocando el siguiente comando. Si usa el argumento opcional full , todos los archivos que no están marcados como que necesitan reparación también se sincronizan.
gluster volume heal volumeName
Opcional:
gluster volume heal volumeName full
Solucionar un problema de cerebro dividido
Un cerebro dividido El problema ocurre cuando uno de los nodos replicados se desconecta (o se desconecta del clúster) y se actualiza un archivo en uno de sus ladrillos. Después de que el nodo se reincorpora al clúster de GlusterFS, el proceso de recuperación falla debido al conflicto causado por dos versiones diferentes del archivo.
En el siguiente ejemplo, este problema se activa manualmente y luego se soluciona. El nodo llamado gluster4 se desconecta y uno de los archivos almacenados en su bloque se modifica:
[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)
Ahora se activa el proceso de curación:
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
Observe que el testfile.txt aparece en la lista, lo que significa que GlusterFS no sabe qué versión del archivo es la correcta. Es importante solucionar este problema porque puede confundir a los clientes y hacer que se bloqueen.
Cada ladrillo GlusterFS tiene una carpeta oculta, glusterfs , que contiene un ID de GlusterFS hexadecimal (GFID) de cada archivo como un enlace codificado. En nuestro ejemplo, gluster4 es una réplica del nodo gluster1. El siguiente ejemplo muestra los GFID de testfile.txt en gluster1 y 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
En uno de los nodos, el archivo en sí, así como el archivo GFID asociado (en este caso, a702251d-e4c5-47e2-ba2f-96b896a43718), deben eliminarse del montaje subyacente. Solo entonces se puede desencadenar de nuevo el proceso de curación. Es fundamental comprender qué copia del archivo desea guardar. Si es posible, guarde una copia completa del archivo en una ubicación fuera de GlusterFS, elimine el archivo de todos los nodos, active un proceso de reparación y vuelva a copiar el archivo sobre el punto de montaje. Este método es más de fuerza bruta, pero funciona si el proceso de reparación aún no puede corregir correctamente el archivo a través de la replicación.
[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
Siguiente sección - GlusterFS HA y equilibrio de carga