Sistema de archivos de red

Network File System ( NFS ) es un protocolo de sistema de archivos distribuido desarrollado originalmente por Sun Microsystems (Sun) en 1984, ^[1] que permite a un usuario de una computadora cliente acceder a archivos a través de una red informática de forma muy similar a como se accede al almacenamiento local. NFS, como muchos otros protocolos, se basa en el sistema de Llamada a Procedimiento Remoto de Computación en Red Abierta (ONC RPC). NFS es un estándar abierto de IETF definido en una Solicitud de Comentarios (RFC), que permite que cualquiera implemente el protocolo.

Sun utilizó la versión 1 sólo con fines experimentales internos. Cuando el equipo de desarrollo añadió cambios sustanciales a la versión 1 de NFS y la lanzó fuera de Sun, decidieron lanzar la nueva versión como v2, de modo que se pudiera probar la interoperabilidad de versiones y la versión de respaldo de RPC. ^{[2] [3]}

La versión 2 del protocolo (definida en RFC 1094, marzo de 1989) originalmente operaba únicamente sobre el Protocolo de datagramas de usuario (UDP). Sus diseñadores pretendían mantener el lado del servidor sin estado , con bloqueos (por ejemplo) implementados fuera del protocolo central. Entre las personas involucradas en la creación de la versión 2 de NFS se encuentran Russel Sandberg, Bob Lyon, Bill Joy , Steve Kleiman y otros. ^{[1] [4]}

La interfaz del Sistema de Archivos Virtuales permite una implementación modular, reflejada en un protocolo simple. En febrero de 1986, se demostraron implementaciones para sistemas operativos como System V release 2, DOS y VAX/VMS utilizando Eunice . ^[4] NFSv2 solo permite leer los primeros 2 GB de un archivo debido a las limitaciones de 32 bits .

Versión 3 (RFC 1813, junio de 1995) agregada:

• soporte para tamaños de archivos y desplazamientos de 64 bits, para manejar archivos mayores a 2 gigabytes (GB);
• soporte para escrituras asincrónicas en el servidor, para mejorar el rendimiento de escritura;
• atributos de archivo adicionales en muchas respuestas, para evitar la necesidad de volver a buscarlos;
• una operación READDIRPLUS, para obtener identificadores de archivos ^[5] y atributos junto con nombres de archivos al escanear un directorio;
• Varias otras mejoras.

La primera propuesta de NFS Versión 3 dentro de Sun Microsystems fue creada poco después del lanzamiento de NFS Versión 2. La motivación principal fue un intento de mitigar el problema de rendimiento de la operación de escritura sincrónica en NFS Versión 2. ^[6] Para julio de 1992, la práctica de implementación había resuelto muchas deficiencias de NFS Versión 2, dejando solo la falta de soporte de archivos grandes (tamaños de archivos de 64 bits y desplazamientos) como un problema apremiante. En el momento de la introducción de la Versión 3, el soporte de los proveedores para TCP como protocolo de capa de transporte comenzó a aumentar. Si bien varios proveedores ya habían agregado soporte para NFS Versión 2 con TCP como transporte, Sun Microsystems agregó soporte para TCP como transporte para NFS al mismo tiempo que agregó soporte para la Versión 3. El uso de TCP como transporte hizo que el uso de NFS sobre una WAN fuera más factible y permitió el uso de tamaños de transferencia de lectura y escritura más grandes más allá del límite de 8 KB impuesto por el Protocolo de datagramas de usuario .

WebNFS fue una extensión de NFSv2 y NFSv3 que le permitía funcionar detrás de cortafuegos restrictivos sin la complejidad de los protocolos Portmap y MOUNT. WebNFS tenía un número de puerto TCP/UDP fijo (2049) y, en lugar de requerir que el cliente se pusiera en contacto con el servicio RPC MOUNT para determinar el identificador de archivo inicial de cada sistema de archivos, introdujo el concepto de un identificador de archivo público (nulo para NFSv2, longitud cero para NFSv3) que podía utilizarse como punto de partida. Ambos cambios se incorporaron posteriormente a NFSv4.

La versión 4 (RFC 3010, diciembre de 2000; revisada en RFC 3530, abril de 2003 y nuevamente en RFC 7530, marzo de 2015), influenciada por Andrew File System (AFS) y Server Message Block (SMB, también denominado CIFS), incluye mejoras de rendimiento, exige una seguridad sólida e introduce un protocolo con estado . ^{[7] [8]} La versión 4 se convirtió en la primera versión desarrollada con el Internet Engineering Task Force (IETF) después de que Sun Microsystems entregara el desarrollo de los protocolos NFS.

La versión 4.1 de NFS (RFC 5661, enero de 2010; revisada en RFC 8881, agosto de 2020) tiene como objetivo brindar soporte de protocolo para aprovechar las implementaciones de servidores en clúster, incluida la capacidad de proporcionar acceso paralelo escalable a archivos distribuidos entre múltiples servidores (extensión pNFS). La versión 4.1 incluye un mecanismo de enlace troncal de sesiones (también conocido como NFS Multipathing) y está disponible en algunas soluciones empresariales como VMware ESXi .

