Saltar al contenido

VAAI & VVOL – quién ahora está a cargo de trabajar con los depósitos

VAAI & VVOL - quién ahora está a cargo de trabajar con los depósitos

Si ya está familiarizado con las características de la sexta versión de vSphere, probablemente también esté interesado en la nueva lógica de trabajar con archivos: VVOL. Continuando con el estudio de la idea de «VMDK como elemento principal de almacenamiento», propongo la traducción de un artículo de los compañeros de punchingclouds.com con un estudio detallado de cómo se llevó a cabo la delegación de diferentes tareas al almacenamiento de ESX y está sucediendo.

Hay muchos términos y abreviaturas en el artículo: si ha olvidado alguno de ellos, al final del material he preparado un pequeño glosario.

En 2011, VMware presentó vSphere 4.1 con soporte para VAAI, una nueva API para dispositivos de bloque. Esta interfaz ayudó a mejorar el rendimiento de VMFS al delegar algunas operaciones a la matriz de discos. Las versiones posteriores agregaron soporte para dispositivos NAS, tecnología Thin Provision y el conjunto de instrucciones T10 para almacenamiento en bloque.

Con el lanzamiento de Virtual Volumes (VVOL), la compañía ha introducido un nuevo enfoque para interactuar con máquinas virtuales, en el que sus discos se convierten en el control principal de los sistemas de almacenamiento. La nueva idea permite operaciones a nivel de arreglo (como instantáneas) en VMDK individuales, lo que permite que la aplicación se «alinee» con sus datos reales y ofrece la flexibilidad para hacer cumplir todo tipo de políticas de almacenamiento.

La pregunta sigue siendo: ¿Qué función se asigna ahora a la API VAAI y cómo se relaciona con VVOL? Cuando se trabaja con volúmenes virtuales, el host ESXi controla no solo el flujo de datos, sino también el canal de control al arreglo. Entonces, VVOL parece una extensión más avanzada de la interfaz NAS VAAI. Bueno, propongo examinar los escenarios típicos para la interacción de volúmenes virtuales con VAAI.

GO vs VVOL

Blocky GO y VVOL

GO describe las primitivas SCSI básicas que utiliza el hipervisor para descargar algunas operaciones al almacenamiento. Al mismo tiempo, mucho depende del sistema de archivos VMFS, que administra el proceso y envía directamente los comandos GO TO.

Gracias a VVOL, los sistemas de almacenamiento ahora son conscientes de la presencia de discos virtuales y pueden crear instantáneas, clones y deshacer VMDK específicos.

Sin embargo, el bloqueo VAAI y el aprovisionamiento ligero aún coexisten con los nuevos volúmenes virtuales:

  • Operaciones ATS Todos config VVOL en el almacenamiento de volumen virtual están formateados para VMFS y, por lo tanto, requieren soporte para comandos ATS. La compatibilidad con este conjunto de comandos está determinada por la presencia del ATS para el LUN de punto final de protocolo (PE) con el que están asociados los volúmenes virtuales.
  • XCOPY cuando se trabaja con volúmenes virtuales, ESXi siempre intenta utilizar el mecanismo de copia de VVOL utilizando fuerzas de matriz, utilizando primitivas copia las diferencias al volumen virtual o Clon de volumen virtual. Si no son compatibles, se utilizará el método de copia de software normal. Dado que la copia electrónica implica la transferencia de datos entre PE LUN y VMFS LUN, existe alguna posibilidad de utilizar XCOPY en este caso. Cuando se llama al método de movimiento programático, vSphere usa el comando XCOPY para mover una máquina virtual de VMFS al almacenamiento VVOL (o entre particiones VVOL). En la primera versión de los volúmenes virtuales, XCOPY no se usa al migrar una VM desde una partición VVOL a un volumen normal. El hipervisor determina la compatibilidad con XCOPY en función de la presencia de VAAI XCOPY en el PE LUN al que está asociado el volumen virtual.
  • Bloque de puesta a cero. El objetivo principal de esta primitiva es inicializar discos gruesos en volúmenes VMFS. Pero para los datos en volúmenes virtuales, no se usa, ya que VMFS en la sección de configuración de VVOL contiene solo metadatos (descriptores, archivos vmx, estadísticas y registros). En este caso, el tipo de disco de la máquina virtual se selecciona al crear la partición VVOL y la configuración de VVOL es «delgada» por definición.

