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 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 cada una a través de un sistema de archivos unificado , con importantes ventajas de rendimiento y disponibilidad . El principal beneficio de rendimiento proviene de la solución del problema de coherencia de la caché de disco entre las computadoras participantes. El DLM se utiliza no sólo para bloquear archivos sino también para coordinar todos los accesos al disco . VMScluster , el primer sistema de agrupación en clústeres de uso generalizado, se basó en OpenVMS DLM precisamente de esta manera.
El DLM utiliza un concepto generalizado de recurso , que es alguna 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 . 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:
Luego, un proceso puede adquirir bloqueos en la base de datos en su conjunto y luego en partes particulares de la base de datos. Se debe obtener un bloqueo en un recurso principal antes de poder bloquear un recurso subordinado.
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.
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 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 en cola puede completarse de forma sincrónica, en cuyo caso el proceso espera hasta que se conceda 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 está impidiendo el acceso al recurso por parte de otro proceso. El proceso original puede entonces, opcionalmente, tomar medidas para permitir el acceso del otro (por ejemplo, degradando o liberando el bloqueo).
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 contener cualquier información sobre el recurso que elija el diseñador de la aplicación. Un uso típico es contener 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 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ó y por lo tanto no es necesario volver a leerla. Por 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 impide que otro obtenga un bloqueo y ninguno de ellos puede continuar. Esto se conoce como punto muerto ( EW Dijkstra originalmente lo llamó abrazo mortal ). [1]
Un ejemplo simple es cuando el Proceso 1 obtuvo un bloqueo exclusivo en el Recurso A y el Proceso 2 obtuvo 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 se 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 bloqueo en cola de uno de los procesos regresaría con un estado de interbloqueo. Entonces le correspondería a este proceso tomar medidas para resolver el punto muerto, en este caso liberando el primer bloqueo que obtuvo.
Tanto Red Hat como Oracle han desarrollado software de agrupación en clústeres para Linux .
OCFS2 , el sistema de archivos Oracle Cluster, se agregó [2] al kernel oficial de Linux con la versión 2.6.16, en enero de 2006. La advertencia del código de calidad alfa en OCFS2 se eliminó en 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 inspirado en el venerable VMS DLM. [4] 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 Red Hat dlm_locktienen 11).
Otras implementaciones de DLM incluyen las siguientes:
{{cite web}}: Falta o está vacío |title=( ayuda ) [ falta título ]