Antes de instalar y configurar GFS2, tenga en cuenta las siguientes características clave de sus sistemas de archivos GFS2:

Tabla 1.1, “Límites de soporte de GFS2” resume el tamaño máximo actual del sistema de archivos y el número de nodos que admite GFS2.

GFS2 se basa en una arquitectura de 64 bits, que teóricamente puede acomodar un sistema de archivos de 8 EB. Si su sistema requiere sistemas de archivos GFS2 más grandes que los soportados actualmente, contacte con su representante de servicio de Red Hat.

Al determinar el tamaño de su sistema de archivos, debe tener en cuenta sus necesidades de recuperación. Ejecutar el comando fsck.gfs2 en un sistema de archivos muy grande puede llevar mucho tiempo y consumir una gran cantidad de memoria. Además, en el caso de que se produzca un fallo en el disco o en el subsistema de disco, el tiempo de recuperación está limitado por la velocidad de los medios de copia de seguridad. Para obtener información sobre la cantidad de memoria que requiere el comando fsck.gfs2, consulte Determinación de la memoria necesaria para ejecutar fsck.gfs2.

Mientras que un sistema de archivos GFS2 puede ser usado fuera de LVM, Red Hat sólo soporta sistemas de archivos GFS2 que son creados en un volumen lógico LVM compartido.

Esta sección ofrece recomendaciones sobre cómo formatear su sistema de archivos GFS2 para optimizar el rendimiento.

Tamaño del sistema de archivos: Cuanto más pequeño, mejor

GFS2 se basa en una arquitectura de 64 bits, que teóricamente puede albergar un sistema de archivos de 8 EB. Sin embargo, el tamaño máximo admitido actualmente de un sistema de archivos GFS2 para el hardware de 64 bits es de 100 TB.

Tenga en cuenta que aunque los sistemas de archivos de gran tamaño de GFS2 son posibles, eso no significa que sean recomendables. La regla general con GFS2 es que más pequeño es mejor: es mejor tener 10 sistemas de archivos de 1TB que un sistema de archivos de 10TB.

Hay varias razones por las que deberías mantener tus sistemas de archivos GFS2 pequeños:

Además, un menor número de grupos de recursos que mantener supone un mayor rendimiento.

Por supuesto, si haces tu sistema de archivos GFS2 demasiado pequeño, podrías quedarte sin espacio, y eso tiene sus propias consecuencias. Debes considerar tus propios casos de uso antes de decidir el tamaño.

Tamaño del bloque: Se prefieren los bloques por defecto (4K)

El comando mkfs.gfs2 intenta estimar un tamaño de bloque óptimo basado en la topología del dispositivo. En general, los bloques de 4K son el tamaño de bloque preferido porque 4K es el tamaño de página (memoria) por defecto para Red Hat Enterprise Linux. A diferencia de otros sistemas de archivos, GFS2 realiza la mayoría de sus operaciones utilizando buffers de kernel de 4K. Si su tamaño de bloque es 4K, el kernel tiene que hacer menos trabajo para manipular los buffers.

Se recomienda utilizar el tamaño de bloque por defecto, que debería producir el mayor rendimiento. Puede que necesites utilizar un tamaño de bloque diferente sólo si necesitas un almacenamiento eficiente de muchos archivos muy pequeños.

Tamaño del diario: Por defecto (128MB) suele ser óptimo

Cuando se ejecuta el comando mkfs.gfs2 para crear un sistema de archivos GFS2, se puede especificar el tamaño de los diarios. Si no se especifica un tamaño, será por defecto de 128MB, que debería ser óptimo para la mayoría de las aplicaciones.

Algunos administradores de sistemas podrían pensar que 128MB es excesivo y estarían tentados a reducir el tamaño del diario al mínimo de 8MB o a un más conservador 32MB. Aunque esto podría funcionar, puede afectar gravemente al rendimiento. Al igual que muchos sistemas de archivos con registro en el diario, cada vez que GFS2 escribe metadatos, éstos se consignan en el diario antes de colocarlos. Esto asegura que si el sistema se bloquea o pierde energía, recuperará todos los metadatos cuando el diario se reproduzca automáticamente en el momento del montaje. Sin embargo, no hace falta mucha actividad del sistema de archivos para llenar un diario de 8 MB, y cuando el diario está lleno, el rendimiento se ralentiza porque GFS2 tiene que esperar las escrituras en el almacenamiento.

Generalmente se recomienda utilizar el tamaño de diario por defecto de 128MB. Si su sistema de archivos es muy pequeño (por ejemplo, 5GB), tener un diario de 128MB puede ser poco práctico. Si tienes un sistema de archivos más grande y puedes permitirte el espacio, usar diarios de 256MB podría mejorar el rendimiento.

Tamaño y número de grupos de recursos

Cuando se crea un sistema de archivos GFS2 con el comando mkfs.gfs2, éste divide el almacenamiento en porciones uniformes conocidas como grupos de recursos. Intenta estimar un tamaño de grupo de recursos óptimo (que va de 32MB a 2GB). Puede anular el valor predeterminado con la opción -r del comando mkfs.gfs2.

El tamaño óptimo de su grupo de recursos depende de cómo vaya a utilizar el sistema de archivos. Ten en cuenta lo lleno que estará y si estará o no muy fragmentado.

Debería experimentar con diferentes tamaños de grupos de recursos para ver cuál resulta en un rendimiento óptimo. Es una buena práctica experimentar con un clúster de prueba antes de desplegar GFS2 en plena producción.

Si tu sistema de archivos tiene demasiados grupos de recursos, cada uno de los cuales es demasiado pequeño, las asignaciones de bloques pueden perder demasiado tiempo buscando decenas de miles de grupos de recursos para un bloque libre. Cuanto más lleno esté tu sistema de archivos, más grupos de recursos se buscarán, y cada uno de ellos requiere un bloqueo en todo el clúster. Esto conduce a un rendimiento lento.

Sin embargo, si su sistema de archivos tiene muy pocos grupos de recursos, cada uno de los cuales es demasiado grande, las asignaciones de bloques pueden competir más a menudo por el mismo bloqueo de grupo de recursos, lo que también afecta al rendimiento. Por ejemplo, si tiene un sistema de archivos de 10 GB que está dividido en cinco grupos de recursos de 2 GB, los nodos de su clúster se pelearán por esos cinco grupos de recursos con más frecuencia que si el mismo sistema de archivos estuviera dividido en 320 grupos de recursos de 32 MB. El problema se agrava si el sistema de archivos está casi lleno, ya que cada asignación de bloques podría tener que buscar en varios grupos de recursos antes de encontrar uno con un bloque libre. GFS2 intenta mitigar este problema de dos maneras:

El peor escenario es cuando hay un directorio central en el que todos los nodos crean archivos, porque todos los nodos lucharán constantemente para bloquear el mismo grupo de recursos.

A la hora de determinar el número de nodos que contendrá su sistema, tenga en cuenta que existe un compromiso entre la alta disponibilidad y el rendimiento. Con un número mayor de nodos, se hace cada vez más difícil hacer escalar las cargas de trabajo. Por esta razón, Red Hat no soporta el uso de GFS2 para implementaciones de sistemas de archivos en cluster mayores a 16 nodos.

El despliegue de un sistema de archivos en cluster no es un reemplazo "drop in" para el despliegue de un solo nodo. Red Hat recomienda que permita un período de alrededor de 8-12 semanas de pruebas en las nuevas instalaciones con el fin de probar el sistema y asegurarse de que está trabajando en el nivel de rendimiento requerido. Durante este período, se puede resolver cualquier problema de rendimiento o funcionalidad y cualquier consulta debe dirigirse al equipo de soporte de Red Hat.

Red Hat recomienda a los clientes que estén pensando en implantar clusters que sus configuraciones sean revisadas por el soporte de Red Hat antes de la implantación para evitar posibles problemas de soporte más adelante.

Debe tener en cuenta las siguientes consideraciones de hardware al desplegar un sistema de archivos GFS2.

Cada inodo de archivo y de directorio tiene tres marcas de tiempo asociadas:

