Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Buenas

Uno de los problemas que tenemos con el uso de máquinas virtuales es el procedimiento de "reclamación de espacio". ¿Qué es esto?

Cuando se crea una máquina virtual, se le asigna un "datastore" que es un disco duro lógico. En nuestro caso (y en el de muchas instalaciones) este disco duro lógico está asociado a un volumen definido en un storage externo tipo EMC, Compellent, etc.

Aún cuando un server tenga definido un disco duro lógico de 300GB, en el storage externo se va "gastando" únicamente lo que va consumiendo, esto porque el disco es caro y no tiene sentido marcar como usado algo que no está usado. Entonces, el server al inicio gasta en el storage externo 1GB (o lo que ocupe la instalación inicial del sistema operativo), y si le copias un archivo ISO de 4GB pues el gasto de espacio utilizado en el storage externo será de 5GB.

Hasta ahí vamos bien, no? El problema viene cuando quiero borrar archivos, no se borran del storage externo. La situación sería la siguiente:

Tienes un servidor de archivos que por una razón excepcional se llenó en 3TB. Esos 3TB se "gastaron" en el storage externo. Luego, borras 1 TB de archivos y el sistema operativo te dice ahora que sólo tienes utilizados 2TB, pero en el storage externo sigue marcado como "gastado" 3TB.

En la configuración por defecto, Así tal cual, como diría el hombre que se lo llevaron engañao pa Chillán, efectivamente VMware no le va a decir al storage que libere el espacio utilizado. Googleando y leyendo artículos me encontré con que moviendo perillas en Vmware 6 y tocando configuraciones en Windows 2012 R2 se puede informarle al storage externo que libere el disco ocupado.

http://blog.purestorage.com/direct-guest-os-unmap-in-vsphere-6-0-2/

pero googleando y googleando no veo nada de Linux así de preciso.


En lo que respecta a servidores físicos, que están conectados directamente al storage externo yo hice pruebas y realicé implementaciones con RedHat 6 y ext4 en que se gastaba 1TB por un respaldo de base de datos y cuando ese respaldo se elimina también se libera en el storage Compellent (discard era el flag), pero cuando reiniciaba el servidor ese volumen pedía remontar y escanear los bloques y p'ta, no me gustó así que lo deshabilité. Pero de que se puede se puede. Mi problema es con servers Linux en Vmware...


Leí que con RedHat 7 viene el Kernel 3.0 y el filesystem por defecto es XFS, y ya en esta versión hace "discard" en tiempo real.

http://www.techopsguys.com/2012/03/20/storage-reclamation-under-linux/

http://xfs.org/index.php/FITRIM/discard


¿Alguno de ustedes tiene este problema? ¿Cómo lo resuelven? Yo igual voy a hacer pruebas con RedHat 7 y XFS y si funciona lo documento acá como guía, pero agradecería de ustedes sus experiencias o conocimiento teórico al respecto.

Mi storage es Compellent, pero acá EMC tiene una guía super buena.

http://www.emc.com/collateral/softw...virtual-provisioning-space-reclamation-wp.pdf
 

Cosme

Gold Member
Se incorporó
27 Febrero 2005
Mensajes
8.281
Entonces, por lo que entendí, para simplicar la idea:

*Tienes los discos fisicos

*En un storage dedicado.

*En este storage dedicado armas los volumenes
___en estos volumenes habilitas dedup?
___en estos volumenes habilitas la tolerancia a fallos? es raid o alguna tech propietaria del storage?

*estos volumenes se los presentas al software
___a vmware o se los presentas directamente a la vm? y de como los montas?

*Si se lo presentas directamente a la vm
___con que tipo de conexion?
___en la vm formateas el volumen en el fs que necesitas (cual estas usando en la vm con el problema?)

Depende mucho del software que corras si realmente debas liberar inmediatamente el espacio; recuerda que si habilitas dedup, hay un procesamiento intenso en el nas para calcular los bloques duplicados, y si estas copiando archivos con pocas diferencias, liberar el espacio hará que el dedup trabaje muchisimo mas y genere mas iops de escritura contra los medios fisicos.


