Almacenamiento en bloques GFS2 compartido con aprovisionamiento fino

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:

• Quieres aumentar la eficiencia del espacio. Las imágenes están escasamente asignadas y no densamente asignadas.
• Desea reducir la cantidad de operaciones de E/S por segundo en su cabina de almacenamiento. GFS2 SR es el primer tipo de SR que admite el almacenamiento en caché de lectura de almacenamiento en almacenamiento en bloque compartido.
• Se usa una imagen base común para varias máquinas virtuales. Por lo general, las imágenes de las VM individuales utilizarán incluso menos espacio.
• Usas instantáneas. Cada instantánea es una imagen y ahora cada imagen es escasa.
• Desea crear VDI con un tamaño superior a 2 TiB. La GFS2 SR admite VDI de hasta 16 TiB de tamaño.
• Su almacenamiento no admite NFS ni SMB3 y solo admite el almacenamiento en bloques. Si su almacenamiento admite NFS o SMB3, le recomendamos que utilice estos tipos de SR en lugar de GFS2.
• Su almacenamiento no admite el aprovisionamiento ligero de LUNs. Si su almacenamiento utiliza LUNs de aprovisionamiento ligero, puede tener problemas y quedarse sin espacio al combinarlo con GFS2. La combinación de GFS2 con un LUN de aprovisionamiento ligero no ofrece muchas ventajas adicionales y no se recomienda.

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.

1. Planifique su entorno GFS2

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, 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 resiliencia y redundancia posible.

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

• Recomendado: configure una infraestructura de red redundante.

• Recomendado: Cree una red enlazada dedicada

• Obligatorio: configurar un grupo agrupado

• Opcional: aumentar la memoria de su dominio de control

• 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.

2. Configurar una infraestructura de red redundante

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 añaden resiliencia frente a fallos de software, hardware o alimentación 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 enlazada, no solo puertos en el mismo conmutador.
• Asegúrese de que los conmutadores independientes obtengan energía de unidades de distribución de energía (PDU) diferentes e independientes.
• Si es posible, en su centro de datos, coloque las PDU en diferentes fases de la alimentación o incluso en las fuentes proporcionadas por diferentes empresas de servicios públicos.
• Considere la posibilidad de utilizar unidades de alimentación ininterrumpida para garantizar que los conmutadores y servidores de la red puedan seguir funcionando o realizar un apagado ordenado en caso de un corte de energía.

3. Cree una red vinculada dedicada

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, es posible que el servicio de soporte le pida 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:

1. 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:

   • TCP: 8892, 8896, 21064
   • UDP: 5404, 5405

   Para obtener más información, consulte Puertos de comunicación que utiliza Citrix Hypervisor.

2. Abra una consola en el servidor Citrix Hypervisor que desee que actúe como maestro del grupo.

3. 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.

4. Encuentre los UUID de los PIF que se van a usar en el enlace mediante el siguiente comando:

   xe pif-list
   <!--NeedCopy-->
   

5. 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 maestro del grupo, cuando une otros servidores 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 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:

• Extrayendo físicamente 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 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.

4. Configurar un grupo agrupado

Para usar el almacenamiento GFS2 compartido, el grupo de recursos de Citrix Hypervisor debe ser un grupo en clúster. Habilite la agrupación en clústeres en su grupo antes de crear una 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 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.

• Todos los servidores de Citrix Hypervisor del grupo agrupado en clústeres deben tener al menos 2 GiB de memoria de dominio de control.
• Todos los hosts del clúster deben usar direcciones IP estáticas para la red del clúster.
• Si está agrupando un grupo existente, asegúrese de que la alta disponibilidad esté inhabilitada. Puede volver a habilitar la alta disponibilidad después de habilitar la agrupación en clústeres.

Para usar la CLI xe para crear un grupo en clúster:

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

   Repita los siguientes pasos cada vez que se una a un servidor Citrix Hypervisor que no sea el maestro del grupo:

   1. Abra una consola en el servidor de Citrix Hypervisor.

   2. Conecte el servidor de Citrix Hypervisor al grupo en el maestro de grupos mediante el siguiente comando:

      xe pool-join master-address=<master_address> /
          master-username=<administrators_username> /
          master-password=<password>
      <!--NeedCopy-->
      

      El valor del parámetro master-address debe establecerse en el nombre de dominio completo del servidor de Citrix Hypervisor que es el maestro de grupo. password 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.

2. Para cada PIF que pertenezca a esta red, defina disallow-unplug=true.

   1. Busque los UUID de los PIF que pertenecen a la red mediante el siguiente comando:

      xe pif-list
      <!--NeedCopy-->
      

   2. Ejecute el siguiente comando en un servidor de Citrix Hypervisor de su grupo de recursos:

      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      <!--NeedCopy-->
      

3. Habilite la agrupación en clústeres en su grupo. Ejecute el siguiente comando en un servidor de Citrix Hypervisor 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.

5. Aumentar la memoria de su dominio de control

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.

6. Configurar múltiples rutas de almacenamiento

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.

Para habilitar las rutas múltiples mediante la CLI xe

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.

1. Abra una consola en el servidor de Citrix Hypervisor.

2. 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.

3. Establezca el valor del parámetro multipathing en true mediante el siguiente comando:

   xe host-param-set uuid=<host uuid> multipathing=true
   <!--NeedCopy-->
   

4. 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-->
     

5. 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.

7. Crear un GFS2 SR

Cree su GFS2 SR compartido en un LUN iSCSI o HBA que esté visible para todos los servidores Citrix Hypervisor de su grupo 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 Citrix Hypervisor 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, Citrix Hypervisor 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.

Crear una SR GFS2 compartida a través de iSCSI

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:

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-->

1. 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.

2. Repita el comando y agregue nuevos parámetros cada vez.

3. 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.

Crear una GFS2 compartida 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 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:

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>

1. 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.

2. Repita el comando y agregue nuevos parámetros cada vez.

3. 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.

¿Qué sigue?

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.

Limitaciones

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 FCoE de software no es compatible con los SR de GFS2 (para FCoE completamente descargados, utilice el HBA).

• Recortar/desasignar no se admite en los SR de GFS2.

• Los SR de GFS2 no admiten CHAP.

• Las máquinas virtuales de clonación completa de MCS no son compatibles con los RA de GFS2.

• No se admite el uso de varios RA 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 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 Citrix Hypervisor escriba en él.

• No recomendamos usar la desduplicación de SAN con los SR de GFS2. Sin embargo, si elige esta configuración, debe utilizar una supervisión externa adecuada de la utilización de la SAN para asegurarse de que siempre haya espacio en el que Citrix Hypervisor pueda escribir.

• Su sistema de archivos GFS2 no puede superar los 100 TiB.

• 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.