Nueva Web www.germanalbalate.es

Buenas a todos!

A partir de ahora ya no publicaré más artículos en esta web.

Seguiré publicando en mi nueva página personal:

www.germanalbalate.es

Gracias por visitarla!!

Oversubscription en vSphere – Memoria

Buenas a todos!

Vamos a repasar las técnicas que utiliza nuestros ESXi para reducir la cantidad de memoria física usada por nuestras VM:

Page Sharing. Es una técnica propietaria que permite compartir páginas de memoria entre diferentes máquinas virtuales de manera segura y transparente para nosotros. Por ejemplo: Si tenemos muchas VM con el mismo sistema operativo, habrá muchas páginas de memoria que serán «iguales»: Con esta técnica, los hosts ESXi comparte dichas páginas eliminando las páginas de memoria redundantes. Esta técnica se usa por defecto.

Ballooning. Para usar esta técnica, la VM debe de tener las VMWare Tools (Deberíais de tenerlas instaladas en todas vuestras máquinas). Mediante un módulo de las VMWare Tools, nuestros ESXi harán que la VM deseche las páginas de memoria que sean menos importantes. Esta técnica es utilizada por el ESXi cuando se va quedando con poca memoria libre y las VM van alcanzado el máximo de memoria asignada.

Memory compression. Si la VM llega a un nivel de uso de memoria en el que se requiere un swapping a nivel de host, el ESXi comprimirá páginas de memoria para tener que hacer un swap-out de una menor cantidad de ellas. ¿Porque hace esto? Porque la latencia de descomprimir una página de memoria es menos que la de hacer un swap-in.

Swap to host cache. Para usar esta técnica debemos tener algún datastore con discos SSD (De hecho, si los datastores no son de discos SSD, no aparecerán en la página de configuración del host cache). Esta técnica hace que que el ESXi use estos datastores para escribir archivos swap de las máquinas virtuales. Aunque el rendimiento se verá aumentado, esto no es lo mismo que usar un datastore SSD para almacenar los archivos regular swap de las VM, ya que estos se seguirán creando en el almacenamiento que tengamos configurado para ello.

Regular host-level swapping. Si no se ha configurado el host cache o si este se llena, los ESXi hará un swap-out de la memoria de las VM a un archivo regular swap. Al igual que con la técnica anterior, esto puede hacer que el ESXi haga un swap-out de páginas de memoria que se estén usando, pero al no tratarse de discos SSD (Lo normal es que sean discos SATA/SAS), la latencia se verá aumentada impactando negativamente en el rendimiento ofreció por nuestras VM.

---

Una vez vistas las técnicas que utiliza ESXi podemos observar que, al menos que tengamos muchas máquinas virtuales con el mismo sistema operativo, no deberíamos de abusar del overcommit con la memoria. De hecho, muchos expertos en virtualización aseguran que es una buena práctica no hacer overcommit de memoria en absoluto, y que en caso de hacerlo, este no debe sobrepasar nunca el 125% de la memoria física del host ESXi.

Al igual que con el ratio vCPU:pCPU, mucho de dependerá de la cantidad y el tipo de carga que tengan nuestras VM. Si es necesario podemos ir introduciendo VM en nuestro cluster e ir monitorizando tanto el ESXi como el rendimiento de las VM hasta que veamos que el rendimiento de las mismas se esta viendo afectado. ¿Que debemos de monitorizar? Según VMWare:

En la pestaña de rendimiento de la VM: Memory Balloon (Average), Consumed and active memory, Swap-in y Decompress.

• Si el valor del memory balloon es nulo o pequeño, eso indica que la VM no está bajo una gran carga de uso de memoria.
• Si el valor de la consumed memory es mayor que la active memory, esto es indicativo de que la máquina está usando la memoria que necesita para ofrecer su mejor rendimiento.
• Si existe Swapping-in y decompressing, indica que la VM esta siendo sometida a carga en el uso de la memoria.

Espero que os haya parecido interesante!

Un saludo!

 

Oversubscription en vSphere – Ratio vCPU:pCPU