Ahorrando blabla, si el disco lo montas en la vm, debes revisar en el software de la vm que haga la notificacion de limpieza; y si lo montas via vmware + vmfs, debes verlo en vmware.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
*En este storage dedicado armas los volumenes
___en estos volumenes habilitas dedup?
___en estos volumenes habilitas la tolerancia a fallos? es raid o alguna tech propietaria del storage?

Dedup es deduplicación?
Internamente el storage tiene su tech para tolerancia a fallo. Mezcla RAID 1 con RAID 5 en storage layers.

*estos volumenes se los presentas al software
___a vmware o se los presentas directamente a la vm? y de como los montas?

Se los presento a Vmware y en VMware creo el datastore, que es un volumen vmware, un volumen virtual.Luego, a la máquina virtual le presento ese datastore.


Depende mucho del software que corras si realmente debas liberar inmediatamente el espacio; recuerda que si habilitas dedup, hay un procesamiento intenso en el nas para calcular los bloques duplicados, y si estas copiando archivos con pocas diferencias, liberar el espacio hará que el dedup trabaje muchisimo mas y genere mas iops de escritura contra los medios fisicos.
Pero al margen de si tiene o no tiene dedup el storage externo, igual por defecto no libera el espacio eliminado por el sistema operativo de la máquina virtual.


Ahorrando blabla, si el disco lo montas en la vm, debes revisar en el software de la vm que haga la notificacion de limpieza; y si lo montas via vmware + vmfs, debes verlo en vmware.

Esa es la huea. En el link que puse en el post inicial muestran como hacer que Windows 2012 realice la notificación de limpieza, pero además hay que hacerle unas magias a Vmware.
No encontré ningún documento que muestre lo mismo con Linux+Vmware, pero en teoría debería ser lo mismo.

Yo les pedía experiencias y consejos porque cuando implementé el discard en ext4 con RedHat 6 en un servidor físico (directo al storage externo) me daba jugo el reinicio y me pedía revisar los sectores malos y todo eso.
 
Upvote 0

Koji Nanjo

Sushiman
Se incorporó
21 Marzo 2006
Mensajes
1.725
Si bien no uso vmware hace rato y menos servidores físicos (solo aws) me suscribo igual porque está interesante :uy
 
Upvote 0

K3rnelpanic

non serviam
Miembro del Equipo
MOD
Se incorporó
1 Octubre 2007
Mensajes
6.065
Ahí para no entrar a la KB de vmware :zippy

To shrink a thin provisioned disk (VMDK):
  1. Use a third-party tool within the guest operating system to zero-out disk blocks that may have previously been written with data, but have subsequently been deleted.
  2. Storage vMotion the virtual machine or VMDK to a datastore formatted with a different block size.
For example, if the VMDK is on a datastore formatted with 2 MB blocks, format the target VMFS datastore with a 1 MB, 4 MB, or 8 MB block size.

To reclaim the unused space of a virtual disk in ESXi/ESX 4.1 or later:

Note: Where vmkfstools supports the -K option (--punchzero), you can reclaim the zeroed blocks of thin-provisioned virtual disks without the need to clone to another VMFS datastore with a different block size.
  1. Ensure that the disk has no Snapshots.
  2. In a Windows virtual machine, run the SDelete command (or a tool with similar functionality) to zero out all unused space. The syntax for the SDelete command is SDelete -z driveletter. If you use SDelete, ensure that you use version 1.6 or later.

    Note: Zeroing all unused blocks inflates the disk to its full size and converts it into an eagerzeroed disk. If the original disk is a thin provisioned disk, ensure that there is sufficient space on the datastore to allow the disk to grow to its full size. For more information, see Determining if a VMDK is zeroedthick or eagerzeroedthick (1011170).

  3. Shut down the virtual machine or temporarily remove the virtual disk from the virtual machine to ensure that it is not in use.
  4. Erase all unused blocks by running the command:

    vmkfstools -K /path/to/disk-name.vmdk


    Note: The punchzero (vmkfstools -K) command is not compatible with NFS based VMFS datastores.

    This option de-allocates all zeroed out blocks and leaves only those blocks that were allocated previously and contain valid data. The resulting virtual disk is in thin format. For more information on the vmkfstools command, see Removing Zeroed Blocks in the ESX Configuration Guide.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
