Reclamando espacio en cabinas Thin Provision a nivel de vSphere

septiembre 2, 2016 — por Albert Gris0

main

Assoc. Cat. VirtualitzacióCloudCPDDatacoreMetodologíaStorageVirtualizacionVMware

Reclamando espacio en cabinas Thin Provision a nivel de vSphere

septiembre 2, 2016 — por Albert Gris0

Una de las grandes novedades que trajo vSphere 5.0 fueron las APIs de integración con las cabinas para optimizar ciertas tareas, sobretodo aligerando la carga del hipervisor. La idea es pasar esta carga a la cabina, quien tiene más facilidad para operar con los datos que ya residen en ella.

Si tenemos una cabina con configuración compatible con estas APIs, las tenemos habilitadas por defecto por lo que el uso de muchas de sus funcionalidades las usamos de manera transparente. Sin embargo, hay algunas de estas “primitivas” que nos pueden ayudar muchísimo pero hay que conocerlas, puesto que requiere que las invoquemos de alguna manera. Una de ellas es “Unmap”:

“Unmap” resuelve un dolor de cabeza con el que te habrás enfrentado si usas una cabina con Thin Provisioning, que es la reclamación. Thin Provisioning, como toda innovación, aporta muchas ventajas pero también tiene sus consideraciones. Una de ellas es la necesidad de reclamar el espacio inutilizado.

Este espacio se genera cuando el SO de nuestras máquinas virtuales deja de usar una cantidad de almacenamiento que anteriormente usaba. Lo que sucede es que en realidad, el sistema operativo marca este espacio como libre pero no hace lo propio la cabina, quien aún lo mostrará como espacio ocupado en nuestros Disk Groups.
A nivel de vSphere es más sencillo de entender: Supongamos que tenemos una LUN/Datastore de 500GB de capacidad con una VM en ella de 100GB en uso. En ese momento, nuestro Disk Pool en la cabina marcará que tenemos 100GB utilizados. Pero pongamos que, por algún motivo, tenemos que restaurar esa misma VM, en esa misma LUN. Sin problema, podremos mantener las dos VMs y nuestro Datastore marcará un uso de 200GB, hasta que a posteriori, cuando eliminemos la VM original, el uso de nuestro Datastore será 100GB de nuevo. Sin embargo, en nuestro Disk Pool, aparecerán usados 200GB. Tradicionalmente, el procedimiento por el cual recuperábamos esos 100GB que corresponden a la VM original consistía en crear un VMDK “Thick Provisioned – Lazy Zeroed” de un espacio un poco menor que el que marca el Datastore como libre. En nuestro ejemplo, el Datastore marcará 400GB libres por lo que creando un VMDK de ese modo, lo que haremos es marcar todos los bloques que use ese nuevo disco a cero. Una vez realizado, tendremos que decirle a la cabina que reclame espacio en ese Disk Pool. Lo que hará este comando, es buscar bloques a cero que no estén en uso, por lo que podremos recuperar casi la totalidad de los 100GB que ocupaba la VM que hemos ocupado.

Este método conlleva bastantes problemas potenciales más allá de su relativa complejidad:
El paso de crear el VMDK en Eager Zeroed marcará en cero bastantes bloques. Esta operación es bastante pesada para la cabina por lo que podríamos impactar en el rendimiento de otros servicios. Volviendo a las VAAI, otra primitiva que ayuda un montón es “Write Same”. Tradicionalmente, cuando un host ESXi quería marcar a cero bloques (como al crear un disco en Eager Zeroed), lo hacía mandando comandos SCSI a la cabina que lo cargaban en ciclos de procesador y sobretodo, en la cola de la HBA de turno. Con VAAI esta operación la realiza la cabina de manera transparente descargando al host, pero si no es compatible nuestra LUN, querremos tener control con esta operación.
No podemos crear un VMDK del mismo tamaño que el que marca el datastore como libre, pues lo llenaríamos y bloquearíamos las VMs que se ejecutan en él. Igualmente, querremos quedarnos cuanto más cerca posible de ese valor para recuperar cuanto más espacio. La avaricia rompe el saco, cuanto más cerca queramos quedarnos, en más riesgo entraremos.