Si las actualizaciones de atime están habilitadas, como lo están por defecto en GFS2 y otros sistemas de archivos de Linux, entonces cada vez que se lee un archivo es necesario actualizar su inodo.

Dado que pocas aplicaciones utilizan la información proporcionada por atime, esas actualizaciones pueden requerir una cantidad significativa de tráfico de escritura y de bloqueo de archivos innecesario. Ese tráfico puede degradar el rendimiento; por lo tanto, puede ser preferible desactivar o reducir la frecuencia de las actualizaciones de atime.

Existen los siguientes métodos para reducir los efectos de la actualización de atime:

Utilice el siguiente comando para montar un sistema de archivos GFS2 con la opción de montaje noatime Linux.

mount BlockDevice MountPoint -o noatime

En este ejemplo, el sistema de archivos GFS2 reside en /dev/vg01/lvol0 y está montado en el directorio /mygfs2 con las actualizaciones de atime desactivadas.

# mount /dev/vg01/lvol0 /mygfs2 -o noatime

Como todos los sistemas de archivos de Linux, GFS2 se asienta sobre una capa llamada sistema de archivos virtual (VFS). El VFS proporciona buenos valores predeterminados para la configuración de la caché para la mayoría de las cargas de trabajo y no debería ser necesario cambiarlos en la mayoría de los casos. Sin embargo, si tienes una carga de trabajo que no está funcionando eficientemente (por ejemplo, la caché es demasiado grande o demasiado pequeña) entonces puedes ser capaz de mejorar el rendimiento utilizando el comando sysctl(8) para ajustar los valores de los archivos sysctl en el directorio /proc/sys/vm. La documentación de estos archivos se puede encontrar en el árbol de fuentes del kernel Documentation/sysctl/vm.txt.

Por ejemplo, los valores de dirty_background_ratio y vfs_cache_pressure pueden ajustarse en función de su situación. Para obtener los valores actuales, utilice los siguientes comandos:

# sysctl -n vm.dirty_background_ratio
# sysctl -n vm.vfs_cache_pressure

Los siguientes comandos ajustan los valores:

# sysctl -w vm.dirty_background_ratio=20
# sysctl -w vm.vfs_cache_pressure=500

Puedes cambiar permanentemente los valores de estos parámetros editando el archivo /etc/sysctl.conf.

Para encontrar los valores óptimos para sus casos de uso, investigue las distintas opciones de VFS y experimente en un clúster de prueba antes de desplegarlo en producción completa.

El uso de Security Enhanced Linux (SELinux) con GFS2 incurre en una pequeña penalización de rendimiento. Para evitar esta sobrecarga, puede optar por no utilizar SELinux con GFS2 incluso en un sistema con SELinux en modo de aplicación. Al montar un sistema de archivos GFS2, puede asegurarse de que SELinux no intente leer el elemento seclabel en cada objeto del sistema de archivos utilizando una de las opciones context como se describe en la página man mount(8); SELinux asumirá que todo el contenido del sistema de archivos está etiquetado con el elemento seclabel proporcionado en las opciones de montaje context. Esto también acelerará el procesamiento ya que evita otra lectura en disco del bloque de atributos extendidos que podría contener elementos de seclabel.

Por ejemplo, en un sistema con SELinux en modo de aplicación, puede utilizar el siguiente comando mount para montar el sistema de archivos GFS2 si el sistema de archivos va a contener contenido de Apache. Esta etiqueta se aplicará a todo el sistema de archivos; permanece en la memoria y no se escribe en el disco.

# mount -t gfs2 -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/mapper/xyz/mnt/gfs2

Si no está seguro de si el sistema de archivos tendrá contenido Apache, puede utilizar las etiquetas public_content_rw_t o public_content_t, o puede definir una nueva etiqueta y definir una política en torno a ella.

Tenga en cuenta que en un clúster de Pacemaker siempre debe utilizar Pacemaker para gestionar un sistema de archivos GFS2. Puede especificar las opciones de montaje cuando cree un recurso de sistema de archivos GFS2.

Debido a la complejidad añadida del subsistema de bloqueo de GFS2 y a su naturaleza de clúster, la configuración de NFS sobre GFS2 requiere tomar muchas precauciones y una cuidadosa configuración. Esta sección describe las advertencias que debe tener en cuenta al configurar un servicio NFS sobre un sistema de archivos GFS2.

Además de las consideraciones de bloqueo, debe tener en cuenta lo siguiente cuando configure un servicio NFS sobre un sistema de archivos GFS2.

Puede utilizar el servicio de archivos Samba (SMB o Windows) desde un sistema de archivos GFS2 con CTDB, que permite configuraciones activas/activas.

No se admite el acceso simultáneo a los datos del recurso compartido de Samba desde fuera de Samba. Actualmente no hay soporte para los arrendamientos de clústeres GFS2, lo que ralentiza el servicio de archivos de Samba. Para más información sobre las políticas de soporte para Samba, vea Políticas de soporte para RHEL Resilient Storage - Políticas generales de ctdb y Políticas de soporte para RHEL Resilient Storage - Exportación de contenidos gfs2 a través de otros protocolos en el Portal del cliente de Red Hat.

Cuando se utiliza un sistema de archivos GFS2 con una máquina virtual, es importante que los ajustes de almacenamiento de la máquina virtual en cada nodo estén configurados correctamente para forzar la desactivación de la caché. Por ejemplo, incluir estas configuraciones para cache y io en el dominio libvirt debería permitir que GFS2 se comporte como se espera.

<driver name='qemu' type='raw' cache='none' io='native'/>

Alternativamente, puedes configurar el atributo shareable dentro del elemento dispositivo. Esto indica que se espera que el dispositivo sea compartido entre dominios (siempre que el hipervisor y el SO lo soporten). Si se utiliza shareable, se debe utilizar cache='no' para ese dispositivo.

Esta sección ofrece un resumen de los problemas relacionados con la asignación de bloques en los sistemas de archivos GFS2. Aunque las aplicaciones que sólo escriben datos no suelen preocuparse por cómo o dónde se asigna un bloque, un cierto conocimiento de cómo funciona la asignación de bloques puede ayudarle a optimizar el rendimiento.

Se crea un sistema de archivos GFS2 con el comando mkfs.gfs2. Se crea un sistema de archivos en un volumen LVM activado.

mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

mkfs -t gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

# mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

Antes de poder montar un sistema de archivos GFS2, el sistema de archivos debe existir, el volumen en el que existe el sistema de archivos debe estar activado y los sistemas de agrupación y bloqueo que lo soportan deben estar iniciados. Una vez cumplidos estos requisitos, puede montar el sistema de archivos GFS2 como lo haría con cualquier sistema de archivos de Linux.

Para el correcto funcionamiento del sistema de archivos GFS2, el paquete gfs2-utils debe estar instalado en todos los nodos que monten un sistema de archivos GFS2. El paquete gfs2-utils forma parte del canal Resilient Storage.

Para manipular las ACL de los archivos, debe montar el sistema de archivos con la opción de montaje -o acl. Si un sistema de archivos se monta sin la opción de montaje -o acl, los usuarios pueden ver las ACL (con getfacl), pero no pueden establecerlas (con setfacl).

# mount /dev/vg01/lvol0 /mygfs2

mount BlockDevice MountPoint -o option

umount MountPoint

Es importante hacer copias de seguridad regulares de su sistema de archivos GFS2 en caso de emergencia, independientemente del tamaño de su sistema de archivos. Muchos administradores de sistemas se sienten seguros porque están protegidos por RAID, multipath, mirroring, snapshots y otras formas de redundancia, pero no hay nada suficientemente seguro.

Puede ser un problema crear una copia de seguridad ya que el proceso de copia de seguridad de un nodo o conjunto de nodos suele implicar la lectura de todo el sistema de archivos en secuencia. Si esto se hace desde un solo nodo, ese nodo retendrá toda la información en la caché hasta que otros nodos del cluster comiencen a solicitar bloqueos. Ejecutar este tipo de programa de copia de seguridad mientras el clúster está en funcionamiento tendrá un impacto negativo en el rendimiento.

