Monitorizando la latencia de los discos en VMware ESX/ESXi

Respecto al tema de la latencia de acceso a disco, simplemente añadir un pequeño apunte fruto de la experiencia personal.

En el caso de los HP ProLiant que cuenten con una tarjeta SmartArray P410/P410i, es imperativo el uso del componente de caché interno de la controladora. Este componente lo señalan como «opcional», pero os puedo asegurar que de opcional tiene bastante poco, estamos hablando de una mejora de rendimiento de como mínimo el 300% hasta un 1000%, medidos y comprobados con IOMeter.

En mi caso, las estadísticas de las que habla Jose María en este post fueron las que me dieron la pista de los problemas de acceso a disco y las que me llevaron a más investigaciones.

Para más información podeis acudir a las notas de referencia del producto: http://www.vmware.com/support/vsphere4/doc/vsp_esxi40_u2_rel_notes.html

Se te oye muy bajito en los vídeos. Hay que subir mucho el volumen para entenderte y al terminar, la musiquilla te pega el susto padre.

Hola José María,

Gracias por los aportes que haces en tu blog que siempre resultan de gran interés y de mucha ayuda. Nada más leer éste artículo me he dirigido a comprobar los valores en un entorno ESX 3.5 que disponemos en producción y comprobar dichos valores. A nivel de latencia kernel los valores se adaptan a los que comentas, sin embargo al nivel físico se puede comprobar picos máximos que llegan a superar los 100ms, de todos modos la media total de las LUN’s disponibles se encuentran entre 20 y 30 ms.

¿Qué opinas respecto esos valores?

Algo que si me gustaría comentarte es una cierta «lentitud» que comprobamos en nuestro servidor DFS de Microsoft, no sé si es que no está capacitado dicho servicio para ser virtualizado o es que la configuración usando vmdk en vez de rdm pudiera ser el problema. Lo que ocurre que disponemos de 4 servidores DFS en diferentes ubicaciones, el principal es el virtualizado y el resto físicos. Pues en este virtualizado su memoria RAM siempre está al máximo, consumida por el servicio dfsr.exe, el cual se encarga de la replicación, pero resulta que el resto de servidores DFS tienen la misma programación pero están como tu dices TONTOS, tienen bastantes recursos de sobra…. ¿qué opinas?

Saludos y enhorabuena.

P.D. Tal vez nos crucemos en Julio, ya que vamos a Madrid a realizar la formación VCP en Magirus.

Hola jose maria muchas gracias de antemano por tus videos.

Respecto a querer medir la latencia de los discos en mi Vmware ESXI y seguir los pasos desde mi VMware vSphere Client no pude encontrar la opcion de advanced en la pestaña de performance.

Podrías explicarme como hacerlo o si no lo puedo hacer por mi version free.

Gracias

Un artículo muy interesante José María.

Me hubiera sido muy util para detectar un problema que tuvimos con una cabina de discos. Lo comento por si a alguien le ocurre algo parecido:

Se trata de una cabina DS4300 de IBM. Recibimos una alerta de que una de las baterias que hay en cada controladora estaba averiada. El funcionamiento parecia corecto por lo que no dimos el aviso a soporte inmediatamente. Durante los días posteriores comprobamos una bajada de rendimiento brutal en algunas lunes por cualquiera de las dos controladoras. El problema era debido a que, por defecto, existe un parámetro que desactiva automáticamente la caché de la cabina (en ambas controladoras) cuando falla una bateria. De todas formas, comentar que el parámetro es modificable por LUN.

Saludos.

Ángel,

Nosotros disponemos de DS4300 + EXP700 + EXP100. La instalación se hizo por parte de una empresa y posteriormente se presentó un técnico de IBM el cual lo dejó funcionando. Lo que ocurre que en su momento únicamente era DS4300 + EXP700 y unos años después se conecto la EXP1000, a partir de ese momento pensamos que la conexión ya no es la correcta, es decir, seguimos el redbook con las diferentes opciones de conexión y no nos concuerdan los LOOPS que realizan el cierre para disponer de redundancia.

Nosotros con el Path Preferred nos ocurre también como comentas a la hora de reescanear LUN, reiniciar ESX o te digo más aún… cuando un disco es introducido nuevo para expandir esto genera también perdida de Path. Sin embargo equipos físicos con Windows montados en Cluster que atacan directamente a la Lun, nunca dan dichos problemas de Path, sólo con ESX.. como bien dices parece que no interactuan bien… no sé si será alguna actualización de firmwares pero es que miras la Web de IBM y te pones enfermo con tantas actualiazciones disponibles.

Por cierto, tienes blades de IBM como HS40 o HS20… es que nosotros también encontramos ciertos problemas en las NIC a la hora de hacer teaming, ya que puedes elegir beacon state o link status (supuestamente informa del estado de enlace)… pero no va tampoco muy fino.

Saludos.

Que tal Jose María..

En un post más arriba dices lo siguiente:

«El protocolo de mulitpathing de i/o en VMware es muy simple. Me explico: Si la cabina es Activa/Activa VMware elige el Fixed (path preferred dicho de otro modo). Si la cabina es Activa/Pasiva, VMware elige MRU (Most Recent Used). Si queremos hacer balanceo de carga,podemos seleccionar en una cabina activa/activa el RR (Round Robin)»

Está información aparece en algun documento o la experiencia trabajando en proyectos te lo dice?

Saludos