Azure Files: Solución de problemas de rendimiento

En primer lugar, descarte algunas razones comunes por las que es posible que tenga problemas de rendimiento.

Si la máquina virtual (VM) cliente ejecuta Windows 8.1 o Windows Server 2012 R2, o una distribución o kernel de Linux anterior, es posible que experimente problemas de rendimiento al acceder a recursos compartidos de archivos de Azure. Actualice el sistema operativo del cliente o aplique las correcciones siguientes.

Las solicitudes se limitan cuando se alcanzan los límites de operaciones de E/S por segundo (IOPS), entradas o salidas de un recurso compartido de archivos. Por ejemplo, si el cliente supera la IOPS de base de referencia, el servicio Azure Files lo limitará. La limitación puede dar lugar a que el cliente experimente un rendimiento deficiente.

Para conocer los límites de los recursos compartidos de archivos de nivel Estándar y Premium, consulte Objetivos de escalabilidad de archivos y recursos compartidos de archivos. En función de la carga de trabajo, a menudo se puede evitar la limitación pasando de recursos compartidos de archivos de Azure estándar a premium.

Para obtener más información sobre cómo la limitación en el nivel de recurso compartido o el nivel de cuenta de almacenamiento puede provocar alta latencia, bajo rendimiento y problemas de rendimiento generales, consulte Limitación de la cuenta de almacenamiento o recurso compartido.

Para confirmar si se está limitando el recurso compartido o la cuenta de almacenamiento, puede acceder y usar las métricas de Azure en el portal. También puede crear alertas que le notificarán si un recurso compartido está limitado o está a punto de limitarse. Consulte Solución de problemas de Azure Files mediante la creación de alertas.

1. En Azure Portal, vaya a la cuenta de almacenamiento.

2. En el panel de la izquierda, en Supervisión, seleccione Métricas.

3. Seleccione Archivo como el espacio de nombres de la métrica para el ámbito de la cuenta de almacenamiento.

4. Seleccione Transacciones como métrica.

5. Agregue un filtro para Tipo de respuesta y, luego, compruebe si se ha limitado alguna solicitud.

   En el caso de los recursos compartidos de archivos estándar, se registran los siguientes tipos de respuesta si se limita una solicitud en el nivel de cuenta de cliente:

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   Si se limita una solicitud en los recursos compartidos de archivos prémium, se registran los siguientes tipos de respuesta:

   • SuccessWithShareEgressThrottling
   • SuccessWithShareIngressThrottling
   • SuccessWithShareIopsThrottling
   • ClientShareEgressThrottlingError
   • ClientShareIngressThrottlingError
   • ClientShareIopsThrottlingError

   Si se ha autenticado una solicitud limitada con Kerberos, es posible que vea un prefijo que indica el protocolo de autenticación, como:

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

   Para más información sobre cada tipo de respuesta, consulte Dimensiones de métricas.

   

Si usa un recurso compartido de archivos Premium, aumente el tamaño del recurso compartido de archivos aprovisionado para aumentar el límite de IOPS. Para más información, consulte Descripción del aprovisionamiento de recursos compartidos de archivos premium.

Si la mayoría de las solicitudes se centran en metadatos (como createfile, openfile, closefile, queryinfo o querydirectory), la latencia será peor en comparación con las operaciones de lectura y escritura.

Para determinar si la mayoría de las solicitudes están centradas en los metadatos, empiece por los pasos del 1 al 4, como se ha descrito anteriormente en la causa 1. En el paso 5, en lugar de agregar un filtro para Tipo de respuesta, agregue un filtro de propiedad para Nombre de API.

• Compruebe si la aplicación se puede modificar para reducir el número de operaciones de metadatos.

• Si usa recursos compartidos de archivos de Azure SMB premium, use el almacenamiento en caché de metadatos.

• Separe el recurso compartido de archivos en varios recursos compartidos de archivos dentro de la misma cuenta de almacenamiento.

