Optimización del rendimiento en VM Linux de las series Lsv3, Lasv3 y Lsv2

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux con un estado de finalización del servicio (EOL). Tenga en cuenta su uso y planifique en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida de CentOS.

Se aplica a: ✔️ Máquinas virtuales Linux ✔️ Conjuntos de escalado uniformes

Las máquinas virtuales de Azure (VM de Azure) de las series Lsv3, Lasv3 y Lsv2 admiten varias cargas de trabajo de una amplia gama de sectores y aplicaciones que necesitan una gran cantidad de E/S y un elevado rendimiento en el almacenamiento local. La serie L es ideal para macrodatos, SQL, bases de datos NoSQL, almacenamiento de datos y bases de datos transaccionales de gran tamaño, como Cassandra, MongoDB, Cloudera y Redis.

Hay varias compilaciones disponibles de Azure Marketplace debido al trabajo con asociados en Linux. Estas compilaciones están optimizadas para el rendimiento de las series Lsv3, Lasv3 y Lsv2. Las compilaciones disponibles incluyen las siguientes y versiones posteriores de:

• Ubuntu 16.04
• RHEL 8.0 y clones, incluidos CentOS, Rocky Linux y Alma Linux
• Debian 9
• SUSE Linux 15
• Oracle Linux 8.0

En este artículo se proporcionan consejos y sugerencias para asegurarse de que las cargas de trabajo y las aplicaciones alcanzan el máximo rendimiento diseñado en las máquinas virtuales.

Arquitectura del conjunto de chips AMD EPYC™

Las VM de las series Lasv3 y Lsv2 usan procesadores de servidor AMD EYPC™ basados en la microarquitectura Zen. AMD desarrolló Infinity Fabric (IF) para EYPC™ como interconexión escalable para su modelo NUMA que se puede usar para las comunicaciones en la placa, en el paquete y en comunicaciones de varios paquetes. En comparación con QPI (Quick-Path Interconnect) y UPI (Ultra-Path Interconnect), que se usan en los procesadores de placa monolítica moderna de Intel, la arquitectura de muchas placas pequeñas de NUMA de AMD aporta beneficios de rendimiento, por un lado, y diferentes retos por el otro. Los efectos reales de las restricciones de ancho de banda y latencia de memoria pueden variar según el tipo de cargas de trabajo que se ejecuten.

Sugerencias para maximizar el rendimiento

• Si está cargando un sistema operativo invitado Linux personalizado para la carga de trabajo, tenga en cuenta que las redes aceleradas están desactivadas de manera predeterminada. Si piensa habilitar las redes aceleradas, hágalo en el momento de la creación de las máquinas virtuales para mejorar el rendimiento.
• Para obtener un rendimiento máximo, ejecute varios trabajos con una gran profundidad de cola por dispositivo.
• Evite mezclar los comandos de administrador de NVMe (por ejemplo, la consulta de información SMART de NVMe, etc.) con comandos de E/S de NVMe durante las cargas de trabajo activas. Los dispositivos NVMe de las series Lsv3, Lasv3 y Lsv2 están respaldados por la tecnología NVMe Direct de Hyper-V, que se activa en "modo de baja velocidad" cada vez que hay comandos de administrador de NVMe pendientes. Los usuarios de las series Lsv3, Lasv3 y Lsv2 podrían experimentar una importante caída en el rendimiento de E/S de NVMe si esto sucede.
• No se recomienda que los usuarios de Lsv2 dependan de la información de NUMA del dispositivo (todo 0) que se notifica en la VM para las unidades de datos para decidir la afinidad de NUMA para sus aplicaciones. La manera recomendada de mejorar el rendimiento es distribuir las cargas de trabajo entre las CPU, si es posible.
• La profundidad máxima de cola admitida por cada par de cola de E/S para un dispositivo NVMe de una VM de las series Lsv3, Lasv3 y Lsv2 es 1024. Se recomienda a los usuarios de las series Lsv3, Lasv3 y Lsv2 que limiten sus cargas de trabajo de pruebas comparativas (sintéticas) a una profundidad de cola de 1024 o inferior para evitar que se desencadenen estados de cola completa, que pueden reducir el rendimiento.
• Se obtiene el mejor rendimiento cuando se realiza la E/S directamente en cada uno de los dispositivos NVMe sin formato que no tienen particiones, sistemas de archivos, sin configuración de RAID, etc. Antes de iniciar una sesión de pruebas, asegúrese de que la configuración se encuentra en un estado limpio/nuevo ejecutando blkdiscard en cada uno de los dispositivos NVMe. Para obtener el rendimiento más coherente durante las pruebas comparativas, se recomienda preacondicionar los dispositivos NVMe antes de realizar pruebas mediante la emisión de escrituras aleatorias en todos los LBA de todos los dispositivos dos veces como se define en la Especificación de prueba de rendimiento empresarial de almacenamiento de estado sólido de SNIA.

