Almacenamiento
Este artículo describe cómo el hardware de almacenamiento físico se asigna a las máquinas virtuales (VM) y los objetos de software utilizados por XenServer® para realizar tareas relacionadas con el almacenamiento. También proporciona información sobre los tipos de almacenamiento disponibles para que pueda elegir el hardware de almacenamiento adecuado para su entorno.
Conceptos de almacenamiento
La siguiente imagen muestra cómo se relacionan los objetos de almacenamiento descritos en esta sección:
Repositorios de almacenamiento (SR)
Un Repositorio de Almacenamiento (SR) es un destino de almacenamiento particular, en el que se almacenan las Imágenes de Disco Virtual (VDI) de las Máquinas Virtuales (VM). Una VDI es una abstracción de almacenamiento que representa una unidad de disco duro (HDD) virtual. Para obtener información sobre los tipos de SR compatibles con XenServer, consulte Tipos de repositorio de almacenamiento.
Las abstracciones de SR y VDI permiten exponer funciones de almacenamiento avanzadas en destinos de almacenamiento que las admiten. Por ejemplo, funciones avanzadas como el aprovisionamiento ligero, las instantáneas de VDI y la 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.
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 cualquier dato existente 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 host de XenServer puede usar múltiples 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 por red para cada host del grupo. El almacenamiento compartido no se puede compartir entre varios grupos.
Los comandos SR proporcionan operaciones para crear, destruir, redimensionar, clonar, conectar y descubrir las VDI individuales que contienen. Las operaciones de CLI para administrar repositorios de almacenamiento se describen en Comandos 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 (HDD) virtual. Las VDI son la unidad fundamental de almacenamiento virtualizado en XenServer. Las VDI son objetos persistentes en disco que existen independientemente de los hosts de XenServer. Para obtener más información sobre los formatos de datos admitidos para discos virtuales en XenServer, consulte Formatos de datos de disco virtual.
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 separada para cada SR, llamada API SM, administra los datos.
Dispositivos de bloque físicos (PBD)
Los dispositivos de bloque físicos representan la interfaz entre un servidor físico y un SR adjunto. Los PBD son objetos conectores que permiten que un SR dado 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 dado. Por ejemplo, la configuración del dispositivo NFS incluye la dirección IP del servidor NFS y la ruta asociada que monta el host de XenServer. Los objetos PBD gestionan la conexión en tiempo de ejecución de un SR dado a un host de XenServer dado. Las operaciones de CLI relacionadas con los PBD se describen en comandos PBD.
Dispositivos de bloque virtuales (VBD)
Los dispositivos de bloque virtuales son objetos conectores (similares al PBD descrito anteriormente) que permiten asignaciones entre VDI y VM. Además de proporcionar un mecanismo para adjuntar un VDI a una VM, 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 dado, y si ese VDI se puede arrancar. Las operaciones de CLI relacionadas con los VBD se describen en comandos VBD.
Tipos de repositorios de almacenamiento
XenServer admite una variedad de tipos de almacenamiento para SR conectados tanto local como remotamente.
Advertencia:
XenServer no admite instantáneas a nivel de SAN externa de una LUN para ningún tipo de SR.
SR locales
Un repositorio de almacenamiento local (SR) está conectado a un único host y no se comparte entre todos los hosts de un grupo. El hardware de almacenamiento físico local puede ser una unidad de disco duro (HDD) o una unidad de estado sólido (SSD). Puede conectarse al host utilizando cualquiera de los siguientes métodos: SATA, SCSI, SAS, NVMe.
Los hosts de XenServer admiten los siguientes tipos de almacenamiento local:
SR remotos
XenServer admite almacenamiento conectado remotamente utilizando las siguientes unidades: iSCSI, NFS, SAS, SMB (solo versión 3), Fibre Channel.
Nota:
NVMe over Fibre Channel y NVMe over TCP no son compatibles.
Los siguientes tipos de almacenamiento conectados remotamente se pueden usar para crear SR compartidos para su grupo de XenServer.
Bibliotecas ISO:
Almacenamiento basado en archivos:
Almacenamiento basado en bloques:
- Almacenamiento iSCSI por software
- Almacenamiento HBA por hardware
- Almacenamiento de bloques GFS2 compartido con aprovisionamiento ligero
Comparación de tipos de almacenamiento compartido
La siguiente tabla compara las características de los diferentes tipos de almacenamiento compatibles con los SR compartidos. Tenga en cuenta estas capacidades al elegir su solución de almacenamiento.
| Basado en archivos (SMB/NFS) | Basado en bloques (iSCSI/HBA) LVM | Basado en bloques (iSCSI/HBA) GFS2 | |
|---|---|---|---|
| Tipo de disco virtual | VHD | VHD | QCOW2 |
| Número máximo de discos virtuales por SR | 20000 | 1000 | 20000 |
| Tamaño máximo de disco virtual | 2.040 GiB | 2.040 GiB | 16 TiB |
| Tamaño máximo del pool | 32/64 | 32 | 16 |
| Funciones compatibles | |||
| Migración de almacenamiento | Sí | Sí | No |
| Intellicache | Sí | Sí | No |
| Caché de lectura | Sí | No | Sí |
| Aprovisionamiento ligero (véase la nota) | Sí | No | Sí |
| Recuperación ante desastres | No | Sí | No |
Nota:
Para el almacenamiento LVM basado en bloques, puede implementar el aprovisionamiento ligero en la SAN subyacente. Sin embargo, esto no se recomienda con los SR de GFS2.
Formatos de datos de disco virtual
En general, existen los siguientes tipos de asignación de almacenamiento físico a un VDI:
-
VHD basado en volumen lógico en una LUN: El almacenamiento basado en bloques predeterminado de XenServer inserta un administrador de volúmenes lógicos en un disco. Este disco es un dispositivo conectado localmente (LVM) o una LUN conectada a una 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.
-
QCOW2 basado en archivos en una LUN: Las imágenes de VM se almacenan como archivos en formato QCOW2 de aprovisionamiento ligero en un sistema de archivos de disco compartido GFS2 en una LUN conectada a través de un iniciador de software iSCSI o una 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 ligero en un sistema de archivos local no compartido (SR de tipo EXT3/EXT4), un destino NFS compartido (SR de tipo NFS) o un destino SMB remoto (SR de tipo SMB).
-
QCOW2 basado en archivos en un sistema de archivos: Las imágenes de VM se almacenan como archivos en formato QCOW2 de aprovisionamiento ligero en un sistema de archivos XFS local no compartido.
Tipos de VDI
Para los SR de GFS2 y XFS, 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 el VDI. Esta opción solo se puede especificar mediante la CLI de xe.
Nota:
Si crea un VDI raw en un SR basado en LVM o en un SR de HBA/LUN por VDI, podría permitir que la VM propietaria acceda a datos que formaban parte de un VDI eliminado anteriormente (de cualquier formato) perteneciente a cualquier VM. Le recomendamos que considere sus requisitos de seguridad antes de usar esta opción.
Los VDI raw en un SR de NFS, EXT o SMB no permiten el acceso a los datos de VDI eliminados anteriormente pertenecientes a ninguna VM.
Para comprobar si un VDI se creó con type=raw, compruebe su mapa sm-config. Los comandos xe sr-param-list y vdi-param-list se pueden usar respectivamente para este fin.
Crear un disco virtual raw mediante la CLI de xe
-
Ejecute el siguiente comando para crear un VDI dada la 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 <!--NeedCopy--> -
Conecte el nuevo disco virtual a una VM. Use las herramientas de disco dentro de la VM para particionar y formatear, o para usar el nuevo disco de otra manera. Puede usar el comando
vbd-createpara 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 (ya sea raw, como se describió anteriormente, o VHD) y luego copiar datos en él desde un volumen existente. Use la CLI de xe para asegurarse de que el nuevo VDI tenga un tamaño virtual al menos tan grande como el VDI del que está copiando. Puede hacerlo comprobando su campo virtual-size, por ejemplo, usando el comando vdi-param-list. A continuación, puede conectar este nuevo VDI a una VM y usar su herramienta preferida dentro de la VM para realizar una copia de bloque directa de los datos. Por ejemplo, las herramientas estándar de administración de discos en Windows o el comando 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.
VDIs basados en VHD y QCOW2
Las imágenes VHD y QCOW2 pueden estar encadenadas, lo que permite que dos VDIs 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 copy-on-write del VDI. Esta característica permite que dichas VM se clonen rápidamente a partir de plantillas, lo que facilita un aprovisionamiento y despliegue muy rápidos de nuevas VM.
A medida que las VM y sus VDIs asociados se clonan con el tiempo, esto crea árboles de VDIs encadenados. Cuando se elimina uno de los VDIs de una cadena, XenServer racionaliza los otros VDIs de la cadena para eliminar los VDIs innecesarios. Este proceso de consolidación se ejecuta de forma asíncrona. La cantidad de espacio en disco recuperado y el tiempo necesario para realizar el proceso dependen del tamaño del VDI y de la cantidad de datos compartidos. Para obtener más información, consulte Notas sobre la consolidación.
Tanto los formatos VHD como QCOW2 admiten el aprovisionamiento ligero. El archivo de imagen se extiende automáticamente en fragmentos de grano fino a medida que la VM escribe datos en el disco. Para VHD basado en archivos y QCOW2 basado en GFS2, este enfoque tiene el considerable beneficio 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 del VDI. Sin embargo, el espacio no utilizado en el disco de instancia de copy-on-write 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 la cantidad de datos que se han 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 en modo de solo lectura para preservar la asignación desinflada. Los nodos de instantánea que se adjuntan en modo de lectura-escritura se inflan completamente al adjuntarse y se desinflan al desadjuntarse.
-
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 un VDI de 100 GB para una VM 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, más una pequeña sobrecarga de metadatos.
Al clonar VM basadas en una única plantilla VHD o QCOW2, cada VM secundaria forma una cadena donde los nuevos cambios se escriben en la nueva VM. Los bloques antiguos se leen directamente de la plantilla principal. Si la nueva VM se convierte en una plantilla adicional y se clonan más VM, la cadena resultante provoca una degradación del rendimiento. XenServer 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 VM usando XenCenter o use el comando vm-copy, que restablece la longitud de la cadena a 0.
Notas sobre la consolidación
Solo un proceso de consolidación está activo para un SR. Este hilo de proceso se ejecuta en el coordinador del grupo de SR. Mientras el proceso de consolidación está activo, puede ser necesario espacio adicional en el SR para acomodar los datos que se fusionan de un nivel del árbol delta a otro. Después de este proceso, el nivel redundante se elimina y se libera espacio.
Si tiene VM críticas ejecutándose en el coordinador del grupo, puede seguir los siguientes pasos para mitigar la E/S lenta ocasional:
-
Migre la VM a un host diferente al coordinador del grupo 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 disco virtual.