• Escrito por 
  • Publicado en Blog
  • 4 comentarios

Diseño de la Memoria en VMware vSphere

Diseñando la Memoria en vSphere

Continuando con la serie de diseño de vSphere hoy toca analizar el impacto y las consideraciones del diseño de la memoria Ram en nuestras infraestructuras.

 

Si bien el decidir con cuánta memoria Ram aprovisionaremos nuestros Hosts puede parecer bastante trivial, ésta decisión implica varios aspectos como:

-Modelo Scale Up/Scale Out

-Licenciamiento requerido (en número de Sockets)

-Margen de recursos para alta disponibilidad

-Ventana de mantenimiento para operaciones programadas (actualizaciones, parcheado, etc)

-Recursos disponibles para crecimiento estimado

 

En los Posts anteriores analizamos los aspectos del aprovisionamiento de CPU y de Red.

Si consideramos el uso de sistemas de Almacenamiento de Red no estamos descubriendo la pólvora al afirmar que la cantidad de RAM es lo que define el número de Máquinas Virtuales a consolidar en cada Host.

Esto supone que, considerando el mismo número de VMs, a mayor cantidad de Ram por Host necesitaremos un menor número de Hosts.

En la misma línea si tenemos una menor cantidad de memoria Ram por Host, necesitaremos un mayor número de Hosts para dar servicio al mismo número de VMs en el Host.

De esta forma vemos que la cantidad de Memoria Ram aprovisionada en cada Host está muy relacionada tanto con la elección del modelo (Scale Up/Out) como también con la cantidad de Procesadores a licenciar.

 

VMware vSphere: El campeón de la optimización de la RAM

Antes de continuar merece la pena que repasemos el por qué vSphere es el campeón de la optimización de la memoria Ram en un Host.

 

Entre las tecnologías de optimización de Ram en un Host ESXi tenemos:

-TPS (Transparent Page Sharing): este sistema identifica bloques de memoria idénticos y las gestiona como uno solo realizando una especie de Deduplicación de bloques de Memoria.

-Compresión: cuando los recursos de Ram no abundan y hay que ajustarse el cinturón, el Host busca bloques de memoria que puedan ser comprimidos y ocupar un único bloque físico en vez de dos.

-Balloning: un Host ESXi puede aprovisionar una mayor cantidad de Ram de la que físicamente dispone. En caso que el reclamo de memoria de las VMs comience a acercarse al total de Ram física del Host, éste aplica el Balloning. Ésta tecnología, gracias a las VMware Tools, permite realizar un trasvase de Ram entre una VM y otra.

-Swap a SSD: disponemos de la posibilidad de almacenar los ficheros de paginación de las Máquinas Virtuales en discos SSD locales de los Hosts. Si el Host necesita comenzar a paginar a disco, esta funcionalidad reducirá el impacto negativo que genera la paginación aunque no la eliminará.
El uso de Datastores SSD no es compatible con la aplicación de esos mismos discos SSD para VSAN.

 

Según hemos visto disponemos de varias tecnologías que nos permiten optimizar el uso de la memoria Ram del Host pudiendo aprovisionar a las Máquinas Virtuales una mayor cantidad de Ram de la que dispone físicamente el Host.

 

Cómo saber qué cantidad de Ram necesitamos en nuestras Máquinas Virtuales?

Si no tenemos muy claro este punto difícilmente podremos aprovisionar la Memoria de nuestra infraestructura de forma adecuada.

Utilizar una herramienta como el Capacity Planner o simplemente un Excel con cada una de las Máquinas Virtuales nos ayudará a tener claro qué cantidad de Ram tendremos aprovisionada, reservada así como también la memoria necesaria por el Overhead, sin olvidar el extra necesario para cubrir la Alta Disponibilidad y las ventanas de Mantenimiento de los Hosts.

De forma adicional podemos comprobar la optimización de la Memoria Ram de las Máquinas Virtuales utilizando el vSphere Client y/o el vSphere Web Client para comprobar los valores de Guest Memory:

