Cuando uno trabaja con almacenamiento compartido, en ciertas circunstancias nos veremos en situaciones en que se presentará cierto grado de latencia en el acceso al Storage.
Esta latencia puede deberse a diversos factores. Uno de estos factores, y sobre el cual hablaremos hoy, es del encolamiento (queuing) en los hosts ESX/ESXi y en el arreglo de Storage.
En general hay 2 tipos de encolamiento que determinan como las máquinas virtuales debieran ser distribuidas entre los hosts y datastores, asi como tambien cuantas LUNs (o volumenes VMFS) son necesarios para obtener una performance aceptable
- Encolamiento de comandos (command queueing) en el host
- Encolamiento de comandos (command queueing) en el arreglo de Storage.
Ambos tipos de encolamiento generan un aumento en la latencia
Encolamiento de comandos en el Host
Los drivers de los dispositivos SCSI (como una tarjeta HBA) tienen un parametro configurable llamado LUN Queue Depth (profundidad de cola de LUN). Este parametro determina cuantos comandos pueden estar activos al mismo tiempo en una LUN determinada. El valor por defecto en vSphere 4.x es de 32.
El encolamiento en los hosts ESX/ESXi ocurre primero en la cola de la LUN asociada con el dispositivo SCSI. Uno o más MV en el mismo host, generando I/O a la misma LUN, deben compartir la cola de la LUN o LUN queue.
Si un host ESX/ESXi genera más comandos a una LUN que el valor configurado en el parametro LUN queue depth, los comandos que exceden este paramentro son encolados en el VMkernel, lo cual aumenta la latencia en el acceso al Storage. Si monitoreamos la performance de nuestro host a traves de los graficos de performance, o utilizando ESXTOP/RESXTOP, veremos que aumenta la latencia del VMKernel (Kernel Latency).
Encolamiento de comandos en el Arreglo de Storage
Si multiples hosts ESX/ESXi comparten la misma LUN, los comandos SCSI a esa LUN desde todos los hosts son procesados por el mismo Storage Processor en un arreglo Activo-Pasivo, o por un grupo de Storage Processors en un arreglo Activo-Activo
Dependiendo del fabricante y del modelo del Arreglo de Storage, los Storage Processors pueden estár configuradas con una cola por LUN, o podria haber una cola por cada disco.
Si el arreglo de Storage tiene una cola por LUN, exceder este valor resultará en latencias más altas. Si un Storage Processor no tiene una cola por LUN, envia los comandos directamente a los discos.
Sin importar de que forma esten configuradas las colas en el arreglo, un numero de hosts ESX/ESXi enviando comandos a la misma LUN compartiran la misma cola o colas en el arreglo. Si el numero de los comandos activos a la LUN es muy alto, los comandos comienzan a ser encolados resultando en latencias más altas. Si monitoreamos la performance de nuestro host a traves de los graficos de performance, o utilizando ESXTOP/RESXTOP, veremos que aumenta la latencia del dispositivo fisico (Physical Device Latency).
Reduciendo la latencia
Para reducir la latencia en los hosts, asegurate de que la suma de comandos activos de todas las MV, en su conjunto no excedan el valor configurado como LUN Queue Depth. Este escenario puede evitarse de dos formas:
- Aumentando el valor de LUN Queue Depth, o mover las MV a otra LUN
- Trabajar con el administrador del Storage para asegurarse de que cada LUN está compuesta de multiples discos fisicos
Para reducir la latencia en el Arreglo de Storage, reducir el numero maximo de comandos I/O dirigidos a la LUN compartida.
- Mover las MV a otra LUN
- El numero maximo de comandos I/O que el arreglo es capaz de manejar varia de la configuración del arreglo.
Aumentar el valor de LUN Queue Depth
El parametro LUN Queue Depth determina cuantos comandos serán aceptados por la HBA y procesará por LUN.
Cuando se habla de mejorar la performance de I/O en una infraestructura virtual, una de las recomendaciones más comunes es cambiar el valor del parametro LUN Queue Depth. No obstante, no se debe olvidar que este parametro es solo una parte del path I/O. Cada uno de los componentes de Software y Hardware que forman los paths de I/O pueden tener un gran impacto en la performance de I/O. Es imprescindible que se analice la infraestructura de almacenamiento como un todo, y no solo en forma individual a nivel de host ESX/ESXi.
En la mayoria de los casos, los ambientes virtuales se verán más beneficiados con un diseño balanceado de almacenamiento, en vez de cambiar los valores por defecto de las colas. De todas maneras, habrá casos en que aun sea necesario modificar estos parametros, en casos en que un diseño adecuado no sea suficiente para obtener una buena performance de I/O.
En caso de decidir aumentar el valor del parametro LUN Queue Depth, esto puede ser de poca o ninguna utilidad si uno no configura además el parametro "Disk.SchedNumReqOutstanding". Este parametro debiera estar alineado con el parametro Queue Depth, debido a que si el parametro "Disk.SchedNumReqOutstanding" cuenta con un valor más bajo que el parametro Queue Depth, el primer valor será el numero maximo de comandos que son emitidos simultaneamente desde el kernel de ESX/ESXi a la LUN. Por ejemplo, si se configura el parametro Queue Depth en 64, y el parametro "Disk.SchedNumReqOutstanding" en 32, solo 32 comandos I/O serán emitidos en forma simultanea a la LUN, en vez de los 64 configurados en el parametro Queue Depth. Se considera una buena practica mantener ambos parametros con el mismo valor.
Si se desea cambiar estos parametros, pueden revisar el KB 1267 desde el sitio de VMware, el cual contiene las instrucciones para cambiar estos parametros en HBA's QLogic y Emulex.
0 comentarios:
Publicar un comentario