Introducción sobre el reclamo de espacio muerto que perteneció a VAAI Thin Provisioning Primitives

69 0 0 0

Una nueva primitiva VAAI, utilizando el comando SCSI UNMAP, permite que un host ESXi informe a la matriz de almacenamiento que se puede reclamar espacio que anteriormente había sido ocupado por una máquina virtual que se había migrado a otro almacén de datos o se había eliminado. Esto permite que una matriz informe con precisión el consumo de espacio de un suministro ligero

almacena datos y permite a los usuarios monitorear y pronosticar correctamente los nuevos requisitos de almacenamiento.

El mecanismo para realizar una operación de recuperación de espacio ha cambiado algo desde que se introdujo la primitiva en vSphere 5.0. Luego, la operación fue automática: cuando se migraba una máquina virtual de un almacén de datos o se eliminaba, se llamaba a UNMAP inmediatamente y se reclamaba el espacio en la matriz. Había

algunos problemas con este enfoque, sin embargo, principalmente con respecto al rendimiento y la capacidad de una matriz para recuperar el espacio en un marco de tiempo óptimo. Por esta razón, la operación UNMAP es ahora un proceso manual. Debido a que es la única primitiva iniciada manualmente, el proceso para reclamar el espacio muerto se discutirá en detalle.

Para reclamar el espacio muerto de un almacén de datos de aprovisionamiento ligero en vSphere 5.1, primero verifique que la matriz de almacenamiento sea capaz de procesar el comando SCSI UNMAP. Con esxcli, los usuarios pueden mostrar detalles específicos del dispositivo con respecto a Thin Provisioning y VAAI.


# esxcli storage core device list –d naa.xxx

naa.xxx

Nombre para mostrar: Disco de canal de fibra NETAPP (naa.xxx)

Tiene nombre para mostrar configurable: verdadero

Tamaño: 51200

Tipo de dispositivo: acceso directo

Plugin Multipath: NMP

Ruta de Devfs: /vmfs/devices/disks/naa.xxx

Proveedor: NETAPP

Modelo: LUN

Revisión: 8020

Nivel SCSI: 4

Es pseudo: falso

Estado: en

Es RDM Capable: verdadero

Es local: falso

Es removible: falso

Es SSD: falso

Está desconectado: falso

Está siempre reservado: falso

Estado de aprovisionamiento fino: sí

Filtros adjuntos: VAAI_FILTER

Estado VAAI: soportado

Otros UIDs: vml.xxx


El dispositivo es, en efecto, de aprovisionamiento fino y admite VAAI A continuación, los usuarios pueden mostrar las primitivas VAAI admitidas por la matriz para ese dispositivo, así como si la matriz admite la primitiva UNMAP para la recuperación de espacio muerto (denominada estado de eliminación). Se utiliza otro comando esxcli para este paso, como se muestra a continuación:


# esxcli storage core device vaai status get -d naa.xxx

naa.xxx

Nombre del complemento VAAI: VMW_VAAIP_NETAPP

Estado ATS: soportado

Estado de clonación: soportado

Estado cero: apoyado

Estado de eliminación: apoyado



El dispositivo muestra Eliminar estado: admitido para indicar que es capaz de enviar comandos SCSI UNMAP a la matriz cuando se solicita una operación de recuperación de espacio.

Si se inicia una operación de Storage vMotion y se mueve una máquina virtual de un almacén de datos de origen a un almacén de datos de destino, las siguientes acciones reclamarán ese espacio: Cuando la operación de Storage vMotion se haya completado, vSphere Client informará que el volumen VMFS5 ahora tiene mucho Más espacio libre. El problema es

que cuando se comprueba la cantidad de espacio libre en el LUN de aprovisionamiento fino que respalda este volumen VMFS5 en la matriz de almacenamiento, hay espacio sin utilizar y trenzado. En este ejemplo, una matriz FAS de NetApp proporciona el almacenamiento de back-end. Al usar un comando lun show CLI en esta matriz de NetApp, vemos a continuación que 8.8GB de

se sigue consumiendo espacio, aunque ahora no hay máquinas virtuales ni otros archivos en este almacén de datos.