• Agregue un disco duro virtual (VHD) al recurso compartido de archivos y móntelo a través desde el cliente para realizar operaciones de archivos en los datos. Este enfoque funciona para escenarios de escritor o lector único o escenarios con varios lectores y sin escritores. Dado que el sistema de archivos es propiedad del cliente y no de Azure Files, esto permite que las operaciones de metadatos sean locales. La configuración ofrece un rendimiento similar al de un almacenamiento con conexión directa local. Sin embargo, como los datos están en un disco duro virtual, solo se puede acceder a ellos a través del montaje de SMB, como la API REST o a través de Azure Portal.

  1. Desde la máquina que necesite acceder al recurso compartido de archivos de Azure, monte el recurso compartido de archivos mediante la clave de la cuenta de almacenamiento y asígnelo a una unidad de red disponible (por ejemplo, Z:).
  2. Vaya a Administración de discos y seleccione Acción > Crear disco duro virtual.
  3. Establezca en Ubicación la unidad de red a la que está asignado el recurso compartido de archivos de Azure, establezca el valor de Tamaño del disco duro virtual que sea necesario y seleccione Tamaño fijo.
  4. Seleccione Aceptar. Una vez completada la creación del disco duro virtual, se montará automáticamente y aparecerá un nuevo disco sin asignar.
  5. Haga clic con el botón derecho en el nuevo disco desconocido y seleccione Inicializar disco.
  6. Haga clic con el botón derecho en el área sin asignar y cree un nuevo volumen simple.
  7. Debería ver que en Administración de discos aparece una nueva letra de unidad que representa este disco duro virtual con acceso de lectura y escritura (por ejemplo, E:). En el Explorador de archivos, debería ver el nuevo disco duro virtual en la unidad de red del recurso compartido de archivos de Azure asignado (Z: en este ejemplo). Para que quede claro, debe haber dos letras de unidad presentes: la asignación de red del recurso compartido de archivos de Azure estándar en Z:y la asignación del disco duro virtual en la unidad E:.
  8. Debe haber un rendimiento mucho mejor en las operaciones de metadatos intensivas en archivos de la unidad asignada del disco duro virtual (E:), frente a la unidad asignada del recurso compartido de archivos de Azure (Z:). Si lo desea, debe ser posible desconectar la unidad de red asignada (Z:) y seguir accediendo a la unidad de disco duro virtual montada (E:).
  • Para montar un disco duro virtual en un cliente de Windows, también puede usar el cmdlet de PowerShell Mount-DiskImage.
  • Para montar un disco duro virtual en Linux, consulte la documentación de la distribución de Linux. Este es un ejemplo.

Si la aplicación que usa tiene un único subproceso, esta configuración puede dar lugar a un rendimiento de IOPS significativamente menor que el máximo posible, en función del tamaño del recurso compartido aprovisionado.

• Aumente el paralelismo de la aplicación aumentando el número de subprocesos.
• Cambie a aplicaciones en las que el paralelismo sea posible. Por ejemplo, para las operaciones de copia, podría usar AzCopy o RoboCopy desde clientes de Windows o el comando parallel en los clientes de Linux.

Si usa SMB multicanal y el número de canales que tiene supera los cuatro, el rendimiento será deficiente. Para determinar si el número de conexiones supera las cuatro, use el cmdlet get-SmbClientConfiguration de PowerShell para ver la configuración actual del recuento de conexiones.

Establezca el valor Windows per NIC (Ventanas por NIC) de SMB para que el total de canales no supere los cuatro. Por ejemplo, si tiene dos NIC, puede establecer el máximo por NIC en dos mediante el siguiente cmdlet de PowerShell: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

A partir de la versión 5.4 del kernel de Linux, el cliente NFS de Linux usa un valor predeterminado read_ahead_kb de 128 kibibytes (KiB). Este valor pequeño puede reducir la cantidad de rendimiento de lectura para archivos grandes.

Se recomienda aumentar el valor del read_ahead_kb parámetro kernel a 15 mebibytes (MiB). Para cambiar este valor, establezca el tamaño de lectura anticipada de forma persistente agregando una regla en udev, un administrador de dispositivos kernel de Linux. Siga estos pasos:

1. En un editor de texto, cree el archivo /etc/udev/rules.d/99-nfs.rules escribiendo y guardando el texto siguiente:

   Output

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. En una consola, aplique la regla udev ejecutando el comando udevadm como superusuario y vuelva a cargar los archivos de reglas y otras bases de datos. Para que udev conozca el nuevo archivo, solo tiene que ejecutar este comando una vez.

   Bash

   sudo udevadm control --reload
   

La máquina virtual del cliente podría encontrarse en una región diferente de la del recurso compartido de archivos. Otro motivo por el que la latencia es alta podría ser por la latencia causada por el cliente o la red.

• Ejecute la aplicación desde una máquina virtual que se encuentre en la misma región que el recurso compartido de archivos.
• En la cuenta de almacenamiento, revise las métricas de transacción SuccessE2ELatency y SuccessServerLatency a través de Azure Monitor en Azure Portal. Si hay una gran diferencia entre las métricas SuccessE2ELatency y SuccessServerLatency, significa que probablemente la latencia es debido a la red y el cliente. Consulte Métricas de transacción en la referencia de datos de supervisión de Azure Files.

