vSphere education: ¿cuáles son las desventajas de configurar máquinas virtuales con * demasiada * RAM?

La administración de memoria de VMware parece ser un acto de equilibrio complicado. Con la memoria RAM de clúster, las agrupaciones de recursos, las técnicas de administración de VMware (TPS, globo, intercambio de host), utilización de RAM en el huésped, intercambio, reservas, recursos compartidos y límites, hay muchas variables.

Estoy en una situación en la que los clientes usan recursos de clúster de vSphere dedicados. Sin embargo, están configurando las máquinas virtuales como si estuvieran en hardware físico. A su vez, esto significa que una compilación de VM estándar puede tener 4 vCPU y 16 GB o más de RAM. Vengo de la escuela de comenzar con poco (1 vCPU, RAM mínima), verificar el uso en el mundo real y ajustarlo según sea necesario. Desafortunadamente, muchos requisitos de proveedores y personas que no están familiarizadas con la virtualización solicitan más recursos de los necesarios ... Estoy interesado en cuantificar el impacto de esta decisión.

Algunos ejemplos de un "problema" de clúster.

Resumen del grupo de recursos: parece casi 4: 1 sobrecomprometido. Tenga en cuenta la gran cantidad de RAM en globo.

Asignación de recursos: la columna Asignación del peor caso muestra que estas máquinas virtuales tendrían acceso a menos del 50% de su RAM configurada en condiciones restringidas.

El gráfico de utilización de memoria en tiempo real de la máquina virtual superior en la lista anterior. 4 vCPU y 64 GB de RAM asignados. Tiene un promedio de uso inferior a 9 GB.

Resumen de la misma VM

• ¿Cuáles son las desventajas de comprometerse en exceso y configurar en exceso los recursos (específicamente RAM) en entornos vSphere?

• Suponiendo que las máquinas virtuales pueden ejecutarse en menos RAM, ¿es justo decir que hay gastos generales para configurar máquinas virtuales con más RAM de la que realmente necesitan?

• ¿Cuál es el contraargumento de: "si una VM tiene 16 GB de RAM asignados, pero solo usa 4 GB, ¿cuál es el problema? " Por ejemplo, ¿es necesario que los clientes sepan que las máquinas virtuales no son lo mismo que el hardware físico?

• Qué métrica (s) específica (s) se deben usar para medir el uso de RAM. ¿Rastreando los picos de "Activo" versus tiempo? Viendo "Consumido"?

Actualización: utilicé vCenter Operations Manager para perfilar este entorno y obtener algunos detalles sobre las estadísticas del clúster enumeradas anteriormente. Si bien las cosas definitivamente están sobrecomprometidas, las máquinas virtuales están realmente tan sobreconfiguradas con RAM innecesaria que la huella de memoria real (pequeña) no muestra contención de memoria a nivel de clúster / host ...

Mi conclusión es que las máquinas virtuales realmente deberían tener el tamaño correcto con un poco de búfer para el almacenamiento en caché a nivel del sistema operativo. Comprometerse demasiado por ignorancia o por "requisitos" del proveedor lleva a la situación presentada aquí. El aumento de memoria parece ser malo en todos los casos, ya que hay un impacto en el rendimiento, por lo que el tamaño correcto puede ayudar a prevenir esto.

Actualización 2: algunas de estas máquinas virtuales comienzan a bloquearse con:

kernel:BUG: soft lockup - CPU#1 stuck for 71s! 

VMware describe esto como un síntoma de exceso de compromiso de memoria . Entonces supongo que eso responde la pregunta.

Informe de vCops "Máquinas virtuales de gran tamaño" ...

Gráfico de vCops "Residuos reciclables" ...

La administración de memoria de vSphere es bastante decente, aunque los términos utilizados a menudo causan mucha confusión.

En general, se debe evitar el exceso de memoria ya que crea exactamente este tipo de problema. Sin embargo, hay momentos en los que no se puede evitar, por lo tanto, ¡prevenido está prevenido!

¿Cuáles son las desventajas de comprometer y configurar en exceso los recursos (específicamente RAM) en entornos vSphere?

La desventaja principal de los recursos que se comprometen en exceso es que si tuviera una disputa, sus hosts se verían obligados a aumentar, intercambiar o programar / desduplicar de forma inteligente detrás de escena para dar a cada VM la RAM que necesita.

Para la creación de globos, vSphere inflará un "globo" de RAM dentro de una VM elegida, luego le dará esa RAM en globo al huésped que lo necesita. Esto no es realmente "malo": las máquinas virtuales se están robando la RAM de la otra, por lo que no hay intercambio de discos en curso, pero podría dar lugar a alertas erróneas y métricas sesgadas si estas dependen del análisis del uso de RAM de la máquina virtual, ya que la RAM ganó No se marque como "globo", solo que está "en uso" por el sistema operativo.

