Funciones en NFS versión 4

En esta sección, se proporcionan descripciones de las funciones que se introdujeron en la versión 4 de NFS:

• Anular el uso compartido y volver a compartir un sistema de archivos en NFS versión 4

• Espacio de nombre de sistema de archivos en NFS versión 4

• Identificadores de archivos volátiles en NFS versión 4

• Recuperación de cliente en NFS versión 4

• Compatibilidad de uso compartido OPEN en NFS versión 4

• Delegación en NFS versión 4

• ACL y nfsmapid en NFS versión 4

Para obtener información sobre la configuración de los servicios NFS, consulte Configuración del servicio de NFS.

Anular el uso compartido y volver a compartir un sistema de archivos en NFS versión 4

Con NFS versión 3 y versión 4, si un cliente intenta acceder a un sistema de archivos que se ha dejado de compartir, el servidor responde con un código de error. Sin embargo, con NFS versión 3 el servidor mantiene cualquier bloqueo que los clientes hayan obtenido antes de que se dejara de compartir el sistema de archivos. Por lo tanto, cuando el sistema de archivos se vuelve a compartir, los clientes NFS versión 3 pueden acceder al sistema de archivos como si éste nunca se hubiera dejado de compartir.

Con NFS versión 4, cuando se deja de compartir un sistema de archivos, se destruye toda la información de estado de todos los archivos abiertos o bloqueos de archivos en ese sistema de archivos. Si el cliente intenta acceder a estos archivos o bloqueos, el cliente recibe un error. Este error suele notificarse como un error I/O en la aplicación. Sin embargo. si se vuelve a compartir un sistema de archivos actualmente compartido para cambiar las opciones, no se destruye ninguna información de estado en el servidor.

Para obtener información sobre la recuperación de cliente en NFS versión 4, consulte Recuperación de cliente en NFS versión 4. Para obtener información acerca de las opciones disponibles para el comando unshare, consulte la página del comando man unshare_nfs(1M).

Espacio de nombre de sistema de archivos en NFS versión 4

Los servidores NFS versión 4 crean y mantienen un pseudosistema de archivos que proporciona a los clientes un acceso ininterrumpido a todos los objetos exportados en el servidor. Antes de la versión 4 de NFS, el pseudosistema de archivos no existía. Los clientes estaban forzados a montar cada sistema de archivos de servidor compartido para el acceso.

Un pseudosistema de archivos es una estructura que contiene sólo directorios y se crea mediante el servidor. El pseudosistema de archivos permite que un cliente examine la jerarquía de sistemas de archivos exportados. Por lo tanto, la vista que tiene el cliente del pseudosistema de archivos se limita a rutas que conducen a sistemas de archivos exportados.

Las versiones anteriores de NFS no permitían que un cliente atravesara sistemas de archivos del servidor sin montar cada sistema de archivos. Sin embargo, en la versión 4 de NFS, el espacio de nombres del servidor hace lo siguiente:

• Restringe la vista del sistema de archivos a los directorios que conducen a exportaciones del servidor.

• Proporciona a los clientes un acceso ininterrumpido a las exportaciones del servidor sin necesidad de que el cliente monte cada sistema de archivos subyacente. Sin embargo, según el sistema operativo, pueden ser necesario que el cliente monte cada sistema de archivos del servidor.

Figura 2-2  Vistas del sistema de archivos del servidor y el sistema de archivos del cliente en NFS versión 4

En el ejemplo que se muestra en la figura, el cliente no puede ver el directorio payroll ni el directorionfs4x, ya que estos directorios no se exportan y no conducen a directorios exportados. Sin embargo, el directorio local está visible para el cliente, ya que local es un directorio exportado. El directorio projects es visible para el cliente, ya que projects conduce al directorio exportado nfs4. Por lo tanto, las partes del espacio de nombres del servidor que no están explícitamente exportadas se enlazan con un pseudosistema de archivos que visualiza sólo los directorios exportados y aquellos directorios que conducen a las exportaciones del servidor.

Identificadores de archivos volátiles en NFS versión 4

En el servidor se crean identificadores de archivos que contienen información que identifica de forma exclusiva archivos y directorios. En las versiones 2 y 3 de NFS, el servidor devolvía identificadores de archivos persistentes. Por lo tanto, el cliente podía garantizar que el servidor generara un identificador de archivo que siempre hiciera referencia al mismo archivo. Por ejemplo:

• Si un archivo se suprimía y sustituía por otro archivo con el mismo nombre, el servidor generaba un nuevo identificador de archivos para el archivo nuevo. Si el cliente utilizaba el identificador de archivos anterior, el servidor devolvía un error que indicaba que el identificador de archivos era obsoleto.

• Si se cambiaba el nombre de un archivo, el identificador de archivos seguía siendo el mismo.

• Si el servidor se reiniciaba, los identificadores de archivos seguían siendo los mismos.

Por lo tanto, cuando el servidor recibía una solicitud de un cliente que incluía un identificador de archivo, la resolución era sencilla y el identificador de archivos siempre hacía referencia al archivo correcto.

El método de uso de identificadores de archivos persistentes para identificar los archivos y directorios para las operaciones de NFS era aceptable para la mayoría de los servidores basados en UNIX. Sin embargo, el método no podía ejecutarse en servidores que dependieran de otros métodos de identificación, como el nombre de ruta de un archivo. Para resolver este problema, el protocolo NFS versión 4 permite que un servidor declare que sus identificadores de archivos son volátiles. Si el identificador de archivos cambia, el cliente debe encontrar el nuevo identificador de archivos.

Como en las versiones 2 y 3 de NFS, el servidor Oracle Solaris NFS versión 4 siempre proporciona identificadores de archivos persistentes. Sin embargo, los clientes de Oracle Solaris NFS versión 4 que acceden a servidores que no sean de Oracle Solaris NFS versión 4 deben admitir identificadores de archivos volátiles si el servidor los utiliza. Específicamente, cuando el servidor comunica al cliente que el identificador de archivos es volátil, el cliente debe almacenar en la memoria caché la asignación entre el nombre de la ruta de acceso y el identificador de archivos. El cliente utiliza este identificador de archivos volátil hasta que caduque. Cuando caduca, el cliente hace lo siguiente:

• Vacía la información almacenada en la caché que hace referencia a ese identificador de archivo

• Busca el identificador de archivos nuevo del archivo

• Vuelve a intentar la operación

Los identificadores de archivos volátiles pueden caducar en cualquiera de estas situaciones:

• Cuando cierra un archivo

• Cuando migra el sistema de archivos del identificador de archivos

• Cuando un cliente cambia el nombre de un archivo

• Cuando el servidor se reinicia

Si el cliente no puede encontrar el nuevo identificador de archivos, se coloca un mensaje de error en el archivo syslog. Otros intentos de acceder a este archivo fallan con un error I/O .

Recuperación de cliente en NFS versión 4

El protocolo NFS versión 4 es un protocolo con estado. El cliente y el servidor mantienen información actualizada sobre los archivos abiertos y los bloqueos de archivos.

Cuando un servidor se bloquea y se reinicia, el servidor pierde su estado. El cliente detecta que el servidor se ha reiniciado y comienza el proceso de ayudar a que el servidor vuelva a establecer los estados de apertura y bloqueo que existían antes del error. Este proceso se denomina recuperación de cliente, ya que el cliente dirige el proceso.

Cuando el cliente detecta que el servidor se ha reiniciado, el cliente inmediatamente suspende su actividad actual e inicia el proceso de recuperación de cliente. Cuando el proceso de recuperación se inicia, se muestra un mensaje como el siguiente en el log de errores del sistema /var/adm/messages:

NOTICE: Starting recovery server server-name

Durante el proceso de recuperación, el cliente envía información al servidor sobre el estado anterior del cliente. Sin embargo, que durante este período, el cliente no envía las solicitudes nuevas al servidor. Las solicitudes nuevas para abrir archivos o establecer bloqueos de archivos deben esperar hasta que el servidor complete el proceso de recuperación antes de continuar.

Cuando se completa el proceso de recuperación de cliente, se muestra el siguiente mensaje en el log de errores del sistema :/var/adm/messages.

NOTICE: Recovery done for server server-name

En este punto, el cliente ha completado correctamente el envío de su información de estado al servidor. Sin embargo, aunque el cliente haya completado este proceso, es posible que otros clientes no hayan hecho. Por lo tanto, durante un período, conocido como período de gracia, el servidor no acepta ninguna solicitud de apertura o bloqueo para permitir que todos los clientes completen su recuperación.