-Private

-Shared

-Swapped

-Compressed

-Balloned

-Unaccessed

-Active

 
Recursos de Memoria en VM

Modo Overcommit o No Overcommit?

Esta es otra pregunta de lo más simple pero que su respuesta determina muy claramente el camino a seguir.

Trabajamos en modo Overcommit cuando la capacidad total de Memoria Ram aprovisionada es superior a la cantidad de Memoria Ram física de los Hosts.

Es malo trabajar en modo Overcommit? No necesariamente siempre y cuando esté controlado.

De forma similar al Thin Provisioning la sobreasignación de Memoria es buena de cara a la optimización de recursos pero eso requiere un extra de control y monitorización por parte del administrador.

Si bien trabajar en modo Overcommit hace que saquemos un mayor partido a los recursos, también hace que debamos sacar la calculadora de cara a los recursos necesarios para la Alta Disponibilidad, las Reservas y las ventanas de mantenimiento de los Hosts.

Al igual que en muchos casos, queda al gusto de consumidor.

 

Reservas de Ram en Máquinas Virtuales y Pool de Recursos

Otro de los puntos importantes en el diseño de una infraestructura es la aplicación de Reservas, Shares y Límites aplicables tanto a nivel de Máquina Virtual como de Resource Pool.

Una Máquina Virtual que tenga una reserva (tanto de CPU como de Ram) no se encenderá si el Host no es capaz de aprovisionarle, y garantizarle, esos recursos que tiene reservados.

Las reservas aplicadas a nivel de Pool de Recursos se aplican tanto si hay Máquinas Virtuales encendidas o apagadas dentro del contenedor.

No debemos olvidar que en un entorno de HA estas reservas se suman a los recursos adicionales necesarios para la Alta Disponibilidad.

Como podemos ver es de vital importancia conocer la cantidad necesaria de Memoria Ram a reservar para no desperdiciar este valioso recurso.

 

Nodos Numa

En las placas base de los Hosts cada procesador administra de forma local unos bancos de memoria. Esto supone además que un Host solo puede disponer del máximo de Memoria Ram soportado solo cuando cuenta con dos Procesadores (siempre hablando en físico).

A cada conjunto de Procesador con sus correspondientes bancos de memoria se les llama Nodo Numa. Podemos tener el Nodo 0, Nodo 1 y así sucesivamente para cada Procesador Físico.

El servicio Scheduler es el que vincula los vCPUs y la vRam de las Máquinas Virtuales a cada Nodo Numa.

Supongamos que estamos trabajando con un Host de 2 Procesadores y 128GB de RAM.

Cada Nodo Numa tendría 1 Procesador y 64 GB de Ram.

Podría darse el caso que una Máquina Virtual esté aprovisionada con una mayor cantidad de Memoria Ram de la que dispone un Nodo Numa. De esta forma esa VM estaría desbalanceada y tendría un Overhead en su rendimiento debido al tiempo de espera en la respuesta de un Procesador de un Nodo Numa al otro.

Es por eso que es de vital importancia conocer nuestra infraestructura y aprovisionar nuestras VMs de forma adecuada.

La Memoria y los Nodos NUMA
Imagen del estupendo Blog frankdenneman.nl


El tamaño importa

A la hora de invertir en Hosts es posible llegar a la cantidad total de Ram utilizando múltiples módulos de memoria de diversas capacidades.

Como ejemplo podemos mencionar la posibilidad del uso de módulos de 8, 16 o 32 GB.

Si bien a mayor tamaño del módulo también mayor es su precio, es interesante mirar hacia delante de cara a una más que segura ampliación de la memoria Ram en un futuro.

Considerando un tiempo de amortización de un Host que ronda los 5 años no es extraño contemplar una ampliación de memoria Ram al cabo de dos, tres o cuatro años.

De forma que, por más debamos invertir un poco más, es preferible utilizar una menor cantidad de módulos de memoria de mayor capacidad a utilizar más módulos de menos capacidad.

