Citrix Hypervisor

Almacenamiento en bloque GFS2 compartido de aprovisionamiento fino

January 31, 2025

Contribución de:

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.

El aprovisionamiento fino utiliza mejor el almacenamiento disponible mediante la asignación de espacio de almacenamiento en disco a las VDI a medida que los datos se escriben en el disco virtual, en lugar de asignar el tamaño virtual completo de la VDI por adelantado. El aprovisionamiento ligero le permite reducir significativamente la cantidad de espacio necesario en una cabina de almacenamiento compartido y, con ello, su coste total de propiedad (TCO).

El aprovisionamiento fino para el almacenamiento en bloque compartido es de especial interés en los siguientes casos:

Desea aumentar la eficiencia del espacio. Las imágenes están escasas y no muy distribuidas.
Desea reducir el número de operaciones de E/S por segundo en la cabina de almacenamiento. El GFS2 SR es el primer tipo de SR que admite el almacenamiento en caché de lectura de almacenamiento en el almacenamiento en bloque compartido.
Se usa una imagen base común para varias máquinas virtuales. Normalmente, las imágenes de las máquinas virtuales individuales utilizarán incluso menos espacio.
Utiliza instantáneas. Cada instantánea es una imagen y cada imagen es ahora escasa.
Desea crear VDI que tengan un tamaño superior a 2 TiB. El GFS2 SR admite VDI de hasta 16 TiB de tamaño.
Su almacenamiento no es compatible con NFS o SMB3 y solo admite almacenamiento en bloque. Si su almacenamiento es compatible con NFS o SMB3, le recomendamos que utilice estos tipos de SR en lugar de GFS2.
El almacenamiento no admite el aprovisionamiento fino de LUN. Si su almacenamiento realiza LUN de aprovisionamiento fino, puede encontrar problemas y quedarse sin espacio al combinarlo con GFS2. La combinación de GFS2 con un LUN de aprovisionamiento fino no proporciona muchas ventajas adicionales y no se recomienda.

Nota: No

Se recomienda no utilizar un SR GFS2 con una VLAN debido a un problema conocido en el que no se pueden agregar o eliminar hosts en un grupo agrupado 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 un 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.

1. Planifique su entorno GFS2

Para proporcionar los beneficios del aprovisionamiento fino en el almacenamiento en bloque compartido sin riesgo de pérdida de datos, su grupo debe ofrecer un buen nivel de confiabilidad y conectividad. Es crucial que los hosts del grupo de recursos que utiliza GFS2 puedan comunicarse entre sí de forma fiable. Para garantizar esto, Citrix Hypervisor requiere que utilice un grupo agrupado con su GFS2 SR. También le recomendamos que diseñe su entorno y configure las funciones de Citrix Hypervisor para proporcionar la mayor resistencia y redundancia posible.

Antes de configurar el grupo de Citrix Hypervisor para que funcione con SR de GFS2, revise los siguientes requisitos y recomendaciones para un entorno GFS2 ideal:

Recomendado: Configuración de la infraestructura de red redundante.
Recomendado: Creación de una red enlazada dedicada
Obligatorio: Configuración de un grupo agrupado
Opcional Aumente la memoria del dominio de control
Recomendado: Configuración de múltiples rutas de almacenamiento
Obligatorio: Crear un SR GFS2

Un grupo agrupado con SR GFS2 tiene algunas diferencias en el comportamiento con respecto a otros tipos de grupo y SR. Para obtener más información, consulte Restricciones.

2. Configurar la infraestructura de red redundante

Una red enlazada enlaza dos o más NIC para crear un único canal para el tráfico de red. Se recomienda utilizar una red enlazada para el tráfico del grupo agrupado. Sin embargo, antes de configurar la red enlazada, asegúrese de que la configuración de hardware de 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 entorno.

Las siguientes prácticas recomendadas agregan resistencia frente a errores de software, hardware o energía que pueden afectar a los conmutadores de red:

Asegúrese de tener conmutadores de red físicos independientes disponibles para su uso en la red vinculada, no solo puertos en el mismo conmutador.
Asegúrese de que los interruptores separados extraigan energía de diferentes unidades de distribución de energía (PDU) independientes.
Si es posible, en su centro de datos, coloque las PDU en diferentes fases de la alimentación de energía o incluso en alimentaciones proporcionadas por diferentes compañías de servicios públicos.
Considere la posibilidad de utilizar unidades de alimentación ininterrumpida para garantizar que los conmutadores de red y los servidores puedan seguir funcionando o realizar un apagado ordenado en caso de un corte de energía.