lun show -v / vol / vol2 / thin-lun

/ vol / vol2 / thin-lun 50g (53687091200) (r / w, en línea, mapeado)

Número de serie: xxx

Compartir: ninguno

Reserva de espacio: deshabilitado

Tipo multiprotocolo: vmware

Mapas: unmap = 51 issi = 51

Tamaño ocupado: 8.8g (9473908736)

Hora de creación: mar 24 de abril 15:16:52 BST 2012

Información de volumen compartido del clúster: 0x0



Este es el quid del problema que intentamos resolver con la primitiva VAAI UNMAP. Para ejecutar el comando UNMAP, cambie el directorio a la raíz del volumen VMFS del que desea reclamar espacio. Se ejecuta el siguiente comando:


vmkfstools –y <% de espacio libre para desasignar>


En este ejemplo, intentamos una recuperación del 60 por ciento del espacio libre. El comando vmkfstools -y muestra lo siguiente:



Intento de recuperar el 60% de la capacidad libre de 48.8 GB (29.3 GB) en el sistema de archivos VMFS-5

"Almacén de datos de origen" con un tamaño máximo de archivo de 64 TB.

Cree el archivo .vmfsBalloontsWt8w de tamaño 29.3 GB para reclamar bloques libres.

Hecho.



vmkfstools -y creó un archivo de globo de 29.3GB, que es el 60 por ciento de la capacidad libre (48.8GB). Esta

tempora **** alloon file es igual al tamaño del espacio a ser desasignado / reclamado.



NOTA: Precaución: si se especifica un valor de porcentaje en los 90 o 100 altos, el archivo tempora **** alloon que se crea durante la operación de recuperación puede llenar el volumen VMFS. Cualquier crecimiento de los archivos VMDK actuales debido a la ejecución de máquinas virtuales que escriben en sus discos o la creación de nuevos archivos, como instantáneas, puede fallar.

al espacio no disponible. Se debe tener cuidado al calcular la cantidad de espacio libre para reclamar.


Finalmente, consulte el estado del LUN de aprovisionamiento delgado en la matriz de almacenamiento. Debería mostrar una diferencia en

Tamaño ocupado, como se muestra a continuación:


lun show -v / vol / vol2 / thin-lun

/ vol / vol2 / thin-lun 50g (53687091200) (r / w, en línea, mapeado)

Número de serie: xxx

Compartir: ninguno

Reserva de espacio: deshabilitado

Tipo multiprotocolo: vmware

Mapas: unmap = 51 issi = 51

Tamaño ocupado: 76.3m (79966208)

Hora de creación: mar 24 de abril 15:16:52 BST 2012

Información de volumen compartido del clúster: 0x0



El espacio muerto se ha reclamado con éxito para el almacén de datos de aprovisionamiento delgado; la matriz ahora puede informar correctamente el uso del espacio.



La desactivación de la primitiva UNMAP no afecta a ninguna de las otras primitivas de aprovisionamiento ligero, como el aturdimiento de aprovisionamiento fino y la advertencia de umbral de espacio. Todas las primitivas son ortogonales.


  • x
  • convención:

Responder

Responder
Debe iniciar sesión para responder la publicación Inicio de sesión | Registrarse

Aviso: Para garantizar sus legítimos derechos e intereses, la comunidad y los terceros no publicarán contenido que pueda generar riesgos legales a las partes, por ejemplo, pornografía, contenido político, contenido sobre juego, consumo y tráfico de drogas, así como contenido que viole los derechos de propiedad intelectual de terceros, por ejemplo, secretos comerciales, marcas, derechos de autor, patentes y privacidad personal. No comparta su cuenta ni su contraseña con terceros. Todas las operaciones realizadas usando su cuenta se considerarán como sus acciones y todas las consecuencias que estas acciones generen serán responsabilidad suya. Para obtener información detallada, consulte la “ Política de privacidad.”
Si el botón para adjuntar no está disponible, actualice Adobe Flash Player con la versión más reciente

¡Ingresa y disfruta de todos los beneficios para los miembros!

Aterrizaje
Respuesta rápida Desplácese hasta arriba