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 bloqueos de todo el clúster. De esta manera, un DLM proporciona a las aplicaciones de software que se distribuyen en un clúster en varias máquinas un medio para sincronizar sus accesos a 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 usar el almacenamiento de las demás a través de un sistema de archivos unificado , con importantes ventajas para el rendimiento y la disponibilidad . El principal beneficio en términos de rendimiento proviene de la solución del problema de la coherencia de la memoria caché de disco entre las computadoras participantes. El DLM se utiliza no solo para el bloqueo de archivos , sino también para la coordinación de todos los accesos a los discos . VMScluster , el primer sistema de clúster que se utilizó ampliamente, se basó en el DLM de OpenVMS precisamente de esta manera.
El DLM utiliza un concepto generalizado de recurso , que es una entidad a la que se debe controlar el acceso compartido. 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 . 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:
Un proceso puede entonces adquirir bloqueos en la base de datos en su totalidad y luego en partes específicas de la base de datos. Se debe obtener un bloqueo en un recurso principal antes de que se pueda bloquear un recurso subordinado.
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 y estos determinan el nivel de exclusividad que se otorga; es posible convertir el bloqueo a un nivel de bloqueo superior o inferior. Cuando todos los procesos han desbloqueado un recurso, se destruye la información del sistema sobre el recurso.
La siguiente tabla de verdad muestra la compatibilidad de cada modo de bloqueo con los demás:
Un proceso puede obtener un bloqueo en un recurso al poner en cola una solicitud de bloqueo. Esto es similar a la técnica QIO que se utiliza para realizar operaciones de E/S. La solicitud de bloqueo de puesta en cola puede completarse de forma sincrónica, en cuyo caso el proceso espera hasta que se concede el bloqueo, o de forma asincrónica, en cuyo caso se produce un AST cuando se obtiene 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 medidas opcionales para permitir el acceso del otro proceso (por ejemplo, degradando o liberando el bloqueo).
Cada recurso tiene asociado un bloque de valores de bloqueo. Este puede ser leído por cualquier proceso que haya obtenido un bloqueo en el recurso (excepto 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 almacenar un número de versión del recurso. Cada vez que se actualiza la entidad asociada (por ejemplo, un registro de base de datos), el titular del bloqueo incrementa el bloque de valor de 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 se ha actualizado desde la última vez que la leyó y, por lo tanto, no es necesario leerla nuevamente. Por lo tanto, esta técnica se puede utilizar para implementar varios tipos de caché en una base de datos o aplicación similar.
Cuando uno o más procesos han obtenido bloqueos sobre recursos, es posible producir una situación en la que cada uno impida que otro obtenga un bloqueo y ninguno de ellos pueda continuar. Esto se conoce como un punto muerto ( EW Dijkstra lo llamó originalmente un 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 eternamente el uno al otro.
El DLM de OpenVMS comprueba periódicamente si hay situaciones de bloqueo. En el ejemplo anterior, la segunda solicitud de puesta en cola de bloqueos de uno de los procesos devolvería un estado de bloqueo. Entonces, este proceso tendría que tomar medidas para resolver el bloqueo (en este caso, liberar el primer bloqueo que obtuvo).
Tanto Red Hat como Oracle han desarrollado software de clusterización 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 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 sobre 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$ENQservicio VMS y el de Red Hat dlm_locktienen 11).
Otras implementaciones de DLM incluyen las siguientes:
{{cite web}}: Falta o está vacío |title=( ayuda ) [ título faltante ]