OneFS: Prácticas recomendadas para los ajustes del cliente de NFS

Versiones de protocolo soportadas

En este momento, PowerScale OneFS soporta las versiones 3 y 4 de NFS. No se soporta la versión 2 de NFS.

NFSv3

La versión 3 de NFS es la versión más utilizada del protocolo NFS en la actualidad y, por lo general, se considera que cuenta con el nivel de adopción más amplio de clientes y filer. Estos son los componentes clave de esta versión:

• Sin estado: un cliente no establece técnicamente una nueva sesión si tiene la información correcta para solicitar archivos, etc. Esto permite una conmutación por error simple entre los nodos de OneFS a través de grupos con IP dinámicas.
• La información del usuario y del grupo se presenta numéricamente: el cliente y el servidor comunican la información del usuario mediante identificadores numéricos, lo que permite que el mismo usuario aparezca con nombres diferentes entre el cliente y el servidor.
• El bloqueo de archivos está fuera de banda: la versión 3 de NFS utiliza un protocolo auxiliar llamado NLM para realizar bloqueos. Esto requiere que el cliente responda a los mensajes RPC del servidor para confirmar que se han concedido bloqueos, etc.
• Se puede ejecutar a través de TCP o UDP: esta versión del protocolo se puede ejecutar a través de UDP en lugar de TCP, lo que deja el manejo de la pérdida y la retransmisión al software en lugar del sistema operativo. Siempre recomendamos usar TCP.

NFSv4

La versión 4 de NFS es la revisión principal más reciente del protocolo NFS y está aumentando en adopción. En este momento, NFSv4 tiene, por lo general, un rendimiento menor que v3 en comparación con el mismo flujo de trabajo debido a la mayor cantidad de mapeo de identidades y el trabajo de rastreo de sesiones necesarios para responder. Estas son algunas de las diferencias clave entre v3 y v4

• Con estado: NFSv4 utiliza sesiones para manejar la comunicación, por lo que tanto el cliente como el servidor deben rastrear el estado de la sesión para continuar comunicándose.
  • Antes de OneFS 8.X, esto significaba que los clientes de NFSv4 necesitaban grupos de IP estáticas en PowerScale o podían tener problemas.
• La información del usuario y del grupo se presenta como strings: tanto el cliente como el servidor deben resolver los nombres de la información numérica almacenada. El servidor debe buscar nombres para presentarlos, mientras que el cliente debe volver a asignarlos a números en su extremo.
• El bloqueo de archivos se realiza dentro de banda: la versión 4 ya no utiliza un protocolo separado para el bloqueo de archivos, sino que lo convierte en un tipo de llamada que generalmente se compone con OPENS, CREATES o WRITES.
• Llamadas compuestas: la versión 4 puede agrupar en una serie de llamadas en un solo paquete, lo que permite que el servidor las procese todas y las responda al final. Esto se utiliza para reducir la cantidad de llamadas involucradas en operaciones comunes.
• Solo soporta TCP: la versión 4 de NFS ha dejado la pérdida y la retransmisión hasta el sistema operativo subyacente.

NFSv4.1 y versiones posteriores

NFSv4.1 y v4.2 están disponibles a partir de OneFS versión 9.3

Esta es la información oficial de la versión 9.3:

https://dl.dell.com/content/docu105998_powerscale-onefs-9-3-0-0-release-notes.pdf?language=en_us
 

Opciones de montaje

Si bien no tenemos requisitos complejos para las opciones de montaje, tenemos algunas recomendaciones sobre cómo establecer la conexión con los clientes. No hemos proporcionado strings de montaje específicas, ya que la nomenclatura utilizada para definir estas opciones varía según el sistema operativo en uso. Debe mantener la documentación de los mantenedores de distribución para conocer la nomenclatura de montaje específica.

Definición de reintentos y tiempos de espera agotados

Si bien PowerScale suele responder muy rápidamente a la comunicación con el cliente, durante las instancias en que un nodo ha perdido alimentación o conectividad de red, es posible que sus direcciones IP tarden unos segundos en pasar a un nodo funcional, por lo que es importante tener valores de tiempo de espera y reintentos definidos de manera correcta. Por lo general, PowerScale recomienda utilizar un tiempo de espera agotado de 60 segundos para dar cuenta de una situación de conmutación por error en el peor de los casos, configurado para reintentar dos veces antes de informar una falla.

Montajes físicos en comparación con los digitales

Los montajes físicos ocasionan que el cliente deba volver a realizar sus operaciones indefinidamente tras un tiempo de espera agotado o un error. Esto garantiza que el cliente no desconecte el montaje en circunstancias en que el clúster PowerScale transfiere direcciones IP de un nodo a otro. Un montaje digital generará un error y vencerá el montaje que requiere un nuevo montaje para restaurar el acceso después de que se transfiera la dirección IP.

Permitir interrupción

De manera predeterminada, la mayoría de los clientes no permiten interrumpir una entrada/salida o una espera de I/O, lo que significa que no puede usar ctrl+c, etc. para finalizar el proceso de espera si el clúster deja de responder, incluida la opción de montaje interrupt, con la cual esas señales logran pasar normalmente.

Comparación local con bloqueo remoto

Cuando monte una exportación de NFS, puede especificar si un elemento similar realizará sus bloqueos localmente o si utilizará el coordinador de bloqueo en el clúster. La mayoría de los clientes se configuran de manera predeterminada con el bloqueo remoto y, por lo general, esta es la mejor opción cuando varios clientes accedan al mismo directorio; sin embargo, es posible que realizar el bloqueo local cuando un cliente no debe compartir el acceso al directorio con el que está trabajando tenga beneficios de rendimiento. Además, algunas bases de datos y software le solicitarán que utilice el bloqueo local, ya que tienen su propio coordinador.