La compra de B-hive por parte de Vmware

Recientemente (finales de Mayo) VMware ha comenzado el proceso de compra de la compañia B-Hive. Como reza el comunicado de prensa : "B-Hive proporciona una visión de infraestructura en el rendimiento de aplicaciones (albergadas por entornos virtuales) tales como el tiempo de respuesta del usuario en las transacciones, utilizaciones de VMs y dependencia cruzadas de VMs".

De lo que se trata es de proveer una mayor cantidad de datos a herramientas como DRS y soluciones de management de forma que se pueda resolver problemas de rendimiento de las aplicaciones de forma proactiva realizando acciones como reservar dinamicamente más recursos, migrar las aplicaciones a otro servidor, aprovisionar otras VMs, cambiar el rutado de las transacciones o incluso reinicar el sistema.

La idea basica detrás de un APM (Application Performance Manager) es medir la experiencia del usuario o el rendimiento de las aplicaciones (cómo de rapido esta la apliacion procesando transacciones o unidades de trabajo desde que llegan de los usuarios u otras aplicaciones)

B-hive mide el tiempo de respuesta desde la perspectiva del la capa de presentación(el web server por ejemplo). Las soluciones de APM más antiguas infieren el rendimiento de las aplicaciones mirando los recursos que usan lo cual no es buena aproximación para un entorno virtual.

Funcionamiento General:
B-hive escucha en un puerto mirror (spanned) en el switch que está más cercano a los usuarios, lo que le permite ver las transacciones. En un entorno virtual, B-hive es implementado (de momento) como una virtual appliance que se une al mirror port del virtual switch dentro del ESX.

Mide el tiempo de respuesta entre las peticiones y la respuesta de la apliacaion a determinadas transacciones atomicas (o casi). Dichas operaciones no son algo palpable(xej una pagina web) desde el punto de vista del usuario sino que son opreaciones más pequeñas que dan una idea al personal de IT de cómo va la aplicacion. (El nivel de las transacciones atomicas depende de la aplicacion. Para web son HTTP tiempo peticion/respuesta. Para las que no son web las transacciones son a nivel TCP/IP tiempo peticion/respuesta o a Base de Datos tiempo peticion/respuesta.)


Lo bueno del producto es que es sin agente e independiente del OS de la VM y da el primer paso para proporcionar mejores datos para implementar el modelo de Data center de nube dinamica que es lo que persigue VMware(yo creo que es un buen movimiento de VMware).

Con este producto VMware conseguirá varias cosas (en mi opinion): será capaz de darnos una idea muy concreta de cómo van nuestras aplicaciones virtualizadas, consiguiendo por un lado que podamos dar unos determinados SLAs y por otro que nos atrevamos a realizar virtualizacion de aplicaciones más criticas. Además, ha pegado un mazazo a Citrix Y Microsoft que ahora se tendran que poner las pilas y por ultimo ha provocado una carrera en el mercado de los APM para posicionarse en el mercado de la virtualización.


Aqui os dejo un grafico que ve de foma general el mercado de los APMs. Algunos de los mejor emplazados son Akorri, vmSight y B-Hive.



Se supone que habra movimientos en breve por parte de Microsoft, Citrix, y algunos APMs.

Slow performance of VMs that use vSMP on ESX using certain hardware