La eliminación de las cachés una vez que se ha completado la copia de seguridad reduce el tiempo necesario para que los otros nodos recuperen la propiedad de sus bloqueos/cachés del clúster. Sin embargo, esto no es lo ideal, ya que los otros nodos habrán dejado de almacenar en caché los datos que estaban almacenando antes de que comenzara el proceso de copia de seguridad. Puede eliminar las cachés utilizando el siguiente comando una vez que se haya completado la copia de seguridad:

echo -n 3 > /proc/sys/vm/drop_caches

Es más rápido si cada nodo del clúster hace una copia de seguridad de sus propios archivos, de modo que la tarea se divide entre los nodos. Esto puede lograrse con un script que utilice el comando rsync en directorios específicos de cada nodo.

Red Hat recomienda hacer una copia de seguridad de GFS2 creando una instantánea de hardware en la SAN, presentando la instantánea a otro sistema y haciendo una copia de seguridad allí. El sistema de respaldo debe montar la instantánea con -o lockproto=lock_nolock ya que no estará en un cluster.

Puede suspender la actividad de escritura en un sistema de archivos utilizando el comando dmsetup suspend. La suspensión de la actividad de escritura permite utilizar instantáneas de dispositivos basados en hardware para capturar el sistema de archivos en un estado consistente. El comando dmsetup resume finaliza la suspensión.

El formato del comando para suspender la actividad en un sistema de archivos GFS2 es el siguiente.

dmsetup suspender MountPoint

Este ejemplo suspende las escrituras en el sistema de archivos /mygfs2.

# dmsetup suspend /mygfs2

El formato del comando para finalizar la suspensión de la actividad en un sistema de archivos GFS2 es el siguiente.

dmsetup reanudar MountPoint

Este ejemplo pone fin a la suspensión de las escrituras en el sistema de archivos /mygfs2.

# dmsetup resume /mygfs2

El comando gfs2_grow se utiliza para ampliar un sistema de archivos GFS2 después de que se haya ampliado el dispositivo donde reside el sistema de archivos. La ejecución del comando gfs2_grow en un sistema de archivos GFS2 existente llena todo el espacio libre entre el extremo actual del sistema de archivos y el final del dispositivo con una extensión de sistema de archivos GFS2 recién inicializada. Todos los nodos del clúster pueden entonces utilizar el espacio de almacenamiento extra que se ha añadido.

El comando gfs2_grow debe ejecutarse en un sistema de archivos montado. El siguiente procedimiento aumenta el tamaño del sistema de archivos GFS2 en un clúster que está montado en el volumen lógico shared_vg/shared_lv1 con un punto de montaje de /mnt/gfs2.

GFS2 requiere un diario por cada nodo de un cluster que necesite montar el sistema de archivos. Si añade nodos adicionales al clúster, puede añadir diarios a un sistema de archivos GFS2 con el comando gfs2_jadd. Puede añadir diarios a un sistema de archivos GFS2 de forma dinámica en cualquier momento sin necesidad de ampliar el volumen lógico subyacente. El comando gfs2_jadd debe ejecutarse en un sistema de archivos montado, pero sólo debe ejecutarse en un nodo del clúster. Todos los demás nodos perciben que se ha producido la expansión.

Antes de añadir diarios a un sistema de archivos GFS2, puede averiguar cuántos diarios contiene actualmente el sistema de archivos GFS2 con el comando gfs2_edit -p jindex, como en el siguiente ejemplo:

# gfs2_edit -p jindex /dev/sasdrives/scratch|grep journal
   3/3 [fc7745eb] 4/25 (0x4/0x19): File    journal0
   4/4 [8b70757d] 5/32859 (0x5/0x805b): File    journal1
   5/5 [127924c7] 6/65701 (0x6/0x100a5): File    journal2

El formato del comando básico para añadir diarios a un sistema de archivos GFS2 es el siguiente.

gfs2_jadd -j Number MountPoint

En este ejemplo, se añade un diario al sistema de archivos en el directorio /mygfs2.

gfs2_jadd -j 1 /mygfs2

Para implementar las cuotas de disco, siga los siguientes pasos:

Cada uno de estos pasos se discute en detalle en las siguientes secciones.

# pcs resource create gfs2mount Filesystem options="quota=on" device=BLOCKDEVICE directory=MOUNTPOINT fstype=gfs2 clone

quotacheck -ug /home

# edquota username

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000

# quota testuser

# edquota -g devel

Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0

$ quota -g devel

Si se implantan las cuotas, necesitan cierto mantenimiento, sobre todo en forma de vigilancia para ver si se superan las cuotas y asegurarse de que éstas son exactas.

Si los usuarios exceden repetidamente sus cuotas o alcanzan constantemente sus límites blandos, el administrador del sistema tiene algunas opciones que tomar, dependiendo del tipo de usuarios que sean y del impacto del espacio en disco en su trabajo. El administrador puede ayudar al usuario a determinar cómo utilizar menos espacio en disco o aumentar la cuota de disco del usuario.

Puede crear un informe de uso del disco ejecutando la utilidad repquota. Por ejemplo, el comando repquota /home produce esta salida:

* Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0

Para ver el informe de uso del disco para todos los sistemas de archivos con cuota (opción -a), utilice el comando

# repquota -a

El -- que aparece después de cada usuario es una forma rápida de determinar si se han superado los límites de bloque. Si se ha superado el límite suave de bloque, aparece un en lugar del primer - en la salida. El segundo - indica el límite de inodo, pero los sistemas de archivos GFS2 no admiten límites de inodo, por lo que ese carácter permanecerá como -. Los sistemas de archivos GFS2 no admiten un período de gracia, por lo que la columna grace permanecerá en blanco.

Tenga en cuenta que el comando repquota no es compatible con NFS, independientemente del sistema de archivos subyacente.

Si habilita las cuotas en su sistema de archivos después de un período de tiempo en el que ha estado funcionando con las cuotas deshabilitadas, debe ejecutar el comando quotacheck para crear, comprobar y reparar los archivos de cuotas. Además, puede ejecutar el comando quotacheck si cree que sus archivos de cuotas pueden no ser precisos, como puede ocurrir cuando un sistema de archivos no se desmonta limpiamente después de un fallo del sistema.

Para obtener más información sobre el comando quotacheck, consulte la página de manual quotacheck.

GFS2 almacena toda la información de cuotas en su propio archivo interno en el disco. Un nodo de GFS2 no actualiza este archivo de cuotas con cada escritura del sistema de archivos, sino que, por defecto, actualiza el archivo de cuotas una vez cada 60 segundos. Esto es necesario para evitar la contención entre los nodos que escriben en el archivo de cuotas, lo que provocaría una ralentización del rendimiento.

Cuando un usuario o grupo se acerca a su límite de cuota, GFS2 reduce dinámicamente el tiempo entre sus actualizaciones de archivos de cuota para evitar que se supere el límite. El período de tiempo normal entre sincronizaciones de cuotas es un parámetro ajustable, quota_quantum. Puede cambiar este valor predeterminado de 60 segundos utilizando la opción de montaje quota_quantum=, como se describe en la tabla "Opciones de montaje específicas de GFS2" en Montaje de un sistema de archivos GFS2 que especifica las opciones de montaje.

El parámetro quota_quantum debe establecerse en cada nodo y cada vez que se monte el sistema de archivos. Los cambios en el parámetro quota_quantum no son persistentes a través de los desmontajes. Puede actualizar el valor de quota_quantum con el parámetro mount -o remount.

Puede utilizar el comando quotasync para sincronizar la información de cuotas de un nodo con el archivo de cuotas en disco entre las actualizaciones automáticas realizadas por GFS2. Uso Synchronizing Quota Information

# `quotasync [-ug -a|mountpoint..a`].

Puede ajustar el tiempo entre sincronizaciones especificando una opción de montaje quota-quantum.

# mount -o quota_quantum=secs,remount BlockDevice MountPoint