El vmkfstools lo he usado en modo experimental y funciona, pero es un proceso manual medio engorroso que depende de que el sistema operativo libere físicamente los bloques (por ejemplo, utilizando SDelete en Windows).

Ahora estoy creando una máquina virtual con RedHat 7 y XFS para probar algún método online, que no implique tener que invocar procedimientos manuales.
 
Upvote 0

yakko

pingüino mal genio
Se incorporó
24 Agosto 2004
Mensajes
16.883
El vmkfstools lo he usado en modo experimental y funciona, pero es un proceso manual medio engorroso que depende de que el sistema operativo libere físicamente los bloques (por ejemplo, utilizando SDelete en Windows).

Ahora estoy creando una máquina virtual con RedHat 7 y XFS para probar algún método online, que no implique tener que invocar procedimientos manuales.
no he visto que nadie lo haga, pero si activas el discard en los FS de la VM esto va a ir dejando en 0 todos los sectores del disco que ya no se usan.
sube un poco el io, ojo si tienes un server que usa disco muy intensivamente.
 
Upvote 0

Miguelwill

I am online
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
12.403
Aproximadamente cuantos iops requeriría un proceso de limpieza de bloques como lo que estás realizando? Desde que versión de Windows funciona?
Igual no creo que lo use aún

Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0

Cosme

Gold Member
Se incorporó
27 Febrero 2005
Mensajes
8.281
Aproximadamente cuantos iops requeriría un proceso de limpieza de bloques como lo que estás realizando? Desde que versión de Windows funciona?
Igual no creo que lo use aún

Enviado desde mi XT1058 mediante Tapatalk

Si no se dan todas las condiciones, seria 1 iops de escritura por cada sector a marcar como null.
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Si no se dan todas las condiciones, seria 1 iops de escritura por cada sector a marcar como null.

Igual yo creo que es un costo bastante aceptable para un fileserver por ejemplo, porque claro, sacrificas un poco de rendimiento (que probablemente ni lo note el usuario final) a cambio de la posibilidad de ahorrar disco.
 
Upvote 0

Miguelwill

I am online
Miembro del Equipo
MOD
Se incorporó
23 Febrero 2004
Mensajes
12.403
Mm ok, la primera vez debería demorar y agregar algo de carga, pero sería casi como escribir de nuevo esos bloques para el proceso de liberarlos
Funcionará usando un datastore sobre nfs?

Enviado desde mi XT1058 mediante Tapatalk
 
Upvote 0

yakko

pingüino mal genio
Se incorporó
24 Agosto 2004
Mensajes
16.883
Está en un lvm?
Activaste el discard para el lvm?
Los puntos de montaje tienen discard como opción?
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Está en un lvm?
Activaste el discard para el lvm?
Los puntos de montaje tienen discard como opción?

Si.

originalmente el punto de montaje estaba así:

/dev/mapper/rhel_pruebareclamaespaciolinux-home /home xfs defaults 0 1

Luego cambié el fstab a esto

/dev/mapper/rhel_pruebareclamaespaciolinux-home /home xfs defaults,discard 0 1

Reinicié y paff, el fstrim no andó.
# fstrim /home

discard operation not supported
 
Upvote 0

Zuljin

Fundador
Miembro del Equipo
Fundador
ADMIN
Se incorporó
15 Enero 2004
Mensajes
11.872
Parei que el disco no lo soporta.

# more /sys/block/sda/queue/discard_max_bytes
0

Voy a hacer unas magias en VMware y vuelvo.
 
Upvote 0
Subir