3. Crear una red vinculada dedicada

Es importante asegurarse de que los hosts de un grupo agrupado puedan comunicarse de forma fiable entre sí. La creación de una red enlazada para este tráfico de grupo aumenta la resistencia del grupo agrupado.

Una red enlazada crea un enlace entre dos o más NIC para crear un único canal de alto rendimiento que el grupo agrupado 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 use para administrar el tráfico.

Advertencia:

Si decide no seguir esta recomendación, corre un mayor riesgo de perder paquetes de red de administración de clústeres. La pérdida de paquetes de red de administración de clústeres puede hacer que el grupo agrupado pierda quórum y que algunos o todos los hosts del grupo se autodelimiten.

Si el clúster está cercado o se enfrenta a un problema en esta configuración no recomendada, es posible que el soporte técnico le pida que reproduzca el mismo problema en una configuración recomendada durante el curso de la investigación.

Para crear una red enlazada para utilizarla como red de agrupación en clústeres:

Si tiene un firewall entre los hosts del grupo, asegúrese de que los hosts puedan comunicarse en la red del clúster mediante los siguientes puertos:
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
Para obtener más información, consulte Puertos de comunicación utilizados por Citrix Hypervisor.
Abra una consola en el servidor de Citrix Hypervisor que quiera que actúe como maestro de grupo.
Cree una red para su uso con la NIC enlazada mediante el siguiente comando:
```
  xe network-create name-label=bond0

```
Se devuelve el UUID de la nueva red.
Busque los UUID de los PIF para usar en el enlace mediante el siguiente comando:
```
  xe pif-list

```
Cree su red enlazada en modo activo-activo, modo activo-pasivo o modo de enlace LACP. En función del modo de enlace que desee utilizar, realice una de las siguientes acciones:
- Para configurar el enlace en modo activo-activo (predeterminado), utilice el comando crear vínculos para crear el vínculo. Usando comas para separar los parámetros, especifique el UUID de red recién creado y los UUID de los PIF que se van a vincular:
```
   xe bond-create network-uuid=<network_uuid> /
       pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
 
```
  Escriba dos UUID cuando vincule dos NIC y cuatro UUID cuando vincule cuatro NIC. El UUID del bono se devuelve después de ejecutar el comando.
- Para configurar el enlace en modo de enlace activo-pasivo o LACP, utilice la misma sintaxis, agregue el atributo opcional modo y especifique LACP o copia de seguridad activa:
```
   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
 
```

Después de crear la red enlazada en el maestro de grupo, cuando se une a otros servidores de Citrix Hypervisor al grupo, la información de red y enlace se replica automáticamente en el servidor de unión.

Para obtener más información, consulte Gestión de redes.

Nota: No

Para cambiar la dirección IP de la red del clúster mediante XenCenter, es necesario deshabilitar temporalmente la agrupación en clústeres y GFS2.

No cambie la vinculación de la red de agrupación en clústeres mientras el clúster esté activo y tenga máquinas virtuales en ejecución. Esta acción puede hacer que los hosts del clúster se reinicien de forma completa (cercado).

Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en la red de agrupación en clústeres que involucra al menos a un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercar 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 se produce un error en el enlace activo, hay un período de conmutación por error en el que el enlace de red se interrumpe mientras que el enlace pasivo se activa. Si el tiempo que tarda la red enlazada activa-pasiva en conmutar por error es mayor que el tiempo de espera del clúster, es posible que algunos o todos los hosts del grupo agrupado sigan cercando.

Puede probar el tiempo de conmutación por error de la red enlazada forzando la conmutación por error de la red mediante uno de los siguientes métodos:

Tirando físicamente de los cables de red
Al deshabilitar los puertos del switch en un enlace de red

Repita la prueba varias veces para asegurarse de que el resultado sea consistente.

El valor de tiempo de espera del clúster del grupo depende del número de hosts que haya en el clúster. Ejecute el siguiente comando para encontrar el archivo tiempo de espera de token Valor en segundos para el grupo:

  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 de tiempo de espera, es posible que la infraestructura y la configuración de red no sean lo suficientemente confiables como para admitir un grupo de clústeres.

4. Configurar un grupo agrupado

Para utilizar el almacenamiento compartido GFS2, el grupo de recursos de Citrix Hypervisor debe ser un grupo agrupado. Habilite la agrupación en clústeres en su grupo antes de crear un SR GFS2.

Un grupo agrupado es un grupo de servidores Citrix Hypervisor que están más estrechamente conectados y coordinados que los hosts de grupos no agrupados. 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 cada uno de los hosts del clúster. Esta coordinación de host permite que el clúster controle el acceso al contenido del 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 host que tiene quórum. Si un host no tiene quórum, se reinicia de forma completa y se elimina del clúster. Esta acción se denomina “vallado”.

Para obtener más información, consulte Grupos agrupados.

Antes de empezar a configurar el grupo de agrupados, asegúrese de que se cumplen los siguientes requisitos previos:

Planee 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. Se recomienda utilizar 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 autolimitación de todo el grupo.

Los grupos agrupados solo admiten hasta 16 hosts por grupo.
Todos los servidores Citrix Hypervisor del grupo agrupado deben tener al menos 2 GiB de memoria de dominio de control.
Todos los hosts del clúster deben utilizar direcciones IP estáticas para la red del clúster.
Si va a agrupar en clústeres un grupo existente, asegúrese de que la alta disponibilidad esté deshabilitada. Puede volver a habilitar la alta disponibilidad después de habilitar la agrupación en clústeres.

Para usar la CLI de xe para crear un grupo agrupado:

Cree un grupo de recursos de al menos tres servidores Citrix Hypervisor.

Repita los siguientes pasos en cada servidor Citrix Hypervisor que se una y que no sea el maestro de grupo:
1. Abra una consola en el servidor de Citrix Hypervisor.
2. Únase el servidor Citrix Hypervisor al grupo en el maestro de grupo mediante el siguiente comando:
```
  xe pool-join master-address=<master_address> /
      master-username=<administrators_username> /
      master-password=<password>

```
  El valor de la propiedad dirección-maestra debe establecerse en el nombre de dominio completo del servidor Citrix Hypervisor que es el maestro del grupo. El contraseña Debe ser la contraseña de administrador establecida cuando se instaló el maestro de grupo.
Para obtener más información, consulte Hosts y grupos de recursos.
Para cada PIF que pertenezca a esta red, establezca disallow-unplug=true.
1. Busque los UUID de los PIF que pertenecen a la red mediante el siguiente comando:
```
  xe pif-list

```
2. Ejecute el siguiente comando en un servidor Citrix Hypervisor de su grupo de recursos:
```
  xe pif-param-set disallow-unplug=true uuid=<pif_uuid>

```
Habilite la agrupación en clústeres en el grupo. Ejecute el siguiente comando en un servidor Citrix Hypervisor de su grupo de recursos:
```
  xe cluster-pool-create network-uuid=<network_uuid>

```
Proporcione el UUID de la red enlazada que creó en un paso anterior.

5. Aumente la memoria de su dominio de control

Si no tiene suficiente memoria de dominio de control en los hosts, el grupo puede experimentar inestabilidad de red. La inestabilidad de la red puede causar problemas para un grupo agrupado con SR GFS2.

Es importante asegurarse de que el grupo en clúster tenga una 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.

6. Configurar múltiples rutas de almacenamiento

Asegúrese de que las rutas múltiples de almacenamiento estén configuradas entre el grupo de clústeres y el SR de GFS2.

La ruta múltiple enruta el tráfico de almacenamiento a un dispositivo de almacenamiento a través de varias rutas para obtener redundancia. Todas las rutas pueden tener tráfico activo durante el funcionamiento normal, lo que se traduce en un mayor rendimiento.

Antes de habilitar las rutas múltiples, verifique que las siguientes instrucciones sean verdaderas:

El conmutador Ethernet o de fibra está configurado para que varios destinos estén disponibles en el servidor de almacenamiento.

Por ejemplo, un back-end de almacenamiento iSCSI consultado para Objetivos de envío en un portal determinado devuelve varios destinos, como en el ejemplo siguiente:
```
    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 la ruta múltiple iSCSI para matrices que solo exponen un único destino. Para obtener más información, consulte Múltiples rutas iSCSI para matrices que solo exponen un único destino.
Solo para iSCSI, el dominio de control (dom0) tiene una dirección IP en cada subred utilizada por el almacenamiento de múltiples rutas.

Asegúrese de que para cada ruta de acceso al almacenamiento, tenga una NIC y que haya una dirección IP configurada en cada NIC. Por ejemplo, si desea cuatro rutas de acceso al almacenamiento, debe tener cuatro NIC que tengan configurada una dirección IP cada una.
Solo para iSCSI, cada destino e iniciador iSCSI tiene un IQN único.
Solo para iSCSI, los puertos de destino iSCSI funcionan en modo de portal.
Solo para HBA, se conectan varios HBA a la estructura del conmutador.
Si es posible, utilice varios conmutadores redundantes.

Para habilitar la ruta múltiple mediante la CLI xe

Se recomienda habilitar las rutas múltiples para todos los hosts del grupo antes creando el SR. Si crea el SR antes de habilitar las rutas múltiples, debe poner los hosts en modo de mantenimiento para habilitar las rutas múltiples.

Abra una consola en el servidor de Citrix Hypervisor.
Desconecte todos los PBD del host mediante el siguiente comando:
```
  xe pbd-unplug uuid=<pbd_uuid>

