vSMP (virtual symmetric multiprocessing)

Algo que me vienen preguntando ultimamente es cuándo usar vSMP.
¿Debemos asignar a una VM más de un virtual processor?

Deberíamos usarlo solamente cuando sabemos que se va a aprovechar por las aplicaciones que lleva dentro la VM, no simplemente por pensar "cuantas más vCPU tenga una VM mejor". Hay personas que piensan que cuantas más vCPU tenga una VM mejor, y esto no es necesariamente cierto, de hecho puede correr peor con dos vCPU que con una.

La razon para esto es que el scheduler de CPU del hypervisor debe encontrar el numero cores disponibles simultaneamente igual al numero de vCPUs que tiene asignada la VM. Por ejemplo, una VM con cuatro vCPUs deberá tener cuatro cores disponibles a la vez para cada petición de CPU que hace al host. Si dichos cuatro cores no están disponibles en ese momento (porque hay otra VM usando dos, por ejemplo) la VM deberá esperar hasta que estén disponibles.

Tips respecto a esto:

• Cuantos menos vCPUs lleven las VMs mejor.
• Sólo asignar a una VM multiples vCPUs cuando sabemos que la aplicacion que lleva dentro va a hacer uso de ello.
• Nunca asignar el mismo numero de vCPUs que el numero total de cores de tu host.(pCPUs). Mejor si mantenmos el doble de cores fisicos que los vCPUs de la VM que más tiene. (Por ejemplo, 8 cores fisicos = 4 vCPU como maximo)
• Si estas haciendo P2V de un servidor Windows con varias CPUs a una VM con una vCPU, cambia el HAL de multiprocessor a uniprocessor.
• Si puedes, evita usar afinidad de CPU.

Actualización:
Este link, aunque un poco viejo, explica muy tecnicamente el comportamiento con vSMP y sin él.

Uso de CPU en Oracle 10g RAC en VMware

Resulta que tenemos preparada una maqueta con Oracle 10g RAC de dos VMs con Linux Red Hat 4 U4 para pruebas/tests y desde hace tiempo se quejaban de que iba lenta. Despues de determinar que efectivemente iba lenta, mirando las graficas de la VM se veia que todo era normal: Un relativo uso de CPU alto, disco normal, red normal, etc, etc... Por supuesto los DBAs echaban la culpa al disco (sin saber bien lo que es un vmdk o las capas de abstraccion, caches etc, que tiene desde los discos en RAID5 de una cabina hasta el disco en vmdk....), o a que estaba virtualizado y claro era mas lento por eso...

Despues de descartar una por una las ocurrencias de los DBAs y de probar a cambiar la VM de discos(locales/SAN), de host y probar los polvos magicos, me meti en arena y sacamos unas cuantas cosas (todas en relacion con Oracle):
Indices de base de datos no creados, discos en RAID1 de software realizado por ASM de Oracle... etc, y una vez que teniamos la base de datos mas relajada decidi ver cuanta CPU consumía la VM cuando estaba parada. Fue una sorpresa ver como los scripts de Oracle de administracion, de recogida de estadisticas y en concreto el CRS estaban comiendo CPU aun a pesar de que la DB estaba apagada.

Pues bien, parece ser que uno de estos procesos, en concreto el CRS, realiza chequeos cada cierto tiempo y ello provoca consumo de CPU(se solapan chequeos y se va engordando el consumo, etc...).
Por lo que he podido ver ocurre sólo en entornos de Oracle 10g RAC virtualizado.

He aqui un link http://www.oracloid.com/2007/10/crs-eating-cpu-on-vmware/ que nos dio la solucion.
En la grafica se puede ver el bajon de CPU que se produce al cambiar un SLEEP 1 por un SLEEP 35. L averdad es que no es la primera vez que he observado que en VMware (esto es solo una impresion) con VMs linux, los scripts(perl, shell, compilaciones...) no van todo lo bien que van en fisico....

Compatibilidad de VMotion

En mi opinión, una de las grandes ventajas de VMware (y poco a poco sus competidores) es la capacidad de realizar VMotion. Pienso que es una ventaja clave y que cambia mucho de tener un entorno con o sin ello. Sin ello, simplemente estas poniendo muchos huevos en una cesta, que algun dia puede romperse o puede necesitar pararse. Con ello, tienes la posibilidad de mover esos huevos para arreglar la cesta.

