P+F de NFS para Azure NetApp Files

  • Artículo

En este artículo se responden las preguntas frecuentes (P+F) sobre el protocolo NFS de Azure NetApp Files.

Quiero tener un volumen montado automáticamente cuando se inicia o se reinicia una máquina virtual de Azure. ¿Cómo tengo que configurar mi host para los volúmenes persistentes de NFS?

Para que un volumen NFS se monte automáticamente al inicio o reinicio de una máquina virtual, agregue una entrada al archivo /etc/fstab en el host.

Consulte Montaje de un volumen para máquinas virtuales Windows o Linux para consultar los detalles.

¿Qué versión de NFS admite Azure NetApp Files?

Azure NetApp Files admite NFSv3 y NFSv4.1. Se pueden crear volúmenes con cualquier versión de NFS.

¿Azure NetApp Files admite oficialmente NFSv4.2?

Actualmente, Azure NetApp Files no admite oficialmente NFSv4.2 ni sus características auxiliares (incluidas las operaciones de archivos dispersos, los atributos extendidos y las etiquetas de seguridad). Sin embargo, la funcionalidad está activada para el servidor NFS cuando se usa NFSv4.1, lo que significa que los clientes NFS pueden montar usando el protocolo NFSv4.2 de una de estas dos maneras:

  • Especificar explícitamente vers=4.2, nfsvers=4.2 o nfsvers=4,minorversion=2 en las opciones de montaje.
  • No se especifica una versión NFS en las opciones de montaje y se permite que el cliente NFS negocie con la versión NFS más alta admitida.

En la mayoría de los casos, si un cliente monta con NFSv4.2, no se observan problemas. Sin embargo, algunos clientes pueden experimentar problemas si no son totalmente compatibles con NFSv4.2 o la funcionalidad de atributos extendidos NFSv4.2. Además, dado que NFSv4.2 no se admite actualmente con Azure NetApp Files, los problemas con NFSv4.2 están fuera del ámbito.

Para evitar problemas con los clientes que montan NFSv4.2 y cumplir con la compatibilidad, asegúrese de que la versión NFSv4.1 se especifica en las opciones de montaje o la configuración del cliente NFS se establece para limitar la versión NFS en NFSv4.1.

¿Cómo se puede habilitar root squashing?

El usuario puede especificar si la cuenta raíz tendrá o no acceso al volumen por medio de la directiva de exportación del volumen. Para más información, consulte Configuración de la directiva de exportación para un volumen NFS.

¿Puedo usar la misma ruta de acceso de archivo para varios volúmenes?

La misma ruta de acceso de archivo se puede usar para:

  • volúmenes implementados en diferentes regiones
  • volúmenes implementados en diferentes zonas de disponibilidad dentro de la misma región

Si está usando:

  • volúmenes regionales (sin zonas de disponibilidad) o
  • volúmenes dentro de la misma zona de disponibilidad,

se puede usar la misma ruta de acceso de archivo, pero la ruta de acceso del archivo debe ser única dentro de cada subred delegada o asignada a diferentes subredes delegadas.

Para más información, consulte Creación de un volumen NFS para Azure NetApp Files, Creación de un volumen de protocolo dual para Azure NetApp Files.

Cuando intento acceder a volúmenes NFS a través de un cliente de Windows, ¿por qué el cliente tarda mucho tiempo en buscar carpetas y subcarpetas?

Asegúrese de que CaseSensitiveLookup está habilitado en el cliente de Windows para acelerar la búsqueda de carpetas y subcarpetas:

  1. Use el siguiente comando de PowerShell para habilitar CaseSensitiveLookup:
    Set-NfsClientConfiguration -CaseSensitiveLookup 1
  2. Monte el volumen en el servidor de Windows.
    Ejemplo:
    Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*

¿Cómo admite Azure NetApp Files el bloqueo de archivos de NFSv4.1?

En el caso de los clientes de NFSv4.1, Azure NetApp Files admite el mecanismo de bloqueo de archivos de NFSv4.1 que mantiene el estado de todos los bloqueos de archivos en un modelo basado en concesión.

Por RFC 3530, Azure NetApp Files define un período de concesión único para todos los estados de un cliente NFS. Si el cliente no renueva su concesión dentro del período definido, el servidor liberará todos los estados asociados a la concesión del cliente.

Por ejemplo, si un cliente que monta un volumen deja de responder o se bloquea más allá de los tiempos de espera, se liberarán los bloqueos. El cliente puede renovar su concesión de forma explícita o implícita realizando operaciones como leer un archivo.

Un período de gracia define un período de procesamiento especial en el que los clientes pueden intentar reclamar su estado de bloqueo durante una recuperación del servidor. El tiempo de espera predeterminado para las concesiones es de 30 segundos con un período de gracia de 45 segundos. Transcurrido ese tiempo, se liberará la concesión del cliente.

