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
Repositorios de almacenamiento (SR)
Un repositorio de almacenamiento (SR) es un destino de almacenamiento específico, en el que se almacenan las imágenes de disco virtual (VDI) de la 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 los 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 grupo de recursos definido. Un SR compartido debe ser accesible en 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 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 virtual (VDI) es una abstracción de almacenamiento que representa una unidad de disco duro (HDD) virtual. 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 conectar una VDI a una máquina virtual, las VBD permiten ajustar los parámetros relacionados con la prioridad de E/S del disco 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:
Formatos de datos de discos virtuales
En general, existen los siguientes tipos de asignación de almacenamiento físico a una VDI:
-
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.
-
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.
-
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.
Cree un disco virtual sin formato mediante la CLI xe
-
Ejecute el siguiente comando para crear un VDI dado el UUID del SR en el que quiere 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 <!--NeedCopy--> -
Conecte el nuevo disco virtual a una VM. Use las herramientas de disco dentro de la VM para crear particiones y formatear, o use el disco nuevo. Puede usar el comando
vbd-createpara crear un VBD a fin de asignar el disco virtual a la 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. Puede hacerlo comprobando 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, las herramientas de administración de discos estándar 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 diferentes nodos de disco dentro de la cadena consumen solo la cantidad de datos que 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áneas (instantáneas de VDI) permanecen desinflados cuando no están en uso y se pueden adjuntar como de solo lectura para preservar 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 los VHD basados en archivos y las**imágenes QCOW2 basadas en GFS2, todos los nodos consumen solo la cantidad de datos que se ha 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 utilice el comando vm-copy, 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 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 Priorización de solicitudes de E/S de discos virtuales.