Todo este procedimiento podemos resumirlo en un simple comando, el comando de esxcli “unmap” (valga la redundancia). Además, nos va a recuperar todo el espacio realmente disponible, pues va iterando en búsqueda de bloques ya no usados y los marca a cero automáticamente. Es importante remarcar que, aunque VMware anuncia que a partir de 5.5 el impacto es mínimo, igualmente vamos a sobrecargar cabina al reclamar, así que mejor hacerlo en horario de mantenimiento.

Visto lo que nos puede aportar “unmap”, veamos cómo podemos invocarlo.

Primero de todo, debemos tener el UUID del datastore anotado. Nos conectaremos por SSH a cualquier ESXi que tenga ese Datastore presentado y, una vez dentro, anotaremos qué UUID tienen las LUNs sobre las que queremos reclamar. Para ello, ejecutaremos el comando
# esxcli storage vmfs extent list.
El output nos dará un listado de los Datastores que ve el host con el nombre que les hayamos dado, y al lado qué UUID tienen las LUNs que lo componen, en la columna “Devices”. Tomamos nota de la que nos interesa y listo.
Antes de nada, tendremos que asegurarnos que nuestro datastore soporta VAAI. Para verlo,
# esxcli storage core device vaai status get -d naa.xxxxxxxxxxxxxxxxxxxxxxxxxx.
El campo “Delete” debe estar en “Supported”.
En este momento ya lo tenemos todo listo para ejecutar el comando “unmap”. Solo queda por discutir un punto: cuantos bloques vamos a “unmapear” por iteración. Aquí, lo mejor es hablar con el fabricante de vuestra cabina para acordar qué valor le damos. Así que estamos preparados, vamos a ejecutar:
# esxcli storage vmfs unmap –u XXXXXXXX-XXXXXXXX-XXXX-XXXXXXX –n YYY, donde la cadena de Xs será el UUID que anotamos en el paso 1 y las Ys el número de bloques que queremos que reclame por iteración.
Por último, podremos monitorizar el proceso mediante esxtop. Ejecutamos el comando # esxtop en nuestro ESXi, clickamos “u” para ir a la ventana de discos/devices, clickamos “f” y escogemos qué campos queremos mostrar.

fields

Depende de la resolución de vuestra pantalla, seleccionad solo el campo de “Device name”, que nos mostrará los naa de las LUNs y “o” y “p” para ver las métricas de comandos de VAAI. Además, si os cabe, podéis incluir el campo “i” para ir monitorizando también los tiempos de latencia en general (R/W) y poder ir viendo que no tengamos ningún susto.

Entonces, una vez hemos seleccionado los campos que queremos ver en nuestra ventana de esxtop y hemos ejecutado nuestro comando de unmap en una LUN, veremos algo como esto:

extop

Las columnas que nos interesan son:
DELETE: número de comandos de unmap que se han ejecutado sobre la LUN
DELETE_F: número de comandos de unmap que han fallado sobre la LUN
MBDEL/s: MB que está “unmapeando” en este momento el comando que hemos ejecutado. Aquí solo deberías ver distinto de cero la LUN que has seleccionado.

Por último, tendremos que reclamar. Recordad que con unmap estamos liberando bloques, o informando a la cabina de qué bloques ya no están en uso en vSphere. Lo que faltará és que la cabina los reclame y por lo tanto los marque como Free en nuestro Disk Pool. Aquí ya cada una lo hará a su manera. La mayoría tendrán un botón de “Reclaim” que barrerá todo el Disk Pool en búsqueda de los bloques que habremos liberado, y que por lo tanto, pueda marcar como libres. En el caso de Datacore por ejemplo, al ejecutar el comando de unmap, se dispara automáticamente la funcionalidad de “Auto-Reclaim” que lo que hará será ir reclamando los bloques que vamos liberando de manera transparente, unmap lo desencadena todo. Lo veréis así (Storage Source – Online, auto-reclamation in progress):

cabina

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

7 + 11 =