Esto evitará que paguemos dos veces por la memoria a la hora de necesitar bancos de memoria vacíos y tener que retirar los módulos antiguos para hacer hueco.

 

Resumen y recomendaciones

Llegados a este punto y habiendo repasado tanto las funcionalidades de vSphere para con la memoria como así también algunos puntos importantes podemos sacar la conclusión que, de la misma forma que las cuentas claras conservan la amistad, mejor tener las ideas claras a la hora del diseño de la Memoria Ram.

El Ratio Máquina Virtual/Host siempre estará alineado con la cantidad de Memoria Ram en cada Host, tanto para lo bueno como para lo malo.

Aprovisionar Ram en los Hosts no es solo eso, a la vez estamos definiendo la inversión en Licenciamiento, estableciendo nuestra ventana de Mantenimiento, delimitando la tasa de crecimiento y el margen para la Alta Disponibilidad.

 

4 comentarios

  • Fede
    Fede Miércoles, 23 Julio 2014 07:40 Enlace al Comentario

    Muchas gracias Tomás por tu comentario!!! Espero que te resulte de utilidad...

  • Fede
    Fede Miércoles, 23 Julio 2014 07:39 Enlace al Comentario

    Agustín excelentes Tips!!! Casi has redactado otro Post en los comentarios!!!!! Muy agradecido de tu aportación, sobre todo viniendo del primer VCDX hispanoparlante ;)
    Nuevamente felicitarte por tu gran logro!!!

    Gracias Agustín ;)

  • Agustín Malanco
    Agustín Malanco Miércoles, 23 Julio 2014 02:25 Enlace al Comentario

    Fede,

    ¡Excelente articulo! solo me gustaría comentar algunos casos que se deberían de cubrir:

    * Con respecto al overcommitment se debe de considerar SIEMPRE que cargas son las que se ejecutan, recuerden que en el tema de aplicaciones "Tier 1" lo mejor es siempre reservar la memoria a nivel del Host ESXi (en cada VM) e inluso dentro de la aplicación realizar ciertas modificaciones para prevenir swap/paging (ej. lock pages in memory de SQL)

    * Importante aclarar que TPS y Mem compression se ven afectados cuando utilizas Large Pages, debido a que es casi imposible encontrar páginas de memoria iguales y en el caso que se requiera comprimir memoria estas "Large pages" deberán ser separadas en paginas de 4k (si se llega a un limite "Hard" de MinFreePct)

    *Con respecto a los Nodos NUMA también es importante considerar que el tamaño de las VMs dictarán cual debe de ser el tamaño de estos nodos para prevenir que las VMs esten corriendo como "Wide Numa" y que esto afecte debido a los interconnects de los procesadores (importantisimo para apps sensibles a latencia).

    *Debemos de considerar la configuración de las VMs para poder entender el impacto de sus reservas (en caso que exista, desde mi punto de vista SOLO deben ser utilizadas cuando se justifica) en los distintos controles de admisión, que esto terminará impactando al cluster en cuanto a diseño (ej. tamaño), tolerancia a fallos e incluso a como se constituyen los failure domains (ej. chassises).

    Generalmente desde mi perspectiva es mejor trabajar de arriba para abajo, es decir, definir las cargas a virtualizar, los requerimientos, supuestos y limitantes del proyecto y en base a eso traducirlo hacia una capa física que cumpla con estos lineamientos.

  • Tomás Lara
    Tomás Lara Miércoles, 23 Julio 2014 00:37 Enlace al Comentario

    Bueno consejos Federico, un abrazo.

Deja un comentario

Muchas gracias por tus comentarios!!
Tras la revisión rutinaria, será publicado.

Utilizamos cookies propias y de terceros para facilitar y mejorar nuestros servicios. Al navegar por nuestra página web aceptas nuestras cookies.

Para más información, o para conocer cómo cambiar la configuración, lee nuestra Política de cookies. Saber más

Acepto

Mis Partners