Los sistemas operativos utilizan administradores de bloqueo para organizar y serializar el acceso a los recursos. Un administrador de bloqueo distribuido (DLM) se ejecuta en cada máquina de un clúster, con una copia idéntica de una base de datos de bloqueo de todo el clúster. De esta manera, un DLM proporciona aplicaciones de software que se distribuyen en un clúster en varias máquinas con un medio para sincronizar sus accesos a los recursos compartidos .
Los 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 utilizar el almacenamiento de las demás a través de un sistema de archivos unificado , con importantes ventajas de rendimiento y disponibilidad . El principal beneficio de rendimiento proviene de resolver el problema de la coherencia de la memoria caché del disco entre los equipos participantes. El DLM se utiliza no solo para el bloqueo de archivos, sino también para la coordinación de todos los accesos al disco . VMScluster , el primer sistema de agrupación en clústeres que se usa ampliamente, se basa en OpenVMS DLM precisamente de esta manera.
Implementación de VMS
El VMS (sistema de memoria virtual) de DEC fue el primer sistema operativo ampliamente disponible en implementar un DLM. Esto estuvo disponible en la Versión 4, aunque la interfaz de usuario era la misma que la del administrador de bloqueo de un solo procesador que se implementó por primera vez en la Versión 3.
Recursos
El DLM utiliza un concepto generalizado de recurso , que es una entidad a la que se debe controlar el acceso compartido. Esto puede estar relacionado con un archivo, un registro, un área de memoria compartida o cualquier otra cosa que elija el diseñador de la aplicación . Puede definirse 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
Luego, un proceso puede adquirir bloqueos en la base de datos como un todo y luego en partes particulares de la base de datos. Se debe obtener un bloqueo en un recurso principal antes de que se pueda bloquear un recurso subordinado.
Modos de bloqueo
Un proceso que se ejecuta dentro de un VMSCluster puede obtener un bloqueo en un recurso. Hay seis modos de bloqueo que se pueden otorgar, y estos determinan el nivel de exclusividad que se otorga, es posible convertir el bloqueo a un nivel superior o inferior de modo de bloqueo. Cuando todos los procesos han desbloqueado un recurso, la información del sistema sobre el recurso se destruye.
- Nulo (NL). Indica interés en el recurso, pero no evita 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 bloquea.
- Lectura concurrente (CR). Indica un deseo de leer (pero no actualizar) el recurso. Permite que otros procesos lean o actualicen el recurso, pero evita que otros tengan acceso exclusivo a él. Esto generalmente se emplea en recursos de alto nivel, para que se puedan obtener bloqueos más restrictivos en recursos subordinados.
- Escritura concurrente (CW). Indica un deseo de leer y actualizar el recurso. También permite que otros procesos lean o actualicen el recurso, pero evita que otros tengan acceso exclusivo a él. Esto también se suele emplear en recursos de alto nivel, para que se puedan obtener bloqueos más restrictivos en recursos subordinados.
- Lectura protegida (PR). Este es el bloqueo compartido tradicional , que indica el deseo de leer el recurso pero evita 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 y evita que otros lo actualicen. Sin embargo, otros con 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 y evita que otros tengan acceso a él.
La siguiente tabla de verdad muestra la compatibilidad de cada modo de bloqueo con los demás:
Modo | NL | CR | CW | PR | PW | EX |
---|---|---|---|---|---|---|
NL | sí | sí | sí | sí | sí | sí |
CR | sí | sí | sí | sí | sí | No |
CW | sí | sí | sí | No | No | No |
PR | sí | sí | No | sí | No | No |
PW | sí | sí | No | No | No | No |
EX | sí | No | No | No | No | No |
Obtener un candado
Un proceso puede obtener un bloqueo en un recurso poniendo en cola una solicitud de bloqueo. Esto es similar a la técnica QIO que se utiliza para realizar E / S. La solicitud de bloqueo de puesta en cola 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 AST de bloqueo , que se activa cuando un proceso ha obtenido un bloqueo que impide el acceso al recurso por parte de otro proceso. El proceso original puede entonces tomar acción opcionalmente para permitir el otro acceso (por ejemplo, degradando o liberando el bloqueo).
Bloquear bloque de valor
Un bloque de valor de bloqueo está asociado con cada recurso. Esto puede ser leído por cualquier proceso que haya obtenido un bloqueo en el recurso (que no sea un bloqueo nulo) y puede ser actualizado por un proceso que haya obtenido una actualización protegida o un bloqueo exclusivo en él.
Se puede utilizar para almacenar cualquier información sobre el recurso que elija el diseñador de la aplicación. Un uso típico es mantener un número de versión del recurso. Cada vez que se actualiza la entidad asociada (por ejemplo, un registro de la base de datos), el titular del bloqueo incrementa el bloque de valor del bloqueo. Cuando otro proceso desea leer el recurso, obtiene el bloqueo apropiado y compara el valor de bloqueo actual con el valor que tenía la última vez que el proceso bloqueó el recurso. Si el valor es el mismo, el proceso sabe que la entidad asociada no ha sido actualizada desde la última vez que la leyó, por lo que no es necesario volver a leerla. Por lo tanto, esta técnica se puede utilizar para implementar varios tipos de caché en una base de datos o una aplicación similar.
Detección de interbloqueo
Cuando uno o más procesos han obtenido bloqueos en los recursos, es posible producir una situación en la que cada uno impida que otro obtenga un bloqueo, y ninguno de ellos puede continuar. Esto se conoce como un punto muerto ( EW Dijkstra originalmente lo llamó un abrazo mortal ). [1]
Un ejemplo simple es cuando el proceso 1 ha obtenido un bloqueo exclusivo en el recurso A y el proceso 2 ha obtenido un bloqueo exclusivo en 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 eternamente el uno al otro.
OpenVMS DLM comprueba periódicamente situaciones de interbloqueo. En el ejemplo anterior, la segunda solicitud de bloqueo en cola de uno de los procesos volvería con un estado de interbloqueo. Entonces dependería de este proceso tomar medidas para resolver el punto muerto, en este caso liberando el primer bloqueo obtenido.
Agrupación en clústeres de Linux
Tanto Red Hat como Oracle han desarrollado software de agrupación en clústeres para Linux .
OCFS2 , Oracle Cluster File System 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 2.6.19.
El software de clúster de Red Hat, incluidos 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 en el venerable VMS DLM. [4] El DLM de Oracle tiene una API más simple. (la función principal`` dlmlock()
tiene ocho parámetros, mientras que el SYS$ENQ
servicio VMS y Red Hat dlm_lock
tienen 11.)
Otras implementaciones
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 bloqueo de grano grueso y también proporciona un sistema de archivos distribuido limitado pero confiable. Las partes clave de la infraestructura de Google, incluido el Sistema de archivos de Google , Bigtable y MapReduce , usan Chubby para sincronizar los accesos a los recursos compartidos. Aunque Chubby fue diseñado como un servicio de bloqueo, ahora se usa mucho dentro de Google como servidor de nombres , reemplazando al DNS . [5]
- Apache ZooKeeper , que se creó 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 un almacenamiento y caché de clave-valor avanzados de código abierto, con licencia BSD. [9] Redis se puede utilizar para implementar el algoritmo Redlock para la gestión de bloqueos distribuidos. [10]
- Cónsul 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 administrador de bloqueo distribuido de Taooka [12] utiliza los métodos de "prueba de bloqueo" para evitar interbloqueos . También puede especificar un TTL para cada cerradura con precisión de nanosegundos.
- Un DLM también es un componente clave de proyectos de imagen de sistema único (SSI) más ambiciosos , como OpenSSI .
Referencias
- ^ Gehani, Narain (1991). Ada: Programación concurrente . pag. 105. ISBN 9780929306087.
- ^ kernel / git / torvalds / linux.git - Árbol de fuentes del kernel de Linux [ enlace muerto permanente ] . Kernel.org. Consultado el 18 de septiembre de 2013.
- ^ kernel / git / torvalds / linux.git - Árbol de fuentes del kernel de Linux Archivado el 18 de julio de 2012 en archive.today . Git.kernel.org (7 de diciembre de 2006). Consultado el 18 de septiembre de 2013.
- ^ El sistema de archivos OCFS2 . Lwn.net (24 de mayo de 2005). Consultado el 18 de septiembre de 2013.
- ^ a b Publicación de investigación de Google: Servicio de bloqueo distribuido rechoncho . Research.google.com. Consultado el 18 de septiembre de 2013.
- ^ [1] . Zookeeper.apache.org. Consultado el 18 de septiembre de 2013.
- ^ "CoreOS" . coreos.com .
- ^ etcd: Almacén distribuido confiable de valores clave para los datos más críticos de un sistema distribuido , CoreOS, 2018-01-16 , recuperado 2016-09-20
- ^ http://redis.io/ Consultado el 14 de abril de 2015
- ^ "Candados distribuidos con Redis - Redis" . redis.io . Consultado el 14 de abril de 2015 .
- ^ Visión general del cónsul . Consultado el 19 de febrero de 2015.
- ^ Descripción de Taooka. Consultado el 4 de mayo de 2017 .
- Manual de referencia de servicios de sistemas HP OpenVMS - $ ENQ
- Oficial: un administrador de bloqueo distribuido simple escrito en Ruby
- FLoM: un administrador de bloqueo distribuido de código abierto gratuito que se puede utilizar para sincronizar comandos de shell, scripts y software C, C ++, Java, PHP y Python desarrollado a medida