Una posible causa es la ausencia de compatibilidad multicanal de SMB para recursos compartidos de archivos estándar. Actualmente, Azure Files solo admite un único canal para recursos compartidos de archivos estándar, por lo que solo hay una conexión desde la máquina virtual del cliente al servidor. Esta conexión única se fija a un único núcleo en la máquina virtual del cliente, por lo que el rendimiento máximo alcanzable desde una máquina virtual está limitado por un solo núcleo.

• En el caso de los recursos compartidos de archivos Premium, habilite SMB multicanal.
• Obtener una máquina virtual con un núcleo más grande puede ayudar a mejorar el rendimiento.
• Ejecutar la aplicación cliente desde varias máquinas virtuales aumentará el rendimiento.
• Siempre que sea posible, use las API de REST.
• En el caso de los recursos compartidos de archivos de Azure de NFS, está disponible nconnect. Consulta Mejora del rendimiento de los recursos compartidos de archivos de Azure de NFS con nconnect.

Una posible causa de un rendimiento lento es que el almacenamiento en caché está deshabilitado. El almacenamiento en caché puede ser útil si está accediendo a un archivo repetidamente. De lo contrario, puede ser una sobrecarga. Compruebe si usa la memoria caché antes de deshabilitarla.

Para comprobar si el almacenamiento en caché está deshabilitado, busque la cache= entrada.

Cache=none indica que el almacenamiento en caché está deshabilitado. Vuelva a montar el recurso compartido mediante el comando de montaje predeterminado o agregando explícitamente la cache=strict opción al comando mount para asegurarse de que el modo de almacenamiento en caché predeterminado o "estricto" está habilitado.

En algunos escenarios, la serverino opción de montaje puede hacer que el ls comando se ejecute stat en cada entrada de directorio. Este comportamiento produce una degradación del rendimiento cuando se muestra un listado de un directorio grande. Puede comprobar las opciones de montaje en la entrada /etc/fstab:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

También puede comprobar si se usan las opciones correctas ejecutando el sudo mount | grep cifs comando y comprobando su salida. A continuación se muestra un resultado de ejemplo:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

Si la cache=strict opción o serverino no está presente, desmonte y monte Azure Files de nuevo mediante la ejecución del comando mount desde la documentación. A continuación, vuelva a comprobar que la entrada /etc/fstab tiene las opciones correctas.

Es posible que esté experimentando una limitación y las solicitudes se envían a una cola. Puede comprobarlo aprovechando las métricas de Azure Storage en Azure Monitor. También puede crear alertas que le notifiquen si se está limitando un recurso compartido o está a punto de limitarse. Consulte Solución de problemas de Azure Files mediante la creación de alertas.

Asegúrese de que la aplicación está dentro de los objetivos de escalabilidad de Azure Files. Si usa recursos compartidos de archivos de Azure Estándar, considere la posibilidad de cambiar a Premium.

Se trata de un problema conocido con la implementación del cliente SMB en Linux.

• Distribuir la carga entre varias máquinas virtuales.
• En la misma máquina virtual, use varios puntos de montaje con la opción nosharesock y propague la carga entre estos puntos de montaje.
• En Linux, intente montar una opción nostrictsync para evitar forzar un vaciado de SMB en cada llamada a fsync. Para Azure Files, esta opción no afecta a la coherencia de los datos, pero puede producir metadatos de archivos obsoletos en la lista de directorios (comando ls -l). La consulta directa de metadatos de archivo mediante el comando stat devolverá los metadatos de archivo más recientes.

Falta de compatibilidad para las concesiones de directorios.

• Si es posible, evite usar aperturas o cierres excesivos en el mismo directorio en un período de tiempo breve.
• Para las máquinas virtuales de Linux, aumente el tiempo de espera de caché de entrada de directorio especificando actimeo=<sec> como opción de montaje. De forma predeterminada, el tiempo de espera es de 1 segundo, por lo que un valor mayor, como 30 segundos, podría ayudar.
• En el caso de las máquinas virtuales de CentOS Linux o Red Hat Enterprise Linux (RHEL), actualice el sistema a CentOS Linux 8.2 o RHEL 8.2. En cuanto a las distribuciones de Linux, actualice el kernel a 5.0 o una versión posterior.

Este problema puede producirse si no hay suficiente memoria caché en la máquina cliente para directorios grandes.

Para resolver este problema, ajuste el valor del Registro para permitir el DirectoryCacheEntrySizeMax almacenamiento en caché de listas de directorios más grandes en el equipo cliente:

• Ubicación: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• Nombre de valor: DirectoryCacheEntrySizeMax
• Tipo de valor: DWORD

Por ejemplo, puede establecerlo en 0x100000 y ver si el rendimiento mejora.

