Red Hat Training

A Red Hat training course is available for RHEL 8

6.2. Bloqueo del nodo GFS2

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.

Nota

Debido a la forma en que se implementa el almacenamiento en caché de GFS2, el mejor rendimiento se obtiene cuando se produce cualquiera de las siguientes situaciones:

  • Un inodo se utiliza de forma de sólo lectura en todos los nodos.
  • Un inodo se escribe o modifica desde un solo nodo.

Tenga en cuenta que la inserción y eliminación de entradas de un directorio durante la creación y eliminación de archivos cuenta como escritura en el inodo del directorio.

Es posible romper esta regla siempre que se rompa con relativa poca frecuencia. Ignorar esta regla con demasiada frecuencia dará lugar a una grave penalización del rendimiento.

Si mmap() un archivo en GFS2 con un mapeo de lectura/escritura, pero sólo lee de él, esto sólo cuenta como una lectura.

Si no se establece el parámetro noatime mount , las lecturas también darán lugar a escrituras para actualizar las marcas de tiempo de los archivos. Recomendamos que todos los usuarios de GFS2 monten con noatime a menos que tengan un requisito específico para atime.