NAS GO y VVOL

A diferencia de la versión masiva, toda la funcionalidad NAS VAAI se expone a través de llamadas RPC mediante un complemento de proveedor de almacenamiento. VVOL amplía este modelo con un conjunto de API de VASA, que le permite asumir los hombros de almacenamiento de casi todas las operaciones en la esfera. En vSphere v6, el VAAI NAS existente seguirá funcionando como antes, pero los volúmenes virtuales más avanzados son claramente más rápidos y funcionales. Finalmente, el uso de VVOL no requiere la instalación de un complemento del proveedor de almacenamiento. Otro punto importante con respecto a GO NAS: sus copias instantáneas no se pueden migrar. Si intenta ejecutar Storage vMotion en una máquina con tal volumen, se perderá todo el historial de instantáneas de GOAI. Para los volúmenes virtuales, esto no es un problema, admite la transferencia de instantáneas entre NFS (sin VAAI), VMFS, VSAN y VVOL en cualquier combinación.

VAAI y VVOL de aprovisionamiento ligero:

  • Advertencias de umbral suave. Las alertas de umbral flexible para cualquier actividad en las máquinas virtuales alojadas por VVOL se mostrarán en vCenter. El contenedor con la máquina virtual que llamó al disparador está marcado con un ícono amarillo, aunque sin especificar en qué VM ocurrió el problema. Tal matiz definitivamente molestará al administrador, pero en futuras actualizaciones deberían arreglarlo todo.
  • Advertencias de umbral estricto… El comportamiento de estas alertas es similar al del almacenamiento VMFS. La máquina virtual que recibe el umbral estricto se suspende hasta que el administrador ya no asigna espacio o lo desactiva.
  • UNMAP… Debido a la falta de discos VMFS administrados, la esfera no usará esta primitiva, aunque saltará si proviene del invitado. Cuando se usa VVOL, el comando UNMAP de la máquina virtual se envía directamente al almacenamiento, que ahora ve todas estas «quejas». Windows Server 2012 admitirá inmediatamente UNMAP, pero Linux verificará primero el nivel SCSI en el dispositivo virtual. Si es SCSI-2 (como es ahora), no seguirá UNMAP. Es probable que este problema se resuelva en versiones futuras. GO UNMAP determina la presencia de UNMAP en el extremo del protocolo adjunto al volumen virtual.

Ahora veamos cómo funcionan todas estas optimizaciones en escenarios típicos.

Escenarios típicos

Almacenamiento de VMotion de una máquina que se ejecuta sin instantánea

Para una VM que se ejecuta sin instantáneas, la copia está controlada por el controlador Storage vMotion. Se utiliza el transportador de datos que, si es posible, delega la transferencia de secciones al arreglo de VM en ejecución.

Bloquear VAI y VVOL

  • La API de mapa de bits se utiliza para determinar los bloques de datos a transferir (optimización del uso del espacio).
  • XCOPY para la migración en sí (el anfitrión coordina la matriz).

NAS GO

Sin optimización.

NAS VVOL

  • API de mapa de bits para definir bloques portátiles.

Almacenamiento de VMotion de una máquina de instantáneas en ejecución

Las instantáneas se transfieren primero, después de lo cual el controlador Storage vMotion migrará el estado actual de la máquina virtual.

Blocky GO

  • Se llama a la API de mapa de bits para encontrar bloques de datos para transferir.
  • XCOPY se utiliza para migrar copias instantáneas y el estado actual de una máquina virtual.

Bloquear VVOL

  • API de mapa de bits para definir bloques portátiles.
  • Las API VASA Clone Virtual Volume y Copy Diffs To Virtual Volume se llaman para migrar todas las instantáneas y transferir completamente la actividad al arreglo.
  • XCOPY para transferir el estado actual de la VM (el anfitrión coordina la matriz).

NAS GO

  • No admite la migración de instantáneas de VM.
  • No ofrece optimizaciones.