Para realizar VMotion, además de tener un almacenamiento centralizado SAN/NAS, es necesario que las CPUs de los dos hosts entre los que se va a realizar VMotion sean de la misma familia o compatibles.
Cuando se nos da el caso de que entre los hosts no hay compatibilidad de CPUs podemos usar las mascaras personalizadas de CPU para conseguir realizar VMotion.
Tengo que decir que VMware no da soporte a esto y que no debe hacerse en produccion. También tengo que decir que nunca he visto que haya dado ningun problema y también lo he usado en produccion, asi que cada uno que vea.

Para crear una mascara (custom mask) para las VMs deberemos fijarnos en los valores de los registros de las CPUs de los servidores incompatibles y ver las diferencias para enmascararlas.

El primer paso es recolectar la informacion que necesitamos usando la genial herramienta VMotion Info de run-virtual.
Con ella podemos recabar toda la informacion de nuestra granja de servidores y ver cuales son incompatibles entre sí. Recomiendo activar la opcion "Con Debug" porque nos da los registros de las CPUs ya en binario y solo tenemos que fijarnos en eso:


Como se ve, hay varios procesadores IBMs(entre ellos compatibles) y tres CPUs diferentes de DELL(entre ellos compatibles).
Si intentamos realizar VMotion entre cualquier IBM y cualquier DELL nos dara un error de compatibilidad:

Como vemos, el error esta en el registro EAX del nivel 1. Para arreglarlo anotamos el valor del registro de los servidores incompatibles entre sí y vemos la mascara por defecto que tienen nuestras VMs (Edit Settings, Pestaña Options, Advanced, y en CPU Identification Mask pinchar en Advanced).


Como vemos en la leyenda, hay bits que directamente no interesan para nada (X), de hecho normalmente solo nos interesan los marcados con H, con R, con 0 con 1...

Veamos, tenemos:

Server1 Level1 EAX:   0000 0000 0000 0000 0000 0000 0000 0110 
Server2 Level1 EAX:   0000 0000 0000 0000 0000 0110 1111 0110
Standard CPU Mask Level1 EAX:  XXXX HHHH HHHH XXXX XXXX HHHH XXXX XXXX
Custom CPU Mask Level1 EAX:  ---- ---- ---- ---- ---- -00- ---- ---- 
Effective CPU Mask Level1 EAX:  XXXX HHHH HHHH XXXX XXXX H00H XXXX XXXX

Como podemos ver sólo nos interesa los bytes segundo, tercero y sexto(los demas llevan X asi que lo podemos dejar por defecto). En el caso del segundo y tercero byte, vemos que son iguales, luego no tenemos que hecer nada. En el caso del sexto vemos que los bits del medio son diferentes asi que los enmascaramos.

Ya solo nos queda probar a realizar VMotion, si hay algun otro registro que tocar, el error nos lo describirá(registro ECX, EBX, level 0, etc...)

Deberemos poner la mascara en cada VM con la que queramos realizar Vmotion.

