Optimización del rendimiento

En esta página se explica cómo puedes optimizar el rendimiento de Google Cloud NetApp Volumes.

Antes de empezar

Antes de hacer cambios en tus volúmenes para optimizar el rendimiento, consulta las consideraciones sobre el rendimiento.

Ajustar la configuración del volumen

Para optimizar el rendimiento, puede ajustar los siguientes ajustes de volumen:

• Aumentar la capacidad del volumen: puedes aumentar la capacidad de tu volumen de nivel de servicio Premium, Extreme o Standard para mejorar el rendimiento máximo del volumen. En el caso de los volúmenes de nivel de servicio Flexible, aumenta la capacidad de los grupos de almacenamiento.

• Cambiar a un nivel de servicio superior: puedes cambiar el nivel de servicio Premium de tus volúmenes al nivel Extreme para mejorar el rendimiento. Te recomendamos que asignes el volumen a otro grupo de almacenamiento con un nivel de servicio diferente.

Aumentar la capacidad de volumen y mejorar los niveles de servicio no interrumpe las cargas de trabajo de E/S en proceso en el volumen y no afecta al acceso al volumen de ninguna manera.

Ajustar el cliente

Para mejorar el rendimiento, puedes ajustar los siguientes ajustes en el cliente:

• Colocar clientes en el mismo sitio: la latencia se ve afectada directamente por las funciones y la ubicación del cliente. Para obtener los mejores resultados, coloca el cliente en la misma región que el volumen o lo más cerca posible. Prueba el impacto zonal comprobando la latencia de un cliente en cada zona y usa la zona con la latencia más baja.

• Configurar el ancho de banda de la red de Compute Engine: las funciones de red de las máquinas virtuales de Compute Engine dependen del tipo de instancia que se utilice. Por lo general, las instancias más grandes pueden generar un mayor rendimiento de red. Te recomendamos que selecciones una máquina virtual cliente con una capacidad de ancho de banda de red adecuada, que elijas la interfaz de red NIC virtual de Google (gVNIC) y que habilites el rendimiento Tier_1. Para obtener más información, consulta la documentación de Compute Engine sobre el ancho de banda de red.

• Abrir varias sesiones TCP: si tu aplicación requiere un alto rendimiento, puedes saturar la sesión única del protocolo de control de transmisión (TCP) que subyace a una sesión normal de NFS y SMB. En estos casos, aumenta el número de sesiones TCP que usan tus conexiones NFS y SMB.

  Usa una de las siguientes pestañas para ajustar tu cliente en función del tipo de cliente:

  Linux

  Tradicionalmente, un cliente NFS usa una sola sesión TCP para todos los sistemas de archivos montados en NFS que comparten un endpoint de almacenamiento. La opción de montaje nconnect te permite aumentar el número de sesiones TCP admitidas hasta un máximo de 16.

  Para aprovechar al máximo nconnect, te recomendamos que sigas estas prácticas recomendadas para ajustar el tipo de cliente Linux:

  • Aumentar el número de sesiones TCP con nconnect: cada sesión TCP adicional añade una cola de 128 solicitudes pendientes, lo que mejora la simultaneidad potencial.

  • Definir el parámetro sunrpc.max_tcp_slot_table_entries: sunrpc.max_tcp_slot_table_entries es un parámetro de ajuste a nivel de conexión que puedes modificar para controlar el rendimiento. Recomendamos definir sunrpc.max_tpc_slot_table_enteries en 128 solicitudes o por conexión y no superar las 10.000 ranuras para todos los clientes de NFS de un mismo proyecto que se conecten a volúmenes de NetApp. Para definir el parámetro sunrpc.max_tcp_slot_table_entries, añádelo al archivo /etc/sysctl.conf y vuelve a cargar el archivo de parámetros con el comando sysctl -p.

  • Ajusta el valor máximo admitido por sesión a 180: a diferencia de NFSv3, los clientes de NFSv4.1 definen la relación entre el cliente y el servidor en sesiones. Aunque NetApp Volumes admite hasta 128 solicitudes pendientes por conexión con NFSv3, NFSv4.1 está limitado a 180 solicitudes pendientes por sesión. Los clientes de Linux NFSv4.1 tienen un valor predeterminado de 64 max_session_slots por sesión, pero puedes ajustar este valor según sea necesario. Te recomendamos que cambies el valor máximo admitido por sesión a 180.

    Para ajustar max_session_slots, crea un archivo de configuración en /etc/modprobe.d. Asegúrate de que no aparezcan comillas (" ") en línea. De lo contrario, la opción no se aplicará.

    $ echo "options nfs max_session_slots=180" > /etc/modprobe/d/nfsclient/conf
    $ reboot
    
    Use the systool -v -m nfs command to see the current maximum in use
    by the client. For the command to work, at least one NFSv4.1 mount
    must be in place.
    
    $ systool -v -v nfs
    {
    Module = "nfs"
    …
    Parameters:
    …
    Max_session_slots = "63" <-
    …
    }
    

  En el siguiente gráfico de comparación de NFS nconnect se muestra el impacto que puede tener la configuración de nconnect en una carga de trabajo de NFS. Esta información se ha obtenido con Fio y los siguientes ajustes:

  • Carga de trabajo de lectura al 100 %

  • Tamaño de bloque de 8 KiB en un único volumen

  • Máquina virtual n2-standard-32 con el SO Red Hat 9

  • Conjunto de trabajo de 6 TiB

  Al usar un valor de nconnect de 16, el rendimiento fue cinco veces mayor que cuando no estaba habilitado.

  

  Windows

  En el caso de los clientes basados en Windows, el cliente puede usar SMB Multichannel con Receive Side Scaling (RSS) para abrir varias conexiones TCP. Para conseguir esta configuración, tu máquina virtual debe tener un adaptador de red asignado que admita RSS. Te recomendamos que definas RSS en cuatro u ocho valores. Sin embargo, cualquier valor superior a uno debería aumentar el rendimiento.

  En el siguiente gráfico se muestra la diferencia que puede suponer la configuración de RSS en una carga de trabajo de una pyme. Esta información se ha obtenido con Fio y los siguientes ajustes:

  • Carga de trabajo de lectura al 100 %

  • Tamaño de bloque de 8 KiB en un único volumen

  • Una sola máquina virtual n2-standard-32 que ejecute un SO Windows 2022

  • Conjunto de trabajo de 6 TiB

  Se ejecutaron ocho trabajos en los que solo cambiaba la opción RSS del cliente SMB entre las ejecuciones de prueba. Al usar valores de RSS de 4, 8 y 16, el rendimiento se duplicó en comparación con el uso del valor 1. Cada instancia de RSS se ejecutó nueve veces con un parámetro numjobs de 8. El parámetro iodepth se incrementó en cinco en cada ejecución hasta que se alcanzó el rendimiento máximo.

  

Siguientes pasos

Consulta información sobre los grupos de almacenamiento.