NAS VVOL

  • La API de mapa de bits se utiliza para encontrar los bloques necesarios.
  • Clone el volumen virtual y copie las diferencias en el volumen virtual de la API de VASA para la migración de instantáneas basada en arreglos.

Almacenamiento de VMotion de una máquina apagada sin instantánea

En tales condiciones, en lugar del controlador Storage vMotion, se utiliza el método de mover la máquina (clonación con posterior eliminación de la fuente).

Bloquear GO

  • API de mapa de bits para encontrar los bloques que desee.
  • XCOPY para la migración de máquinas virtuales.

Bloquear VVOL

  • Nuevamente, se llama a la API de mapa de bits para seleccionar los bloques apropiados.
  • Clonar volumen virtual se usa para migrar el estado actual de la máquina virtual usando el arreglo.
  • Copiar diferencias en volumen virtual es responsable de transferir instantáneas (también transfiere completamente la actividad al arreglo).

NAS GO

  • Delegue el proceso de clonación a una matriz.

NAS VVOL

  • Todo es igual que Block VVOL.

Almacenamiento de VMotion de una máquina apagada con instantánea

La idea es la misma que en la versión anterior, pero ahora con instantáneas.

Bloquear GO

  • Se llama a la API de mapa de bits para encontrar los bloques a ajustar.
  • XCOPY para migración de estado e instantáneas de VM.

Bloquear VVOL

  • API de mapa de bits
  • Clone Virtual Volume para migrar el estado actual y las instantáneas de la máquina por completo desde el sistema de almacenamiento.

NAS GO

  • No se pueden migrar imágenes.
  • Delegue la clonación a una matriz.

NAS VVOl (como bloque VVOL)

  • Igual que el bloque VVOL.

Del traductor

El artículo resultó ser bastante rico en términos de abreviaturas y definiciones, por lo que les traigo un pequeño glosario sobre algunas de ellas:

  • VAMOS (vStorage API for Array Integration) es una interfaz especial de VMware diseñada para transferir algunas de las operaciones del disco de la máquina virtual al lado del arreglo. Un ejemplo típico es la inicialización de discos Zeroed-Thick, donde el sistema de almacenamiento realiza la «puesta a cero», no el servidor ESXi.
  • VASA (API de vStorage para reconocimiento de almacenamiento): una interfaz para comunicarse con el sistema de almacenamiento, que permite que el sistema de almacenamiento pase información adicional de LUN al servidor ESXi. Por ejemplo, las características de velocidad y confiabilidad.
  • ATS (Prueba y conjunto atómicos): conjunto de comandos diseñados para comprobar los bloqueos del sistema de archivos por los sistemas de almacenamiento. Los bloqueos son necesarios siempre que se crea o modifica un archivo en un volumen VMFS, y cambiar esta función a un arreglo puede mejorar el rendimiento.
  • UNMAP (Recuperación de espacio de bloque de aprovisionamiento fino): un comando para marcar el espacio libre en disco dentro de la máquina virtual como libre. Sin esto, el archivo de 10 GB eliminado dentro de vmdk no se devolverá al grupo de espacio en disco disponible. El equipo es necesario para un uso más eficiente del espacio de almacenamiento en las máquinas virtuales.
  • T10 – Comité de Estándares SCSI. En el caso de vSphere, esto significa compatibilidad con el conjunto de comandos SCSI extendido, independientemente del proveedor específico. Por supuesto, el sistema de almacenamiento también debe ser compatible con el T10.
  • Config VVOL (Volumen de configuración): una sección VVOL separada para cada máquina virtual que contiene metadatos y archivos de descripción (VMX, registros, descriptores, etc.).
  • Punto final de protocolo (PE) es una especie de punto de montaje analógico de Linux. PE está diseñado para trabajar con un grupo de volumen virtual a través de un único punto de entrada. Para los dispositivos de bloque, PE se representa como un LUN y para los dispositivos de archivo, como un punto de montaje.
  • VSAN (Virtual Storage Area Network) es un nuevo producto de VMware que le permite ensamblar un grupo de almacenamiento para máquinas virtuales desde los discos locales de los servidores ESXi. Análogo a los sistemas tradicionales de almacenamiento de alta disponibilidad.

Califica el artículo