Capítulo 7. Diagnóstico y corrección de problemas en los sistemas de archivos GFS2

La función GFS2 withdraw es una característica de integridad de los datos del sistema de archivos GFS2 que evita posibles daños en el sistema de archivos debido a un hardware o software de kernel defectuoso. Si el módulo del kernel de GFS2 detecta una incoherencia mientras se utiliza un sistema de archivos GFS2 en un nodo de clúster determinado, se retira del sistema de archivos, dejándolo indisponible para ese nodo hasta que se desmonte y se vuelva a montar (o se reinicie la máquina que detecta el problema). Todos los demás sistemas de archivos GFS2 montados siguen siendo totalmente funcionales en ese nodo. (La función de retirada de GFS2 es menos severa que un pánico del kernel, que hace que el nodo sea cercado)

Las principales categorías de incoherencias que pueden provocar una retirada de GFS2 son las siguientes:

Un ejemplo de una incoherencia que podría causar una retirada de GFS2 es un recuento de bloques incorrecto para el inodo de un archivo. Cuando GFS2 borra un archivo, elimina sistemáticamente todos los bloques de datos y metadatos a los que hace referencia ese archivo. Cuando lo hace, comprueba el recuento de bloques del inodo. Si el recuento de bloques no es 1 (lo que significa que todo lo que queda es el propio inodo del disco), eso indica una inconsistencia del sistema de archivos, ya que el recuento de bloques del inodo no coincide con los bloques reales utilizados para el archivo.

En muchos casos, el problema puede haber sido causado por un hardware defectuoso (memoria defectuosa, placa base, HBA, unidades de disco, cables, etc.). También puede haber sido causado por un error del kernel (otro módulo del kernel que sobrescribe accidentalmente la memoria de GFS2), o un daño real del sistema de archivos (causado por un error de GFS2).

En la mayoría de los casos, la mejor manera de recuperarse de un sistema de archivos GFS2 retirado es reiniciar o cercar el nodo. El sistema de archivos GFS2 retirado le dará la oportunidad de reubicar los servicios en otro nodo del clúster. Una vez reubicados los servicios, puede reiniciar el nodo o forzar un vallado con este comando.

# pcs stonith fence node

El problema de consistencia que causó la retirada puede hacer que sea imposible detener el servicio del sistema de archivos, ya que puede hacer que el sistema se cuelgue.

Si el problema persiste después de un nuevo montaje, debe detener el servicio del sistema de archivos para desmontar el sistema de archivos de todos los nodos del clúster y, a continuación, realizar una comprobación del sistema de archivos con el comando fsck.gfs2 antes de reiniciar el servicio con el siguiente procedimiento.

Puede anular la función de retirada de GFS2 montando el sistema de archivos con la opción -o errors=panic especificada en el servicio del sistema de archivos.

# pcs resource update mydata_fs “options=noatime,errors=panic”

Cuando se especifica esta opción, cualquier error que normalmente provocaría la retirada del sistema fuerza un kernel panic en su lugar. Esto detiene las comunicaciones del nodo, lo que hace que el nodo sea cercado. Esto es especialmente útil para los clústeres que se dejan desatendidos durante largos períodos de tiempo sin supervisión o intervención.

Internamente, la función de retirada de GFS2 funciona desconectando el protocolo de bloqueo para garantizar que todas las operaciones posteriores del sistema de archivos den lugar a errores de E/S. Como resultado, cuando se produce la retirada, es normal ver una serie de errores de E/S del dispositivo de mapeo de dispositivos reportados en los registros del sistema.