Durante el período de gracia, si el cliente intenta abrir archivos nuevos o establecer bloqueos nuevos, el servidor niega la solicitud con el código de error GRACE. Al recibir este error, el cliente debe esperar a que finalice el período de gracia y, a continuación, reenviar la solicitud al servidor. Durante el período de gracia, se muestra el siguiente mensaje:

NFS server recovering

Durante el período de gracia, los comandos que no abren archivos ni establecen bloqueos de archivos pueden continuar. Por ejemplo, los comandos ls y cd no abren ningún archivo ni establecen un bloqueo de archivo. Estos comandos no están suspendidos. Sin embargo, un comando como cat, que abre un archivo, se suspendería hasta que el período de gracia finalice.

Cuando el período de gracia termina, se muestra el siguiente mensaje:

NFS server recovery ok.

El cliente ahora puede enviar nuevas solicitudes de apertura y de bloqueo al servidor.

La recuperación de cliente puede fallar por una serie de razones. Por ejemplo, si existe una partición de red después del reinicio del servidor, es posible que el cliente no pueda restablecer su estado con el servidor antes de que finalice el período de gracia. Una vez que finaliza el período de gracia, el servidor no permite que el cliente restablezca su estado, ya que un nuevo estado de operaciones puede crear conflictos. Por ejemplo, un nuevo bloqueo de archivo puede entrar en conflicto con un bloqueo de archivo anterior que el cliente está intentando recuperar. Cuando ocurre este tipo de situaciones, el servidor devuelve el código de error NO_GRACE al cliente.

Si falla la recuperación de una operación de apertura de un archivo en particular, el cliente marca el archivo como no utilizable y se muestra el siguiente mensaje:

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status n):  file :  filename

Si se produce un fallo al volver a establecer un bloqueo de archivo durante la recuperación, se muestra el siguiente mensaje de error:

NOTICE: nfs4_send_siglost:  pid process-ID lost
lock on server server-name

En esta situación, se publica la señal SIGLOST en el proceso. La acción predeterminada para la señal SIGLOST es terminar el proceso.

Para que pueda recuperarse de este estado, debe reiniciar todas las aplicaciones que tengan archivos abiertos en el momento del fallo. Algunos procesos que no volvieron a abrir el archivo pudieron recibir errores I/O . Otros procesos que volvieron a abrir el archivo, o que realizaron la operación de apertura después del error de recuperación, pueden acceder al archivo sin problemas.

Por lo tanto, algunos procesos pueden acceder a un archivo determinado mientras que otros procesos no pueden hacerlo.

Compatibilidad de uso compartido OPEN en NFS versión 4

El protocolo NFS versión 4 proporciona varios modos de uso compartido de archivos que el cliente puede utilizar para controlar el acceso de otros clientes. Un cliente puede especificar lo siguiente:

• El modo DENY_NONE permite que otros clientes tengan acceso de lectura y escritura para un archivo.

• El modo DENY_READ impide que otros clientes tengan acceso de lectura para un archivo.

• El modo DENY_WRITE impide que otros clientes tengan acceso de escritura para un archivo.

• El modo DENY_BOTH impide que otros clientes tengan acceso de lectura y escritura para un archivo.

El servidor Oracle Solaris NFS versión 4 implementa todos estos modos de uso compartido de archivos. Por lo tanto, si un cliente intenta abrir un archivo de forma que entra en conflicto con el modo de uso compartido actual, el servidor impide el intento y hace fallar la operación. Cuando estos intentos fallan con el inicio de las operaciones de apertura o creación, el cliente NFS versión 4 de recibe un error de protocolo. Este error se asigna al error de aplicación EACCES.

Aunque el protocolo proporciona varios modos de uso compartido, la operación de apertura en Oracle Solaris no ofrece varios modos de uso compartido. Al abrir un archivo, un cliente Oracle Solaris NFS versión 4 sólo puede utilizar el modo DENY_NONE.

Delegación en NFS versión 4

