Citrix Hypervisor

Almacenamiento

En esta sección se describe cómo el hardware de almacenamiento físico se asigna a las máquinas virtuales (VM) y los objetos de software que utiliza la API de administración para realizar tareas relacionadas con el almacenamiento. Las secciones detalladas de cada uno de los tipos de almacenamiento admitidos incluyen la siguiente información:

  • Procedimientos para crear almacenamiento para máquinas virtuales mediante la CLI, con opciones de configuración de dispositivos específicos del tipo
  • Generación de instantáneas para realizar copias de seguridad
  • Prácticas recomendadas para administrar el almacenamiento
  • Configuración de QoS (Calidad de servicio) del disco vDisk

Repositorios de almacenamiento (SR)

Un repositorio de almacenamiento (SR) es un destino de almacenamiento concreto, en el que se almacenan imágenes de disco vDisk (VDI) de máquina virtual (VM). Una VDI es una abstracción de almacenamiento que representa una unidad de disco duro virtual (HDD).

Los SR son flexibles, con soporte integrado para las siguientes unidades:

Conectados localmente:

  • SATA
  • SCSI
  • SAS
  • NVMe

El hardware de almacenamiento físico local puede ser una unidad de disco duro (HDD) o una unidad de estado sólido (SSD).

Conectado remotamente:

  • iSCSI
  • NFS
  • SAS
  • Pymes (solo versión 3)
  • Canal de fibra

Nota:

No se admiten NVMe a través de canal de fibra ni NVMe a través de TCP.

Las abstracciones de SR y VDI permiten que las funciones de almacenamiento avanzadas se expongan en los destinos de almacenamiento que las admiten. Por ejemplo, funciones avanzadas como aprovisionamiento ligero, instantáneas de VDI y clonación rápida. Para subsistemas de almacenamiento que no admiten operaciones avanzadas directamente, se proporciona una pila de software que implementa estas funciones. Esta pila de software se basa en la especificación de disco duro virtual (VHD) de Microsoft.

Un repositorio de almacenamiento es una estructura de datos en disco persistente. Para los tipos de SR que utilizan un dispositivo de bloques subyacente, el proceso de creación de un SR implica borrar todos los datos existentes en el destino de almacenamiento especificado. Otros tipos de almacenamiento, como NFS, crean un contenedor en la matriz de almacenamiento en paralelo a los SR existentes.

Cada servidor de Citrix Hypervisor puede usar varios SR y diferentes tipos de SR simultáneamente. Estos SR pueden compartirse entre hosts o dedicarse a hosts particulares. El almacenamiento compartido se agrupa entre varios hosts dentro de un fondo de recursos definido. Un SR compartido debe ser accesible en red para cada host del grupo. Todos los servidores de un único fondo de recursos deben tener al menos un SR compartido en común. El almacenamiento compartido no se puede compartir entre varios grupos.

Los comandos SR proporcionan operaciones para crear, destruir, cambiar el tamaño, clonar, conectar y descubrir los VDI individuales que contienen. Las operaciones de CLI para administrar repositorios de almacenamiento se describen en los comandos de SR.

Advertencia:

Citrix Hypervisor no admite instantáneas en el nivel de SAN externo de un LUN para ningún tipo de SR.

Imagen de disco vDisk (VDI)

Una imagen de disco vDisk (VDI) es una abstracción de almacenamiento que representa una unidad de disco duro virtual (HDD). Los VDI son la unidad fundamental del almacenamiento virtualizado en Citrix Hypervisor. Los VDI son objetos persistentes en disco que existen independientemente de los servidores de Citrix Hypervisor. Las operaciones de la CLI para administrar VDI se describen en los comandos de VDI. La representación en disco de los datos varía según el tipo de SR. Una interfaz de complemento de almacenamiento independiente para cada SR, denominada API de SM, administra los datos.

Dispositivos de bloques físicos (PBD)

Los dispositivos de bloques físicos representan la interfaz entre un servidor físico y un SR conectado. Los PBD son objetos de conector que permiten que un SR determinado se asigne a un host. Los PBD almacenan los campos de configuración del dispositivo que se utilizan para conectarse e interactuar con un destino de almacenamiento determinado. Por ejemplo, la configuración del dispositivo NFS incluye la dirección IP del servidor NFS y la ruta de acceso asociada que monta el servidor de Citrix Hypervisor. Los objetos PBD administran los datos adjuntos en tiempo de ejecución de un SR determinado a un servidor de Citrix Hypervisor determinado. Las operaciones de CLI relacionadas con los PBD se describen en los comandos PBD.

Dispositivos de bloques virtuales (VBD)

Los dispositivos de bloques virtuales son objetos de conector (similares al PBD descrito anteriormente) que permiten asignaciones entre VDI y VM. Además de proporcionar un mecanismo para adjuntar una VDI a una VM, los VBD permiten el ajuste fino de los parámetros relacionados con la QoS (calidad de servicio) y las estadísticas de una VDI determinada, y si esa VDI se puede iniciar. Las operaciones de CLI relacionadas con los VBD se describen en los comandos de VBD.

Resumen de objetos de almacenamiento

La siguiente imagen es un resumen de cómo se relacionan los objetos de almacenamiento presentados hasta el momento:

Descripción general gráfica de los repositorios de almacenamiento y objetos relacionados

Formatos de datos de disco vDisk

En general, existen los siguientes tipos de asignación de almacenamiento físico a una VDI:

  1. VHD basado en volúmenes lógicos en un LUN: El almacenamiento predeterminado basado en bloques de Citrix Hypervisor inserta un administrador de volúmenes lógicos en un disco. Este disco es un dispositivo conectado localmente (LVM) o un LUN conectado a SAN a través de Fibre Channel, iSCSI o SAS. Los VDI se representan como volúmenes dentro del administrador de volúmenes y se almacenan en formato VHD para permitir el aprovisionamiento controlado de nodos de referencia en instantáneas y clones.

  2. QCOW2 basado en archivos en un LUN: las imágenes de VM se almacenan como archivos de formato QCOW2 de aprovisionamiento fino en un sistema de archivos de disco compartido GFS2 en un LUN conectado a través de un iniciador de software iSCSI o un HBA de hardware.

  3. VHD basado en archivos en un sistema de archivos: las imágenes de VM se almacenan como archivos en formato VHD de aprovisionamiento fino en un sistema de archivos local no compartido (EXT3/EXT4 tipo SR), un destino NFS compartido (NFS tipo SR) o un destino SMB remoto (SR de tipo SMB).

Tipos de VDI

Para los SR de GFS2, se crean VDI QCOW2.

Para otros tipos de SR, se crean VDI en formato VHD. Puede optar por usar raw en el momento de crear la VDI. Esta opción solo se puede especificar mediante la CLI xe.

Nota:

Si crea una VDI sin procesar en una SR basada en LVM o SR de HBA/LUN por VDI, podría permitir que la máquina virtual propietaria acceda a los datos que formaban parte de una VDI eliminada anteriormente (de cualquier formato) que pertenece a cualquier máquina virtual. Le recomendamos que tenga en cuenta sus requisitos de seguridad antes de usar esta opción.

Los VDI sin procesar en NFS, EXT o SMB SR no permiten el acceso a los datos de los VDI eliminados anteriormente que pertenecen a ninguna VM.

Para comprobar si se creó una VDI con type=raw, consulte su asignación de sm-config. Los comandos sr-param-list y vdi-param-list xe se pueden usar respectivamente para este propósito.

Crear un disco vDisk sin procesar mediante la CLI xe

  1. Ejecute el siguiente comando para crear un VDI dado el UUID del SR en el que quiere colocar el disco vDisk:

    xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \
            name-label=VDI name sm-config:type=raw
    <!--NeedCopy-->
    
  2. Conecte el nuevo disco vDisk a una máquina virtual. Use las herramientas de disco dentro de la VM para crear particiones y formatear, o use el disco nuevo. Puede utilizar el comando vbd-create para crear un VBD para asignar el disco vDisk a su VM.

Convertir entre formatos VDI

No es posible realizar una conversión directa entre los formatos raw y VHD. En su lugar, puede crear un VDI (ya sea sin procesar, como se describió anteriormente, o VHD) y, a continuación, copiar datos en él desde un volumen existente. Use la CLI xe para asegurarse de que la nueva VDI tenga un tamaño virtual al menos tan grande como la VDI desde la que está copiando. Para ello, compruebe su campo virtual-size, por ejemplo, mediante el comando vdi-param-list. A continuación, puede conectar esta nueva VDI a una VM y usar su herramienta preferida dentro de la VM para hacer una copia en bloque directa de los datos. Por ejemplo, herramientas estándar de administración de discos en Windows o el comando dd en Linux. Si el nuevo volumen es un volumen VHD, utilice una herramienta que evite escribir sectores vacíos en el disco. Esta acción puede garantizar que el espacio se utilice de manera óptima en el repositorio de almacenamiento subyacente. Un enfoque de copia basado en archivos puede ser más adecuado.

VDI basados en VHD y basados en QCow2

Las imágenes VHD y QCOW2 se pueden encadenar, lo que permite que dos VDI compartan datos comunes. En los casos en que se clona una VM respaldada por VHD o QCOW2, las VM resultantes comparten los datos comunes en disco en el momento de la clonación. Cada VM procede a realizar sus propios cambios en una versión aislada de copia en escritura de la VDI. Esta función permite que dichas VM se clonen rápidamente a partir de plantillas, lo que facilita el aprovisionamiento y la implementación muy rápidos de nuevas VM.

A medida que las VM y sus VDI asociados se clonan con el tiempo, esto crea árboles de VDI encadenados. Cuando se elimina uno de los VDI de una cadena, Citrix Hypervisor racionaliza los otros VDI de la cadena para eliminar los VDI innecesarios. Este proceso de fusión se ejecuta de forma asíncrona. La cantidad de espacio en disco recuperado y el tiempo que se tarda en realizar el proceso dependen del tamaño de la VDI y de la cantidad de datos compartidos.

Los formatos VHD y QCOW2 admiten el aprovisionamiento ligero. El archivo de imagen se extiende automáticamente en fragmentos granulares finos a medida que la VM escribe datos en el disco. Para el VHD basado en archivos y QCOW2 basado en GFS2, este enfoque tiene la ventaja considerable de que los archivos de imagen de VM ocupan solo el espacio necesario en el almacenamiento físico. Con VHD basado en LVM, el contenedor de volumen lógico subyacente debe ajustarse al tamaño virtual de la VDI. Sin embargo, el espacio no utilizado en el disco de instancia de copia en escritura subyacente se recupera cuando se produce una instantánea o un clon. La diferencia entre los dos comportamientos se puede describir de la siguiente manera:

  • Para las imágenes VHD basadas en LVM, los nodos de disco de diferencia dentro de la cadena consumen solo tantos datos como se ha escrito en el disco. Sin embargo, los nodos hoja (clones de VDI) permanecen completamente inflados hasta el tamaño virtual del disco. Los nodos hoja de instantánea (instantáneas VDI) permanecen desinflados cuando no están en uso y se pueden adjuntar Solo lectura para conservar la asignación desinflada. Los nodos de instantáneas que están conectados de lectura y escritura se inflan por completo al conectarlos y se desinflan al desconectarse.

  • Para VHD basados en archivos e imágenes QCOW2 basadas en GFS2, todos los nodos consumen solo la cantidad de datos que se han escrito. Los archivos de nodo hoja crecen para acomodar los datos a medida que se escriben activamente. Si se asigna una VDI de 100 GB para una máquina virtual y se instala un sistema operativo, el archivo VDI solo tiene el tamaño físico de los datos del sistema operativo en el disco, además de una sobrecarga de metadatos menor.

Al clonar máquinas virtuales basadas en un único VHD o plantilla QCOW2, cada máquina virtual secundaria forma una cadena en la que se escriben nuevos cambios en la nueva máquina virtual. Los bloques antiguos se leen directamente de la plantilla principal. Si la nueva VM se convirtió en una plantilla adicional y se clonaron más VM, la cadena resultante reduce el rendimiento. Citrix Hypervisor admite una longitud de cadena máxima de 30. No se acerque a este límite sin una buena razón. En caso de duda, “copie” la máquina virtual mediante XenCenter o ejecute el comando vm-copy, que restablece la longitud de la cadena a 0.

Notas específicas de VHD sobre la fusión

Solo un proceso de coalescencia está siempre activo para una SR. Este subproceso de proceso se ejecuta en el host maestro de SR.

Si tiene máquinas virtuales críticas que se ejecutan en el servidor maestro del grupo, puede tomar las siguientes medidas para mitigar las E/S lentas ocasionales:

  • Migrar la máquina virtual a un host que no sea el maestro de SR

  • Establezca la prioridad de E/S del disco en un nivel superior y ajuste el programador. Para obtener más información, consulte Configuración de QoS de disco virtual.

Almacenamiento