Almacenamiento

Importante:

La actualización acumulativa 1 de Citrix Hypervisor 8.2 llega al final de su vida útil el 25 de junio de 2025. Planifique su actualización a XenServer 8 ahora para garantizar una transición fluida y un soporte continuo. Para obtener más información, consulte Actualizar.

Si utiliza los archivos de licencia de Citrix Virtual Apps and Desktops para licenciar los hosts de Citrix Hypervisor 8.2 Cumulative Update 1, estos archivos de licencia no son compatibles con XenServer 8. Antes de actualizar, debe adquirir los archivos de licencia de socket de XenServer Premium Edition para utilizarlos con XenServer 8. Estos archivos de licencia de socket están disponibles como un derecho de las suscripciones de Citrix para Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP y Citrix Platform License para ejecutar sus cargas de trabajo de Citrix. Los clientes de Citrix que aún no hayan realizado la transición a estas nuevas suscripciones pueden solicitar participar en una promoción gratuita de 10.000 licencias de socket de XenServer Premium Edition. Para obtener más información, consulte XenServer.

Si no obtiene una licencia compatible para XenServer 8 antes de actualizar, cuando actualice sus hosts, estos volverán a la edición de prueba de 90 días. La Edición de Prueba ofrece las mismas características que la Edición Premium con algunas limitaciones. Para obtener más información, consulte Descripción general de las licencias de XenServer 8.

En esta sección se describe cómo se asigna el hardware de almacenamiento físico a las máquinas virtuales (VM) y los objetos de software que usa la API de administración para realizar tareas relacionadas con el almacenamiento. Las secciones detalladas sobre 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 dispositivo específicas del tipo
• Generación de instantáneas con fines de copia de seguridad
• Prácticas recomendadas para administrar el almacenamiento

Repositorios de almacenamiento (SR)

Un repositorio de almacenamiento (SR) es un destino de almacenamiento determinado en el que se almacenan imágenes de disco virtual (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:

Conectado 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 de forma remota:

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

Nota: No

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

Las abstracciones SR y VDI permiten que las características de almacenamiento avanzadas se expongan en los destinos de almacenamiento que las admiten. Por ejemplo, las funciones avanzadas como Aprovisionamiento ligero, instantáneas de VDI y clonación rápida. En el caso de los 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.

Un repositorio de almacenamiento es una estructura de datos persistente en disco. En el caso de 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 la cabina de almacenamiento en paralelo a los SR existentes.

Cada servidor Citrix Hypervisor puede utilizar varios SR y diferentes tipos de SR simultáneamente. Estos SR se pueden compartir entre hosts o dedicar a hosts particulares. El almacenamiento compartido se agrupa entre varios hosts dentro de un grupo de recursos definido. Un SR compartido debe ser accesible a la red para cada host del grupo. Todos los servidores de un único grupo 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 las VDI individuales que contienen. Las operaciones de CLI para administrar repositorios de almacenamiento se describen en Comandos SR.

Advertencia:

Citrix Hypervisor no admite instantáneas en el nivel de SAN externa de un LUN para ningún tipo de 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). Las VDI son la unidad fundamental del almacenamiento virtualizado en Citrix Hypervisor. Las VDI son objetos persistentes en disco que existen independientemente de los servidores de Citrix Hypervisor. Las operaciones de CLI para administrar VDI se describen en Comandos VDI. La representación en disco de los datos difiere según el tipo de SR. Una interfaz de complemento de almacenamiento independiente para cada SR, llamada SM API, administra los datos.

Dispositivos de bloque 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 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 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 asociada que monta el servidor Citrix Hypervisor. Los objetos PBD administran la conexión en tiempo de ejecución de un SR determinado a un servidor Citrix Hypervisor determinado. Las operaciones CLI relacionadas con los PBD se describen en Comandos PBD.

Dispositivos de bloque virtual (VBD)

Los dispositivos de bloque virtual son objetos conector (similares a los PBD descritos anteriormente) que permiten asignaciones entre VDI y máquinas virtuales. Además de proporcionar un mecanismo para conectar un VDI a una máquina virtual, los VBD permiten el ajuste fino de los parámetros relacionados con la prioridad de E/S del disco y las estadísticas de un VDI determinado, y si ese VDI se puede arrancar. Las operaciones de CLI relacionadas con los VBD se describen en Comandos VBD.

Resumen de objetos de almacenamiento

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

Formatos de datos de disco virtual

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

1. VHD lógico basado en volumen 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 fino 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 máquina virtual se almacenan como archivos de formato VHD de aprovisionamiento fino en un sistema de archivos local no compartido (tipo SR de EXT3/EXT4), un destino NFS compartido (tipo SR de NFS) o un destino SMB remoto (tipo SR de SMB).

Tipos de VDI

Para los SR GFS2, se crean los VDI QCOW2.

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

Nota: No

Si crea una VDI sin procesar en un SR basado en LVM o un SR de HBA/LUN por VDI, es posible que permita que la máquina virtual propietaria acceda a los datos que formaban parte de una VDI eliminada anteriormente (de cualquier formato) que pertenezca a cualquier máquina virtual. Le recomendamos que tenga en cuenta sus requisitos de seguridad antes de utilizar esta opción.

Las VDI sin procesar en un SR NFS, EXT o SMB no permiten el acceso a los datos de las VDI eliminadas anteriormente que pertenecen a ninguna máquina virtual.

Para comprobar si se ha creado una VDI con tipo=sin procesar, compruebe su sm-config mapa. El sr-param-list y vdi-param-list Los comandos xe se pueden utilizar respectivamente para este propósito.

Creación de un disco virtual sin procesar mediante la CLI de xe

1. Ejecute el siguiente comando para crear una 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. Use las herramientas de disco de la máquina virtual para particionar y formatear, o bien use el nuevo disco. Puede utilizar la función vbd-create para crear un VBD para asignar el disco virtual a la máquina virtual.

Convertir entre formatos VDI

No es posible realizar una conversión directa entre los formatos RAW y VHD. En su lugar, puede crear una VDI (ya sea sin procesar, como se ha descrito anteriormente, o VHD) y, a continuación, copiar datos en ella desde un volumen existente. Utilice 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. Puede hacer esto verificando su tamaño virtual , por ejemplo, mediante el uso de la función vdi-param-list mandar. A continuación, puede adjuntar esta nueva VDI a una máquina virtual y utilizar su herramienta preferida dentro de la máquina virtual para realizar una copia directa en bloque de los datos. Por ejemplo, las herramientas de administración de discos estándar en Windows o el Dd en Linux. Si el nuevo volumen es un volumen VHD, use una herramienta que pueda evitar escribir sectores vacíos en el disco. Esta acción puede garantizar que el espacio se utilice de forma óptima en el repositorio de almacenamiento subyacente. Un enfoque de copia basado en archivos puede ser más adecuado.

VDI basadas en VHD y QCOW2

Las imágenes VHD y QCOW2 pueden ser encadenado, lo que permite que dos VDI compartan datos comunes. En los casos en los que se clona una máquina virtual respaldada por VHD o QCOW2, las máquinas virtuales resultantes comparten los datos comunes en disco en el momento de la clonación. Cada máquina virtual procede a realizar sus propios cambios en una versión aislada de copia en escritura de la VDI. Esta característica 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 máquinas virtuales y sus VDI asociadas se clonan con el tiempo, se crean árboles de VDI encadenadas. Cuando se elimina una de las VDI de una cadena, Citrix Hypervisor racionaliza las demás VDI de la cadena para eliminar las VDI innecesarias. Éste Coalescente El proceso se ejecuta de forma asincrónica. La cantidad de espacio en disco recuperado y el tiempo necesario para realizar el proceso dependen del tamaño de la 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 máquina virtual escribe datos en el disco. En el caso de VHD basado en archivos y QCOW2 basado en GFS2, este enfoque tiene la considerable ventaja 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 tener el 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 Imágenes VHD basadas en LVM, la diferencia Los nodos de disco dentro de la cadena consumen solo la cantidad de datos que se han escrito en el disco. Sin embargo, los nodos hoja (clones de VDI) permanecen completamente inflados al tamaño virtual del disco. Los nodos hoja de instantáneas (instantáneas de VDI) permanecen desinflados cuando no están en uso y se pueden adjuntar en modo de solo lectura para conservar la asignación desinflada. Los nodos de instantánea que están conectados de lectura y escritura se inflan completamente al adjuntar y se desinflan al desconectar.

• Para VHD basados en archivos y 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 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 máquinas virtuales basadas en una sola plantilla de VHD o QCOW2, cada máquina virtual secundaria forma una cadena en la que se escriben los nuevos cambios en la nueva máquina virtual. 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 da como resultado un rendimiento degradado. Citrix Hypervisor admite una longitud de cadena máxima de 30. No te acerques a este límite sin una buena razón. En caso de duda, “copie” la máquina virtual mediante XenCenter o utilice el comando vm-copia , que restablece la longitud de la cadena a 0.

Notas específicas de VHD sobre la fusión

Solo hay un proceso de coalescencia activo para un 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 la E/S lenta ocasional:

• Migración de 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 Priorización de solicitudes de E/S de disco virtual.