NFS versión 4 proporciona compatibilidad de cliente y servidor para la delegación. La delegación es una técnica mediante la cual el servidor delega la gestión de un archivo a un cliente. Por ejemplo, el servidor puede conceder una delegación de lectura o una delegación de escritura a un cliente. Debido a que las delegaciones de lectura no entran en conflicto entre sí, se pueden otorgar a varios clientes al mismo tiempo. Una delegación de escritura se puede otorgar a un sólo cliente, ya que la delegación de escritura entra en conflicto con cualquier acceso de archivo de cualquier otro cliente. En posesión de una delegación de escritura, el cliente no enviaría diversas operaciones al servidor porque el cliente tiene acceso exclusivo garantizado a un archivo. De forma similar, el cliente no envía diversas operaciones al servidor mientras posee una delegación de lectura. Esto se debe a que el servidor garantiza que ningún cliente pueda abrir el archivo en el modo de escritura.

El efecto de la delegación es reducir en gran medida las interacciones entre el servidor y el cliente para los archivos delegados. Por lo tanto, se reduce el tráfico de la red, y se mejora el rendimiento en el cliente y el servidor. Sin embargo, que el grado de mejora del rendimiento depende del tipo de interacción de archivo utilizada por una aplicación y la cantidad de congestión en la red y el servidor.

Un cliente no solicita una delegación. La decisión de conceder una delegación es tomada completamente por el servidor según los patrones de acceso para un archivo. Si varios clientes distintos han accedido recientemente a un archivo en el modo de escritura, es posible que el servidor no otorgue una delegación porque este patrón de acceso indica la posibilidad de conflictos futuros.

Se produce un conflicto cuando un cliente accede a un archivo de una forma que sea incoherente con las delegaciones que se han otorgado para ese archivo. Por ejemplo, si un cliente posee una delegación de escritura sobre un archivo y un segundo cliente abre ese archivo para obtener acceso de lectura o escritura, el servidor recupera la primera delegación de escritura del cliente. De manera similar, si un cliente posee una delegación de lectura y otro cliente abre el mismo archivo para escritura, el servidor recupera la delegación de lectura. En ambas situaciones, no se ha concedido una delegación al segundo cliente porque existe un conflicto.

Cuando se produce un conflicto, el servidor utiliza un mecanismo de devolución de llamada para ponerse en contacto con el cliente que posee actualmente la delegación. Al recibir esta devolución de llamada, el cliente envía el estado actualizado del archivo al servidor y devuelve la delegación. Si el cliente no responde a la recuperación, el servidor revoca la delegación. En tales circunstancias, el servidor rechaza todas las operaciones del cliente para este archivo, y el cliente informa las operaciones solicitadas como fallos. Por lo general, estos fallos se notifican en la aplicación como errores de I/O . Para recuperarse de estos errores, el archivo se debe cerrar y, a continuación, volver a abrir. Pueden producirse fallos desde las delegaciones revocadas cuando existe una partición de red entre el cliente y el servidor mientras el cliente posee una delegación.

Tenga en cuenta que un servidor no puede resolver los conflictos de acceso para un archivo almacenado en otro servidor. Por lo tanto, un servidor NFS sólo resuelve los conflictos para los archivos que almacena. Además, en respuesta a los conflictos provocados por los clientes que ejecutan varias versiones de NFS, un servidor NFS solamente puede iniciar recuperaciones para el cliente que está ejecutando NFS versión 4. Un servidor NFS no puede iniciar recuperaciones para los clientes que ejecutan versiones anteriores de NFS.

El proceso para detectar conflictos varía. Por ejemplo, a diferencia de la versión 4 de NFS, y como las versiones 2 y 3 no tienen un procedimiento abierto, el conflicto sólo se detecta después de que el cliente intenta leer, escribir o bloquear un archivo. La respuesta del servidor frente a estos conflictos también varía. Por ejemplo:

• Para NFS versión 3, el servidor devuelve el error JUKEBOX, que hace que el cliente detenga la solicitud de acceso y vuelva a intentarlo más tarde. El cliente imprime el mensaje File unavailable.

• En el caso de NFS versión 2, como no existe un equivalente para el error JUKEBOX, el servidor no responde, lo que hace que el cliente deba esperar y volver a intentarlo. El cliente muestra el mensaje NFS server not responding.

Los mensajes de error se borran cuando se resuelve el conflicto de delegación.

De manera predeterminada, la delegación de servidor está activada. Puede desactivar la delegación si establece el parámetro server_delegation en off.

