NetApp Tech OnTap

Novedades en NFS Versión 4

Desde su introducción en 1984, el sistema de ficheros en red, Network File System (NFS), se ha convertido en un elemento estándar para compartir ficheros en red, sobre todo en comunidades UNIX® y Linux®. En los últimos 20 años, el protocolo NFS ha evolucionado poco a poco para adaptarse a las nuevas necesidades y los cambios del mercado.

Durante la mayor parte de ese tiempo, en NetApp hemos estado trabajando para dirigir la evolución de NFS hacia una mayor satisfacción de las necesidades del usuario. El oficial jefe de tecnología de NetApp, Brian Pawlowski, es coautor de la especificación NFS versión 3, actualmente la versión más utilizada de NFS, y codirige el grupo de trabajo de la versión 4 de NFS (NFSv4). Mike Eisler y Dave Nioveck, de NetApp, son coautores de la especificación de NFS versión 4, la última versión disponible de NFS, y editores de la especificación de NFS versión 4.1, que en la actualidad está en desarrollo.

 
NFSv3
NFSv4
Personality Stateless Stateful
Semantics UNIX only Suport UNIX and Windows
Authentication Weak (AUTH_SYS) Strong (Kerberos)
Identification 32 bit UID/GID String based (xyz@netapp.com)
Permissions UNIX based Windows like access
Transport UDP & TCP TCP
Caching Ad-hoc Delegations

Figura 1) Comparación de NFSv3 y NFSv4

NFS consta de software de servidor, por ejemplo, el software que se ejecuta en almacenamiento NetApp®, y el software de cliente que se ejecuta en hosts que requieren acceso a almacenamiento en red. Un funcionamiento correcto precisa que ambos lados de la conexión, cliente y servidor, sean sólidos y estén implementados correctamente. Aunque NetApp ha estado lanzando NFS versión 4 desde que Data ONTAP® 6.4, nuestra base de códigos, experimentó numerosos cambios y se consolidó de manera considerable, NFSv4 ha alcanzado ahora un punto en el que creemos que está listo para un uso productivo.

Hoy, las implementaciones del cliente tienen una gran estabilidad. Además, NetApp ha realizado algunos cambios y mejoras importantes en Data ONTAP 7.3 para compatibilidad con NFSv4. En este artículo, voy a analizar tres características significativas de NFSv4 que han llamado mucho la atención:

  • istas de control de acceso (ACL) para seguridad y compatibilidad con Windows®
  • Seguridad obligatoria con Kerberos
  • Delegaciones para almacenamiento en caché del cliente
Si bien este análisis se aplicará en gran medida a implementaciones NFSv4, también describiré algunos detalles que son exclusivos de NetApp, así como las mejores prácticas, donde sea necesario.

  AIX Client Server BSD/OSX Client Server (not sup. by apple) EMC Server Humingbird Client Linux Client Server
(RHEL5)
NetApp Server Solaris 10 client Server
Delegations Yes   Yes   Yes Yes Yes
Access Control lists Yes   Yes   Yes Yes Yes
Kerberos V5 Yes Yes Yes Yes Yes Yes Yes
File Streams           Yes Yes
I18n Yes Yes   Yes Yes Yes Yes
Global Namespace/Referrals Yes       Yes Future  

Figura 2) Estado de implementación de cliente y servidor NFSv4.

Listas de control de acceso (ACL)
Las ACL son una de las características que los usuarios de NetApp solicitan con más frecuencia en su búsqueda de una mayor compatibilidad para clientes Windows. Las ACL NFSv4 mejoran considerablemente la seguridad NFS y la interoperabilidad con CIFS.

Con las ACL, los permisos de acceso se pueden otorgar o denegar por usuario para cada objeto de fichero, lo que proporciona un control de acceso mucho más refinado y un mayor grado de selectividad que los bits de permiso en modo UNIX tradicionales. Las ACL NFSv4 se basan en el modelo NT, pero no contienen información de grupo o propietario. Las ACL NFSv4 están hechas de una selección de entradas de control de acceso (ACE), que contienen información referente a acceso otorgado o denegado, bits de permiso, nombre de usuario o nombre de grupo, e indicadores.

Puesto que NetApp ya ofrece soporte ACL para clientes CIFS, la adición de una ACL en NFSv4 crea algunas consideraciones únicas. NetApp ofrece tres tipos de qtrees (UNIX, NTFS y combinados) para usar por diferentes clientes. La forma en que se tratan las ACL NFSv4 depende del tipo de qtree:

Qtree UNIX

 

  • Efectividad ACL NFSV4 y bits de modo.
  • Los clientes Windows no pueden definir atributos.
  • Semántica UNIX

Qtree NTFS

  • Efectividad ACL NT y bits de modo; los clientes UNIX no pueden definir atributos.
  • Las ACL NFSv4 se generan a partir de bits de modo para clientes NFS que acceden a ficheros con una ACL NT.
  • Semántica NT

Qtree combinado

  • Efectividad ACL NFSv4, ACL NT y bits de modo.
  • Los clientes Windows y UNIX pueden definir atributos.
  • La ACL NFSv4 se genera a partir de bits de modo para ficheros con ACL NT.

Lógicamente, debe seleccionar bien el tipo de qtree que va a utilizar para obtener los resultados deseados:

  • Únicamente acceso NFS: qtree UNIX
  • Acceso combinado: qtree combinado
  • Mayormente acceso CIFS: qtree NTFS
  • Únicamente CIFS: qtree NTFS

La única otra mejor práctica con respecto a las ACL es usar más de 192 ACE por ACL. Puede aumentar el número de ACE por ACL a un máximo actual de 400, pero al hacerlo podría tener problemas en caso de que necesite volver a una versión anterior de Data ONTAP o si utiliza SnapMirror® para ir a una versión anterior.

Seguridad obligatoria

Además de incluir ACL, NFSv4 mejora en cuanto a la seguridad de versiones NFS anteriores por:

  • Exigir la disponibilidad de seguridad RPC sólida que depende de criptografía.
  • Negociar el tipo de seguridad utilizada entre servidor y cliente mediante un sistema en banda seguro.
  • Usar cadenas de caracteres en vez de números enteros para representar identificadores de usuarios y de grupos.

La seguridad NFS se ha reforzado con la adición de seguridad basada en GSS-API (Generic Security Services API), llamada RPCSEC_GSS [RFC2203]. Todas las versiones de NFS pueden usar RPCSEC_GSS. Sin embargo, una correcta implementación de NFS versión 4 debe incluir RPCSEC_GSS. RPCSEC_GSS se asigna de forma análoga a la seguridad AUTH_SYS comúnmente utilizada, que era el método estándar de autenticación en versiones NFS anteriores.
RPCSEC_GSS difiere de AUTH_SYS y otros mecanismos de seguridad NFS tradicionales en dos cosas:

  • RPCSEC_GSS realiza una mayor autenticación. Es capaz de realizar comprobaciones de integridad y cifrado de todo el volumen de la petición y respuesta RPC. Por tanto, RPCSEC_GSS proporciona seguridad más allá de la simple autenticación.
  • Puesto que RPCSEC_GSS simplemente encapsula los símbolos (tokens) de mensajería GSS-API, es decir, actúa como mero transporte para tokens específicos de mecanismo para mecanismos de seguridad como Kerberos, la adición de nuevos mecanismos de seguridad (siempre que se ajusten a GSS-API) no requiere la reescritura de partes importantes de NFS.

NFS AUTH System















Figura 3) NFS con AUTH_SYS frente a seguridad RPCSEC-GSS.

NFSv3 y NFSv4 pueden utilizar RPCSEC-GSS. Sin embargo, AUTH_SYS es el valor predeterminado para NFSv3.

El único mecanismo de seguridad que NetApp o la mayoría de clientes NFSv4 ofrecen actualmente con RPCSEC_GSS es Kerberos 5. Kerberos es un mecanismo de autenticación que emplea cifrado de claves simétricas. Nunca envía contraseñas a través de la red ya sea en texto sencillo o en forma cifrada, y se basa en tickets y claves de sesión cifrados para autenticar a los usuarios antes de que puedan utilizar los recursos de la red. El sistema Kerberos emplea centros de distribución de claves (KDC) que contienen una base de datos centralizada de nombres de usuario y contraseñas. NetApp admite dos tipos de KDC: UNIX y Windows Active Directory.

Aun así, tiene la opción de utilizar el débil método de autenticación de versiones NFS anteriores (AUTH_SYS) en caso necesario. Puede lograrlo si especifica sec=sys en la línea de comandos exportfs o en el fichero /etc/exports. Cuando se usa AUTH_SYS, Data ONTAP sólo admite un máximo de 16 identificadores de grupos complementarios en una credencial, más 1 identificador de grupo principal. Kerberos admite un máximo de 32 identificadores de grupos complementarios.