El siguiente ejemplo sincroniza todas las cuotas sucias almacenadas en caché del nodo en el que se ejecuta al archivo de cuotas en disco para el sistema de archivos /mnt/mygfs2.

# quotasync -ug /mnt/mygfs2

El siguiente ejemplo cambia el período de tiempo por defecto entre las actualizaciones regulares de archivos de cuota a una hora (3600 segundos) para el sistema de archivos /mnt/mygfs2 cuando se vuelve a montar ese sistema de archivos en el volumen lógico /dev/volgroup/logical_volume.

# mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2

La ejecución del comando fsck.gfs2 puede requerir memoria del sistema más allá de la memoria utilizada por el sistema operativo y el kernel. Los sistemas de archivos más grandes, en particular, pueden requerir memoria adicional para ejecutar este comando.

La siguiente tabla muestra los valores aproximados de memoria que pueden ser necesarios para ejecutar sistemas de archivos fsck.gfs2 en sistemas de archivos GFS2 de 1TB, 10TB y 100TB con un tamaño de bloque de 4K.

Tenga en cuenta que un tamaño de bloque menor para el sistema de archivos requeriría una mayor cantidad de memoria. Por ejemplo, los sistemas de archivos GFS2 con un tamaño de bloque de 1K requerirían cuatro veces la cantidad de memoria indicada en esta tabla.

A continuación se muestra el formato del comando fsck.gfs2 para reparar un sistema de archivos GFS2.

fsck.gfs2 -y BlockDevice

En este ejemplo, se repara el sistema de archivos GFS2 que reside en el dispositivo de bloque /dev/testvg/testlv. Todas las consultas de reparación se responden automáticamente con yes.

# fsck.gfs2 -y /dev/testvg/testlv
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Clearing journals (this may take a while)...
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Pass5 complete
Writing changes to disk
fsck.gfs2 complete

Aunque no existe una herramienta de desfragmentación para GFS2 en Red Hat Enterprise Linux, puede desfragmentar archivos individuales identificándolos con la herramienta filefrag, copiándolos a archivos temporales y renombrando los archivos temporales para reemplazar los originales.

Para obtener el mejor rendimiento de un sistema de archivos GFS2, es importante entender parte de la teoría básica de su funcionamiento. Un sistema de archivos de un solo nodo se implementa junto con una caché, cuyo propósito es eliminar la latencia de los accesos al disco cuando se utilizan datos solicitados con frecuencia. En Linux, la caché de páginas (e históricamente la caché de búferes) proporciona esta función de caché.

Con GFS2, cada nodo tiene su propia caché de páginas que puede contener una parte de los datos en disco. GFS2 utiliza un mecanismo de bloqueo llamado glocks (se pronuncia gee-locks) para mantener la integridad de la caché entre nodos. El subsistema glock proporciona una función de gestión de la caché que se implementa utilizando el distributed lock manager (DLM) como capa de comunicación subyacente.

Los glocks proporcionan protección para la caché en base a cada nodo, por lo que hay un bloqueo por nodo que se utiliza para controlar la capa de caché. Si ese glock se concede en modo compartido (modo de bloqueo DLM: PR) entonces los datos bajo ese glock pueden ser almacenados en caché en uno o más nodos al mismo tiempo, de modo que todos los nodos pueden tener acceso local a los datos.

Si el glock se concede en modo exclusivo (modo de bloqueo DLM: EX) entonces sólo un único nodo puede almacenar en caché los datos bajo ese glock. Este modo es utilizado por todas las operaciones que modifican los datos (como la llamada al sistema write ).

Si otro nodo solicita un glock que no puede ser concedido inmediatamente, entonces el DLM envía un mensaje al nodo o nodos que actualmente tienen los glocks que bloquean la nueva solicitud para pedirles que suelten sus bloqueos. La eliminación de los bloqueos puede ser (en comparación con la mayoría de las operaciones del sistema de archivos) un proceso largo. La eliminación de un glock compartido sólo requiere la invalidación de la caché, lo cual es relativamente rápido y proporcional a la cantidad de datos almacenados en la caché.

El abandono de un glock exclusivo requiere un vaciado del registro, y la escritura de cualquier dato modificado en el disco, seguido de la invalidación según el glock compartido.

La diferencia entre un sistema de archivos de un solo nodo y GFS2, por tanto, es que un sistema de archivos de un solo nodo tiene una única caché y GFS2 tiene una caché independiente en cada nodo. En ambos casos, la latencia para acceder a los datos almacenados en caché es de un orden de magnitud similar, pero la latencia para acceder a los datos no almacenados en caché es mucho mayor en GFS2 si otro nodo ha almacenado previamente esos mismos datos.

Operaciones como read (con buffer), stat, y readdir sólo requieren un glock compartido. Operaciones como write (con buffer), mkdir, rmdir, y unlink requieren un glock exclusivo. Las operaciones de lectura/escritura de E/S directa requieren un glock diferido si no se está realizando ninguna asignación, o un glock exclusivo si la escritura requiere una asignación (es decir, ampliar el archivo, o rellenar agujeros).

Hay dos consideraciones principales de rendimiento que se derivan de esto. En primer lugar, las operaciones de sólo lectura se paralelizan muy bien en un clúster, ya que pueden ejecutarse independientemente en cada nodo. En segundo lugar, las operaciones que requieren un glock exclusivo pueden reducir el rendimiento, si hay varios nodos compitiendo por el acceso al mismo nodo(s). Por lo tanto, la consideración del conjunto de trabajo en cada nodo es un factor importante en el rendimiento del sistema de archivos GFS2, como cuando, por ejemplo, se realiza una copia de seguridad del sistema de archivos, como se describe en Copia de seguridad de un sistema de archivos GFS2.

Otra consecuencia de esto es que recomendamos el uso de la opción de montaje noatime o nodiratime con GFS2 siempre que sea posible, con preferencia por noatime cuando la aplicación lo permita. Esto evita que las lecturas requieran bloqueos exclusivos para actualizar la marca de tiempo atime.

Para los usuarios que se preocupan por el conjunto de trabajo o la eficiencia de la caché, GFS2 proporciona herramientas que permiten supervisar el rendimiento de un sistema de archivos GFS2: Performance Co-Pilot y GFS2 tracepoints.

Al utilizar el bloqueo Posix, debe tener en cuenta lo siguiente:

Por lo general, es posible alterar la forma en que una aplicación problemática almacena sus datos para obtener una considerable ventaja de rendimiento.

Un ejemplo típico de aplicación problemática es un servidor de correo electrónico. Estos suelen estar dispuestos con un directorio spool que contiene archivos para cada usuario (mbox), o con un directorio para cada usuario que contiene un archivo para cada mensaje (maildir). Cuando las peticiones llegan a través de IMAP, lo ideal es dar a cada usuario una afinidad con un nodo concreto. De esta forma, sus peticiones para ver y borrar mensajes de correo electrónico tenderán a ser servidas desde la caché de ese nodo. Obviamente, si ese nodo falla, la sesión puede reiniciarse en un nodo diferente.

Cuando el correo llega por medio de SMTP, de nuevo los nodos individuales pueden ser configurados para pasar el correo de un determinado usuario a un nodo particular por defecto. Si el nodo por defecto no está activo, entonces el mensaje puede ser guardado directamente en el spool de correo del usuario por el nodo receptor. Una vez más, este diseño está pensado para mantener determinados conjuntos de archivos en caché en un solo nodo en el caso normal, pero para permitir el acceso directo en caso de fallo del nodo.

Esta configuración permite el mejor uso de la caché de páginas de GFS2 y también hace que los fallos sean transparentes para la aplicación, ya sea imap o smtp.

Las copias de seguridad suelen ser otra área complicada. De nuevo, si es posible, es muy preferible hacer una copia de seguridad del conjunto de trabajo de cada nodo directamente desde el nodo que está almacenando en caché ese conjunto concreto de inodos. Si tienes un script de copia de seguridad que se ejecuta en un punto regular en el tiempo, y que parece coincidir con un pico en el tiempo de respuesta de una aplicación que se ejecuta en GFS2, entonces hay una buena posibilidad de que el clúster no esté haciendo el uso más eficiente de la caché de páginas.

