¿Ejecutar permanentemente en una instantánea VMWare es malo para el rendimiento?

Entiendo que el VMWare KB desaprueba las instantáneas de larga duración debido principalmente a dos cosas (en mi opinión)

• Tomar toneladas de instantáneas puede llenar el almacén de datos. Las instantáneas son simplemente archivos delta. Digamos que tiene un VMDK de 50 Gig, casi lleno, y toma una instantánea. En su instantánea, voltea cada bit. Su archivo delta también tendrá unos 50 GB. Instantánea de nuevo, voltear los bits, otro archivo delta 50 Gig. Estos pueden salirse de control rápidamente.

• Cometer grandes instantáneas conlleva riesgos. Al consolidar las instantáneas, está escribiendo los cambios delta en el VMDK original. Esto lleva tiempo y conlleva el riesgo de que si sucede algo, simplemente destruya su VMDK.

Sus advertencias parecen tener sentido lógico.

Dicho esto, ¿es inherentemente malo ejecutar mi máquina permanentemente fuera de una instantánea VMDK? Quiero hacer que mi árbol sea el siguiente:

• Base
  • Snap1
    • Snap 2
    • Estás aquí

Los Snap 1 y 2 se tomarán inmediatamente después de instalar y aprovisionar el sistema base. Estas son máquinas que planeo actualizar con frecuencia, así que simplemente haré que mi árbol se vea así:

• Base
  • Snap1
    • Estás aquí
    • Snap 2

Eliminar Snap2 y recrear Snap2.

No puedo ver cómo esto podría tener implicaciones por las siguientes razones:

• Como simplemente instalé una imagen base y tomé mis deltas inmediatamente después de que no hay forma de que pueda llenar el almacén de datos. Suponiendo que mi imagen base es de solo 10 GB (en un disco de aprovisionamiento delgado de 50 GB), incluso si mi delta se voltea cada bit, el máximo de mi uso total podría ser 60 GB (VMDK base de 10 GB que está bloqueado + 50 GB de delta en el archivo VMDK de instantánea). Esto supone que no creo más instantáneas.

• Como mi caso de uso no requiere la consolidación de las instantáneas, no corro el riesgo de errores al consolidar mis deltas. Cuando vuelvo a Snap1 y elimino Snap2, todo el delta que residía en Snap2 simplemente se elimina.

• La carga de almacenamiento es exactamente la misma, por lo que debería recibir los mismos IOPS. Entiendo que algunos archivos (principalmente archivos del sistema) existirán en el VMDK original y otros (todo después de la base) residirán en el delta, pero no veo cómo le importaría a ESXI. Todos los archivos están en el mismo almacén de datos físico, por lo que el rendimiento debe ser equivalente a hacer referencia a todo en el VMDK original sin instantáneas.

¿Alguna idea? ESXI 5.5 con el almacén de datos siendo RAID'd DAS.

No tengo una licencia de vCenter, por lo que la plantilla y la clonación están fuera de la mesa.

RESULTADOS DE LA PRUEBA

Hoy llegué temprano para hacer algunas pruebas. Aquí están los resultados. Hay una penalización de rendimiento, pero no estoy seguro de por qué.

Antes de la instantánea:

Después de la instantánea:

Sí, hay implicaciones de rendimiento para las instantáneas de larga duración. Hay implicaciones aún mayores para consolidar VMDK delta de nuevo al archivo de disco original. Esto puede causar falta de respuesta en el sistema operativo de su VM u otro comportamiento indeseable.

VMware tiene una funcionalidad de creación de plantillas y clonación integrada en vCenter. Necesita una licencia de vSphere Essentials de $ 600 para habilitar esto.

Puede crear una VM a su gusto y luego clonarla en una plantilla. Esa plantilla se puede utilizar para generar nuevas máquinas virtuales a partir de una imagen "Golden Master".

Esto le permite tener un "estado limpio" pero también crear máquinas virtuales permanentes o de larga duración a partir de esa imagen maestra. No se necesitan instantáneas.

La respuesta de ewwhite es correcta, pero solo para ampliar un poco más o la penalización de rendimiento, considere el siguiente escenario:

Creas una VM. Una lectura virtual de vmdk toma una lectura de disco físico del mismo tamaño. Bastante sencillo.

Ahora imagine que toma una instantánea de la VM. Ahora, por cada lectura virtual, incurrirá en 2 lecturas físicas, una del vmdk base y otra del vmdk delta, porque necesita información de ambas para obtener el estado actual. Ahora tiene el doble de lecturas del disco físico.

Para dos instantáneas, está haciendo tres veces las lecturas, y así sucesivamente. Si tiene muchas instantáneas, puede ver cómo esto puede ser una penalización de rendimiento bastante significativa. No necesariamente se traduce en un rendimiento n veces peor (debido al almacenamiento en caché, secciones que no se han cambiado, etc.), pero no es una buena práctica.

Las instantáneas de VMware ESX están destinadas para uso a corto plazo.

El uso prolongado y las E / S intensas pueden causar congelaciones de VM. Si tiene un caso cuando escribir IO es más grande / más rápido que la consolidación de instantáneas, ESX congelará la VM para proteger los datos. Con el tiempo, las instantáneas se fragmentan y ESX realiza la consolidación interna, puede experimentar congelaciones periódicas.

Puede realizar plantillas de VM manualmente a través de ssh. Copie la carpeta VM que contiene vmdk, vmx, etc. a una carpeta nueva. En el archivo vmx de la VM recién copiada, cambie el UID y la dirección MAC.

VMware tiene un producto, Linked Clone, que es lo mismo que está intentando hacer. Y dicen que tiene problemas potenciales de rendimiento. En la práctica, remasterizarás las máquinas virtuales después de un tiempo. https://www.vmware.com/support/ws5/doc/ws_clone_typeofclone.html