4.14. La función de retiro de GFS2


La función de retiro de GFS2 es una funcionalidad de integridad de datos de sistemas de archivos de GFS2 en un clúster. Si el módulo de kernel de GFS2 detecta una inconsistencia en un sistema de archivos GFS2, debido a una operación de E/S, el sistema de archivos no estará disponible para el clúster. La operación de E/S se detiene y el sistema esperará otras operaciones de E/S para detenerse con un error, evitando más daños. Cuando esto ocurra, puede detener de forma manual, cualquier otro servicio o aplicación, tras de lo cual puede reiniciar o remontar el sistema de archivos GFS2 para reproducir los diarios. Si el problema persiste, desmonte el sistema de archivos de todos los nodos en el clúster y recupere el sistema de archivos con el comando fsck.gfs2. La función de retiro de GFS es menos severa que la de un pánico de kernel, lo cual haría que otro nodo cerque el nodo.
Si su sistema está configurado con el script de inicio de gfs2 habilitado y el sistema de archivos GFS2 se incluye en el archivo /etc/fstab, el sistema de archivos GFS2 volverá a montarse durante el reinicio. Si el sistema de archivos GFS2 se retiró debido a que percibió un daño en el sistema de archivos, se recomienda ejecutar el comando fsck.gfs2 antes de volver a montar el sistema de archivos. En este caso, para evitar que su sistema de archivos se vuelva a montar en el momento de arranque, puede realizar lo siguiente:
  1. Temporalmente desactive el script de inicio en el nodo afectado mediante el siguiente comando:
    # chkconfig gfs2 off
  2. Reinicie el nodo afectado, al iniciar el software de clúster. El sistema de archivos GFS2 no será montado.
  3. Desmonte el sistema de archivos de cada nodo en el clúster.
  4. Ejecute fsck.gfs2 en el sistema de archivos desde un nodo solamente para asegurarse de que no hay sistemas de archivos corruptos.
  5. Rehabilite el script de inicio en el nodo afectado ejecutando el siguiente comando:
    # chkconfig gfs2 on
  6. Vuelva a montar el sistema de archivos GFS2 de todos los nodos en el cluster.
Un ejemplo de una inconsistencia que puede generar un retiro de GFS2 es un conteo de bloques incorrecto. Cuando el kernel de GFS borra un archivo de un sistema de archivos, sistemáticamente elimina todos los datos y bloques de metadatos con ese archivo. Cuando se hace esto, revisa el conteo de bloques. Si el conteo de bloques no es uno (lo que significa que lo resta es el inodo de disco mismo), eso indica una inconsistencia en un sistema de archivos puesto que el conteo de bloques no coincidió con la lista de bloques encontrada.
Puede sobrescribir la función de retiro de GSF2 al montar el sistema de archivos con la opción -o errors=panic especificada. Cuando se especifica esta opción, los errores que normalmente harían que el sistema de archivos se retire provocarían pánico en el sistema. Esta opción detiene comunicaciones de clúster de nodo, las cuales cercan al nodo con vallas.
Internamente, la función de retiro de GFS2 funciona al hacer que el kernel envíe un mensaje al demonio gfs_controld solicitando el retiro. El demonio gfs_controld ejecuta el programa dmsetup para colocar el destino de error de mapeador de dispositivo bajo el sistema de archivos previniendo el acceso al dispositivo de bloque. Luego, le dice al kernel que ha completado. Esta es la razón por la cual se requiere que el soporte de GFS2 siempre utilice el dispositivo CLVM bajo GFS2, puesto que de lo contrario no es posible insertar un destino de mapeador de dispositivo.
El propósito del destino de error de un mapeador de dispositivo es el de garantizar que todas las futuras operaciones de E/S resulten en un error de E/S que permitan el desmontaje ordenado del sistema de archivos. Como resultado, cuando se presente el retiro, es normal ver una cantidad de errores de E/S del mapeador de dispositivos reportado en los registros de sistema.
En ocasiones, el retiro puede fallar si no es posible para el programa dmsetup insertar el destino de error como se solicitó. Esto puede suceder si hay una escasez de memoria en el momento del retiro y no se puede reclamar debido al problema que activó el retiro en primer lugar.
Un retiro no siempre significa que hay un error en GFS2. Algunas veces la función de retiro puede activarse por errores de E/S del dispositivo relativos al dispositivo de bloque. Es altamente recomendable revisar lo registros para ver si ese es el caso si se presenta un retiro.
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.