Obviamente, si usted está en la posición de poder detener la aplicación para realizar una copia de seguridad, entonces esto no será un problema. Por otro lado, si una copia de seguridad se ejecuta desde un solo nodo, después de que se haya completado una gran parte del sistema de archivos se almacenará en caché en ese nodo, con una penalización de rendimiento para los accesos posteriores desde otros nodos. Esto se puede mitigar hasta cierto punto eliminando la caché de páginas VFS en el nodo de copia de seguridad después de que se haya completado la copia de seguridad con el siguiente comando:

echo -n 3 >/proc/sys/vm/drop_caches

Sin embargo, esta solución no es tan buena como asegurarse de que el conjunto de trabajo de cada nodo sea compartido, de sólo lectura en el clúster, o que se acceda a él principalmente desde un solo nodo.

Si el rendimiento de su clúster se ve afectado por el uso ineficiente de la caché de GFS2, es posible que vea tiempos de espera de E/S grandes y crecientes. Puede hacer uso de la información de volcado de bloqueos de GFS2 para determinar la causa del problema.

Esta sección proporciona una visión general del volcado de bloqueos de GFS2.

La información de volcado de bloqueos de GFS2 puede obtenerse del archivo debugfs que puede encontrarse en el siguiente nombre de ruta, asumiendo que debugfs está montado en /sys/kernel/debug/:

/sys/kernel/debug/gfs2/fsname/glocks

El contenido del archivo es una serie de líneas. Cada línea que comienza con G: representa un glock, y las líneas siguientes, sangradas por un solo espacio, representan un elemento de información relacionado con el glock inmediatamente anterior en el archivo.

La mejor manera de utilizar el archivo debugfs es usar el comando cat para tomar una copia del contenido completo del archivo (puede tomar mucho tiempo si tiene una gran cantidad de RAM y muchos inodos en caché) mientras la aplicación está experimentando problemas, y luego mirar los datos resultantes en una fecha posterior.

Las líneas del archivo debugfs que comienzan con H: (holders) representan solicitudes de bloqueo concedidas o en espera de ser concedidas. El campo de banderas en la línea de titulares f: muestra cuál: La bandera 'W' se refiere a una solicitud en espera, la bandera 'H' se refiere a una solicitud concedida. Los glocks que tienen un gran número de solicitudes en espera son probablemente los que están experimentando una contención particular.

Tabla 6.1, “Banderas Glock” muestra los significados de las diferentes banderas de las glock y Tabla 6.2, “Banderas de soporte de Glock” muestra los significados de las diferentes banderas de los soportes de las glock.

Una vez identificado un glock que está causando un problema, el siguiente paso es averiguar a qué inodo se refiere. El número de glock (n: en la línea G:) lo indica. Es de la forma type/number y si type es 2, entonces el glock es un glock de inodo y number es un número de inodo. Para localizar el inodo, puede ejecutar find -inum number donde number es el número de inodo convertido del formato hexadecimal del archivo glocks a decimal.

Tabla 6.3, “Tipos de Glock” muestra los significados de los diferentes tipos de glock.

Si el glock que se identificó era de un tipo diferente, lo más probable es que sea del tipo 3: (grupo de recursos). Si ve un número significativo de procesos esperando por otros tipos de glock bajo cargas normales, infórmelo al soporte de Red Hat.

Si ves un número de solicitudes en espera en el bloqueo de un grupo de recursos, puede haber varias razones para ello. Una de ellas es que haya un gran número de nodos en comparación con el número de grupos de recursos en el sistema de archivos. Otra es que el sistema de archivos puede estar casi lleno (lo que requiere, por término medio, más tiempo de búsqueda de bloques libres). La situación en ambos casos puede mejorarse añadiendo más almacenamiento y utilizando el comando gfs2_grow para ampliar el sistema de archivos.

Normalmente, GFS2 sólo escribe metadatos en su diario. El contenido de los archivos se escribe posteriormente en el disco mediante la sincronización periódica del kernel que vacía los búferes del sistema de archivos. Una llamada a fsync() en un archivo hace que los datos del archivo se escriban en el disco inmediatamente. La llamada regresa cuando el disco informa que todos los datos se han escrito con seguridad.

El registro en el diario de datos puede dar lugar a una reducción del tiempo de fsync() para archivos muy pequeños, ya que los datos del archivo se escriben en el diario además de los metadatos. Esta ventaja se reduce rápidamente a medida que aumenta el tamaño del archivo. La escritura en archivos medianos y grandes será mucho más lenta con el registro en el diario de datos activado.

Las aplicaciones que dependen de fsync() para sincronizar los datos de los archivos pueden ver mejorado su rendimiento si utilizan el registro en el diario de datos. El registro en el diario de datos puede activarse automáticamente para cualquier archivo GFS2 creado en un directorio marcado (y todos sus subdirectorios). También se puede activar o desactivar el registro en el diario de datos de los archivos existentes con longitud cero.

La activación del registro en el diario de datos en un directorio establece que el directorio "hereda jdata", lo que indica que todos los archivos y directorios creados posteriormente en ese directorio se registran en el diario. Puede activar y desactivar el registro en el diario de datos de un archivo con el comando chattr.

Los siguientes comandos habilitan el registro en el diario de datos en el archivo /mnt/gfs2/gfs2_dir/newfile y luego comprueban si el indicador se ha establecido correctamente.

# chattr +j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

Los siguientes comandos desactivan el registro en el diario de datos en el archivo /mnt/gfs2/gfs2_dir/newfile y luego comprueban si el indicador se ha establecido correctamente.

# chattr -j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile

También puede utilizar el comando chattr para establecer la bandera j en un directorio. Cuando se establece este indicador para un directorio, todos los archivos y directorios creados posteriormente en ese directorio se registran en el diario. El siguiente conjunto de comandos establece la bandera j en el directorio gfs2_dir, y luego comprueba si la bandera se ha establecido correctamente. Después de esto, los comandos crean un nuevo archivo llamado newfile en el directorio /mnt/gfs2/gfs2_dir y luego comprueban si la bandera j ha sido establecida para el archivo. Dado que la bandera j está establecida para el directorio, entonces newfile también debería tener el registro en el diario habilitado.

# chattr -j /mnt/gfs2/gfs2_dir
# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
# touch /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

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.

Si su sistema de archivos GFS2 se cuelga y no devuelve los comandos ejecutados en él, pero al reiniciar un nodo específico el sistema vuelve a la normalidad, esto puede ser indicativo de un problema de bloqueo o de un error. Si esto ocurre, reúna los datos de GFS2 durante una de estas ocurrencias y abra un ticket de soporte con el Soporte de Red Hat, como se describe en Recopilación de datos de GFS2 para la resolución de problemas.

Si su sistema de archivos GFS2 se cuelga y no devuelve los comandos que se ejecutan en él, requiriendo que reinicie todos los nodos del clúster antes de utilizarlo, compruebe los siguientes problemas.

Si añade un nuevo nodo a un clúster y descubre que no puede montar su sistema de archivos GFS2 en ese nodo, es posible que tenga menos diarios en el sistema de archivos GFS2 que nodos que intenten acceder al sistema de archivos GFS2. Debe tener un diario por cada host GFS2 en el que pretenda montar el sistema de archivos (a excepción de los sistemas de archivos GFS2 montados con la opción de montaje spectator, ya que éstos no requieren un diario). Puede añadir diarios a un sistema de archivos GFS2 con el comando gfs2_jadd. Añadir diarios a un sistema de archivos GFS2.

If you have an empty GFS2 file system, the df command will show that there is space being taken up. This is because GFS2 file system journals consume space (number of journals * journal size) on disk. If you created a GFS2 file system with a large number of journals or specified a large journal size then you will be see (number of journals * journal size) as already in use when you execute the df command. Even if you did not specify a large number of journals or large journals, small GFS2 file systems (in the 1GB or less range) will show a large amount of space as being in use with the default GFS2 journal size.