Como reza el título del post VMware ha publicado el dia 11 de Junio un articulo en la Knowledge Base que detalla un problema de rendimiento en VMs que se ejecutan en servidores ESX (3.0.x y 3.5) y que utilizan más de una vSMP y todo ello bajo determinados tipos de hardware (que no concretan por cierto). Todo el articulo es un poco difuminado (Puede ser leído aqui: http://kb.vmware.com/kb/1004901) y nos viene a decir que se puede apreciar un rendimiento pobre (no lo contabilizan) cuando usamos VMs con mas de una vSMP, además este rendimiento pobre también se puede manifestar en el Reinicio de la VM: "Síntoma: Reinicar una VM que tiene mas de un vSMP lleva significativamente más tiempo que si solo tuviera una vSMP, bajo ESX y bajo determinados HW...".

Como veis la explicacion no es muy detallada y para mi bastante confusa. En la explicacion nos comentan que parece que está relacionado con el COW (Copy-On-Write) de las VMs que tiene mas de una vSMP y nos proponen Apagar la maquina y Encenderla en lugar de Reinicarla pues esto hace que la memoria de COW se vacie y se llene.

Nos comentan también que para resolver el problema definitivamente se puede desactivar el Page Sharing (Transparen Page Sharing, TPS) de nuestro servidor ESX(Confguration-Advanced Settings- Set Mem-Mem.ShareScanGHz = 0, Reinica ESX).
El TPS nos proporciona la posibilidad de que se compartan paginas de memoria entre VMs resultando en grandes beneficios sobretodo si solemos tener sistemas operativos iguales en nuestro ESX. El resultado es muy visible cuando se inica una VM o varias a la vez. Por defecto VMware lo activa en nuestros servidores y parece que es el camino que van a seguir en el futuro.
Nos avisan que desactivarlo en todo el servidor puede producir mayor swapping si se hace Overcommitting de la memoria del ESX.
(Un post cojonudo sobre Gestion y Sobresuscripcion de Memoria de J.L. Medina).

Como ya he comentado antes la descripcion del problema es bastante disfusa y confusa (en mi opinión). Si por ejemplo, creo que estoy experimentando problemas de rendimiento en mi entorno de ESX(VI3) ¿Como sé yo si es este tipo de issue o no? Digo, antes de volverme loco intentando ver donde está el problema o cuello de botella, que, por cierto, no es de las cosas más faciles de pillar en VI3. (Espero escribir un post sobre ello...). Supongo que no será facil pero, creo que deberían describir mejor en que condiciones se produce, cuanto merma el rendimiento (%), etc, etc, para ver si nuestros sintomas coinciden con el KB.

Por otra parte el tema de desactivar el TPS para que la cosa vaya mejor me ha recordado a la directiva sched.mem.pshare.enable que es capaz de desctivar el TPS a nivel de VM y no a nivel de ESX como nos recomiendan en el KB. Es muy posible que esto también funcione, en lugar de tener que reinicar todo el ESX despues de cambiar la opcion en Advanced Settings como comentaba más arriba.

Este es uno de los parametros que mi colega Josep Ros comenta en su gran blog como polvos magicos para VMware.

En concreto los parametros que se comentan para aumentar el rendimiento de una VM (en lo que a gestion de memoria se refiere) son:

mainMem.useNamedFile = "FALSE"
Cuando está puesta a TRUE, se crea un fichero de tamaño de la RAM en el propio directorio con un nombre aleatorio.
Cuand se pone a FALSE, en Windows causa que la memoria la lleve el espacio de swap del host y en Linux causa que se cree un fichero en un directorio temporal (el fichero es borrado cuando se apaga la VM).
Se suele poner a FALSE cuando ejecutamos una VM desde un USB o un disco que tenga escrituras lentas.

MemAllowAutoScaleDown = "FALSE"
Permite ajustar automaticamente el tamaño de la memoria. Si esta puesto a TRUE, cuando encendemos una VM automaticamente se ajustará el tamaño de la memoria si el tamaño especificado no está disponible (en caso de sobresuscripcion)

MemTrimRate = "0"
El ESX chequea regularmente memoria virtual no usada y la recupera para sí(para correr mśa VMs o lo que sea). Cuando la VM que ha sido robada pide más memoria, el ESX se la da, epro esto tiene un precio en rendimiento. Si lo ponemos a "0" evitamos que nos coja memoria de dicha VM.

sched.mem.pshare.enable = "FALSE"
Como hemos comentado antes, VMware usa TPS para permitir almacenar como una sola pagina Copy-On-Write las paginas de memoria de las VM que contengan identico contenido. Esto hace que las VMs usen menos memoria pero consume mayores recursos, sobre todo CPU, pero también potencialmente ancho de banda de I/O.
Desactivarlo puede ser interesante en Hosts en los que tengamos memoria de sobra y nos interese que la VM tenga poca latencia de I/O.
(Mas info: http://communities.vmware.com/message/251822)

Conjuntado estas opciones tendremos una VM que escibe su memoria en la swap del propio ESX o en el temp, pero nunca un fichero de X gigas (tanta como RAM tenga la VM) en el propio directorio, además la VM será capaz de adecuar su memoria y no dejará que el ESX le reclame memoria cuando no la use.
Por último, la opcion más importante, no usara TPS, lo cual le dejará sus paginas de memoria dedicadas para sí misma, sin compartir. (Ojo, estas opciones no son recomendadas cuando usamos overcommittement, vamos sobresuscripcion).
Todo esto resultará en un incremento de rendimiento siempre que viene muy bien siempre y cuando sepamos que hemos tocado esto y que no deberemos pasarnos con la sobresuscripcion.