```
Puede utilizar el comando xe pbd-list para encontrar el UUID de los PBD.
Establezca el valor de la propiedad Rutas múltiples parámetro a verdadero mediante el siguiente comando:
```
  xe host-param-set uuid=<host uuid> multipathing=true

```
Si hay SR existentes en los hosts que se ejecutan en modo de ruta única que tienen varias rutas:
- Migre o suspenda los invitados en ejecución con discos virtuales en los SR afectados.
- Vuelva a conectar el PBD de los SR afectados para volver a conectarlos mediante múltiples rutas:
```
   xe pbd-plug uuid=<pbd_uuid>
 
```
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. Todo el cableado y, en el caso de iSCSI, las configuraciones de subred deben coincidir con las NIC correspondientes de cada host.

Para obtener más información, consulte Múltiples rutas de almacenamiento.

7. Crea un GFS2 SR

Cree su SR GFS2 compartido en un iSCSI o un LUN de HBA que sea visible para todos los servidores de Citrix Hypervisor de su grupo de recursos. No se recomienda utilizar 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 Citrix Hypervisor escriba en él.

Puede agregar hasta 62 SR GFS2 a un grupo agrupado.

Si ha utilizado anteriormente su dispositivo de almacenamiento basado en bloques para el aprovisionamiento grueso con LVM, Citrix Hypervisor lo detecta. XenCenter le da la oportunidad de utilizar la partición LVM existente o de formatear el disco y configurar una partición GFS2.

Creación de un GFS2 compartido a través de iSCSI SR

Puede crear GFS2 a través de SR iSCSI mediante XenCenter. Para obtener más información, consulte Almacenamiento iSCSI de software en la documentación del producto XenCenter.

Como alternativa, puede utilizar la CLI xe para crear un GFS2 a través de iSCSI SR.

Parámetros de configuración del dispositivo para SR GFS2:

Nombre del parámetro	Descripción	Si son necesarias?
`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 destino IQN del archivador iSCSI que aloja el SR	Sí
`SCSIid`	ID de SCSI del dispositivo	Sí

Puede encontrar los valores que se van a utilizar para estos parámetros mediante el comando xe sr-probe-ext mandar.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

Comience ejecutando el siguiente comando:
```
  xe sr-probe-ext type=gfs2 device-config:provider=iscsi

```
La salida del comando le pide que proporcione parámetros adicionales y proporciona una lista de valores posibles en cada paso.
Repita el comando, agregando nuevos parámetros cada vez.

Cuando la salida del comando comienza con Se encontraron las siguientes configuraciones completas que se pueden usar para crear SR:, puede localizar el SR utilizando el comando xe sr-create y el comando configuración-dispositivo parámetros que especificó.

Salida de ejemplo:

  Found the following complete configurations that can be used to create SRs:
  Configuration 0:
    SCSIid       : 36001405852f77532a064687aea8a5b3f
        targetIQN: iqn.2009-01.example.com:iscsi192a25d6
           target: 198.51.100.27
         provider: iscsi


  Configuration 0 extra information:
<!--NeedCopy-->

Para crear un SR GFS2 compartido en un LUN específico de un destino iSCSI, ejecute el siguiente comando en un servidor del 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>
<!--NeedCopy-->

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 se reinicien de forma completa (cercado).

Para obtener más información sobre cómo trabajar con SR iSCSI, consulte Compatibilidad con iSCSI de software.

Creación de un GFS2 compartido a través de HBA SR

Puede crear GFS2 a través de SR de HBA mediante XenCenter. Para obtener más información, consulte Almacenamiento HBA de hardware en la documentación del producto XenCenter.

Como alternativa, puede usar la CLI xe para crear un GFS2 a través de HBA SR.

Parámetros de configuración del dispositivo para SR GFS2:

Nombre del parámetro	Descripción	Si son necesarias?
`provider`	La implementación del proveedor de bloques. En este caso, `Hba`.	Sí
`SCSIid`	ID de 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 mandar.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

Comience ejecutando 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 proporciona una lista de valores posibles en cada paso.
Repita el comando, agregando nuevos parámetros cada vez.

Salida de ejemplo:

  Found the following complete configurations that can be used to create SRs:
  Configuration 0:
    SCSIid       : 36001405852f77532a064687aea8a5b3f
        targetIQN: iqn.2009-01.example.com:iscsi192a25d6
           target: 198.51.100.27
         provider: iscsi


  Configuration 0 extra information:
<!--NeedCopy-->

Para crear un SR GFS2 compartido en un LUN específico de un destino HBA, ejecute el siguiente comando en un servidor del grupo agrupado:

  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.

¿Qué sigue?

Ahora que ha configurado su entorno GFS2, es importante que mantenga la estabilidad de su grupo agrupado asegurándose de que tenga quórum. Para obtener más información, consulte Administre su grupo agrupado.

Si tiene problemas con su entorno GFS2, consulte Solución de problemas de grupos agrupados.

Puede administrar su SR GFS2 de la misma manera que lo hace con otros SR. Por ejemplo, puede agregar capacidad a la cabina de almacenamiento para aumentar el tamaño del LUN. Para obtener más información, consulte Expansión de LUN en vivo.

Restricciones

Actualmente, el almacenamiento compartido GFS2 tiene las siguientes restricciones:

Al igual que con cualquier SR de aprovisionamiento fino, si el uso de SR de GFS2 crece hasta el 100 %, se producen errores en las escrituras adicionales de las máquinas virtuales. Estas escrituras fallidas pueden provocar errores dentro de la máquina virtual, posibles daños en los datos o ambos.
XenCenter muestra una alerta cuando el uso de SR aumenta al 80 %. Asegúrese de supervisar su GFS2 SR para esta alerta y tomar las medidas adecuadas si la observa. En un SR GFS2, el uso elevado provoca una degradación del rendimiento. Te recomendamos que mantengas el uso de la 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 FCoE de software no es compatible con los SR GFS2 (para FCoE completamente descargado usa HBA).
Recortar/desasignar no es compatible con los SR GFS2.
CHAP no es compatible con los SR GFS2.
Las máquinas virtuales de clones completos de MCS no son compatibles con los SR de GFS2.
No se admite el uso de varios SR GFS2 en el mismo catálogo de MCS.
Las métricas de rendimiento no están disponibles para los SR de GFS2 y los discos de estos SR.
El seguimiento de bloques modificados no es compatible con las VDI almacenadas en SR GFS2.
No se pueden 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 se recomienda utilizar 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 Citrix Hypervisor escriba en él.
No se recomienda utilizar la deduplicación de SAN con SR GFS2. Sin embargo, si elige esta configuración, debe utilizar una supervisión externa adecuada de la utilización de su SAN para asegurarse de que siempre haya espacio para que Citrix Hypervisor escriba.
El sistema de archivos GFS2 no puede tener más de 100 TiB.
No puede tener más de 62 SR GFS2 en su grupo.
Los grupos agrupados solo admiten hasta 16 hosts por grupo.
Para habilitar HA en el grupo agrupado, el SR de latido debe ser un SR GFS2.
Para el tráfico de clúster, se recomienda encarecidamente utilizar 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 del clúster mediante XenCenter, es necesario deshabilitar temporalmente la agrupación en clústeres y GFS2.
No cambie la vinculación de la red de agrupación en clústeres mientras el clúster esté activo y tenga máquinas virtuales en ejecución. Esta acción puede hacer que los hosts del clúster se reinicien de forma completa (cercado).
Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en la red de agrupación en clústeres que involucra al menos a un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercar cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Cloud Software Group solo tiene traducción automática. Cloud Software Group no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Cloud Software Group se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Cloud Software Group, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Cloud Software Group no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

¿Le ha resultado útil?

Almacenamiento en bloque GFS2 compartido de aprovisionamiento fino

January 31, 2025

Contribución de:

January 31, 2025

Contribución de:

En este artículo

1. Planifique su entorno GFS2
2. Configurar la infraestructura de red redundante
3. Crear una red vinculada dedicada
4. Configurar un grupo agrupado
5. Aumente la memoria de su dominio de control
6. Configurar múltiples rutas de almacenamiento
7. Crea un GFS2 SR
¿Qué sigue?
Restricciones

¿Le ha resultado útil?