Si su sistema de archivos GFS2 se cuelga y no devuelve los comandos que se ejecutan contra él y se ve en la necesidad de abrir un ticket con el Soporte de Red Hat, primero debería reunir los siguientes datos:

Una vez que haya reunido esos datos, puede abrir un ticket con el Soporte de Red Hat y proporcionar los datos que ha recopilado.

Actualmente hay tres tipos de tracepoints GFS2: glock (pronunciado \ "gee-lock") tracepoints, bmap tracepoints y log tracepoints. Estos pueden ser usados para monitorear un sistema de archivos GFS2 en ejecución y dar información adicional a la que puede ser obtenida con las opciones de depuración soportadas en versiones anteriores de Red Hat Enterprise Linux. Los tracepoints son particularmente útiles cuando un problema, como un cuelgue o un problema de rendimiento, es reproducible y por lo tanto la salida del tracepoint puede obtenerse durante la operación problemática. En GFS2, los glocks son el principal mecanismo de control de la caché y son la clave para entender el rendimiento del núcleo de GFS2. Los tracepoints bmap (mapa de bloques) pueden utilizarse para supervisar las asignaciones de bloques y el mapeo de bloques (búsqueda de bloques ya asignados en el árbol de metadatos del disco) a medida que se producen y comprobar cualquier problema relacionado con la localidad de acceso. Los tracepoints de registro hacen un seguimiento de los datos que se escriben y liberan del diario y pueden proporcionar información útil sobre esa parte de GFS2.

Los tracepoints están diseñados para ser lo más genéricos posible. Esto debería significar que no será necesario cambiar la API durante el transcurso de Red Hat Enterprise Linux 8. Por otro lado, los usuarios de esta interfaz deberían ser conscientes de que se trata de una interfaz de depuración y no forma parte del conjunto normal de API de Red Hat Enterprise Linux 8, y como tal Red Hat no garantiza que no se produzcan cambios en la interfaz de tracepoints de GFS2.

Los tracepoints son una característica genérica de Red Hat Enterprise Linux y su alcance va mucho más allá de GFS2. En particular, se utilizan para implementar la infraestructura blktrace y los tracepoints de blktrace pueden utilizarse en combinación con los de GFS2 para obtener una imagen más completa del rendimiento del sistema. Debido al nivel en el que operan los tracepoints, pueden producir grandes volúmenes de datos en un periodo de tiempo muy corto. Se han diseñado para que supongan una carga mínima para el sistema cuando están activados, pero es inevitable que tengan algún efecto. El filtrado de los eventos por diversos medios puede ayudar a reducir el volumen de datos y a centrarse en la obtención de sólo la información que es útil para entender cualquier situación particular.

Los tracepoints se encuentran en el directorio /sys/kernel/debug/tracing/ suponiendo que debugfs esté montado en el lugar estándar del directorio /sys/kernel/debug. El subdirectorio events contiene todos los eventos de rastreo que se pueden especificar y, siempre que se cargue el módulo gfs2, habrá un subdirectorio gfs2 que contiene otros subdirectorios, uno para cada evento GFS2. El contenido del directorio /sys/kernel/debug/tracing/events/gfs2 debería ser más o menos el siguiente:

[root@chywoon gfs2]# ls
enable            gfs2_bmap       gfs2_glock_queue         gfs2_log_flush
filter            gfs2_demote_rq  gfs2_glock_state_change  gfs2_pin
gfs2_block_alloc  gfs2_glock_put  gfs2_log_blocks          gfs2_promote

Para activar todos los tracepoints GFS2, introduzca el siguiente comando:

[root@chywoon gfs2]# echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable

Para habilitar un tracepoint específico, hay un archivo enable en cada uno de los subdirectorios de eventos individuales. Lo mismo ocurre con el archivo filter, que puede utilizarse para establecer un filtro de eventos para cada evento o conjunto de eventos. El significado de los eventos individuales se explica con más detalle a continuación.

La salida de los tracepoints está disponible en formato ASCII o binario. Este apéndice no cubre actualmente la interfaz binaria. La interfaz ASCII está disponible de dos maneras. Para listar el contenido actual del buffer del anillo, puede introducir el siguiente comando:

[root@chywoon gfs2]# cat /sys/kernel/debug/tracing/trace

Esta interfaz es útil en los casos en los que se utiliza un proceso de larga duración durante un cierto período de tiempo y, después de algún evento, se desea consultar la última información capturada en el buffer. Una interfaz alternativa, /sys/kernel/debug/tracing/trace_pipe, se puede utilizar cuando se requiere toda la salida. Los eventos se leen de este archivo a medida que ocurren; no hay información histórica disponible a través de esta interfaz. El formato de la salida es el mismo desde ambas interfaces y se describe para cada uno de los eventos de GFS2 en las secciones posteriores de este apéndice.

Existe una utilidad llamada trace-cmd para leer los datos de los tracepoints. Para más información sobre esta utilidad, consulte el enlace en Sección 8.10, “Referencias”. La utilidad trace-cmd puede utilizarse de forma similar a la utilidad strace, por ejemplo para ejecutar un comando mientras se recopilan datos de trazas de varias fuentes.

Para entender GFS2, el concepto más importante que hay que entender, y el que lo diferencia de otros sistemas de archivos, es el concepto de glocks. En términos del código fuente, un glock es una estructura de datos que reúne el DLM y la caché en una sola máquina de estado. Cada glock tiene una relación 1:1 con un único bloqueo del DLM, y proporciona el almacenamiento en caché de ese estado de bloqueo para que las operaciones repetitivas realizadas desde un único nodo del sistema de archivos no tengan que llamar repetidamente al DLM, y así ayudan a evitar el tráfico de red innecesario. Existen dos grandes categorías de glocks, los que almacenan en caché los metadatos y los que no. Los glocks de inodo y los glocks de grupo de recursos almacenan en caché los metadatos, los otros tipos de glocks no almacenan en caché los metadatos. El inode glock también participa en el almacenamiento en caché de los datos además de los metadatos y tiene la lógica más compleja de todos los glocks.

Los glocks permanecen en memoria hasta que se desbloquean (a petición de otro nodo o a petición de la VM) y no hay usuarios locales. En ese momento se eliminan de la tabla hash de glock y se liberan. Cuando se crea un glock, el bloqueo DLM no se asocia con el glock inmediatamente. El bloqueo DLM se asocia con el glock en la primera petición al DLM, y si esta petición tiene éxito entonces la bandera 'I' (inicial) se establecerá en el glock. Tabla 8.4, “Banderas Glock” muestra los significados de las diferentes banderas del glock. Una vez que el DLM ha sido asociado con el glock, el bloqueo del DLM siempre permanecerá al menos en el modo de bloqueo NL (Nulo) hasta que el glock sea liberado. Una degradación del bloqueo DLM de NL a desbloqueado es siempre la última operación en la vida de un glock.

Cada glock puede tener un número de "holders" asociados, cada uno de los cuales representa una solicitud de bloqueo de las capas superiores. Las llamadas del sistema relacionadas con GFS2 ponen en cola y decaen los titulares del glock para proteger la sección crítica del código.

La máquina de estado glock se basa en una cola de trabajo. Por razones de rendimiento, los tasklets serían preferibles; sin embargo, en la implementación actual necesitamos enviar E/S desde ese contexto, lo que prohíbe su uso.

Tabla 8.2, “Modos y tipos de datos de Glock” muestra qué estado puede ser almacenado en caché bajo cada uno de los modos de glock y si ese estado almacenado en caché puede estar sucio. Esto se aplica tanto a los bloqueos de inodos como a los de grupos de recursos, aunque no hay ningún componente de datos para los bloqueos de grupos de recursos, sólo metadatos.

La interfaz de glock debugfs permite visualizar el estado interno de los glock y los soportes y también incluye algunos detalles resumidos de los objetos que se bloquean en algunos casos. Cada línea del archivo o bien comienza con G: sin sangría (que se refiere al propio glock) o bien comienza con una letra diferente, sangrada con un solo espacio, y se refiere a las estructuras asociadas al glock inmediatamente superior en el archivo (H: es un holder, I: un inodo, y R: un grupo de recursos) . He aquí un ejemplo de cómo podría ser el contenido de este archivo:

G:  s:SH n:5/75320 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:3/258028 f:yI t:EX d:EX/0 a:3 r:4
 H: s:EX f:tH e:0 p:4466 [postmark] gfs2_inplace_reserve_i+0x177/0x780 [gfs2]
 R: n:258028 f:05 b:22256/22256 i:16800
G:  s:EX n:2/219916 f:yfI t:EX d:EX/0 a:0 r:3
 I: n:75661/219916 t:8 f:0x10 d:0x00000000 s:7522/7522
G:  s:SH n:5/127205 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:2/50382 f:yfI t:EX d:EX/0 a:0 r:2
G:  s:SH n:5/302519 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/313874 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/271916 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/312732 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]

El ejemplo anterior es una serie de extractos (de un archivo de aproximadamente 18 MB) generados por el comando cat /sys/kernel/debug/gfs2/unity:myfs/glocks >my.lock durante una ejecución del benchmark postmark en un sistema de archivos GFS2 de un solo nodo. Los glocks de la figura se han seleccionado para mostrar algunas de las características más interesantes de los volcados de glock.

Los estados de glock son EX (exclusivo), DF (diferido), SH (compartido) o UN (desbloqueado). Estos estados se corresponden directamente con los modos de bloqueo DLM, excepto UN, que puede representar el estado de bloqueo DLM nulo, o que GFS2 no mantiene un bloqueo DLM (dependiendo de la bandera I, como se ha explicado anteriormente). El campo s: del glock indica el estado actual del bloqueo y el mismo campo en el holder indica el modo solicitado. Si el bloqueo se concede, el soporte tendrá el bit H activado en sus banderas (campo f:). En caso contrario, tendrá activado el bit de espera W.

El campo n: (número) indica el número asociado a cada elemento. En el caso de los glocks, es el número de tipo seguido del número de glock, de modo que en el ejemplo anterior, el primer glock es n:5/75320; lo que indica un glock iopen que se relaciona con el inodo 75320. En el caso de los glocks de inodo y iopen, el número de glock es siempre idéntico al número de bloque de disco del inodo.

El listado completo de todas las banderas, tanto para el titular como para el glock, se encuentra en Tabla 8.4, “Banderas Glock” y Tabla 8.5, “Banderas de soporte de Glock”. El contenido de los bloques de valores de los candados no está disponible actualmente a través de la interfaz de glock debugfs.

Tabla 8.3, “Tipos de Glock” muestra los significados de los diferentes tipos de glock.

Una de las banderas más importantes de glock es la bandera l (locked). Este es el bit de bloqueo que se utiliza para arbitrar el acceso al estado de glock cuando se va a realizar un cambio de estado. Se establece cuando la máquina de estado está a punto de enviar una solicitud de bloqueo remoto a través del DLM, y sólo se borra cuando la operación completa se ha realizado. A veces esto puede significar que se haya enviado más de una solicitud de bloqueo, con varias invalidaciones que se producen entre las veces.

Tabla 8.4, “Banderas Glock” muestra los significados de las diferentes banderas de las glock.

Cuando se recibe una devolución de llamada remota de un nodo que quiere obtener un bloqueo en un modo que entra en conflicto con el que se mantiene en el nodo local, entonces se establece uno u otro de los dos indicadores D (demote) o d (demote pending). Para evitar que se produzcan condiciones de inanición cuando hay contención en un determinado bloqueo, a cada bloqueo se le asigna un tiempo de retención mínimo. Un nodo que aún no ha tenido el bloqueo durante el tiempo mínimo de retención se le permite retener ese bloqueo hasta que el intervalo de tiempo haya expirado.

Si el intervalo de tiempo ha expirado, se activará la bandera D (demote) y se registrará el estado requerido. En ese caso, la próxima vez que no haya bloqueos concedidos en la cola de titulares, el bloqueo será degradado. Si el intervalo de tiempo no ha expirado, entonces se establece la bandera d (demote pending) en su lugar. Esto también programa la máquina de estado para borrar d (demote pending) y establecer D (demote) cuando el tiempo mínimo de retención haya expirado.

La bandera I (inicial) se establece cuando a la glock se le ha asignado un bloqueo DLM. Esto sucede cuando la glock se utiliza por primera vez y la bandera I permanecerá entonces establecida hasta que la glock sea finalmente liberada (que el bloqueo DLM se desbloquee).

enTabla 8.5, “Banderas de soporte de Glock” se muestran los significados de las diferentes banderas de los soportes de las glock.

Los indicadores de titular más importantes son H (titular) y W (espera), como se mencionó anteriormente, ya que se establecen en las solicitudes de bloqueo concedidas y en las solicitudes de bloqueo en cola, respectivamente. El orden de los titulares en la lista es importante. Si hay titulares concedidos, siempre estarán a la cabeza de la cola, seguidos de los titulares en cola.

Si no hay titulares concedidos, el primer titular de la lista será el que desencadene el siguiente cambio de estado. Dado que las solicitudes de baja se consideran siempre de mayor prioridad que las solicitudes del sistema de archivos, esto podría no siempre resultar directamente en un cambio de estado solicitado.

El subsistema glock soporta dos tipos de bloqueos "try". Estos son útiles tanto porque permiten la toma de bloqueos fuera del orden normal (con un retroceso y reintento adecuados) como porque pueden ser utilizados para ayudar a evitar recursos en uso por otros nodos. El bloqueo normal t (try) es justo lo que su nombre indica; es un bloqueo "try" que no hace nada especial. El bloqueo T (try 1CB), por otro lado, es idéntico al bloqueo t, excepto que el DLM enviará una única devolución de llamada a los actuales titulares de bloqueos incompatibles. Un uso del bloqueo T (try 1CB) es con los bloqueos iopen, que se utilizan para arbitrar entre los nodos cuando la cuenta i_nlink de un nodo es cero, y determinar cuál de los nodos será responsable de la desasignación del nodo. El glock de iopen se mantiene normalmente en estado compartido, pero cuando la cuenta de i_nlink llega a cero y se llama a →evict_inode(), solicitará un bloqueo exclusivo con T (try 1CB) establecido. Si el bloqueo es concedido, continuará con la asignación del inodo. Si el bloqueo no se concede, el nodo(s) que impedía(n) la concesión del bloqueo marcará(n) su(s) glock(s) con la bandera D (demote), que se comprueba en →drop_inode() para asegurar que la desasignación no se olvida.

Esto significa que los inodos que tienen un recuento de enlaces cero pero que todavía están abiertos serán desasignados por el nodo en el que se produce el close() final. Además, al mismo tiempo que el recuento de enlaces del nodo se reduce a cero, el nodo se marca como en el estado especial de tener un recuento de enlaces cero pero todavía en uso en el mapa de bits del grupo de recursos. Esto funciona como la lista de huérfanos del sistema de archivos ext3 en el sentido de que permite a cualquier lector posterior del mapa de bits saber que existe un espacio potencialmente recuperable, e intentar recuperarlo.

Los tracepoints también están diseñados para poder confirmar la corrección del control de la caché combinándolos con la salida de blktrace y con el conocimiento de la disposición en el disco. De este modo, es posible comprobar que cualquier E/S se ha emitido y completado bajo el bloqueo correcto, y que no hay carreras presentes.

El tracepoint gfs2_glock_state_change es el más importante para entender. Rastrea todos los cambios de estado del glock desde su creación inicial hasta el descenso final que termina con gfs2_glock_put y la transición final de NL a desbloqueado. La bandera l (bloqueada) de la glock siempre se establece antes de que se produzca un cambio de estado y no se borrará hasta después de que haya terminado. Durante un cambio de estado nunca hay titulares concedidos (la bandera de titular de glock H). Si hay titulares en cola, siempre estarán en el estado W (esperando). Cuando el cambio de estado se ha completado, los titulares pueden ser concedidos, que es la operación final antes de que la bandera l glock se borre.

