Blog

29 junio, 2022

Asignación de Recursos en Virtualización (PARTE 1)

Como administradores de nuestras plataformas de virtualización siempre hemos disfrutado de la disponibilidad y agilidad que nos entrega la virtualización para hacer lo más básico, crear maquinas virtuales (VMs). Cuando creamos estas VMs siempre tenemos en cuenta los recursos que nos solicita el Sistema Operativo a instalar (invitado) más las aplicaciones o servicios que esta VM debe entregar.

Cuando estamos comenzando con nuestras plataformas todo funciona perfecto, una luna de miel que a veces, según sea el crecimiento de tu plataforma, en algún momento, se puede acabar.

Uds saben que al momento de seleccionar o aceptar un diseño de una plataforma, por muy buena que sea tenemos limites de recursos que debemos saber administrar y este blog trataremos de explicar algunas cosas.

Definamos algunas cosas primero:

Las máquinas virtuales dependen de los recursos de host disponibles (CPU, memoria) y el sistema operativo invitado consume esos recursos. Un problema con la disponibilidad de recursos o la programación dentro o fuera de la máquina virtual puede hacer que deje de responder o que responda de forma deficiente.

Hagamos un ejercicio muy sencillo

Pensemos que tenemos un Host (Servidor con ESXi) con 2 CPU físicas con 4 core cada CPU, eso nos permite tener 8 core disponibles sin considerar hyper threading activado que ya explicare por que lo dejamos fuera. Si en ese host tenemos una VM con 8 vCPU, como lo muestra la imagen (no soy muy bueno para las ilustraciones) esa VM tiene acceso liberado a estos recursos del host.

Ahora, para seguir con este sencillo ejercicio, digamos que la VM tiene 12 vCPU asignados y seguimos en el mismo host con 8 core, lo que pasaría al momento de realizar los procesos sería algo como esto:

Como se ve en mi gran ilustración, tendríamos como resultado que 8 vCPU tendría acceso rápido a los recursos del host pero las otras 4 vCPU tendrían que esperar que se desocupen algunos de los core para poder realizar su proceso.

Lindo debate

El tema de la asignación de recursos siempre es un lindo debate por quienes nos dedicamos a diseñar las plataformas virtuales vs quienes las terminan usando y administrando. Estos últimos, generalmente guiados por las buenas practicas que les indican las mismas aplicaciones o servicios que deben instalar y configurar. Mi propósito acá es no decir que esta bien diseñado a nivel de VM y que no, pero si que puedan tener una visión de su infraestructura de forma general ya que lamentablemente, por muy virtual que sea, los recursos no son infinitos.

Por muchos años, VMware nos ha dicho que siempre hay que partir de menos a más (en términos de asignación de recursos) pero también hay que entender que los requerimientos de algunos Sistemas Operativos y aplicaciones han cambiado, los sistemas que funcionaban con un único core también se esta convirtiendo en algo obsoleto, sin embargo, reitero, no pierda de vista la mirada general.

¿Como asignamos vCPU?

Como mostré en el ejercicio anterior, tenemos que entender la información que nos entrega la CPU de nuestro sistema. Me gustan los ejemplos prácticos, así que, vamos con uno.

Es común que nuestros sistemas que tienen implementado virtualización (nuestro hipervisor ESXi) son servidores con 2 procesadores (2 CPU físicas o 2 socket).

Digamos que nuestro host tiene 2 CPU Procesador Intel® Xeon® Gold 6342, este es un procesador de 24 Core y cuenta con la tecnología Hyper Threading (HTT) (si no sabe lo que es, lo invito a revisar este link del mismo Intel  What Is Hyper-Threading? – Intel)

Siguiendo con nuestro ejercicio, nosotros tenemos a disposición los 24 core multiplicados por nuestras dos CPU, o sea, tendríamos 48 vCPU para asignar.

Relación 1:1

Pensar en una asignación uno es uno (1:1) se puede entender que tendríamos 48 core para entregar a distintas VMs que estén alojadas en ese host. Claramente pensando en la virtualización, no es muy común que uno dimensione de esa manera, quizás en un ambiente muy crítico podría darse una situación así.

Relación 2:1

Es una buena relación entre CPU vs vCPU, con nuestra CPU Intel® Xeon® Gold 6342, esta relación nos permitiría asignar 96 vCPU, sigue siendo una relación optima para trabajar con cargas fuertes de trabajo.

Relación 3:1

Nuestra asignación de vCPU sube a 144 vCPU (recuerden que escogimos una CPU de ejemplo), recomendado para un ambiente más variado de exigencia, múltiples propósitos muchas veces lo definen las marcas.

Relación 4:1

196 vCPU posibles para asignar, esta relación ya comenzamos a dejar de lado cargas críticas, también es una muy buena relación para ambientes VDI.

Relación 5:1

Y terminando con nuestro ejercicio, en el host podríamos llegar a asignar 240 vCPU, solo recomendaría esto en un ambiente VDI y teniendo un presupuesto apretado.

Con esto, podemos deducir que una relación más alta, es seguro que vas a tener problemas de rendimiento en tu plataforma.

Estas relaciones no son una receta mágica, en realidad, hay muchos factores que intervienen en la definición de cuál debe ser la proporción de vCPU a CPU en un entorno determinado. Y, a medida que las cargas de trabajo siguen cambiando y se utilizan a lo largo del día, el número de proporción «mágica» cambia. Por lo tanto, no existe una regla general para definir este número y, en realidad, no hay forma de administrar las cargas de trabajo críticas para el negocio de la misma manera que en un entorno de TI típico con cargas de trabajo mixtas.

Bajo del punto de vista de VMware, mirando todo el entorno, es bueno eso si que no se pierda de vista estas relaciones y saber cuanto puedo crecer o asignar.

vRealize Operations Manager es una herramienta que te puede ayudar a identificar VMs con recursos sobre asignados fácilmente, es más, te ira dando recomendaciones para una sizing más adecuado.

En la parte 2 de este blog vamos a repasar los problemas de la sobre asignación y las posibles recomendaciones.

 

José Luis Fernández VCP / VCAP / vExpert

Uncategorized

Deje un Comentario

Tu dirección de correo electrónico no será publicada.