Mejorando el rendimiento del storage: aplicar limitaciones y prioridades de IOPS a nivel de VM

julio 25, 2016 — por Albert Gris0

main

Assoc. Cat. VirtualitzacióConsultoríaVirtualizacionVMware

Mejorando el rendimiento del storage: aplicar limitaciones y prioridades de IOPS a nivel de VM

julio 25, 2016 — por Albert Gris0

Detectar latencias de acceso a disco (tanto escrituras como lecturas) en ciertos discos de nuestras VMs nos indica que tenemos un problema de rendimiento en nuestra SAN. Hay que tener presente que observar estos altos tiempos de respuesta son indicativos de que estemos sufriendo alguno de estos problemas, en cualquiera de los componentes que integran nuestra red de storage. Son pues la principal métrica a revisar si se sospechan malfuncionamientos en la capa de almacenamiento, pero hay que tener en cuenta que solo nos está informando de una consecuencia, no tienen porqué indicar en sí ninguna causa. Es importante este primer punto, pues una VM podría sufrir altas latencias de acceso pero ser otra VM o incluso otro componente de la SAN, como podría ser el switching o el cableado, el causante.

En este caso, supondremos el siguiente escenario: hemos observado altos niveles de latencia en ciertas LUNs de nuestra cabina y nos disponemos a analizar qué puede estar causándolos. Después de consultar alguna de nuestras herramientas de monitorización (o el mismo vCenter), observamos que durante el periodo en el que se ha observado el problema, cierta máquina ha estado consumiendo grandes cantidades de IOps. Este despunte en el consumo de IOps puede suponer una contención en la cabina, pues según su dimensionamiento o diseño quizás no pueda satisfacer esta demanda de órdenes y encole algunas. La generación de estas colas derivan en altos niveles de latencia que pueden impactar en el rendimiento de otras VMs que están en niveles “normales” de consumo.

En este caso es imprescindible discernir si este alto consumo de IOps en la máquina causante es debido a algún problema en alguno de sus servicios o si por el contrario es un comportamiento esperable y al que se debe dar respuesta. En este último caso, no queda otra que redimensionar o rediseñar nuestra SAN para poder responder a esa nueva demanda sin impactar ni a esa ni a otras cargas.

Sin embargo, este replanteamiento puede suponer un cierto tiempo en idearse y llevarse a cabo. Es por este motivo que hay que considerar acciones aplicables de manera casi inmediata para mitigar al máximo el impacto en el rendimiento de nuestro acceso a disco.

Además de mover las VMs más delicadas a LUNs con menos tiempos de latencia en un intento de salvaguardarlas, en general, tendremos dos niveles donde aplicar políticas QoS. O directamente en nuestra cabina, donde seguramente podremos aplicar alguna limitación en el consumo de IOps a nivel de LUN o host o a nivel de disco virtual (vmdk) en vSphere. Si nuestra cabina sirve a un entorno de virtualización, difícilmente nos servirá aplicar limitaciones a su nivel, pues generalmente solo podremos discernir entre hosts, cuando nuestro causante es solo una VM. Sí nos serviría si, por ejemplo disponemos de un entorno físico-virtual y la máquina causante es física. Ahí sí que directamente podremos aplicar limitaciones de consumo de IOps en el host causante.

De todos modos, volvamos a suponer que nuestra causante es una VM. De ahí se nos abren 2 posibilidades: ayudarnos de Storage IO Control (SIOC) o simples shares a nivel de acceso de disco para priorizar las máquinas más críticas asumiendo que afrontaremos escenarios de contención, o directamente aplicar un límite de consumo de IOps sobre la máquina causante. No se trata de acciones suplementarias, ya que podríamos llegar a complementarlas.

Mejorando el rendimiento del storageEl primer caso consistiría en dar más prioridad con shares a las máquinas más sensibles a latencias. Hay que tener mucho en cuenta la diferencia entre usar SIOC o no, pues puede ser definitivo para solventar nuestro problema. Queda muy claro su funcionamiento en este post de Duncan Epping (recomiendo ver video). Tomando su ejemplo para explicarlo rápidamente, dados 2 hosts, el primero con 2 VMs y el segundo con 1, con todas las VMs con discos en el mismo datastore, la suma de todos los shares será 1500+500+500=2500 y por tanto, el porcentaje de capacidad de acceso a disco para la VM A (1500 shares) será 1500/2500*100=60%.

Sin SIOC en cambio, no se toma como acumulado de shares el agregado de los configurados en las VMs que acceden al datastore, sino simplemente los shares que tengan las VMs de cada host. En este caso, para el primer host será 1500+500=2000, y el porcentaje que le quedaría a la VM A sería 1500/2000*100=75%. Como hay dos hosts accediendo a ese datastore, cada uno tendrá el 50% de prioridad, al 75% que le tocaba a la VM A le quedará un 37,5% (38%). Lo más curioso es el caso de la VM C. Como está sola en el segundo host, todo lo que pueda dar ese host (50%) está dedicado para ella.

La paradoja de no usar SIOC es que habiendo dado a la VM A 1500 shares y a la C 500, la C resulta teniendo más prioridad que la A por estar sola en un host. SIOC nos ayuda a balancear de manera más coherente y transversal entre ESXis estas prioridades de acceso a disco. Además, SIOC solo activa estas políticas de QoS en el datastore si este llega a un determinado umbral de milisegundos de latencia.

La otra opción sería usar directamente limitaciones de IOps. Estas se aplican a nivel de vmdk. La operativa sería la descrita en esta KB. Paramos máquina, vamos a “Edit settings”, y a cada vmdk le indicamos los IOps máximos al que lo queremos limitar. Hay que tener mucho en cuenta que la limitación que tendrá una máquina será la suma de las limitaciones que tengan sus vmdks. Supongamos una VM con dos vmdk al mismo datastore. Si limitamos un vmdk a 500 y otro a 500, la VM tendrá como límite 1000 IOps, de manera que habrá que vigilar como distribuimos estas configuraciones. Algunas veces, hará falta un reload del fichero vmx para ver aplicada la limitación pues sino, no funcionará.

Como última consideración al aplicar uno de estos límites, hay que revisar qué versión de vSphere estamos usando, pues a partir de 5.5 se usa un tamaño de IO distinto a 5.1. El impacto que puede suponer este caso es que si nuestra VM usa un tamaño de IO mayor que 32kB, un IO a nivel de Guest supondría más de un IO para el hipervisor.

Lidiar con este tipo de problemáticas resulta tedioso en la mayoría de los casos: el escenario ideal es alinear las configuraciones desde las aplicaciones involucradas en la VM hasta la cabina pasando por el hipervisor, de manera que se tenga una imagen fiel de los datos que sacamos de la monitorización. Estos procedimientos que he relatado solo intentan guiar en casos suficientemente comunes en cualquier infraestructura, cada acción a tomar en un caso de contención debería ser siempre contrastada con datos de monitorización.

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

1 × 1 =