Administrador de bloqueos distribuidos

Un gestor de bloqueos distribuido ( DLM ) se ejecuta en cada máquina de un clúster, con una copia idéntica de la base de datos de bloqueos del clúster. Los sistemas operativos utilizan gestores de bloqueos para organizar y serializar el acceso a los recursos. De esta forma , un DLM proporciona a las aplicaciones de software distribuidas en un clúster (en varias máquinas) un medio para sincronizar sus accesos a los recursos compartidos .

Las DLM se han utilizado como base para varios sistemas de archivos en clúster exitosos , en los que las máquinas de un clúster pueden usar el almacenamiento de las demás a través de un sistema de archivos unificado , con ventajas significativas en rendimiento y disponibilidad . El principal beneficio en rendimiento proviene de la solución del problema de la coherencia de la caché de disco entre los equipos participantes. La DLM se utiliza no solo para el bloqueo de archivos , sino también para la coordinación de todo el acceso al disco . VMScluster , el primer sistema de clúster de uso generalizado, se basó en la DLM de OpenVMS precisamente de esta manera.

El DLM utiliza un concepto generalizado de recurso , que es una entidad cuyo acceso compartido debe controlarse. Esto puede referirse a un archivo, un registro, un área de memoria compartida o cualquier otra cosa que el diseñador de la aplicación elija. Se puede definir una jerarquía de recursos, de modo que se puedan implementar varios niveles de bloqueo. Por ejemplo, una base de datos hipotética podría definir una jerarquía de recursos de la siguiente manera:

• Base de datos
• Mesa
• Registro
• Campo

Un proceso puede adquirir bloqueos en la base de datos en su conjunto y, posteriormente, en partes específicas de la misma. Es necesario obtener un bloqueo en un recurso principal antes de poder bloquear un recurso secundario.

Un proceso que se ejecuta dentro de un VMSCluster puede obtener un bloqueo sobre un recurso. Existen seis modos de bloqueo que se pueden otorgar, los cuales determinan el nivel de exclusividad concedido. Es posible cambiar el modo de bloqueo a uno de mayor o menor nivel. Cuando todos los procesos han desbloqueado un recurso, la información del sistema sobre dicho recurso se elimina.

• Nulo (NL). Indica interés en el recurso, pero no impide que otros procesos lo bloqueen. Tiene la ventaja de que el recurso y su bloque de valor de bloqueo se conservan, incluso cuando ningún proceso lo está bloqueando.
• Lectura concurrente (CR). Indica el deseo de leer (pero no actualizar) el recurso. Permite que otros procesos lean o actualicen el recurso, pero impide que otros tengan acceso exclusivo a él. Generalmente se utiliza en recursos de alto nivel, para poder obtener bloqueos más restrictivos en los recursos subordinados.
• Escritura concurrente (CW). Indica el deseo de leer y actualizar el recurso. Permite que otros procesos también lo lean o actualicen, pero impide que otros tengan acceso exclusivo al mismo. Generalmente se utiliza en recursos de alto nivel para obtener bloqueos más restrictivos en recursos subordinados.
• Lectura protegida (RP). Este es el bloqueo de uso compartido tradicional , que indica el deseo de leer el recurso pero impide que otros lo actualicen. Sin embargo, otros también pueden leer el recurso.
• Escritura protegida (PW). Este es el bloqueo de actualización tradicional , que indica el deseo de leer y actualizar el recurso e impide que otros lo hagan. Sin embargo, quienes tengan acceso de lectura concurrente pueden leer el recurso.
• Exclusivo (EX). Este es el bloqueo exclusivo tradicional que permite el acceso de lectura y actualización al recurso, e impide que otros tengan acceso al mismo.

La siguiente tabla de verdad muestra la compatibilidad de cada modo de bloqueo con los demás:

Un proceso puede obtener un bloqueo sobre un recurso mediante la puesta en cola de una solicitud de bloqueo. Esto es similar a la técnica QIO que se utiliza para realizar operaciones de entrada/salida. La solicitud de bloqueo puede completarse de forma síncrona, en cuyo caso el proceso espera hasta que se conceda el bloqueo, o de forma asíncrona, en cuyo caso se produce un AST cuando se ha obtenido el bloqueo.

También es posible establecer un árbol de sintaxis abstracta (AST) bloqueante , que se activa cuando un proceso obtiene un bloqueo que impide el acceso al recurso por parte de otro proceso. El proceso original puede entonces, opcionalmente, tomar medidas para permitir el acceso al otro proceso (por ejemplo, degradando o liberando el bloqueo).

Cada recurso tiene asociado un bloque de valor de bloqueo. Este bloque puede ser leído por cualquier proceso que haya obtenido un bloqueo sobre el recurso (excepto un bloqueo nulo) y puede ser actualizado por un proceso que haya obtenido un bloqueo exclusivo o de actualización protegida sobre él.

