layout: doc description: “Thin provisioning better utilizes the available storage by allocating disk storage space to VDIs as data is written to the virtual disk, rather than allocating the full virtual size of the VDI in advance. The shared GFS2 type represents disks as a filesystem created on an iSCSI or HBA LUN.”—
El Provisioning ligero utiliza mejor el almacenamiento disponible al asignar espacio de almacenamiento en disco a los VDI a medida que los datos se escriben en el disco vDisk, en lugar de asignar el tamaño virtual completo del VDI por adelantado. El Provisioning ligero le permite reducir significativamente la cantidad de espacio necesario en un arreglo de discos de almacenamiento compartido y, con ello, su coste total de propiedad (TCO).
El aprovisionamiento controlado para el almacenamiento en bloque compartido es de particular interés en los siguientes casos:
Nota:
Recomendamos no usar una SR de GFS2 con una VLAN debido a un problema conocido por el que no se pueden agregar ni quitar hosts en una agrupación en clústeres si la red del clúster está en una VLAN que no es de administración.
El tipo GFS2 compartido representa los discos como un sistema de archivos creado en un LUN iSCSI o HBA. Los VDI almacenados en una SR GFS2 se almacenan en el formato de imagen QCOW2.
En este artículo se describe cómo configurar el entorno GFS2 mediante la CLI xe. Para configurar un entorno GFS2 mediante XenCenter, consulte la documentación del producto XenCenter.
Para ofrecer las ventajas del aprovisionamiento ligero en el almacenamiento en bloques compartidos sin riesgo de pérdida de datos, su grupo debe ofrecer un buen nivel de confiabilidad y conectividad. Es crucial que los hosts de la agrupación de recursos que usa GFS2 puedan comunicarse entre sí de manera confiable. Para garantizar esto, XenServer requiere que utilice un grupo agrupado en clústeres con su GFS2 SR. También le recomendamos que diseñe su entorno y configure las funciones de XenServer para proporcionar la mayor capacidad de recuperación y redundancia posible.
Antes de configurar el grupo de XenServer para que funcione con los SR de GFS2, revise los siguientes requisitos y recomendaciones para un entorno GFS2 ideal:
Recomendado: configure una infraestructura de red redundante.
Recomendado: Cree una red enlazada dedicada
Obligatorio: configurar un grupo agrupado
Recomendado: configurar múltiples rutas de almacenamiento
Obligatorio: crear un GFS2 SR
Un grupo agrupado con SR de GFS2 tiene algunas diferencias de comportamiento con respecto a otros tipos de grupo y SR. Para obtener más información, consulte Restricciones.
Una red enlazada conecta dos o más NIC para crear un único canal para el tráfico de la red. Le recomendamos que utilice una red enlazada para el tráfico de su grupo agrupado. Sin embargo, antes de configurar la red enlazada, asegúrese de que la configuración del hardware de la red promueva la redundancia en la red enlazada. Considere la posibilidad de implementar tantas de estas recomendaciones como sea posible para su organización y su entorno.
Las siguientes prácticas recomendadas agregan resiliencia frente a fallos de software, hardware o alimentación que pueden afectar a los conmutadores de red.
Es importante asegurarse de que los hosts de un grupo agrupado en clústeres puedan comunicarse entre sí de forma fiable. La creación de una red enlazada para el tráfico de este grupo aumenta la resiliencia del grupo agrupado.
Una red enlazada crea un vínculo entre dos o más NIC para crear un único canal de alto rendimiento que el grupo agrupado en clústeres puede utilizar para el tráfico de latidos del clúster. Recomendamos encarecidamente que esta red enlazada no se utilice para ningún otro tráfico. Cree una red independiente para que el grupo la utilice para el tráfico de administración.
Advertencia:
Si decide no seguir esta recomendación, corre un mayor riesgo de perder los paquetes de red de administración de clústeres. La pérdida de paquetes de red de administración de clústeres puede provocar que el grupo agrupado pierda quórum y que algunos o todos los hosts del grupo se autobloqueen.
Si el clúster está delimitado o tiene algún problema con esta configuración no recomendada, el servicio de soporte de XenServer podría pedirle que reproduzca el mismo problema en una configuración recomendada durante el transcurso de la investigación.
Para crear una red enlazada para utilizarla como red de agrupamiento:
Si tiene un firewall entre los hosts de su grupo, asegúrese de que los hosts puedan comunicarse en la red del clúster mediante los siguientes puertos:
Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.
Abra una consola en el host de XenServer que desee que actúe como coordinadora del grupo.
Cree una red para usarla con la NIC enlazada mediante el siguiente comando:
xe network-create name-label=bond0
<!--NeedCopy-->
Se devuelve el UUID de la nueva red.
Encuentre los UUID de los PIF que se van a usar en el enlace mediante el siguiente comando:
xe pif-list
<!--NeedCopy-->
Cree su red enlazada en modo activo-activo, modo activo-pasivo o modo enlace LACP. Según el modo de enlace que quiera usar, realice una de las siguientes acciones:
Para configurar el enlace en modo activo-activo (predeterminado), utilice el comando bond-create para crear el enlace. Con comas para separar los parámetros, especifique el UUID de red recién creado y los UUID de los PIF que se van a unir:
xe bond-create network-uuid=<network_uuid> /
pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
<!--NeedCopy-->
Escriba dos UUID cuando vincule dos NIC y cuatro UUID cuando vincule cuatro NIC. El UUID del enlace se devuelve después de ejecutar el comando.
Para configurar el enlace en modo activo-pasivo o enlace LACP, utilice la misma sintaxis, agregue el parámetro mode opcional y especifique lacp o active-backup:
xe bond-create network-uuid=<network_uuid> /
pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
mode=balance-slb | active-backup | lacp
<!--NeedCopy-->
Después de crear la red enlazada en el coordinador del grupo, al unir otros hosts XenServer al grupo, la información de red y enlace se replica automáticamente en el servidor que se une.
Para obtener más información, consulte Redes.
Nota:
- Para cambiar la dirección IP de la red de clústeres mediante XenCenter, es necesario inhabilitar temporalmente la agrupación en clústeres y GFS2.
- No cambie la vinculación de la red de clústeres mientras el clúster está activo y tiene máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien por completo (valla).
- Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en su red de clústeres que implica al menos un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercarlo cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.
Para probar los tiempos de conmutación por error de la red enlazada activa-pasiva:
En el caso de las redes enlazadas que utilizan el modo activo-pasivo, si el enlace activo falla, hay un período de conmutación por error en el que el enlace de red se interrumpe mientras el enlace pasivo pasa a estar activo. Si el tiempo que tarda la red enlazada activo-pasiva en realizar la conmutación por error supera el tiempo de espera del clúster, es posible que algunos o todos los hosts del grupo agrupado en clústeres sigan bloqueados.
Puede probar el tiempo de conmutación por error de la red enlazada obligando a la red a realizar la conmutación por error mediante uno de los métodos siguientes:
Repita la prueba varias veces para asegurarse de que el resultado sea uniforme.
El valor de tiempo de espera del clúster de su grupo depende del número de hosts que haya en el clúster. Ejecute el siguiente comando para encontrar el token-timeout valor del pool en segundos:
xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout
Si es probable que el tiempo de conmutación por error sea mayor que el valor del tiempo de espera, es posible que la infraestructura y la configuración de la red no sean lo suficientemente confiables como para admitir un grupo agrupado en clústeres.
Para usar el almacenamiento GFS2 compartido, el grupo de recursos de XenServer debe ser un grupo agrupado en clústeres. Habilite la agrupación en clústeres en su grupo antes de crear una SR GFS2.
Un grupo agrupado en clústeres es un grupo de hosts de XenServer que están más estrechamente conectados y coordinados que los hosts de grupos no agrupados en clústeres. Los hosts del clúster mantienen una comunicación constante entre sí en una red seleccionada. Todos los hosts del clúster conocen el estado de todos los hosts del clúster. Esta coordinación de host permite que el clúster controle el acceso al contenido de GFS2 SR. Para garantizar que el grupo agrupado permanezca siempre en comunicación, cada host de un clúster debe estar siempre en comunicación con al menos la mitad de los hosts del clúster (incluido él mismo). Este estado se conoce como anfitrión que tiene quórum. Si un host no tiene quórum, se reinicia con fuerza y se elimina del clúster. Esta acción se conoce como “esgrima”.
Para obtener más información, consulte Grupos agrupados.
Antes de empezar a configurar el grupo agrupado, asegúrese de que se cumplen los siguientes requisitos previos:
Planifique crear un grupo de entre 3 y 16 hosts.
Siempre que sea posible, utilice un número impar de hosts en un grupo agrupado, ya que esto garantiza que los hosts siempre puedan determinar si tienen quorun. Le recomendamos que utilice la agrupación en clústeres solo en grupos que contengan al menos tres hosts, ya que los grupos de dos hosts son sensibles a la posibilidad de que se autoproteja todo el grupo.
Los grupos agrupados solo admiten hasta 16 hosts por grupo.
Para usar la CLI xe para crear un grupo en clúster:
Cree un grupo de recursos de al menos tres hosts de XenServer.
Repita los siguientes pasos en cada host de XenServer que no sea el coordinador del grupo:
Une el host de XenServer al grupo en el coordinador del grupo mediante el siguiente comando:
xe pool-join master-address=<master_address> /
master-username=<administrators_username> /
master-password=<password>
<!--NeedCopy-->
El valor del master-address parámetro debe establecerse en el nombre de dominio completo del host de XenServer que es el coordinador del grupo. password Debe ser la contraseña de administrador establecida cuando se instaló el coordinador de la agrupación.
Para obtener más información, consulte Hosts y grupos de recursos.
Para cada PIF que pertenezca a esta red, defina disallow-unplug=true.
Busque los UUID de los PIF que pertenecen a la red mediante el siguiente comando:
xe pif-list
<!--NeedCopy-->
Ejecute el siguiente comando en un host de XenServer de su grupo de recursos:
xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
<!--NeedCopy-->
Habilite la agrupación en clústeres en su grupo. Ejecute el siguiente comando en un host de XenServer de su grupo de recursos:
xe cluster-pool-create network-uuid=<network_uuid>
<!--NeedCopy-->
Proporcione el UUID de la red enlazada que creó en un paso anterior.
Si no tiene suficiente memoria de dominio de control en sus hosts, su agrupación puede experimentar inestabilidad en la red. La inestabilidad de la red puede causar problemas a una agrupación en clústeres con la SR de GFS2.
Es importante asegurarse de que su agrupación en clústeres tenga la cantidad adecuada de memoria de dominio de control. Para obtener información sobre cómo cambiar la cantidad de memoria del dominio de control y supervisar el comportamiento de la memoria, consulte Uso de memoria.
Asegúrese de que las rutas múltiples de almacenamiento estén configuradas entre su grupo en clúster y su SR GFS2.
Las rutas múltiples enrutan el tráfico de almacenamiento a un dispositivo de almacenamiento a través de múltiples rutas para lograr redundancia. Todas las rutas pueden tener tráfico activo durante el funcionamiento normal, lo que se traduce en un aumento del rendimiento.
Antes de habilitar las rutas múltiples, compruebe que se cumplen estas afirmaciones:
Su conmutador Ethernet o de fibra está configurado para que varios destinos estén disponibles en su servidor de almacenamiento.
Por ejemplo, un back-end de almacenamiento iSCSI consultado por sendtargets en un portal determinado devuelve varios destinos, como en el siguiente ejemplo:
iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
192.168.0.161:3260,1 iqn.strawberry:litchie
192.168.0.204:3260,2 iqn.strawberry:litchie
Sin embargo, puede realizar una configuración adicional para habilitar rutas múltiples iSCSI para arreglos que solo exponen un único destino. Para obtener más información, consulte Rutas múltiples iSCSI para arreglos que solo exponen un único objetivo.
Solo para iSCSI, el dominio de control (dom0) tiene una dirección IP en cada subred utilizada por el almacenamiento de rutas múltiples.
Asegúrese de que para cada ruta al almacenamiento tenga una NIC y que haya una dirección IP configurada en cada NIC. Por ejemplo, si quiere cuatro rutas a su almacenamiento, debe tener cuatro NIC que tengan una dirección IP configurada cada una.
Solo para iSCSI, cada objetivo e iniciador iSCSI tiene un IQN único.
Solo para iSCSI, los puertos de destino iSCSI funcionan en modo portal.
Solo para HBA, hay varios HBA conectados a la estructura del conmutador.
Si es posible, utilice varios conmutadores redundantes.
Le recomendamos que habilite las rutas múltiples para todos los hosts de su grupo antes de crear el SR. Si crea el SR antes de habilitar las rutas múltiples, debe poner sus hosts en modo de mantenimiento para habilitar las rutas múltiples.
Abra una consola en el host de XenServer.
Desconecte todos los PBD del host mediante el siguiente comando:
xe pbd-unplug uuid=<pbd_uuid>
<!--NeedCopy-->
Puede usar el comando xe pbd-list para encontrar el UUID de los PBD.
Establezca el valor del parámetro multipathing en true mediante el siguiente comando:
xe host-param-set uuid=<host uuid> multipathing=true
<!--NeedCopy-->
Si hay SR existentes en los hosts que se ejecutan en el modo de ruta única y tienen varias rutas:
Migre o suspenda cualquier huésped en ejecución con discos virtuales en los SR afectados.
Conecte de nuevo el PBD de los RA afectados para volver a conectarlos mediante rutas múltiples:
xe pbd-plug uuid=<pbd_uuid>
<!--NeedCopy-->
Repita estos pasos para habilitar las rutas múltiples en todos los hosts del grupo.
Asegúrese de habilitar las rutas múltiples en todos los hosts del grupo. Todas las configuraciones de cableado y, en el caso de iSCSI, de subred deben coincidir con las NIC correspondientes de cada host.
Para obtener más información, consulte Múltiples rutas de almacenamiento.
Cree su GFS2 SR compartido en un LUN iSCSI o HBA que esté visible para todos los hosts de XenServer de su agrupación de recursos. No recomendamos usar un LUN de aprovisionamiento fino con GFS2. Sin embargo, si elige esta configuración, debe asegurarse de que el LUN siempre tenga suficiente espacio para permitir que XenServer escriba en él.
Puede agregar hasta 62 SR de GFS2 a un grupo agrupado.
Si ha utilizado anteriormente su dispositivo de almacenamiento basado en bloques para un aprovisionamiento denso con LVM, XenServer lo detectará. XenCenter le brinda la oportunidad de usar la partición LVM existente o de formatear el disco y configurar una partición GFS2.
Puede crear GFS2 a través de SRs iSCSI mediante XenCenter. Para obtener más información, consulte Almacenamiento iSCSI de software en la documentación del producto XenCenter.
Como alternativa, puede usar la CLI xe para crear una SR GFS2 sobre iSCSI.
Parámetros de configuración de dispositivos para SRs GFS2:
| Nombre del parámetro | Descripción | ¿Obligatorio? |
|---|---|---|
provider |
La implementación del proveedor de bloques. En este caso, iscsi. |
Sí |
target |
La dirección IP o el nombre de host del archivador iSCSI que aloja | Sí |
targetIQN |
El objetivo IQN del archivador iSCSI que aloja el SR | Sí |
SCSIid |
Identificador SCSI del dispositivo | Sí |
Puede encontrar los valores que se van a usar para estos parámetros mediante el comando xe sr-probe-ext.
xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->
Comience por ejecutar el siguiente comando:
xe sr-probe-ext type=gfs2 device-config:provider=iscsi
<!--NeedCopy-->
La salida del comando le pide que proporcione parámetros adicionales y le da una lista de valores posibles en cada paso.
Repita el comando y agregue nuevos parámetros cada vez.
Cuando el resultado del comando comienza con Found the following complete configurations that can be used to create SRs:, puede localizar el SR mediante el comando xe sr-create y los device-config parámetros que especificó.
Ejemplo de salida :
``` Se encontraron las siguientes configuraciones completas que se pueden usar para crear SR: Configuración 0: scsiId: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 target: 198.51.100.27 provider: iscsi
Configuration 0 extra information: ```
Para crear una SR GFS2 compartida en un LUN específico de un destino iSCSI, ejecute el siguiente comando en un servidor de su grupo en clúster:
xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
device-config:provider=iscsi device-config:targetIQN=<target_iqns> \
device-config:target=<portal_address> device-config:SCSIid=<scsci_id>
Si no se puede acceder al destino iSCSI mientras los sistemas de archivos GFS2 están montados, es posible que algunos hosts del grupo agrupado en clústeres se reinicien con fuerza (valla).
Para obtener más información sobre cómo trabajar con SR iSCSI, consulte Compatibilidad con iSCSI de software.
Puede crear GFS2 a través de SR de HBA mediante XenCenter. Para obtener más información, consulte Almacenamiento de HBA de hardware en la documentación del producto XenCenter.
Como alternativa, puede usar la CLI xe para crear una GFS2 a través de HBA SR.
Parámetros de configuración de dispositivos para SRs GFS2:
| Nombre del parámetro | Descripción | ¿Obligatorio? |
|---|---|---|
provider |
La implementación del proveedor de bloques. En este caso, hba. |
Sí |
SCSIid |
Identificador SCSI del dispositivo | Sí |
Puede encontrar los valores que se van a usar para el parámetro ScsiId mediante el comando xe sr-probe-ext.
xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
Comience por ejecutar el siguiente comando:
xe sr-probe-ext type=gfs2 device-config:provider=hba
La salida del comando le pide que proporcione parámetros adicionales y le da una lista de valores posibles en cada paso.
Repita el comando y agregue nuevos parámetros cada vez.
Cuando el resultado del comando comienza con Found the following complete configurations that can be used to create SRs:, puede localizar el SR mediante el comando xe sr-create y los device-config parámetros que especificó.
Ejemplo de salida :
``` Se encontraron las siguientes configuraciones completas que se pueden usar para crear SR: Configuración 0: scsiId: 36001405852f77532a064687aea8a5b3f TargetIQN: iqn.2009-01.example.com:iscsi192a25d6 target: 198.51.100.27 provider: iscsi
Configuration 0 extra information: ```
Para crear una SR GFS2 compartida en un LUN específico de un destino de HBA, ejecute el siguiente comando en un servidor de su grupo agrupado en clúster:
xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
device-config:provider=hba device-config:SCSIid=<device_scsi_id>
<!--NeedCopy-->
Para obtener más información sobre cómo trabajar con SR de HBA, consulte Adaptadores de bus de host de hardware.
Ahora que ha configurado su entorno de GFS2, es importante que mantenga la estabilidad de su grupo agrupado asegurándose de que tiene quórum. Para obtener más información, consulte Administrar su grupo agrupado.
Si tiene problemas con su entorno de GFS2, consulte Solucionar problemasde grupos agrupados en clústeres.
Puede gestionar su GFS2 SR de la misma forma que lo hace con otros SR. Por ejemplo, puede agregar capacidad a la matriz de almacenamiento para aumentar el tamaño del LUN. Para obtener más información, consulte Expansión de LUN en vivo.
El almacenamiento GFS2 compartido tiene actualmente las siguientes restricciones:
Al igual que con cualquier SR de aprovisionamiento ligero, si el uso de SR de GFS2 aumenta hasta el 100%, fallan las escrituras posteriores de las VM. Estas escrituras fallidas pueden provocar fallos en la máquina virtual, posibles daños en los datos o ambas cosas.
XenCenter muestra una alerta cuando el uso de SR aumenta hasta un 80%. Asegúrese de supervisar su GFS2 SR para detectar esta alerta y tomar las medidas apropiadas si lo ve. En una GFS2 SR, el uso elevado provoca una degradación del rendimiento. Le recomendamos que mantenga su uso de SR por debajo del 80%.
La migración de máquinas virtuales con migración de almacenamiento (en vivo o sin conexión) no es compatible con las máquinas virtuales cuyas VDI están en un SR GFS2. Tampoco puede migrar VDI de otro tipo de SR a un SR GFS2.
El transporte de FCoE no es compatible con los SR GFS2.
Recortar/desasignar no se admite en los SR de GFS2.
Los SR de GFS2 no admiten CHAP.
Las métricas de rendimiento no están disponibles para los SR de GFS2 y los discos en estos SR.
El seguimiento de bloques modificados no es compatible con los VDI almacenados en SRs de GFS2.
No puede exportar VDI de más de 2 TiB como VHD u OVA/OVF. Sin embargo, puede exportar máquinas virtuales con VDI de más de 2 TiB en formato XVA.
No recomendamos usar un LUN de aprovisionamiento fino con GFS2. Sin embargo, si elige esta configuración, debe asegurarse de que el LUN siempre tenga suficiente espacio para permitir que XenServer escriba en él.
No puede tener más de 62 SR GFS2 en su agrupación.
Los grupos agrupados solo admiten hasta 16 hosts por grupo.
Para habilitar la alta disponibilidad en su agrupación en clústeres, la SR de latido debe ser una SR de GFS2.
Para el tráfico de clústeres, le recomendamos encarecidamente que utilice una red enlazada que utilice al menos dos conmutadores de red diferentes. No utilice esta red para ningún otro propósito.
Para cambiar la dirección IP de la red de clústeres mediante XenCenter, es necesario inhabilitar temporalmente la agrupación en clústeres y GFS2.
No cambie la vinculación de la red de clústeres mientras el clúster está activo y tiene máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien por completo (valla).
Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en su red de clústeres que implica al menos un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercarlo cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.