# sharectl set -p server_delegation=off nfs

No se requieren palabras clave para la delegación de cliente. El daemon de devolución de llamadas NFS versión 4, nfs4cbd, proporciona el servicio de devolución de llamada en el cliente. El daemon se inicia automáticamente siempre que haya un montaje para la versión 4 de NFS activado. De manera predeterminada, el cliente ofrece la información de devolución de llamada necesaria al servidor para todos los transportes de Internet que se muestran en el archivo de sistema /etc/netconfig. Tenga en cuenta que si el cliente está activado para IPv6 y la dirección IPv6 para el nombre del cliente se puede determinar, el daemon de devolución de llamadas acepta las conexiones IPv6.

El daemon de devolución de llamadas utiliza un número de programa transitorio y un número de puerto asignado de forma dinámica. Esta información se proporciona al servidor, y el servidor prueba la ruta de devolución de llamadas antes de conceder delegaciones. Si la ruta de devolución de llamadas no es correcta, el servidor no otorga las delegaciones, lo cual es el único comportamiento externamente visible.

Debido a que la información de devolución de llamadas está integrada en una solicitud de NFS versión 4, el servidor no puede establecer contacto con el cliente a través de un dispositivo que utiliza traducción de direcciones de red (NAT). Además, el daemon de devolución de llamadas utiliza un número de puerto dinámico. Por lo tanto, es posible que el servidor no pueda atravesar un cortafuegos, incluso si el cortafuegos permite el tráfico NFS normal en el puerto 2049. En tales situaciones, el servidor no otorga delegaciones.

ACL y nfsmapid en NFS versión 4

Una lista de control de acceso (ACL) proporciona una mejor seguridad de archivos al activar al responsable de un archivo para que defina los permisos para el responsable del archivo, el grupo u otros usuarios o grupos específicos. En sistemas de archivos ZFS, las ACL se establecen en el servidor y el cliente mediante el comando chmod. Para sistemas de archivos UFS, puede utilizar el comando setfacl. Para obtener más información, consulte las páginas del comando man chmod(1) y setfacl(1). En NFS versión 4, el asignador de ID nfsmapid se utiliza para asignar los ID de usuario o de grupo en las entradas de la ACL de un servidor a los ID de usuario o de grupo en las entradas de ACL de un cliente. Lo contrario también es cierto: los ID de grupo y de usuario en las entradas de la ACL deben existir en el cliente y el servidor.

Para obtener más información sobre las ACL y nfsmapid, consulte lo siguiente:

• Capítulo 7, Uso de listas de control de acceso y atributos para proteger archivos Oracle Solaris ZFS de Gestión de sistemas de archivos ZFS en Oracle Solaris 11.2

• Daemons NFS

Problemas de asignación de ID

Las siguientes situaciones pueden originar una falla en la asignación de ID:

• Si el usuario o grupo que existe en una entrada de la ACL en el servidor no se puede asignar a un usuario o grupo válidos en el cliente, el usuario puede leer la ACL, pero algunos de los usuarios o grupos se mostrarán como unknown.

  Por ejemplo, en esta situación, cuando ejecuta el comando ls –lv o ls –lV, en algunas de las entradas de ACL se mostrará el grupo o el usuario como unknown.

• Si el ID de usuario o de grupo en cualquier entrada de la ACL establecida en el cliente no se puede asignar a un ID de usuario o grupo válido en el servidor, los comandos setfacl o chmod pueden fallar y devolver el mensaje de error Permission denied.

• Si el cliente y el servidor no hacen coincidir correctamente los valores nfsmapid_domain, la asignación de ID falla. Para obtener más información, consulte Daemons NFS.

Para evitar problemas de asignación de ID, haga lo siguiente:

• Asegúrese de que el valor para nfsmapid_domain esté definido correctamente. El dominio NFSv4 seleccionado actualmente está disponible en el archivo /var/run/nfs4_domain.

• Asegúrese de que todos los ID de usuario y de grupo en las entradas de la ACL existan tanto en el cliente como en el servidor de NFS versión 4.

Comprobación de ID de usuario o de grupo sin asignar

Para determinar si un usuario o grupo no se pueden asignar al servidor o al cliente, utilice la siguiente secuencia de comandos:

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}