El sistema de archivos de red (manual administración de redes con Linux)

El Sistema de Archivos de Red (NFS, por sus siglas en Inglés) es probablemente el más prominente servicio de red usando RPC. Permite acceder a archivos en nodos remotos exactamente en la misma manera que si fueran locales. Una mezcla de soporte desde el kernel y demonios de espacio de usuario en el lado del cliente, junto con un servidor NFS en el otro lado lo hacen posible. Este acceso a los archivos es completamente transparente al cliente y trabaja con una variedad de servidores y arquitecturas de nodos.
NFS ofrece ciertas ventajas:
• Pueden guardarse los datos accedidos por todos los usuarios en un modo central, los clientes montan este directorio al arrancar. Por ejemplo, se puede mantener todas la cuentas de usuario en un nodo y hacer que todos los nodos de la red monten el directorio /honre desde ese nodo. Si se instlaa NFS junto a NIS, los usuarios pueden entrar en cualquier sistema y trabajar en un conjunto de archivos.
• La información que consume grandes espacios de disco pueden mantenerse en un solo nodo. Por ejemplo, todos los archivos y programas reltaivos a LaTeX y METAFONT pueden ser almacenados y mantenidos en un lugar..
• La información Administrativa puede ser almacenada en un solo nodo. No es necesario usar rcp para instalar el mismo archivo tonto en 20 máquinas diferentes.
No es demasiado difícil preparar el funcionamiento de NFS básico en el cliente y el servidor; este capítulo le dice cómo.
Linux NFS es principalmente trabajo de Rick Sladkey, quien escribió el código del kernel de NFS y gran parte del servidor de NFS.1 Lo último se deriva del unfsd espacio de usuario del servidor de NFS, originalmente escrito por Mark Shand, y el hnfs servidor Harris de NFS, escrito por Donald Becker.
Demos una mirada a cómo trabaja NFS. Primero, un cliente intenta montar un directorio de un nodo remoto en un directorio local en la misma manera que si fuese un dispositivo físico. Sin embargo, la sintaxis usada para especificar el directorio remoto es diferente. Por ejemplo, para montar /honre from host vlager to /users sobre vale, el administrador escribe el siguiente comando en vale.
mount tratará de conectar con el demonio remoto sobre rpc.mountd de vlager vía RPC. El servidor verificará si vale tiene permiso para montar el directorio en cuestión, en cuyo caso, devuelve un descriptor de archivo. Este descriptor será usado en todas las demandas subsecuentes que se hagan sobre los archivos bajo /users.
Cuando alguien accede un archivo sobre NFS, el núcleo manda una llamada de RPC a rpc.nfsd (el demonio de NFS) en la máquina servidor. Esta llamada toma el descriptor de archivo, el nombre del archivo a acceder y los identificadores de usuario y grupo del usuario como parámetros. Estos son usados en la determinación de los derechos de acceso al archivo especificado. Para prevenir que usuarios no autorizados lean o modifiquen archivos, los identificadores de usuario y grupo deben ser iguales en ambos nodos..
En la mayoría de las implementaciones de Unix, la funcionalidad de cliente y servidor NFS se implementan como demonios a nivel de núcleo que arrancan desde el ambiente de usuario al arrancar la máquina. Estos son NFS Daemon (rpc.nfsd) en el nodo servidor, y Block I/O Daemon (biod) en el nodo cliente. Para mejorar el rendimiento, biod realiza la E/S usando leer-delante y escribir-detrás asíncrono; también, varios demonios rpc.nfsd están usualmente corriendo concurrentemente.
La implementación actual de NFS de Linux es un poco diferente del NFS clásico en la que el código de servidor corre enteramente en ambiente de usuario, así que correr múltiples copias simultáneamente es más complicado. La implementación actual derpc.nfsd ofrece una característica experimental que permite apoyo limitado para múltiples servidores. Olaf Kirch desarrolló el soporte para servidor NFS basado en el núcleo ofrecido en la versión 2.2 del kernel de Linux. Su actuación es significativamente mejor que la de la implementación en el ambiente de usuario existente. Lo describiremos más adelante en este capítulo.