vSphere 5 – Lo nuevo en VAAI ¿NFS?

Que tal gente, vamos a continuar con lo nuevo de vSphere 5 en almacenamiento, es momento de hablar de VAAI (fase 2). En vSphere 4 ya contábamos con distintas primitivas de VAAI (instrucciones SCSI), para poder realizar una descarga de funciones hacia el almacenamiento permitiendo así poder optimizar operaciones como clonado, snapshots, creación de discos eageredzeroed, etc.

En vSphere 5 se continua con el desarrollo de las primitivas VAAI y se nos entregan nuevas capacidades, vamos a comenzar hablando de VAAI y NFS:

En vSphere 5 tenemos las siguientes primitivas para NAS:

  • Full file clone – muy parecido a lo que tenemos con VAAI y VMFS en el caso de clonado de bloques, esta primitiva permite que el servidor NFS realice el clonado del archivo en cuestión.

 

  • Native snaphsot support – Con esta primitiva en el momento de tomar un snapshot a nivel de VMware de una vm la creación del redo log (disco delta) será descargada al servidor NAS.

 

  • Reserve Space – permite la creación de vmdks en formato “thick”, recordemos que anteriormente solo teníamos la opción de tener discos thin provision en un almacenamiento NFS:

Sin VAAI

Con VAAI

Algo interesante que debemos saber es que los plugins de VAAI para NAS no están incluidos con ESXi 5.0 cada proveedor entregará un paquete .vib con el plugin.

También es bueno saber que tenemos manejo de NAS a través de esxcli:

esxcli storage nfs [add/list/remove]

En esta fase 2 de VAAI se nos entrega una nueva primitiva conocida como Dead space reclamation o UNMAP . Con el uso de Thin provision a nivel de almacenamiento se presentan varios problemas:

Al crear y borrar archivos se acumula “espacio en blanco” en el momento que nosotros estamos trabajando un LUN en modo thin provision (de almacenamiento) cuando creamos archivos se asignan los bloques necesarios, ¿Pero que pasa cuando estos archivos (VMs, vmdks, logs, snaps,etc) son migrados o borrados? los bloques que estos archivos ocuparon no son reclamados por el almacenamiento, teniendo una situación como la siguiente:

Sin UNMAP

La primitiva de UNMAP (42h) nos ayuda a recuperar ese espacio en blanco o bloques que fueron utilizados anteriormente por los archivos que se encontraban alojados en dicha LUN en formato Thin haciéndole saber al sistema de almacenamiento que dichos bloques ya no están en uso:

Con UNMAP

Esta primitiva nos ayuda a poder tener una utilización real de nuestro almacenamiento, y viene a complementar todas las funciones como Storage VMotion, SDRS, etc.

Con el siguiente comando podemos saber si nuestro LUN soporta UNMAP:

esxcli storage core device vaai status get -d naa.xxxx

Podemos reclamar espacio existente en un sistema de archivos VMFS-3 que haya sido actualizado a VMFS-5 con los siguientes comandos:

cd /vmfs/volumes/volumen_Thin

vmkfstools -y [valorarecuperar]

ejemplo:

Por ultimo podemos deshabilitar UNMAP (solo en casos que sea requerido por soporte VMware):

esxcli system advcfg setvalue –int-value 1 –option /VMFS3/EnableBlockDelete

Leave a Reply