Para los que no sepan lo que quiere decir el título del post, y de una manera resumida, significa que cuantos vCPU podemos asignar en total a todas nuestras máquinas virtuales por cada host ESXi:

vCPU (Virtual CPU) : pCPU (Physical CPU)

Todos nos hemos hecho esta pregunta, pero la verdad es que no tiene una respuesta igual para todos. Muchos recomiendan no superar el ratio 1:1, otros dicen que ellos están usando un ratio 10:1, y VMware dice que vSphere (En la versión 5) soporta hasta un ratio de 25:1…¿Con cual nos quedamos?

La verdad es que esto depende del tipo de carga de trabajo al que estén sometidas nuestras VM, de si nuestros procesadores soportan o no HT (Hyper Threading), de como tengamos configurado nuestro entorno vSphere y nuestras VM…

En cuanto al HT, hay que entender, que aunque lo activemos (Si lo hacemos, el ESXi nos enseñará 2 procesadores lógicos por cada core físico), el rendimiento no aumenta en un 100%. Por ejemplo:

Tenemos 1 host ESXi con dos procesadores de 8 cores cada uno: Sin HT activado, el ESXi nos enseñara 16 procesadores lógicos pero si activamos, nos enseñará 32. Aunque pensemos que de 16 a 32 el rendimiento mejoraría el doble, la realidad es que mejora alrededor de un 20-30%.

Una vez aclarado esto, no nos queda más remedio que ir probando en nuestro entorno e ir introduciendo MV (Siempre siguiendo las buenas prácticas que escribiré en un post más adelante) y monitorizando el host ESXi (Sobre todo, y para esto, debemos fijarnos en el valor CPU Ready. Más adelante escribiré otro post acerca de esto.)

Según este whitepaper de Dell se pueden seguir las siguientes recomendaciones:

The following vCPU:pCPU guidelines are established:

• 1:1 to 3:1 is no problem
• 3:1 to 5:1 may begin to cause performance degradation
• 6:1 or greater is often going to cause a problem
• Additional guidance suggests that keeping the CPU Ready metric at 5% or below is considered a best practice.

Ahora, que cada uno saque sus propias conclusiones 🙂

¿Qué es VMWare VAAI?

VAAI (vStorage API for Array Integration) son un conjunto de API´s que permiten a los ESXi comunicarse con dispositivos de almacenamiento  descargando en los SP (Storage Processors) trabajo que de otro modo tendría que realizar el propio ESXi: Snapshots, Clonar VM, discos Eager/lazy zeroed, etc. Esto permite una importante reducción en el uso de la red de almacenamiento, siendo especialmente importante en entornos 1GB iSCSI.

Esta característica se introdujo en la versión 4.1 de vSphere pero solo soportaba SAN´s con tecnologías iSCSI y Fiber Channel. En las versión 5.1 se soportó VAAI en LUN´s NFS.

Para poder usarla esta característica se deben cumplir dos requisitos: Que nuestro dispositivo de almacenamiento la soporte (Hoy en día la inmensa mayoría de SAN´s la soportan) y que tengamos la licencia VMware necesaria para poder usarla.

Si queremos comprobar que dispositivos soportan VAAI, podemos verlo en la HCL (Hardware Compatibility List) de VMWare.

En cuanto a la licencia VMware, necesitaremos como mínimo la versión Standard (Novedad en vSphere 6.0). Podéis comprobarlo aquí. Los Kits Essential y Essential Plus no permiten el uso de estas API, aunque hay rumores que dicen que si instalamos una versión de prueba de 60 días (Enterprise Plus) y después le cambiamos la licencia a la Essential…VAAI sigue funcionando. No he podido comprobarlo personalmente: Hay gente que dice que sí sigue funcionando y otros que después de reiniciar el host ESXi se desactiva.

Pero lo que si tengo claro, es que en el caso de que siguiese funcionando estaríamos violando el apartado 3.1 de la EULA de VMWare, por lo que os dejo el link del artículo de la KB que indica como desactivarlo.

Si cumplís todos los requisitos, aquí tenéis el TechPaper.

Un saludo!