Delegaciones para almacenamiento en caché del cliente

En NFSv3, los clientes generalmente funcionan como si hubiera duda por los ficheros abiertos (aunque este no suele ser el caso). Una consistencia débil de la caché se mantiene a través de las frecuentes peticiones del cliente al servidor por saber si un fichero abierto ha sido modificado por otra persona, lo que puede causar un tráfico de red innecesario y retrasos en entornos de alta latencia. En situaciones en las que un cliente mantiene un bloqueo sobre un fichero, se requiere que todos los datos I/O de escritura sean sincrónicos, además de influir en el rendimiento del cliente en muchos casos.

NFSv4 difiere de las versiones anteriores de NFS en que permite que un servidor delegue acciones específicas sobre un fichero en un cliente para que haya un almacenamiento en caché de datos más agresivo por parte del cliente y un almacenamiento en caché del estado de bloqueo. Un servidor cede control de actualizaciones de ficheros y el estado de bloqueo a un cliente a través de una delegación. Esto reduce la latencia al permitir al cliente la realización de diversas operaciones y datos de caché localmente. Actualmente existen dos tipos de delegaciones: lectura y escritura. El servidor tiene la capacidad de devolver la petición de una delegación de un cliente si hay posibilidad de duda para un fichero.

Una vez que un cliente tiene una delegación, puede realizar operaciones en ficheros cuyos datos se han almacenado en caché localmente para evitar latencia de red y optimizar I/O. El almacenamiento en caché más agresivo resultante de delegaciones puede ser una gran ayuda en entornos con las siguientes características:

  • Aperturas y cierres frecuentes
  • Procesos GETATTR frecuentes
  • Bloqueo de ficheros
  • Uso compartido de sólo lectura
  • Alta latencia
  • Clientes rápidos
  • Servidor muy cargado con muchos clientes

Data ONTAP admite delegaciones de lectura y escritura, y puede definir por separado el servidor NFSv4 para activar o desactivar uno o ambos tipos de delegaciones. Cuando se activan las delegaciones, Data ONTAP otorgará de forma automática una delegación de lectura a un cliente que abra un fichero para leer, o bien, una delegación de escritura a un cliente que abra un fichero para escribir.

Se han suministrado opciones para activar o desactivar delegaciones de lectura y escritura para ofrecerle un nivel de control sobre el impacto de las delegaciones. Lo ideal es que el servidor determine si proporcionará o no una delegación a los clientes. Activar la delegación de lectura en un entorno muy intensivo de lectura será beneficioso. Las delegaciones de escritura en entornos de desarrollo en los que cada usuario escribe en ficheros de desarrollo independientes y no existe posibilidad de duda, también mejorará el rendimiento. Sin embargo, es posible que las delegaciones de escritura no sean útiles en casos en los hay que varios desarrolladores en el mismo fichero.

Conozca más datos

Si le preocupa la seguridad de los datos (¿a quién no?), las nuevas características de NFSv4, como soporte ACL y seguridad obligatoria, pueden reducir considerablemente el riesgo de acceso a datos no autorizado. Otro objetivo de diseño importante para NFSv4 ha sido el rendimiento mejorado en Internet. La mejora del almacenamiento en caché de cliente a través de las delegaciones tiene como fin satisfacer este objetivo.

  • Eliminación del mount daemon independiente y otros servicios accesorios que precisan puertos abiertos adicionales.
  • Solicitudes compuestas que agrupan las tareas comunes en una sola operación para acelerar la respuesta y reducir el tráfico de red.

Si desea saber más sobre éstas y otras características de NFSv4 TR-3085 ofrece una buena referencia general. También puede consultar mi reciente

author

Bikash R. Choudhury
Arquitecto de soluciones
NetApp

Bikash entró a formar parte de NetApp hace ocho años como ingeniero de soporte técnico y, más tarde, se convirtió en el asesor técnico global (TGA) para uno de los mayores clientes de NetApp. Como TGA, se centró en la creación de sólidas relaciones con el cliente, así como de soluciones técnicas. En su cargo actual como arquitecto de soluciones de aplicaciones técnicas y NFS, Bikash se centra en el diseño de arquitecturas para soluciones de aplicaciones técnicas que usan NFS. Además, realiza pruebas y certificaciones funcionales, y ofrece asistencia Global Partner Alliance para las mejores prácticas NFS.

Comente sobre este artículo
Explore