La versión 4.2 de NFS (RFC 7862) se publicó en noviembre de 2016 ^[9] con nuevas características que incluyen: clonación y copia del lado del servidor, asesoramiento de E/S de la aplicación, archivos dispersos, reserva de espacio, bloque de datos de la aplicación (ADB), NFS etiquetado con sec_label que se adapta a cualquier sistema de seguridad MAC y dos nuevas operaciones para pNFS (LAYOUTERROR y LAYOUTSTATS).

Una gran ventaja de NFSv4 sobre sus predecesores es que solo se utiliza un puerto UDP o TCP, 2049, para ejecutar el servicio, lo que simplifica el uso del protocolo a través de firewalls. ^[10]

WebNFS , una extensión de las versiones 2 y 3, permite que NFS se integre más fácilmente en los navegadores web y permita su funcionamiento a través de cortafuegos. En 2007, Sun Microsystems publicó en código abierto su implementación de WebNFS del lado del cliente. ^[11]

Se han asociado varios protocolos de banda lateral con NFS. Nota:

• el protocolo Network Lock Manager (NLM) de asesoramiento de rango de bytes (agregado para admitir las API de bloqueo de archivos de UNIX System V )
• El protocolo de informes de cuotas remotas (RQUOTAD), que permite a los usuarios de NFS ver sus cuotas de almacenamiento de datos en servidores NFS
• NFS sobre RDMA, una adaptación de NFS que utiliza el acceso directo a memoria remota (RDMA) como transporte ^{[12] [13]}
• NFS-Ganesha, un servidor NFS que se ejecuta en el espacio de usuario y admite varios sistemas de archivos como GPFS/Spectrum Scale y CephFS a través de los módulos FSAL (capa de abstracción del sistema de archivos) correspondientes. El FSAL de CephFS se admite mediante libcephfs ^[14]

• Sistema de archivos de confianza (TNFS) ^[15]

NFS se utiliza a menudo con sistemas operativos Unix (como Solaris , AIX , HP-UX ), macOS de Apple y sistemas operativos similares a Unix (como Linux y FreeBSD ). También está disponible para sistemas operativos como Acorn RISC OS , ^[16] AmigaOS , el Mac OS clásico , OpenVMS , ^[3] MS-DOS , ^[17] Microsoft Windows , ^[18] OS/2 , ^[19] ArcaOS , ^[20] Novell NetWare , ^[21] e IBM i . ^[22] Los protocolos alternativos de acceso remoto a archivos incluyen el bloque de mensajes del servidor (SMB, también denominado CIFS), el protocolo de archivos de Apple (AFP), el protocolo de núcleo NetWare (NCP) y el sistema de archivos del servidor de archivos OS/400 (QFileSvr.400).

SMB y NetWare Core Protocol (NCP) aparecen con más frecuencia que NFS en sistemas que ejecutan Microsoft Windows; AFP aparece con más frecuencia que NFS en sistemas Apple Macintosh ; y QFileSvr.400 aparece con más frecuencia en sistemas IBM i. En 2012, Haiku agregó compatibilidad con NFSv4 como parte de un proyecto Google Summer of Code.

Suponiendo un escenario de estilo Unix en el que una máquina (el cliente ) necesita acceso a datos almacenados en otra máquina (el servidor NFS ):

1. El servidor implementa procesos demonionfsd NFS, que se ejecutan de forma predeterminada como , para que sus datos estén disponibles de forma genérica para los clientes.
2. El administrador del servidor determina qué poner a disposición, exportando los nombres y parámetros de los directorios , normalmente utilizando el /etc/exportsarchivo de configuración y el exportfscomando.
3. La administración de seguridad del servidor garantiza que pueda reconocer y aprobar clientes validados.
4. La configuración de la red del servidor garantiza que los clientes adecuados puedan negociar con él a través de cualquier sistema de firewall .
5. La máquina cliente solicita acceso a los datos exportados, generalmente mediante la emisión de un mountcomando. (El cliente le pregunta al servidor (rpcbind) qué puerto está utilizando el servidor NFS, el cliente se conecta al servidor NFS (nfsd), nfsd pasa la solicitud a mountd)
6. Si todo va bien, los usuarios de la máquina cliente podrán ver e interactuar con los sistemas de archivos montados en el servidor dentro de los parámetros permitidos.

Tenga en cuenta que es posible que se lleve a cabo la automatización del proceso de montaje de NFS, quizás mediante el uso /etc/fstab de funciones de montaje automático .