Azure NetApp Files también admite los bloqueos de archivos importantes.

Para más información sobre el bloqueo de archivos en Azure NetApp Files, consulte Bloqueo de archivos.

¿Por qué el directorio .snapshot no está visible en un volumen NFSv4.1, pero sí lo está en un volumen NFSv3?

Por naturaleza, el directorio .snapshot nunca es visible para los clientes de NFSv4.1. De forma predeterminada, el directorio .snapshot es visible para los clientes de NFSv3. Para ocultar el directorio .snapshot de los clientes de NFSv3, edite las propiedades del volumen para ocultar la ruta de acceso de la instantánea.

Oracle dNFS

¿Hay alguna revisión de Oracle necesaria con dNFS?

Importante

Los clientes que usan Oracle 19c y versiones posteriores deben asegurarse de que cuentan con la revisión para los errores de Oracle 32931941. La mayoría de los conjuntos de revisiones actualmente en uso por parte de los clientes de Oracle no incluyen esta revisión. La revisión solo se ha incluido en un subconjunto de conjuntos de revisiones recientes.

Si una base de datos se expone a este error, es muy probable que las interrupciones de red produzcan datos dañados debido a bloques fracturados. Las interrupciones de red incluyen eventos como la reubicación de puntos de conexión de almacenamiento, la reubicación del volumen y los eventos de mantenimiento del servicio de almacenamiento. Es posible que los daños no se detecten inmediatamente.

Esto no es un error en ONTAP ni en el propio servicio de Azure NetApp Files, sino el resultado de un error de Oracle dNFS. La respuesta a una NFS E/S durante una determinada interrupción de red o eventos de reconfiguración se controla incorrectamente. La base de datos escribirá erróneamente un bloque que se estaba actualizando según se escribía en el mismo. En algunos casos, una sobrescritura posterior de ese mismo bloque dañará silenciosamente el bloque dañado. Si no es el caso, los procesos de base de datos Oracle lo detectarán finalmente. Se debe registrar un error en los registros de alertas y es probable que la instancia de Oracle finalice. Además, las operaciones dbv y RMAN pueden detectar los daños.

Oracle publica el documento 1495104.1, que se actualiza continuamente con las revisiones de dNFS recomendadas. Si su base de datos usa dNFS, asegúrese de que el equipo de DBA comprueba si hay actualizaciones en este documento.

Importante

Los clientes que usan Oracle dNFS con NFSv4.1 en volúmenes de Azure NetApp Files deben asegurarse de realizar acciones mencionadas en ¿Hay revisiones necesarias para el uso de Oracle dNFS con NFSv4.1?.

¿Hay revisiones necesarias para el uso de dNFS de Oracle con NFSv4.1?

Importante

Si las bases de datos usan dNFS de Oracle con NFSv4.1, deben aplicarse las revisiones para los errores de Oracle 33132050 y 33676296. Es posible que tenga que solicitar una portabilidad a una versión anterior de Oracle. Por ejemplo, en este momento, estas revisiones están disponibles para la versión 19.11, pero aún no para 19.3. Si cita estos números de error en el caso de soporte técnico, los ingenieros de soporte técnico de Oracle saben qué hacer.

Este requisito se aplica a los sistemas y servicios basados en ONTAP en general, incluidos ONTAP local y Azure NetApp Files.

Ejemplos de los posibles problemas si no se aplican estas revisiones:

  1. La base de datos se bloquea en los movimientos del punto de conexión de almacenamiento de back-end.
  2. La base de datos se bloquea en eventos de mantenimiento del servicio Azure NetApp Files.
  3. Oracle se bloquea brevemente durante el funcionamiento normal, puede o no ser notable.
  4. Oracle se apaga lentamente: si supervisa el proceso de apagado, verá pausas que podrían agregar hasta minutos de retrasos, ya que se agota el tiempo de espera de E/S de dNFS.
  5. Comportamiento incorrecto del almacenamiento en caché de respuestas de dNFS en lecturas que bloquearán una base de datos.

Las revisiones incluyen un cambio en la administración de sesiones de dNFS y el almacenamiento en caché de respuesta NFS que resuelve estos problemas.

Si no puede aplicar las revisiones para solucionar estos dos errores, no debe usar dNFS con NFSv4.1. Puede deshabilitar dNFS o cambiar a NFSv3.

¿Puedo usar múltiples rutas con dNFS de Oracle y NFSv4.1?

Al usar NFSv4.1, dNFS no funcionará con varias rutas de acceso. Si necesita varias rutas, debe usar NFSv3. dNFS requiere clientID en todo el clúster y el enlace troncal de sessionID para que nfSv4.1 funcione con varias rutas, que Azure NetApp Files no admite. Como resultado, experimentará un bloqueo durante el inicio de dNFS

Pasos siguientes