Buenos días!


En esta ocasión me gustaría tratar con vosotros un tema especialmente importante. Referente al acceso a los datastores y por ende al comportamiento de las máquinas virtuales que viven en ellos.

Toma mayor importancia si en nuestro caso se trata de un clúster de acceso compartido activo/activo como viene a ser vSphere de VMware.

En un entorno al uso tendremos varios datastores, que bien podrán tener origen en el almacenamiento local de los servidores físicos o en LUs (Logical Units) procedentes de un almacenamiento compartido como puede ser una SAN/NAS sirviendo por uno o varios protocolos como iSCSI/FC/NFS.

En estos datastores vivirán las máquinas virtuales del entorno, muchas veces compartiendo varias máquinas un mismo datastore y otras donde habremos optado por dar uso en exclusividad a una máquina virtual (o incluso a uno de sus discos duros virtuales en concreto) de ese datastore.

Este último punto dependerá de qué rol desempeñen esas máquinas y en función de sus requisitos de acceso a disco las aglutinaremos o disgregaremos. Pudiendo tener discos virtuales de una misma máquina soportados por diferentes tipos de RAID (normalmente 5, 6 1+0), tipos de disco (SATA/SAS/SSD) e incluso velocidad (10K, 15K rpm).

Es conocido que no va a demandar el mismo acceso a disco una máquina que en exclusiva desempeñe la función de Controlador de Dominio que el disco de datos de una máquina corriendo las BBDD corporativas de la empresa.

¿Y qué pasa cuando el rendimiento del entorno se degrada? ¿Cómo podemos diagnosticar la salud del acceso al almacenamiento? ¿Tenemos datos de fácil interpretación que nos puedan ayudar?

La respuesta a priori es SI A TODO 😉

Para ayudar en la explicación y evitar tanto ladrillo de texto me apoyaré en unas gráficas tomadas para este propósito.

Detonantes comunes pueden ser:

  • La visualización de Alarmas en el propio vCenter avisando de un incremento de las latencias de acceso a disco de uno o varios datastores. 
  • También la aparición de Eventos a nivel de Clúster y/o host avisando del incremento de la latencia a un dispositivo naa.xxxxxxxx
  • Presencia de Hidden Snapshots o Consolidate Helper-0 snapshot

Tras haber recibido alguno de los chivatazos ahora comentados es momento de ahondar un poco más en la causa de esos eventos.

El primer paso dado en esta ocasión es ver que está haciendo nuestra cabina, cual es su comportamiento. De ahí iremos tirando del hilo hasta dar con el causante. En el caso que nos ocupa aprovecharemos el entorno de administración de la cabina que nos ofrece de série una potente herramienta de recolección y visualización de datos de uso/rendimiento. Veamos unas capturas ilustrativas.

IO+CTL0.png

Gráfica 1

La intención de la Gráfica 1 es mostrar el volúmen de acceso des de los hosts hacia la cabina teniendo en cuenta los puertos de una de las dos controladoras. Con lo que hay que temer que la otra controladora aportará otro tanto en volúmen de acceso sumando lecturas y escrituras.

Se ve claramente como a partir de las 11:52 decrece notablemente la cantidad de accesos demandados. Coincidiendo con el cese de la contingencia provocada para estresar el entorno. Veamos la siguiente…

LUN0004-pre.png

Gráfica 2

Desgranando la Gráfica 2, veremos por donde está viniendo la carga soportada por la cabina. Ahora nos centramos a nivel de LU (Logical Unit). Muy claramente se muestra que la LUN0004 tiene un volúmen de acceso muy superior al resto de LUs. Vemos también como cesa y vuelve la carga hacia esta con el arranque y cese del acceso provocado para estresar la LU.

Ahora bien, ¿qué tenemos dentro de esa LU? ¿Qué provoca ese comportamiento?

Si como hemos comentado al principio del escrito, se da el caso que solo hubiera una máquina virtual, pronto tendríamos identificado el causante. Pero no suele ser así, pues es habitual compartir un Datastore con más de una máquina virtual. Así que tendremos que apoyarnos en las gráficas de Performance del entorno vSphere para seguir la pista al evento.

Datastore.png

Gráfica 3

De todas las máquinas presentes en la Gráfica 3 queda claro cual de ellas está provocando ese alto nivel de acceso tanto en lectura hacia ese datastore/LU. 

Por último nos tocará averiguar qué proceso de esa máquina causa ese comportamiento, aislarlo y verificar si es ese su comportamiento normal o hay algo que no va fino en su interior. En este caso se trataba de un bug del UI (User Interface) de una aplicación instalada en esa máquina virtual.

En base a la conclusión final de cada posible causante en uno u otro entorno, podremos apoyarnos en lo descubierto para hacer la toma de decisiones.

  • Puede ser que tal vez baste con mover una máquina de un datastore a otro para aliviar ese estrés.
  • Revisar configuraciones en relación a la conectividad entre los hosts y cabina para descartar una mal balanceo de las LU, una mala configuración o gestión de la memoria caché, etc.
  • Puede que tengamos que seguir investigando para localizar si tenemos un cuello de botella en el medio, sea cobre para iSCSI o fibra óptica para FC.
  • Que el cuello de botella esté en la cabina y sea hora de ampliar la cantidad de discos para conseguir mayor rendimiento y poder asumir la carga.

¿Qué os ha parecido el uso de estas funciones que nos vienen de serie para localizar la contingencia?

Espero que os haya gustado la entrada y hasta la próxima.

Saludos,

Ivan

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Post Relacionados: