VMware: Vistazo rápido a UNMAP y novedades en vSphere 6.7 – Reclamando espacio vacío en disco

Saludos amigos, hace unos días que me encontraba con preguntas sobre UNMAP, así que he preferido crear este breve post para contaros mas.

¿Qué es VMware UNMAP?

VMware UNMAP es un comando que nos permite recuperar espacio de bloques que ya han sido escritos después de que se hayan eliminado los datos que residían previamente en esos bloques de datos.

Cuando se hace uso de cualquier almacenamiento SAN y se está usando VMware VMFS, cuando los datos se eliminan en VMs que se está usando thin provision, el almacenamiento no es consciente de esa eliminación. El almacenamiento todavía “ve” que los datos están siendo asignados. La capa de abstracción que proporciona VMFS introduce este “problema” único que impide que el almacenamiento vea la capacidad real que realmente existe después de que se eliminan los archivos.

Si hacemos una referencia a la documentación de  VMware vSphere 6.7 :

VMFS6 procesa la petición unmap del SO huésped sólo cuando el espacio a recuperar es igual a 1 MB o es múltiplo de 1 MB. Si el espacio es inferior a 1 MB o no está alineado con 1 MB, las solicitudes no asignadas no se procesan.

Para máquinas virtuales con snapshots en el formato SEsparse predeterminado, VMFS6 admite la recuperación automática de espacio sólo en hosts ESXi versión 6.7 o posterior. Si migramos las VM a hosts ESXi versión 6.5 o anterior, la recuperación automática de espacio deja de funcionar para las VM con snapshots.

Una vez conocemos la teoría, vamos a ver todas las novedades que vSphere 6.7 nos trae respecto a UNMAP.

Comprobando la configuración de UNMAP en nuestro vSphere Client

Nos iremos hasta nuestro  vSphere Client y seleccionaremos Storage > haremos click en Datastore > General > Space Reclamation

Podremos ver a qué velocidad nuestro UNMAP está configurado, por defecto seguramente sea a la velocidad mínima, podemos aumentar esta velocidad hasta los 2000MB/s si nuestro Storage nos lo permite.

Si quisiéramos comprobarlo mediante CLI, el comando sería el siguiente, cambiar el nombre del Datastore por el vuestro:

esxcli storage vmfs reclaim config get --volume-label=ZINT-ESXi2-SSD-03
   Reclaim Granularity: 1048576 Bytes
   Reclaim Priority: low
   Reclaim Method: fixed
   Reclaim Bandwidth: 2000 MB/s

Novedades en vSphere 6.7: UNMAP en el Sistema Operativo Guest y Snapshots

Una de las novedades que vSphere 6.7 nos trae frente a anteriores versiones es que gracias a VMFS6 y vSphere 6.7, haciendo uso de SESparse en Snapshots de discos thin, si superamos el umbral de 2GB de espacio que se puede recuperar en el Sistema Operativo, VMware lanzará el trabajo de UNMAP automáticamente para reclamar ese espacio. Vamos a verlo con un ejemplo.

Tengo una VM con un disco de 400GB en modo Thin, he realizado un Snapshot, donde podemos ver que nos genera el fichero de SESparse adicionalmente, de momento son 1.8GB casi como podemos ver:

[root@esxi-zlon-002:/vmfs/volumes/5b296914-d4b2cb3f-2414-0cc47a7b5fa2/Veeam-B&R-v9.5] ls -la
-rw-------    1 root     root     1796734976 Dec  9 15:02 Veeam-B&R-v9.5_1-000001-sesparse.vmdk
-rw-------    1 root     root           329 Dec  9 01:31 Veeam-B&R-v9.5_1-000001.vmdk
-rw-------    1 root     root     429496729600 Dec  9 01:02 Veeam-B&R-v9.5_1-flat.vmdk
-rw-------    1 root     root           561 Dec  8 20:21 Veeam-B&R-v9.5_1.vmdk

He copiado unos vídeos del VMworld USA a este disco para inflar de manera temporal este fichero:

Con lo que si lanzo el comando de nuevo, mi SESparse ocupa ahora 12GB:

[root@esxi-zlon-002:/vmfs/volumes/5b296914-d4b2cb3f-2414-0cc47a7b5fa2/Veeam-B&R-v9.5] ls -la
-rw-------    1 root     root     12737052672 Dec  9 15:32 Veeam-B&R-v9.5_1-000001-sesparse.vmdk
-rw-------    1 root     root           329 Dec  9 01:31 Veeam-B&R-v9.5_1-000001.vmdk
-rw-------    1 root     root     429496729600 Dec  9 01:02 Veeam-B&R-v9.5_1-flat.vmdk
-rw-------    1 root     root           561 Dec  8 20:21 Veeam-B&R-v9.5_1.vmdk

Vamos a lanzar una prueba y borrar todos los ficheros que hemos añadido, de tal forma que el UNMAP se lanzará, pero antes vamos a ver cómo podemos monitorizar que se está haciendo de manera correcta, desde un SSH, lanzaremos un esxtop y nos iremos a la sección de VMs (presionando“v”) después añadiremos las estadísticas de UNMAP (presionar “f” y luego “L”).

Current Field order: ABCDEfghIJKL

* A:  ID = Vscsi Id
* B:  GID = Grp Id
* C:  VMNAME = VM Name
* D:  VDEVNAME = Virtual Device Name
* E:  NVDISK = Num of Virtual Disks
  F:  NUMIOFILTERS = Num of IOFilters 
  G:  IOFILTERCLASS = IOFILTERCLASS TYPE
  H:  IOFILTERSTATS = IOFILTER STATS
* I:  IOSTATS = I/O Stats
* J:  LATSTATS/rd = Read Latency Stats (ms)
* K:  LATSTATS/wr = Write Latency Stats (ms)
* L:  UMPSTATS = Unmap Stats

Toggle fields with a-l, any other key to return:

Ahora que tenemos ya el ESXTOP funcionando y mostrándonos las estadísticas de UNMAP, podremos continuar:

Si lanzamos ahora una prueba, y eliminamos todos estos ficheros de la VM, podremos ver que el proceso de UNMAP sucede de manera inmediata y recuperamos el espacio en disco de manera automática, incluso en este Snapshot, en vSphere 6.7:

Con lo que conseguiremos Snapshots más eficientes y ocupando menos espacio en disco si usamos vSphere 6.7 y VMFS6 en nuestros Datastores de nuestras cabinas.

Si queréis conocer más en detalle sobre UNMAP, os dejo el siguiente enlace a la sesión de los VMworld US y Europe:

• https://storagehub.vmware.com/t/vsphere-storage/vmworld-2/better-storage-utilization-with-space-reclamation-unmap-hci3331bu/

Un saludo y espero que os guste.