La otra característica que puede usar vSphere es Transparent Page Sharing (TPS), que es esencialmente la deduplicación de RAM. vSphere escaneará periódicamente toda la RAM asignada, buscando páginas duplicadas. Cuando se encuentre, se deduplicará y liberará las páginas duplicadas.

Echar un vistazo a la Dirección de memoria vSphere documento técnico (PDF) - específicamente "Memoria de Recuperación en ESXi" (página 8) - si necesita una explicación más en profundidad.

Suponiendo que las máquinas virtuales pueden ejecutarse en menos RAM, ¿es justo decir que hay gastos generales para configurar máquinas virtuales con más RAM de la que necesitan?

No hay sobrecarga visible: puede asignar 100 GB de RAM en un host con 16 GB (sin embargo, eso no significa que deba hacerlo , por las razones anteriores).

La memoria total en uso por todas sus máquinas virtuales es la curva "Activa" que se muestra en sus gráficos. Por supuesto, nunca debe confiar solo en esa cifra cuando calcule cuánto le gustaría comprometerse demasiado, pero si tiene métricas históricas como las que tiene, puede analizarlas y calcularlas en función del uso real.

La diferencia entre RAM "Activa" y "Consumida" se discute en este hilo de VMWare Community .

¿Cuál es el contraargumento para: "si una VM tiene 16 GB de RAM asignados, pero solo usa 4 GB, cuál es el problema?" ? Por ejemplo, ¿los clientes necesitan ser educados?

La respuesta breve a esto es sí : los clientes siempre deben ser educados en las mejores prácticas, independientemente de las herramientas a su disposición.

Los clientes deben ser educados para dimensionar sus máquinas virtuales de acuerdo con lo que usan , en lugar de lo que quieren . La mayoría de las veces, las personas especificarán en exceso sus máquinas virtuales solo porque podrían necesitar 16 GB de RAM, incluso si históricamente están trabajando en 2 GB día tras día. Como administrador de vSphere, tiene el conocimiento, las métricas y el poder para desafiarlos y preguntarles si realmente necesitan la RAM que han asignado.

Dicho esto, si combina la administración de memoria de vSphere con límites de sobrecompromiso cuidadosamente controlados, rara vez debería tener un problema en la práctica, la probabilidad de quedarse sin RAM durante un período prolongado de tiempo es relativamente remota.

Además de esto, vMotion automatizado (llamado Programación de recursos distribuidos por VMware) es esencialmente un equilibrador de carga para sus máquinas virtuales: si una sola máquina virtual se está convirtiendo en un acaparador de recursos, DRS debe migrar las máquinas virtuales para aprovechar al máximo los recursos del clúster.

Qué métrica específica se debe usar para medir el uso de RAM. ¿Rastreando los picos de "Activo" versus tiempo?

Principalmente cubierto anteriormente: su principal preocupación debe ser el uso de RAM "activa", aunque debe definir cuidadosamente sus umbrales de sobrecompromiso para que si alcanza una cierta proporción ( este es un ejemplo decente , aunque puede estar un poco desactualizado). Por lo general, me quedaría dentro del 120% de la RAM total del clúster, pero depende de usted decidir con qué relación se siente cómodo.

Algunos buenos artículos / debates sobre el exceso de memoria:

• ¿Sobrecompromiso de memoria en producción? SI SI SI
• vSphere: ¿memoria excesiva?
• Sobrecompromiso de memoria en vSphere

Además de la excelente respuesta de Craig Watson, me gustaría agregar lo siguiente:

El exceso de memoria en VMware no es algo que deba hacer a propósito. En general, muestra que usted o su cliente están suscribiendo en exceso el hardware.

Si exceso de la comisión es la única opción entonces fuertemente aconsejo que cumplir las reglas de prioridad. Si alguien está decidido a dar una VM no crítica de 16 GB de vRam cuando solo necesita 4 GB, al menos coloque esa VM en un grupo de recursos bajos o déle una prioridad baja. Realmente no desea que el hipervisor intercambie una base de datos de producción crítica. El rendimiento no solo disminuirá, sino que también consumirá las colas de E / S contra su almacenamiento de back-end.

Si está ejecutando un almacenamiento increíblemente rápido (FusionIO, Violin, SSD locales, etc.), el intercambio podría no ser una gran preocupación, pero con el almacenamiento SAN tradicional eventualmente afectará a cada VM y host conectados al mismo arreglo / controlador.