Network Lock Manager

Network Lock Manager (NLM) es un protocolo que trabaja en cooperación con Network File System (NFS) para proporcionar un estilo similar a la semántica de bloqueo de archivos de aviso POSIX para NFS versión 2 y 3.

Tiene una arquitectura que incluye las funciones de cliente siendo este el responsable de procesar las solicitudes de las aplicaciones y enviarlas al administrador de bloqueo de red en el servidor. Y el servidor será el responsable de aceptar las solicitudes de bloqueo de los clientes y generar las llamadas de bloqueo adecuadas en el servidor.

Este protocolo consta de dos demonios que se están ejecutando continuamente tanto en el servidor NFS como en los clientes NFS para poder saber que procesos están bloqueados y cuales tienen los bloqueos. Uno de estos demonios es el administrador de bloqueo de red (rpc.lockd) y el otro es el monitor de estado de la red (rpc.statd) para ello vamos a verlos con detalle.

Historia

Este protocolo surgió después del lanzamiento de NFS al agregarse soporte de bloqueo de rango de bytes en SunOS, ya que este bloqueo requiere un protocolo con estado.

Ha habido 4 versiones diferentes del protocolo NLM , las versiones 1 a 3 son prácticamente idénticas con la excepción de funciones adicionales que se han agregado a la versión 2 y 3 para adaptarse a clientes que no son UNIX (lea PC-NFS para DOS y Windows). Estas versiones son todas para la versión 2 de NFS.

Con el lanzamiento de la versión 3 de NFS , la estructura del identificador de archivos para el protocolo NFS tuvo que cambiar su formato de cable. Al compartir esta estructura con el protocolo NFS, esto supuso que se especificara una nueva versión de NLM. La versión 4 de NLM se utiliza junto con la versión 3 de NFS .

Con la versión 4 de NFS, el protocolo NLM se ha eliminado y las funciones de bloqueo están implementadas en el propio protocolo NFS .

Demonios

rpc.lockd

Este demonio se implementa como un conjunto de subprocesos del kernel (similar al servidor NFS). Recibirá mensajes del cliente NFS cuando se solicite un bloqueo, y enviará solicitudes NLM al servidor NLM en la máquina del servidor NFS, y recibirá solicitudes NLM de los clientes NFS de la máquina en la que se está ejecutando y hará un bloqueo local de llamadas en nombre de esos clientes.

rpc.statd

Este demonio es un proceso a nivel de usuario el cual se ejecuta en cada nodo del clúster en caso de que el nodo falle mientras mantiene un bloqueo en el servidor NFS. Al ocurrir esto, el programa rpc.statd en el nodo del clúster notificará al servidor NFS cuando se reinicie el nodo del clúster que ahora está operativo nuevamente. Rpc.statd en el cliente NFS sabe que debe hacer esto, porque escribe el nombre de cada servidor NFS en una unidad de disco local la primera vez que un proceso que se ejecuta en el nodo del clúster intenta bloquear un archivo en el servidor NFS.

Proceso de bloqueo

Cuando una aplicación desea obtener un bloqueo en un archivo local, envía su solicitud al kernel utilizando las subrutinas lockf, fcntl o flock.

El kernel procesa la solicitud de bloqueo. Sin embargo, si una aplicación en un cliente NFS realiza una solicitud de bloqueo para un archivo remoto, el cliente NLM genera una llamada a procedimiento remoto (RPC) al servidor para manejar la solicitud.

Cuando el cliente recibe una solicitud de bloqueo remoto inicial, registra interés en el servidor con el demonio rpc.statd del cliente. Lo mismo ocurre con el administrador de bloqueo de red en el servidor. En la solicitud inicial de un cliente, registra interés en el cliente con el monitor de estado de la red local.

Dependencias

Hay cuatro dependencias:

ONC-RPC: Los protocolos NLM se implementan sobre ONC-RPC como número de programa 100021. NLM generalmente se implementa sobre UDP pero existen clientes que utilizan TCP.
Portmap: Un cliente normalmente necesita el servicio Portmap para descubrir en qué puerto está disponible el servicio NSM.
NSM: Los pares del administrador de bloqueos confían en el protocolo NSM para notificarse entre sí sobre los reinicios/reinicios del servicio para que los bloqueos se puedan resincronizar después de un reinicio.
KLM: En algunas plataformas, la interfaz sobre la interfaz de bucle invertido donde el código del cliente NFS en el kernel habla con el administrador de bloqueo del espacio de usuario.

Síncrono vs asíncrono

Hay dos tipos de NLM que proporcionan las mismas funciones; Síncrono y asíncrono. Casi todas las implementaciones usan la versión síncrona, aunque algunos como HP-UX, usan la versión asíncrona. La principal diferencia es que la versión síncrona NLM es un protocolo de solicitud/respuesta ONC-RPC normal, mientras que la versión asíncrona es un protocolo de mensaje/mensaje.

En la versión asíncrona de NLM no habrá ninguna respuesta de capa ONC-RPC, en su lugar, las respuestas NLM se envían como mensajes de solicitud ONC-RPC. Esto significa que el ID de transacción ONC-RPC (XID) no se puede usar para hacer coincidir solicitudes con respuestas, ni se puede usar el XID para detectar retransmisiones potenciales. En su lugar, el campo de la cookie al principio de cada PDU NLM se utiliza para hacer coincidir las solicitudes y las respuestas. Este campo de cookie también está presente en la versión síncrona de NLM pero no tiene ningún significado semántico allí.

Rango de puertos

La variable de entorno NFS_PORT_RANGE se puede utilizar para limitar el puerto de origen de las llamadas de red que el cliente realiza al servidor.

Para usar esta variable tiene que ser añadida al archivo /etc/environment con el siguiente formato:

NFS_PORT_RANGE=udp[4000-5000]:tcp[7000-8000]

Aquí podemos ver que los paquetes UDP enviados por el cliente tienen un puerto de origen en el rango 4000 - 5000, y las conexiones TCP tienen un puerto de origen en el rango 7000 - 8000. Para evitar problemas de reutilización de puertos, los números de puerto que se especifican en este rango no se deben utilizar como números de puerto fijos para ninguno de los demonios de NFS en el archivo /etc/services.