Es importnate también darse un paseo por la web de IBM o Dell y ver que es lo que hemos podido enmascarar a la VM, para ver posibles efectos que pueda tener sobre ella. Yo hasta el momento no he tenido ningun problema. (ejemplo: http://www.intel.com/design/processor/applnots/241618.htm)

Cualquier comentario o correccion será bienvenido!

Consulta: Numero de VM por servidor o core

Rodrigo nos comenta:
Hola,

he estado leyendo tus artículos y me parecen muy útiles, y me parece que conoces bastante el tema, por lo que te hago una consulta que hace tiempo tengo, que es
¿Como saber o calcular el número de virtual machine que puedes instalar en un server?
La pregunta me parece bastante completa, pero debe existir algún tipo de calculo según Nº CPUs, RAM y otros datos.
Tu sabes que documentación o alguna forma de calcular esto?
Saludos

En primer lugar, muchas gracias por el comentario Rodrigo, es un aliciente muy grande que te resulten útiles los artículos.
La verdad es que, como te comenté, en este tema no existe una regla o formula que te diga: Puedes poner en tu servidor ESX "n" maquinas virtuales y te va a ir bien. Es algo muy relativo. A mi me gusta verlo por cores, porque hoy en día los servidores ya vienen con dos procesadores y dual core o quad core en la mayoría de los casos.

Los vendedores de servidores, sobretodo de blades (los cuales no me gustan para virtualizar dicho sea de paso), suelen mencionar que su hardware puede correr X maquinas virtuales, pero desde luego hay que cogerlo con pinzas, está claro que NO sale de un método científico, no tiene todos los fabricantes el mismo baremo y es algo comercial.

El numero de VMs soportado por un servidor depende de la carga que tenga cada una de las VMs (es algo muy relativo). Además, influyen factores como la RAM y el disco: Puedes quedarte sin disco o sin RAM antes de quedarte sin CPU en un servidor, de hecho esto ocurre frecuentemente.

He visto varios sitios que corren unas 30 VMs por cada servidor (8 cores), lo que da un ratio de 3,75 VMs/core, aunque muy probablemente se podría aumentar a 50Vms por cada server (8 cores) , que es un ratio de 6,25 VMs/core.

Este es el orden de magnitud: desde 4 hasta 8 VMs/core en servidores de aplicaciones normales.
Cuando hablamos de escritorios virtuales el numero aumenta algo, por lo que he visto, suelen andar por los 8 VDesktop/core, aunque seguro que hay gente que tiene 15! (En este caso la RAM puede ser nuestro limite de forma muy facil!)

Para que veas unos números según el preliminar de "2008 Purchasing Intentions Survey", el 61% corren menos de 10 VMs por servidor, el 33% corren de 10 a 25 VMs por servidor y un 5% corren mas de 25 VMs en un servidor. (Se supone un servidor con dos procesadores aunque no dicen el numero de cores por procesador).

Tal y como lo veo yo, la infraestructura virtual (de producción) debe estar cargada cerca del 75% (en RAM, CPU, Disco). Si se sube más de ahí, es mejor ir pensando en aprovisionar más servidor, memoria o disco, con los tiempos de entrega dará tiempo a que se pueda seguir trabajando y a que lleguen los materiales para mantenernos en dicho 75%.

Con DRS es muy fácil ver de un plumazo qué tal va la cosa, por ejemplo:


La imagen responde a un cluster de 9 servidores donde ahy todo tipo de servidores: Linux, Windows, Oracle, OAS, Apache-Tomcat, Webmail, Samba, PeopleSoft, Meta4, etc, etc. Puedes ver que hay 53 VMs en 9 servidores (con dos procesadores dual core), lo cual da un 1,5 VMs/core. Ya se ve que la infraestructura puede crecer, y así te lo dice el gráfico de utilización:


Cuatro de los nueve servidores se encuentra con un 15%(entre el 10 y el 20) de CPU(aprox.), dos de ellos con un 25%(entre 20 y 30) y otros dos con un 35%(entre 30 y 40). El ultimo tiene un 55%(entre 50 y 60) de uso de CPU. De media saldría un 26%. (Esto en el gráfico en dicho momento, que habría que ver si es como normalmente suele estar, para ello te puedes ayudar de las grafías de performance).
Con nuestros cálculos podríamos tener 3 veces (3*26 = 75%) las VMs que tenemos ahora, es decir 1,5 *3 = 4 VMs/core de media(algo bastante razonable, es decir 150 VMs(4VMs/core * 9 servidores * 4 cores/servidor) ).

En el gráfico de uso de GHz se puede ver como llega a los 28GHz en el punto mas alto, de los 89GHz que tenemos (un 30%, este dato es mas exacto y corrobora lo que nos indicaba antes el gráfico(26%)).


Ya ves que en este caso vamos mucho peor de RAM que de CPU: Fíjate en la gráfica(segundo dibujo), un 60% de RAM usado. Además, en este caso se está usando el 95% del disco disponible. Esto es lo que te comentaba antes, te puedes quedar sin disco antes que sin CPU.

Espero que esto te ayude!
Saludos,

Bluebear (Koala y Kodiak) Posible Cliente de Virtual Center de Linux

Muchos ya habreis oido hablar de ello, otros no. La compañia Bluebear, una startup de Washington, además de ofrecer servidores para virtualizar llamados Koala, está trabajando sobre una aplicacion multiplataforma (Windows, Mac OS y Linux) llamada Kodiak (es el nombre de un oso de Alaska) para gestionar nuestro imperio virtual (como ellos ponen: "Ruling your virtual empire!"). Se trata (se tratará pues de momento es beta y solo se puede probar bajo invitación) de una aplicacion de codigo abierto que sea capaz de manejar Vmware ESX, Citrix XenServer y MS Hyper-V. Por el momento empiezan dando soporte a VMware ESX, esto puede que supla la necesidad de tener un cliente de VMware en Linux(por fin), veremos qué tal es el producto, desde luego por los pantallazos tiene muy buena pinta!



Según lo que ellos mismo dicen:
Welcome to the next generation of unified systems management! Kodiak, from BlueBear, enables unprecedented visibility into and control over virtualized infrastructures, regardless of size or composition. As the industry's only application that's both hypervisor-agnostic and cross-platform, Kodiak sets a new standard in versatility, pushing virtualization out of the datacenter and catalyzing it's widespread adoption throughout the information technology landscape. BlueBear believes useful software should be available to anybody who needs it, and at no cost; hence Kodiak's price, totally free!