Almacenamiento

En esta sección se describe cómo el hardware de almacenamiento físico se asigna a máquinas virtuales (VM) y los objetos de software utilizados por 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 de tipo
  • Generación de instantáneas con fines de backup
  • Prácticas recomendadas para administrar el almacenamiento de información
  • Configuración de QoS (Calidad de servicio) del disco virtual

Repositorios de almacenamiento (SRs)

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

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

Conectado localmente:

  • IDA
  • SATA
  • SCSI
  • SAS

Conexión remota:

  • iSCSI
  • NFS
  • SAS
  • Canal de fibra

Las abstracciones SR y VDI permiten que las funciones avanzadas de almacenamiento se expongan en destinos de almacenamiento que las soportan. 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 características. Esta pila de software se basa en la especificación de disco duro virtual (VHD) de Microsoft.

Los comandos SR proporcionan operaciones para crear, destruir, cambiar el tamaño, clonar, conectar y descubrir los VDI individuales que contienen.

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

Cada servidor Citrix Hypervisor puede utilizar varios SRs y diferentes tipos de SR simultáneamente. Estos SRs se pueden compartir entre hosts o dedicados a hosts concretos. El almacenamiento compartido se agrupa entre varios hosts dentro de un grupo de recursos definido. Una SR compartida debe tener acceso a la red para cada host del grupo. Todos los servidores de un único grupo de recursos deben tener al menos una SR compartida en común. El almacenamiento compartido no se puede compartir entre varios grupos.

Las operaciones de CLI para administrar repositorios de almacenamiento se describen enComandos SR.

Imagen de disco virtual (VDI)

Una imagen de disco virtual (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 Citrix Hypervisor. Las operaciones de CLI para administrar los VDI se describen enComandos de VDI. La representación en disco de los datos difiere según el tipo SR. Una interfaz de plug-in de almacenamiento independiente para cada SR, llamada SM API, administra los datos.

Dispositivos de bloqueo físico (PBD)

Los dispositivos de bloque físico representan la interfaz entre un servidor físico y un SR conectado. Los PBD son objetos de conector que permiten asignar un SR determinado a un host. Los PBD almacenan los campos de configuración del dispositivo que se utilizan para conectarse a un destino de almacenamiento determinado e interactuar con él. 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 Citrix Hypervisor. Los objetos PBD administran los datos adjuntos en tiempo de ejecución de un SR dado a un servidor Citrix Hypervisor determinado. Las operaciones de CLI relacionadas con PBD se describen enComandos PBD.

Dispositivos de bloque virtual (VBD)

Los dispositivos de bloque virtual son objetos de conector (similares al PBD descrito anteriormente) que permiten asignaciones entre VDI y VM. Además de proporcionar un mecanismo para conectar un VDI a una VM, los VBD permiten ajustar los parámetros relativos a QoS (Calidad de servicio) y las estadísticas de un VDI determinado, y si ese VDI puede iniciarse. Las operaciones de CLI relacionadas con VBD se describen enComandos VBD.

Resumen de objetos de almacenamiento

La siguiente imagen es un resumen de cómo están relacionados los objetos de almacenamiento presentados hasta ahora:

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

Formatos de datos de disco virtual

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

  1. VHD basado en volumen lógico en un LUN: el almacenamiento predeterminado basado en bloques de Citrix Hypervisor inserta un administrador de volúmenes lógico 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 ligero 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 delgado en un sistema de archivos de disco compartido GFS2 en un LUN conectado a través del iniciador de software iSCSI o HBA de hardware.

  3. VHD basado en archivos en un sistema de archivos: las imágenes de VM se almacenan como archivos de formato VHD de aprovisionamiento delgado en un sistema de archivos local no compartido (tipo EXT SR) o en un destino NFS compartido (tipo NFS SR).

Tipos de VDI

Para la mayoría de los tipos SR, se crean VDI de formato VHD. Puede optar por utilizar raw en el momento de crear el VDI. Esta opción sólo se puede especificar mediante la CLI xe. Para los SRs de GFS2, se crean VDI QCOW2.

Para comprobar si se creó un VDI contype=raw, compruebe susm-configmapa. Los comandossr-param-list yvdi-param-list xe se pueden utilizar respectivamente para este propósito.

Crear un disco virtual sin procesar mediante la CLI xe

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

    xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \
            name-label=VDI name sm-config:type=raw
    
  2. Conecte el nuevo disco virtual a una máquina virtual. Utilice las herramientas de disco dentro de la máquina virtual para crear particiones y formatear, o bien utilice el nuevo disco. Puede utilizar elvbd-create comando para crear un VBD para asignar el disco virtual 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 (sin formato, como se describe anteriormente, o VHD) y, a continuación, copiar datos en él desde un volumen existente. Utilice la CLI xe para asegurarse de que el nuevo VDI tenga un tamaño virtual al menos tan grande como el VDI desde el que está copiando. Para ello, compruebe suvirtual-size campo, por ejemplo, mediante elvdi-param-list comando. A continuación, puede adjuntar este nuevo VDI a una máquina virtual y utilizar la herramienta preferida dentro de la máquina virtual para realizar una copia de bloque directa de los datos. Por ejemplo, herramientas estándar de administración de discos en Windows o eldd comando 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 basada en archivos puede ser más adecuado.

VDI basados en VHD y 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 del VDI. Esta función permite que dichas máquinas virtuales se clonen rápidamente a partir de plantillas, lo que facilita el aprovisionamiento y la implementación muy rápidos de nuevas máquinas virtuales.

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 demás 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 depende del tamaño del VDI y de la cantidad de datos compartidos.

Los formatos VHD y QCOW2 admiten 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 QCOW2 basado en archivos VHD y GFS2, este enfoque tiene la considerable ventaja de que los archivos de imagen de VM ocupan solo tanto espacio en el almacenamiento físico como sea necesario. Con VHD basado en LVM, el contenedor de volumen lógico subyacente debe ajustarse al tamaño virtual del 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 sólo tantos datos como se ha escrito en el disco. Sin embargo, los nodos hoja (clones VDI) permanecen completamente inflados al 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 Sólo lectura para conservar la asignación desinflada. Los nodos de instantánea que están conectados de lectura y escritura se infla completamente al adjuntar y se desinfla al desenlazar.

  • Para VHD basados en archivos e imágenes QCOW2 basadas en GFS2 , todos los nodos consumen sólo 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 un VDI de 100 GB para una máquina virtual y se instala un sistema operativo, el archivo VDI es físicamente solo del tamaño de los datos del sistema operativo en el disco, además de una sobrecarga de metadatos menor.

Al clonar VM basadas en una única plantilla VHD o QCOW2, cada VM secundaria forma una cadena en la que se escriben nuevos cambios en la nueva VM. Los bloques antiguos se leen directamente desde la plantilla principal. Si la nueva máquina virtual se convirtió en una plantilla adicional y se clonaron más máquinas virtuales, la cadena resultante produce un rendimiento degradado. Citrix Hypervisor admite una longitud máxima de cadena 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 utilice elvm-copy comando, que restablece la longitud de la cadena a 0.

Notas específicas de VHD sobre coalce

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

Si tiene máquinas virtuales críticas ejecutándose en el servidor maestro del grupo, puede realizar los siguientes pasos para mitigar las E/S lentas ocasionales:

  • Migrar la máquina virtual a un host que no sea el maestro 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 del disco virtual.