Uso de almacenamiento local de NVMe

El almacenamiento local en el disco de NVMe de 1,92 TB de todas las VM de las series Lsv3, Lasv3 y Lsv2 es efímero. Durante un reinicio estándar correcto de la máquina virtual, se conservarán los datos del disco local de NVMe. No se conservarán los datos en el NVMe si la máquina virtual se vuelve a implementar, se desasigna o se elimina. No se conservan los datos si algún otro problema provoca un error en el estado de la VM o el hardware en que se ejecuta. Cuando se presenta este escenario, se borran de forma segura los datos en el host antiguo.

También hay casos en que la VM tenga que moverse a otra máquina host; por ejemplo, durante una operación de mantenimiento planeado. Las operaciones de mantenimiento planeado y algunos errores de hardware pueden anticiparse con los eventos programados. Use Scheduled Events para mantenerse al tanto de todas las operaciones de recuperación y mantenimiento previstas.

En el caso de que un evento de mantenimiento planeado requiera que la VM se vuelva a crear en un nuevo host con discos locales vacíos, los datos se deben volver a sincronizar (de nuevo, borrando de forma segura los datos del host antiguo). Este escenario ocurre porque las VM de las series Lsv3, Lasv3 y Lsv2 no admiten actualmente la migración en directo en el disco local de NVMe.

Existen dos modos de realizar el mantenimiento planeado.

Mantenimiento controlado por el cliente de máquina virtual estándar

• La máquina virtual se mueve a un host actualizado durante un período de 30 días.
• Los datos del almacenamiento local de las series Lsv3, Lasv3 y Lsv2 pueden perderse, por lo que se recomienda hacer copias de seguridad de los datos antes del evento.

Mantenimiento automático

• Se produce si el cliente no ejecuta el mantenimiento controlado por el cliente o debido a procedimientos de emergencias, como un evento de seguridad de día cero.
• Diseñado para conservar los datos del cliente, pero hay un pequeño riesgo de bloqueo o reinicio de la VM.
• Los datos del almacenamiento local de las series Lsv3, Lasv3 y Lsv2 pueden perderse, por lo que se recomienda hacer copias de seguridad de los datos antes del evento.

Para los próximos eventos de servicio, utilice el proceso de mantenimiento controlado para seleccionar un momento más conveniente para la actualización. Antes del evento, haga una copia de seguridad de los datos en Premium Storage. Una vez completado el evento de mantenimiento, puede devolver los datos al almacenamiento de NVMe local de las VM Lsv3, Lasv3 y Lsv2 actualizadas.

Entre los escenarios que mantienen los datos en discos NVMe locales están los siguientes:

• La máquina virtual se está ejecutando y se encuentra en buen estado.
• La máquina virtual se reinicia in situ (por usted o Azure).
• La máquina virtual se pausa (detenida sin desasignación).
• La mayoría de las operaciones de servicio de mantenimiento planeado.

Los escenarios que borran de forma segura los datos para proteger al cliente incluyen:

• La máquina virtual se vuelve a implementar, se detiene (desasigna) o la elimina el usuario (usted).
• La máquina virtual pasa a un estado incorrecto y es necesario recurrir a otro nodo debido a un problema de hardware.
• Varias operaciones de servicio de mantenimiento planeado requieren que la VM se reasigne a otro host para el servicio.

Preguntas más frecuentes

Las siguientes son preguntas frecuentes sobre estas series.

¿Cómo se puede iniciar la implementación de VM de la serie L?

Al igual que cualquier otra máquina virtual, use el Portal, la CLI de Azure o PowerShell para crear una máquina virtual.

¿Puede un único error de disco NVMe provocar un error en todas las VM del host?

Si se detecta un error de disco en el nodo de hardware, el hardware está en estado de error. Cuando se produce este problema, se anula automáticamente la asignación de todas las máquinas virtuales del nodo y estas se trasladan a un nodo correcto. En el caso de las VM de las series Lsv3, Lasv3 y Lsv2, este problema significa que los datos del cliente del nodo con errores también se borran de forma segura. El cliente debe volver a crear los datos en el nuevo nodo.

¿Es necesario cambiar la configuración de blk_mq?

RHEL/CentOS 7.x usa automáticamente blk_mq para los dispositivos NVMe. No se requieren hay cambios en la configuración o los parámetros.

Pasos siguientes

Consulte las especificaciones de todas las máquinas virtuales optimizadas para el rendimiento del almacenamiento en Azure