Durante el desarrollo del protocolo ONC (llamado SunRPC en ese momento), sólo el Network Computing System (NCS) de Apollo ofrecía una funcionalidad comparable. Dos grupos en competencia se desarrollaron sobre las diferencias fundamentales en los dos sistemas de llamada a procedimiento remoto. Las discusiones se centraron en el método de codificación de datos: la representación de datos externos (XDR) de ONC siempre representaba los números enteros en orden big-endian , incluso si ambos pares de la conexión tenían arquitecturas de máquina little-endian , mientras que el método de NCS intentaba evitar el intercambio de bytes siempre que dos pares compartieran un orden de endianidad común en sus arquitecturas de máquina. Un grupo de la industria llamado Network Computing Forum se formó (marzo de 1987) en un intento (finalmente infructuoso) de reconciliar los dos entornos de computación en red.

En 1987, Sun y AT&T anunciaron que desarrollarían conjuntamente el UNIX System V Release 4 de AT&T. ^[23] Esto provocó que muchos de los otros licenciatarios de UNIX System de AT&T se preocuparan de que esto pondría a Sun en una posición ventajosa, y finalmente llevó a Digital Equipment, HP, IBM y otros a formar la Open Software Foundation (OSF) en 1988. Irónicamente, Sun y AT&T habían competido anteriormente por el NFS de Sun contra el Remote File System (RFS) de AT&T, y la rápida adopción de NFS sobre RFS por parte de Digital Equipment, HP, IBM y muchos otros proveedores de computadoras inclinó a la mayoría de los usuarios a favor de NFS. La interoperabilidad de NFS se vio facilitada por eventos llamados "Connectathons" que comenzaron en 1986 que permitieron la prueba neutral de proveedores de implementaciones entre sí. ^[24] OSF adoptó el Entorno de Computación Distribuida (DCE) y el Sistema de Archivos Distribuidos (DFS) DCE sobre Sun/ONC RPC y NFS. DFS utilizó DCE como RPC, y DFS se derivó del Andrew File System (AFS); el DCE a su vez se derivó de un conjunto de tecnologías, incluyendo NCS y Kerberos de Apollo . ^{[ cita requerida ]}

Sun Microsystems y la Internet Society (ISOC) llegaron a un acuerdo para ceder el "control de cambios" de ONC RPC de modo que el organismo de estándares de ingeniería de ISOC, Internet Engineering Task Force (IETF), pudiera publicar documentos de estándares (RFC) relacionados con los protocolos ONC RPC y pudiera extender ONC RPC. OSF intentó convertir DCE RPC en un estándar de IETF, pero finalmente se mostró reacio a renunciar al control de cambios. Más tarde, IETF decidió extender ONC RPC agregando una nueva variante de autenticación basada en la Interfaz de Programación de Aplicaciones de Servicios de Seguridad Genéricos (GSSAPI), RPCSEC GSS, para cumplir con los requisitos de IETF de que los estándares de protocolo tengan la seguridad adecuada.

Más tarde, Sun e ISOC llegaron a un acuerdo similar para otorgarle a ISOC el control de cambios sobre NFS, aunque redactaron el contrato con cuidado para excluir las versiones 2 y 3 de NFS. En cambio, ISOC obtuvo el derecho a agregar nuevas versiones al protocolo NFS, lo que resultó en que IETF especificara la versión 4 de NFS en 2003.

En el siglo XXI, ni DFS ni AFS habían conseguido un éxito comercial importante en comparación con SMB-CIFS o NFS. IBM, que había adquirido anteriormente al principal proveedor comercial de DFS y AFS, Transarc , donó la mayor parte del código fuente de AFS a la comunidad de software libre en 2000. El proyecto OpenAFS sigue vivo. A principios de 2005, IBM anunció el fin de las ventas de AFS y DFS.

En enero de 2010, Panasas propuso un NFSv4.1 basado en su tecnología NFS paralela (pNFS) que afirmaba mejorar la capacidad de paralelismo en el acceso a los datos ^{[25] . El protocolo NFSv4.1 define un método para separar los} metadatos del sistema de archivos de la ubicación de los datos de los archivos; va más allá de la simple separación de nombres y datos al distribuir los datos entre un conjunto de servidores de datos. Esto difiere del servidor NFS tradicional que mantiene los nombres de los archivos y sus datos bajo el paraguas único del servidor. Algunos productos son servidores NFS de varios nodos, pero la participación del cliente en la separación de metadatos y datos es limitada.

El servidor pNFS NFSv4.1 es un conjunto de recursos o componentes del servidor; se supone que estos están controlados por el servidor de metadatos.

El cliente pNFS sigue accediendo a un servidor de metadatos para recorrer o interactuar con el espacio de nombres; cuando el cliente mueve datos hacia y desde el servidor, puede interactuar directamente con el conjunto de servidores de datos que pertenecen a la colección de servidores pNFS. El cliente NFSv4.1 puede habilitarse para que sea un participante directo en la ubicación exacta de los datos de archivo y para evitar la interacción solitaria con un servidor NFS al mover datos.

Además de pNFS, NFSv4.1 proporciona:

• Sesiones
• Delegación de directorios y notificaciones
• Espacio de nombres multiservidor
• listas de control de acceso y control de acceso discrecional
• Atribuciones de retención
• SECINFO_NO_NOMBRE