En algunos casos se puede producir que la configuración por defecto del Round Robin (método de selección de ruta de envío y recepción de datos) de IOPS de los hosts VMware ESX, que es de 1000 IOPS, provoque algunos problemas de latencia en su conexión con la SAN. Este parámetro indica al ESX que en operaciones de lectura/escritura en la SAN, cuando tiene varios caminos HBA, envíe 1000 IOS por un canal, espere a enviar esos 1000 y luego envíe otros 1000 por otro canal. Esto puede provocar problemas de latencia, por lo que en estos casos se recomienda dejar este parámetro a valor 1, de forma que enviará 1 IO por un canal y 1 IO por otro canal, de forma que la espera es inferior, al tener que esperar solo el envío de 1 IO. Explicamos en este artículo cómo modificar el parámetro anterior para dejarlo a valor 1.
- Escenario inicial, requisitos para mejora el rendimiento de lectura/escritura de un host VMware ESX en un entorno sobre SAN.
- Modificar valor del parámetro para que solo envíe un IO por cada petición a cada canal.
Escenario inicial, requisitos para mejora el rendimiento de lectura/escritura de un host VMware ESX en un entorno sobre SAN
Desde la web oficial de VMware, en uno de sus artículos, nos habla precisamente de este parámetro y sus posibles consecuencias:
Cambiar el valor predeterminado de los IOPS a un valor inferior con la opción Round Robin de la Política de selección de ruta es una configuración de ajuste de rendimiento y puede ayudar a equilibrar la carga en los procesadores de almacenamiento y las rutas de HBA en una matriz de almacenamiento.
Con IOPS = 1000, se envían 1000 I/Os por una ruta antes de alternar a la siguiente ruta. Esto podría generar un escenario en el que todos los LUN podrían enviar 1000 I/Os por la misma ruta al mismo tiempo, dejando un procesador de almacenamiento en la matriz que procesa las E/S (I/O), mientras que los otros están en estado inactivo.
Al alternar la ruta después de una I/O, obtendrá un mejor equilibrio de E/S en las rutas y, por lo tanto, en los procesadores de almacenamiento. Se obtendría un equilibrio uniforme de E/S a través de los caminos. Si se produce saturación, su duración sería muy corta y le da al proceso de almacenamiento más tiempo para procesar la E/S.
En primer lugar necesitaremos disponer de un sistema de virtualización con VMware ESX, con uno o varios host ESX. Y estos estarán conectados al sistema de almacenamiento SAN mediante tarjeta HBA de fibra. Normalmente estas tarjetas suelen tener dos paths (rutas) por cada una. Cada cable suele ir conectado a un switch de fibra diferente o bien a un puerto de la SAN de controladoras diferentes. De esta forma se consigue que los host ESX puedan enviar y recibir información del sistema de almacenamiento por dos caminos diferentes y casi simultáneamente.
Por lo tanto dispondremos de un sistema de almacenamiento SAN conectado por fibra directamente a los servidores VMware ESX o bien a través de switchs de fibra. Antes de hacer cambios en el parámetro que explicaremos a continuación conviene comprobar en la especificaciones de cada SAN qué IOPS de los ESX son los recomendamos para reducir al máximo la latencia.
Recomendamos que si se dispone de varios host ESX con clúster vCenter, se deje uno de ellos sin máquinas virtuales, migrándolas al resto de hosts. Una vez que esté sin máquinas se le aplica el procedimiento que explicamos a continuación, se le migra una única máquina virtual (a ser posible que no sea crítica) y se comprueba que todo funciona correctamente. Cuando se haga la comprobación se podrán migrar el resto de máquinas virtuales.
Necesitaremos disponer de usuario y contraseña de acceso a los host VMware ESX con permisos suficientes para acceso por SSH y poder ejecutar comandos en la consola. Además, deberemos activar el acceso SSH a cada host, como indicamos en este artículo:
Modificar valor del parámetro para que solo envíe un IO por cada petición a cada canal
El proceso que explicaremos a continuación puede hacerse online (en caliente), sin detener el servidor ESX, sin reiniciarlo e incluso sin apagar las máquinas virtuales que contenga. Aunque, por seguridad, es recomendable migrar las máquinas virtuales a otro host o si solo disponemos de un host ESX sería conveniente apagar las máquinas virtuales antes de realizar el proceso. Sobre todo para probar con una de ellas, la menos crítica y verificar que el cambio se ha aplicado correctamente.
Abriremos una sesión de SSH con PuTTY o cualquier otro cliente, nos conectaremos al servidor ESX:
Una vez conectados al ESX ejecutaremos el siguiente comando para que nos muestre la lista de controladoras HBA y su UID (identificador), así como el valor del parámetro IOS:
esxcli storage nmp device list
En la imagen siguiente podemos ver el resultado de la ejecución de este comando. Donde [1] será la HBA uno, con su identificador naa.xxx y los iosps, por defecto a 1000 y la [2] HBA dos:
Para cambiar el valor 1000 del parámetro ips de cada controladora HBA ejecutaremos el siguiente comando:
|
1 |
for i in `esxcfg-scsidevs -c |awk '{print $1}' | grep naa.xxx`; do esxcli storage nmp psp roundrobin deviceconfig set --type=iops --iops=1 --device=$i; done |
Sustituyendo «naa.xxx» por el identificador de la controladora y ejecutando este comando tantas veces como controladoras HBA haya, en nuestro caso dos. Y manteniendo las comillas tal y como se muestra en el comando anterior.
Si volvemos a ejecutar el comando inicial, veremos que en todas las controladoras HBA el valor de iops ha cambiado a 1:
Por lo que el servidor ESX habrá quedado bien configurado. Ahora podremos ir migrando máquinas a este ESX y comprobando que funcionan correctamente. Según el artículo oficial de WMware, y en función de la SAN, el rendimiento puede mejorar entre un 10 y un 20% en determinadas circunstancias de lectura y escritura de datos.