Se puede utilizar para almacenar cualquier información sobre el recurso que el diseñador de la aplicación elija. Un uso típico es almacenar el número de versión del recurso. Cada vez que se actualiza la entidad asociada (por ejemplo, un registro de base de datos), quien posee el bloqueo incrementa el bloque de valor de bloqueo. Cuando otro proceso desea leer el recurso, obtiene el bloqueo correspondiente y compara el valor actual del bloqueo con el valor que tenía la última vez que bloqueó el recurso. Si el valor es el mismo, el proceso sabe que la entidad asociada no se ha actualizado desde la última vez que la leyó y, por lo tanto, no es necesario leerla de nuevo. Por consiguiente, esta técnica se puede utilizar para implementar diversos tipos de caché en una base de datos o aplicación similar.

Cuando uno o más procesos obtienen bloqueos sobre recursos, es posible que se produzca una situación en la que cada uno impida que otro obtenga un bloqueo, y ninguno pueda continuar. Esto se conoce como interbloqueo ( EW Dijkstra lo denominó originalmente abrazo mortal ). ^{[ 1 ]}

Un ejemplo sencillo es cuando el Proceso 1 ha obtenido un bloqueo exclusivo sobre el Recurso A, y el Proceso 2 ha obtenido un bloqueo exclusivo sobre el Recurso B. Si el Proceso 1 intenta bloquear el Recurso B, tendrá que esperar a que el Proceso 2 lo libere. Pero si el Proceso 2 intenta bloquear el Recurso A, ambos procesos esperarán indefinidamente el uno al otro.

El DLM de OpenVMS comprueba periódicamente si existen situaciones de interbloqueo. En el ejemplo anterior, la segunda solicitud de encolamiento de bloqueo de uno de los procesos devolvería un estado de interbloqueo. En ese caso, sería responsabilidad de dicho proceso tomar medidas para resolver el interbloqueo, liberando el primer bloqueo que obtuvo.

Tanto Red Hat como Oracle han desarrollado software de clúster para Linux .

OCFS2 , el sistema de archivos de clúster de Oracle, se agregó ^{[ 2 ]} al kernel oficial de Linux con la versión 2.6.16, en enero de 2006. La advertencia de código de calidad alfa en OCFS2 se eliminó en la versión 2.6.19.

El software de clúster de Red Hat, incluidos su DLM y GFS2, se agregó oficialmente al kernel de Linux ^{[ 3 ]} con la versión 2.6.19, en noviembre de 2006.

Ambos sistemas utilizan un DLM modelado a partir del venerable DLM de VMS. ^{[ 4 ]} El DLM de Oracle tiene una API más simple. (La función principal dlmlock()tiene ocho parámetros, mientras que el SYS$ENQservicio VMS y el de Red Hat dlm_locktienen 11).

Otras implementaciones de DLM incluyen las siguientes:

• Google ha desarrollado Chubby , un servicio de bloqueo para sistemas distribuidos débilmente acoplados. ^{[ 5 ]} Está diseñado para el bloqueo de grano grueso y también proporciona un sistema de archivos distribuido limitado pero fiable. Partes clave de la infraestructura de Google, incluyendo Google File System , Bigtable y MapReduce , utilizan Chubby para sincronizar los accesos a recursos compartidos. Aunque Chubby fue diseñado como un servicio de bloqueo, ahora se utiliza ampliamente dentro de Google como servidor de nombres , reemplazando a DNS . ^{[ 5 ]}
• Apache ZooKeeper , que fue creado en Yahoo , es un software de código abierto y también se puede utilizar para realizar bloqueos distribuidos ^{[ 6 ] .}
• Etcd es un software de código abierto, desarrollado en CoreOS bajo la licencia Apache . ^{[ 7 ]} También se puede utilizar para realizar bloqueos distribuidos. ^{[ 8 ]}
• Redis es una caché y almacén de clave-valor avanzado de código abierto, con licencia Redis Source Available License. ^{[ 9 ]} Redis se puede utilizar para implementar el algoritmo Redlock para la gestión distribuida de bloqueos. ^{[ 10 ]}
• Consul de HashiCorp , ^{[ 11 ]} que fue creado por HashiCorp , es un software de código abierto y también se puede utilizar para realizar bloqueos distribuidos.
• El gestor de bloqueos distribuidos Taooka ^{[ 12 ]} utiliza los métodos de "try lock" para evitar interbloqueos . También puede especificar un TTL para cada bloqueo con precisión de nanosegundos.
• Un DLM es también un componente clave de proyectos de imagen de sistema único (SSI) más ambiciosos, como OpenSSI .