El tracepoint gfs2_demote_rq lleva la cuenta de las peticiones de demote, tanto locales como remotas. Asumiendo que hay suficiente memoria en el nodo, las peticiones de demote locales raramente se verán, y la mayoría de las veces serán creadas por umount o por recuperaciones de memoria ocasionales. El número de peticiones de baja remotas es una medida de la contención entre nodos para un nodo o grupo de recursos en particular.

El tracepoint gfs2_glock_lock_time proporciona información sobre el tiempo que tardan las peticiones al DLM. La bandera de bloqueo (b) se introdujo en el glock específicamente para ser utilizada en combinación con este tracepoint.

Cuando a un titular se le concede un bloqueo, se llama a gfs2_promote, esto ocurre como las etapas finales de un cambio de estado o cuando se solicita un bloqueo que puede ser concedido inmediatamente debido a que el estado de glock ya tiene en caché un bloqueo de un modo adecuado. Si el titular es el primero en ser concedido para este glock, entonces la bandera f (primero) se establece en ese titular. En la actualidad, esto sólo lo utilizan los grupos de recursos.

El mapeo de bloques es una tarea fundamental para cualquier sistema de archivos. GFS2 utiliza un sistema tradicional basado en mapas de bits con dos bits por bloque. El objetivo principal de los tracepoints en este subsistema es permitir el control del tiempo que se tarda en asignar y mapear los bloques.

El tracepoint gfs2_bmap se llama dos veces para cada operación bmap: una vez al principio para mostrar la petición bmap, y otra al final para mostrar el resultado. Esto facilita el cotejo de las peticiones y los resultados y la medición del tiempo que se tarda en mapear bloques en diferentes partes del sistema de archivos, diferentes offsets de archivos, o incluso de diferentes archivos. También es posible ver cuáles son los tamaños medios de extensión que se devuelven en comparación con los solicitados.

El tracepoint gfs2_rs rastrea las reservas de bloques a medida que se crean, utilizan y destruyen en el asignador de bloques.

Para hacer un seguimiento de los bloques asignados, se llama a gfs2_block_alloc no sólo en las asignaciones, sino también en la liberación de bloques. Dado que todas las asignaciones están referenciadas según el inodo al que está destinado el bloque, esto puede utilizarse para rastrear qué bloques físicos pertenecen a qué archivos en un sistema de archivos activo. Esto es particularmente útil cuando se combina con blktrace, que mostrará patrones de E/S problemáticos que pueden ser referenciados de nuevo a los inodos relevantes usando el mapeo obtenido por medio de este tracepoint.

La E/S directa (iomap) es una política de caché alternativa que permite que las transferencias de datos de archivos se realicen directamente entre el disco y el buffer del usuario. Esto tiene ventajas en situaciones en las que se espera que la tasa de éxito de la caché sea baja. Tanto gfs2_iomap_start como gfs2_iomap_end trazan estas operaciones y pueden ser utilizadas para mantener un registro del mapeo que utiliza la E/S directa, las posiciones en el sistema de archivos de la E/S directa junto con el tipo de operación.

Los puntos de seguimiento de este subsistema registran los bloques que se añaden y eliminan del diario (gfs2_pin), así como el tiempo que se tarda en consignar las transacciones en el registro (gfs2_log_flush). Esto puede ser muy útil cuando se trata de depurar los problemas de rendimiento del diario.

El tracepoint gfs2_log_blocks lleva la cuenta de los bloques reservados en el registro, lo que puede ayudar a mostrar si el registro es demasiado pequeño para la carga de trabajo, por ejemplo.

El tracepoint gfs2_ail_flush es similar al tracepoint gfs2_log_flush en el sentido de que mantiene un registro del inicio y el final de los vaciados de la lista AIL. La lista AIL contiene búferes que han pasado por el registro, pero que aún no han sido escritos de nuevo en su lugar y esto se vacía periódicamente con el fin de liberar más espacio de registro para su uso por el sistema de archivos, o cuando un proceso solicita un sync o fsync.

GFS2 mantiene estadísticas que pueden ayudar a rastrear lo que está sucediendo dentro del sistema de archivos. Esto le permite detectar problemas de rendimiento.

GFS2 mantiene dos contadores:

Además, GFS2 mantiene tres pares de media/varianza. Los pares media/varianza son estimaciones exponenciales suavizadas y el algoritmo utilizado es el que se emplea para calcular los tiempos de ida y vuelta en el código de red.

Los pares de media y varianza mantenidos en GFS2 no están escalados, sino que están en unidades de nanosegundos enteros.

Una petición no bloqueante es aquella que se completará inmediatamente, sea cual sea el estado del bloqueo DLM en cuestión. Esto significa actualmente cualquier petición cuando (a) el estado actual del bloqueo es exclusivo (b) el estado solicitado es nulo o desbloqueado o (c) la bandera "try lock" está activada. Una solicitud de bloqueo cubre todas las demás solicitudes de bloqueo.

Los tiempos más grandes son mejores para los IRTT, mientras que los tiempos más pequeños son mejores para los RTT.

Las estadísticas se guardan en dos archivos sysfs:

Para más información sobre los tracepoints y el archivo GFS2 glocks, consulte los siguientes recursos:

Para funcionar correctamente, el PMDA GFS2 requiere que el sistema de archivos debugfs esté montado. Si el sistema de archivos debugfs no está montado, ejecute los siguientes comandos antes de instalar el GFS2 PMDA:

# mkdir /sys/kernel/debug
# mount -t debugfs none /sys/kernel/debug

El PMDA de GFS2 no está habilitado como parte de la instalación por defecto. Para hacer uso de la monitorización de métricas de GFS2 a través de PCP debe habilitarla después de la instalación.

Ejecute los siguientes comandos para instalar PCP y habilitar el PMDA de GFS2. Tenga en cuenta que el script de instalación de PMDA debe ejecutarse como root.

# yum install pcp pcp-pmda-gfs2
# cd /var/lib/pcp/pmdas/gfs2
# ./Install
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Check gfs2 metrics have appeared ... 346 metrics and 255 values

La herramienta pminfo muestra información sobre las métricas de rendimiento disponibles. Las siguientes secciones muestran ejemplos de diferentes métricas de GFS2 que puede mostrar con esta herramienta.

# pminfo -f gfs2.glocks

gfs2.glocks.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glocks.shared
    inst [0 or "afc_cluster:data"] value 25
    inst [1 or "afc_cluster:bin"] value 25

gfs2.glocks.unlocked
    inst [0 or "afc_cluster:data"] value 43652
    inst [1 or "afc_cluster:bin"] value 2063

gfs2.glocks.deferred
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glocks.exclusive
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

# pminfo -f gfs2.glstats

gfs2.glstats.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glstats.trans
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

gfs2.glstats.inode
    inst [0 or "afc_cluster:data"] value 17
    inst [1 or "afc_cluster:bin"] value 17

gfs2.glstats.rgrp
    inst [0 or "afc_cluster:data"] value 43642
    inst [1 or "afc_cluster:bin"] value 2053

gfs2.glstats.meta
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

gfs2.glstats.iopen
    inst [0 or "afc_cluster:data"] value 16
    inst [1 or "afc_cluster:bin"] value 16

gfs2.glstats.flock
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.quota
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.journal
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

# pminfo -f gfs2.holders.flags.wait

gfs2.holders.flags.wait
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.log_flush.total

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

Tabla 9.1, “Lista completa de métricas” describe la lista completa de métricas de rendimiento que ofrece el paquete pcp-pmda-gfs2 para los sistemas de archivos GFS2.

El siguiente procedimiento describe las instrucciones sobre cómo instalar una configuración mínima de PCP para recopilar estadísticas en Red Hat Enterprise Linux. Esta configuración implica añadir el número mínimo de paquetes en un sistema de producción necesario para recopilar datos para su posterior análisis.

El archivo tar.gz resultante de la salida de pmlogger puede analizarse utilizando otras herramientas de PCP y puede compararse con otras fuentes de información sobre el rendimiento.