Buscar

2.9. Bloqueo de nodo GFS2

download PDF
Para obtener el mejor rendimiento de un sistema de archivos GFS2, es muy importante entender alguna teoría básica de su operación. Un sistema de archivos de nodo único se implementa junto a la memoria cache, con el propósito de eliminar latencia de acceso de disco cuando se utilicen datos solicitados con frecuencia. En la página cache de Linux (e históricamente la cache de buffer) se proporciona esta función de cache.
Con GFS2, cada nodo tiene su propia página cache que contiene alguna parte de datos en disco. GFS2 utiliza un mecanismo de bloqueo llamado glocks para mantener la integridad de la cache entre nodos. El subsistema de glock ofrece una función de manejo de cache que se implementa con el administrador de cerrojo distribuido (DLM) como la capa de comunicación subyacente.
Los glock proporcionan protección para la cache en una base por inodo, por lo tanto hay un cerrojo por inodo, el cual sirve para controlar la capa de memoria cache. Si ese glock se otorga en modo compartido (modo de cerrojo DLM: PR) entonces los datos bajo ese glock pueden ser puestos en memoria cache tras uno o más nodos al mismo tiempo, para que todos los nodos puedan tener acceso local a datos.
Si se le otorga modo exclusivo al glock (modo de cerrojo DLM: EX) entonces solamente un nodo único puede poner en memoria cache los datos bajo ese glock. Este modo es utilizado por todas las operaciones que modifican los datos (tal como la llamada a sistema write).
Si otro nodo solicita un glock que no puede ser otorgado inmediatamente, entonces el DLM envía un mensaje al nodo o nodos que actualmente guardan los glock bloqueando la nueva solicitud para pedirles que coloquen los cerrojos. Colocar los glock (por las normas de la mayoría de operaciones del sistema de archivos) puede ser un proceso largo. Colocar un glock compartido requiere que la cache sea invalidada, lo cual es relativamente rápido y proporcional a la cantidad de datos en memoria cache.
Colocar un glock exclusivo requiere un vaciado de registro, y volver a escribir al disco los datos cambiados, seguido de la invalidación como el glock compartido.
La diferencia entre un sistema de archivos de nodo único y GFS2, es que el sistema de archivos de nodo único tiene una cache única y GFS2 tiene una cache independiente para cada nodo. En ambos casos, la latencia de acceso a los datos en memoria cache es de un orden de magnitud similar, pero la latencia para acceder datos que no están en memoria cache es mucho mayor en GFS2 si otro nodo ha puesto anteriormente en memoria cache esos mismos datos.

Nota

Debido a la forma en la que la puesta en memoria cache de GFS2 se implementa, el mejor rendimiento se obtiene cuando algo de esto tiene lugar:
  • Un inodo se utiliza en modo de solo lectura a través de todos los nodos.
  • Un inodo se escribe o modifica desde un solo nodo únicamente.
Observe que insertar o retirar entradas de un directorio durante la creación y borrado de un archivo, cuenta como escribir en el inodo del directorio.
Es posible romper esta regla si pocas veces se rompe. Si ignora esta regla con mucha frecuencia, resultará en una pena severa en el rendimiento.
Si ejecuta mmap() de un archivo en GFS2 con una asignación de lectura/escritura, pero solamente lee desde él, solo cuenta como de lectura. En GFS, sin embargo, este archivo cuenta como de escritura, por lo tanto GFS2 es mucho más escalable con E/S de mmap().
Si no ha establecido el parámetro noatime mount, entonces las lecturas también resultarán en escrituras para actualizar las marcas de tiempo del archivo. Se recomienda que todos los usuarios de GFS2 monten con noatime a menos que tengan un requerimiento específico para atime.

2.9.1. Problemas con Bloqueo de Posix

Al utilizar el bloqueo de Posix, debe tener en cuenta lo siguiente:
  • El uso de Flocks generará un procesamiento más rápido que el uso de cerrojos Posix.
  • Los programas que usan cerrojos Posix en GFS2 deben evitar el uso de la función GETLK ya que en un entorno de clúster, el ID de proceso puede ser para un nodo diferente en el clúster.
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.