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 en una computadora cliente acceder a archivos a través de una red informática de manera 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 del IETF definido en una Solicitud de comentarios (RFC), que permite a cualquiera implementar el protocolo.
Sun utilizó la versión 1 sólo con fines experimentales internos. Cuando el equipo de desarrollo agregó cambios sustanciales a la versión 1 de NFS y la lanzó fuera de Sun, decidieron lanzar la nueva versión como v2, para poder probar la interoperación de versiones y la versión alternativa de RPC. [2] [3]
La versión 2 del protocolo (definida en RFC 1094, marzo de 1989) originalmente operaba solo sobre el Protocolo de datagramas de usuario (UDP). Sus diseñadores pretendían mantener el lado del servidor sin estado , con el bloqueo (por ejemplo) implementado fuera del protocolo central. Las personas involucradas en la creación de la versión 2 de NFS incluyen a Russel Sandberg, Bob Lyon, Bill Joy , Steve Kleiman y otros. [1] [4]
La interfaz del Virtual File System permite una implementación modular, reflejada en un protocolo simple. En febrero de 1986, se demostraron implementaciones para sistemas operativos como System V versión 2, DOS y VAX/VMS utilizando Eunice . [4] NFSv2 solo permite leer los primeros 2 GB de un archivo debido a limitaciones de 32 bits .
La versión 3 (RFC 1813, junio de 1995) agregó:
La primera propuesta de NFS Versión 3 dentro de Sun Microsystems se creó 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 síncrona en NFS Versión 2. [6] En julio de 1992, la implementación La práctica había resuelto muchas deficiencias de NFS Versión 2, dejando sólo la falta de soporte para archivos grandes (tamaños de archivos de 64 bits y compensaciones) como un problema apremiante. Esto se convirtió en un grave problema para Digital Equipment Corporation con la introducción de una versión de 64 bits de Ultrix para admitir su procesador RISC de 64 bits recién lanzado , el Alpha 21064 . 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. Uso de TCP como transporte realizado usando NFS a través de una WAN 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 era una extensión de NFSv2 y NFSv3 que le permitía funcionar detrás de firewalls 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 comunicara con el servicio MOUNT RPC para determinar el identificador de archivos inicial de cada sistema de archivos, introdujo el concepto de un identificador de archivos público (nulo para NFSv2, longitud cero). para NFSv3) que podría usarse 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 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 proporcionar 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 sesión (también conocido como ruta múltiple NFS) 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, aviso de E/S de aplicaciones, archivos dispersos, reserva de espacio, bloque de datos de aplicaciones (ADB), etiquetado NFS 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 sólo se utiliza un puerto UDP o TCP, el 2049, para ejecutar el servicio, lo que simplifica el uso del protocolo a través de firewalls.
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 la operación a través de firewalls. En 2007, Sun Microsystems abrió su implementación WebNFS del lado del cliente. [10]
Varios protocolos de banda lateral se han asociado con NFS. Nota:
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 , [15] AmigaOS , el clásico Mac OS , OpenVMS , [3] MS-DOS , [16] Microsoft Windows , [17] OS/2 , [18] ArcaOS , [19] Novell NetWare , [20] e IBM i . [21] 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 principal de NetWare (NCP) y el sistema de archivos del servidor de archivos OS/400 (QFileSvr.400).
SMB y NetWare Core Protocol (NCP) ocurren con más frecuencia que NFS en sistemas que ejecutan Microsoft Windows; AFP ocurre con más frecuencia que NFS en los sistemas Apple Macintosh ; y QFileSvr.400 ocurre con más frecuencia en sistemas IBM i. Haiku en 2012 agregó soporte NFSv4 como parte de un proyecto Google Summer of Code.
Suponiendo un escenario estilo Unix en el que una máquina (el cliente ) necesita acceso a los datos almacenados en otra máquina (el servidor NFS ):
nfsd, para que sus datos estén disponibles genéricamente para los clientes./etc/exportsarchivo de configuración y el exportfscomando.mountcomando. (El cliente pregunta al servidor (rpcbind) qué puerto está usando el servidor NFS, el cliente se conecta al servidor NFS (nfsd), nfsd pasa la solicitud a mountd)Tenga en cuenta que puede llevarse a cabo la automatización del proceso de montaje de NFS, tal vez utilizando /etc/fstab y/o instalaciones 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 diferencias fundamentales en los dos sistemas de llamadas a procedimientos remotos. Los argumentos se centraron en el método de codificación de datos: la representación de datos externos (XDR) de ONC siempre representaba 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. cada vez que dos pares compartían una endianidad común en sus arquitecturas de máquinas. Se formó un grupo industrial llamado Network Computing Forum (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 UNIX System V Release 4 de AT&T. [22] Esto hizo 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, en última instancia, condujo a Digital Equipment. , HP, IBM y otros formaron la Open Software Foundation (OSF) en 1988. Irónicamente, Sun y AT&T habían competido anteriormente por NFS de Sun versus Remote File System (RFS) de AT&T, y por la rápida adopción de NFS sobre RFS por parte de Digital Equipment, HP, IBM y muchos otros proveedores de computadoras inclinaron a la mayoría de los usuarios a favor de NFS. La interoperabilidad de NFS se vio favorecida por eventos llamados "Connectathons" que comenzaron en 1986 y que permitieron realizar pruebas de implementaciones neutrales entre sí. [23] OSF adoptó el entorno informático distribuido (DCE) y el sistema de archivos distribuidos (DFS) DCE sobre Sun/ONC RPC y NFS. DFS utilizó DCE como RPC y DFS derivó del Andrew File System (AFS); El propio DCE se deriva de un conjunto de tecnologías, incluidas NCS y Kerberos de Apollo . [ cita necesaria ]
Sun Microsystems e Internet Society (ISOC) llegaron a un acuerdo para ceder el "control de cambios" de ONC RPC para 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 ONC RPC. protocolos y podría extender ONC RPC. OSF intentó convertir a DCE RPC en un estándar del IETF, pero finalmente se mostró reacio a renunciar al control de cambios. Posteriormente, el IETF optó por ampliar ONC RPC agregando un nuevo tipo de autenticación basado en la Interfaz de programa de aplicación de servicios de seguridad genéricos (GSSAPI), RPCSEC GSS, para cumplir con los requisitos del IETF de que los estándares de protocolo tengan una seguridad adecuada.
Más tarde, Sun e ISOC llegaron a un acuerdo similar para darle a ISOC control de cambios sobre NFS, aunque redactaron el contrato cuidadosamente para excluir NFS versión 2 y versión 3. En cambio, ISOC obtuvo el derecho de agregar nuevas versiones al protocolo NFS, lo que resultó en IETF. especificando NFS versión 4 en 2003.
En el siglo XXI, ni DFS ni AFS habían logrado un éxito comercial importante en comparación con SMB-CIFS o NFS. IBM, que anteriormente había adquirido el 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 Parallel NFS (pNFS), afirmando mejorar la capacidad de paralelismo de acceso a datos [24] . El protocolo NFSv4.1 define un método para separar los metadatos del sistema de archivos de la ubicación de los datos del archivo; va más allá de la simple separación de nombre/datos al dividir 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 único paraguas del servidor. Algunos productos son servidores NFS de múltiples 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 todavía accede a un servidor de metadatos para atravesar 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 se puede habilitar para que participe directamente en la ubicación exacta de los datos del archivo y evite la interacción solitaria con un servidor NFS al mover datos.
Además de pNFS, NFSv4.1 proporciona:
NFS-Ganesha es un servidor NFS que se ejecuta en el espacio del usuario y admite CephFS FSAL (capa de abstracción del sistema de archivos) mediante libcephfs.
{{cite news}}: CS1 maint: numeric names: authors list (link)