Puede que experimente un rendimiento lento cuando intente transferir archivos al servicio Azure Files. Si no tiene un requisito mínimo de tamaño de E/S específico, se recomienda que use 1 MiB como tamaño de E/S para disfrutar de un rendimiento óptimo.

Si el número de llamadas DirectoryOpen/DirectoryClose se encuentra entre las llamadas de API principales y no espera que el cliente realice esa cantidad de llamadas, el problema podría estar producido por el software de antivirus instalado en la máquina virtual del cliente de Azure.

La Actualización de la plataforma para Windows de abril incluye una corrección para este problema.

Cambios recientes en la configuración de SMB multicanal sin volver a montar.

• Después de cualquier cambio en la configuración de SMB multicanal de la cuenta o cliente SMB de Windows, tiene que desmontar el recurso compartido, esperar 60 segundos y volver a montar el recurso compartido para desencadenar el multicanal.
• Para el sistema operativo del cliente de Windows, genere una carga de E/S con una profundidad de cola alta, como PC = 8, por ejemplo, copiando un archivo para desencadenar SMB multicanal. En el caso del sistema operativo de servidor, SMB multicanal se desencadena con PC = 1, lo que significa en cuanto se inicie alguna ES en el recurso compartido.

Según el método de compresión exacto y la operación de descomprimir usada, las operaciones de descompresión pueden realizarse más lentamente en un recurso compartido de archivos de Azure que en el disco local. Esto suele deberse a que las herramientas de descompresión realizan varias operaciones de metadatos en el proceso de descompresión de un archivo comprimido. Para obtener el mejor rendimiento, se recomienda copiar el archivo comprimido del recurso compartido de archivos de Azure en el disco local, descomprimirlo allí y, a continuación, usar una herramienta de copia como Robocopy (o AzCopy) para copiarlo de nuevo al recurso compartido de archivos de Azure. Usar una herramienta de copia como Robocopy puede compensar el rendimiento reducido de las operaciones de metadatos en Azure Files con respecto al disco local mediante varios hilos para copiar datos en paralelo.

La notificación de cambio de un número alto de archivos en recursos compartidos de archivos puede producir latencias altas. Esto suele ocurrir con sitios web hospedados en recursos compartidos de archivos con una estructura de directorios anidada profunda. Un escenario típico es la aplicación web hospedada en IIS donde se configura la notificación de cambio de archivos para cada directorio en la configuración predeterminada. Cada cambio (ReadDirectoryChangesW) en el recurso compartido en el que está registrado el cliente envía una notificación de cambio desde el servicio de archivos al cliente, que usa recursos del sistema, y el problema empeora con el número de cambios. Esto puede dar lugar a una limitación de recursos compartidos y, por tanto, a una mayor latencia del lado cliente.

Para confirmarlo, puede usar las métricas de Azure en el portal.

1. En Azure Portal, vaya a la cuenta de almacenamiento.
2. En el menú de la izquierda, en Supervisión, seleccione Métricas.
3. Seleccione Archivo como el espacio de nombres de la métrica para el ámbito de la cuenta de almacenamiento.
4. Seleccione Transacciones como métrica.
5. Agregue un filtro para ResponseType y compruebe si alguna solicitud tiene un código de respuesta de SuccessWithThrottling (para SMB o NFS) o ClientThrottlingError (para REST).

• Si no se usa la notificación de cambio de archivo, deshabilite la notificación de cambio de archivo (preferido).

  • Deshabilite la notificación de cambio de archivo actualizando FCNMode.
  • Actualice el intervalo de sondeo del proceso de trabajo de IIS (W3WP) a 0 estableciendo HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds en el registro y reinicie el proceso W3WP. Para obtener más información acerca de esta configuración, vea las claves de registro comunes que utilizan muchas partes de IIS.

• Aumente la frecuencia del intervalo de sondeo de notificación de cambio de archivo para reducir el volumen.

  Actualice el intervalo de sondeo del proceso de trabajo de W3WP a un valor mayor (por ejemplo, 10 o 30 minutos) según sus necesidades. Establezca HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds en el del registro y reinicie el proceso W3WP.

• Si el directorio físico asignado del sitio web tiene una estructura de directorio anidada, puede intentar limitar el ámbito de las notificaciones de cambio de archivo para reducir el volumen de notificaciones. De forma predeterminada, IIS usa la configuración de los archivos Web.config en el directorio físico al que se asigna el directorio virtual, así como en los directorios secundarios de ese directorio físico. Si no desea usar archivos Web.config en directorios secundarios, especifique false para el allowSubDirConfig atributo en el directorio virtual. Se pueden encontrar más detalles aquí.

  Establezca la configuración del directorio allowSubDirConfig virtual de IIS en Web.Config para false excluir los directorios secundarios físicos asignados del ámbito.