Almacenamiento en bloque GFS2 compartido de aprovisionamiento ligero

El aprovisionamiento ligero aprovecha mejor el almacenamiento disponible al asignar espacio de almacenamiento en disco a los VDI a medida que se escriben datos en el disco virtual, en lugar de asignar el tamaño virtual completo del VDI por adelantado. El aprovisionamiento ligero le permite reducir significativamente la cantidad de espacio necesario en una matriz de almacenamiento compartido y, con ello, su Costo Total de Propiedad (TCO).

Advertencia:

GFS2 tiene una serie de limitaciones y complejidades que deben considerarse cuidadosamente antes de continuar. En muchos casos, una estrategia de almacenamiento alternativa será más adecuada.

Las limitaciones de GFS2 incluyen:

• No está completamente equipado (sin soporte para DR, sin soporte para migración de almacenamiento, tamaños de pool limitados a 16)
• Limitaciones de rendimiento, lo que lo hace inadecuado para cargas de trabajo grandes e intensivas en E/S
• Requiere servicios de clúster, lo que puede generar problemas de estabilidad
• Más complejo de entender, lo que resulta en un aumento de las configuraciones erróneas y los errores

Comprendiendo estas limitaciones y complejidades, solo se recomienda usar GFS2 cuando no existan alternativas para satisfacer los requisitos. Los escenarios en los que GFS2 puede ser apropiado son:

• Se requiere aprovisionamiento ligero y su SAN no lo proporciona. La recomendación es usar almacenamiento LVM con una SAN que proporcione los requisitos de aprovisionamiento ligero. Cuando esto no sea posible, se puede considerar GFS2.
• Soporte para discos de >2 TiB. GFS2 admitirá discos de hasta 16 TB. Cuando se requieran discos de >2 TiB, se puede considerar GFS2. Los clientes deben realizar pruebas para asegurarse de que el entorno pueda cumplir con los requisitos de carga y rendimiento.

Si su SAN admite aprovisionamiento ligero, le recomendamos que utilice esto, con LVM, en lugar de GFS2 a menos que necesite discos de VM de más de 2 TiB. Para los casos en que se requieran discos de VM de más de 2 TiB, considere usar varios discos en LVM para lograrlo.

El tipo GFS2 compartido representa los discos como un sistema de archivos creado en una LUN iSCSI o HBA. Los VDI almacenados en un SR GFS2 se almacenan en formato de imagen QCOW2.

Este artículo describe cómo configurar su entorno GFS2 utilizando la CLI xe. Para configurar un entorno GFS2 utilizando XenCenter, consulte la documentación del producto XenCenter.

1. Planifique su entorno GFS2

Para proporcionar los beneficios del aprovisionamiento ligero en el almacenamiento de bloques compartido sin riesgo de pérdida de datos, su grupo debe ofrecer un buen nivel de fiabilidad y conectividad. Es crucial que los hosts del grupo de recursos que utiliza GFS2 puedan comunicarse de forma fiable entre sí. Para garantizar esto, XenServer® requiere que utilice un grupo en clúster con su SR GFS2. También recomendamos que diseñe su entorno y configure las funciones de XenServer para proporcionar la mayor resiliencia y redundancia posibles.

Antes de configurar su grupo de XenServer para trabajar con SR GFS2, revise los siguientes requisitos y recomendaciones para un entorno GFS2 ideal:

• Recomendado: Configurar infraestructura de red redundante.

• Recomendado: Crear una red enlazada dedicada

• Obligatorio: (#4-set-up-a-clustered-pool)

• Opcional Aumentar la memoria de su dominio de control

• Recomendado: Configurar la multiruta de almacenamiento

• Obligatorio: (#7-create-a-gfs2-sr)

Un grupo en clúster con SR GFS2 tiene algunas diferencias de comportamiento con respecto a otros tipos de grupos y SR. Para obtener más información, consulte (#constraints).

2. Configure una infraestructura de red redundante

Una red enlazada une dos o más NIC para crear un único canal para el tráfico de red. Le recomendamos que utilice una red enlazada para el tráfico de su grupo en clúster. Sin embargo, antes de configurar su red enlazada, asegúrese de que la configuración de su hardware de red promueva la redundancia en la red enlazada. Considere implementar tantas de estas recomendaciones como sea factible para su organización y entorno.

Las siguientes prácticas recomendadas añaden resiliencia contra fallos de software, hardware o energía que pueden afectar a sus conmutadores de red.

• Asegúrese de tener conmutadores de red físicos separados disponibles para su uso en la red enlazada, no solo puertos en el mismo conmutador.
• Asegúrese de que los conmutadores separados 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 del suministro eléctrico o incluso en suministros proporcionados por diferentes empresas de servicios públicos.
• Considere el uso de unidades de suministro de energía ininterrumpida (SAI) para asegurar que los conmutadores de red y los servidores puedan seguir funcionando o realizar un apagado ordenado en caso de un fallo de alimentación.

3. Crear una red enlazada dedicada

Es importante asegurar que los hosts en un grupo en clúster puedan comunicarse de forma fiable entre sí. La creación de una red enlazada para este tráfico de grupo aumenta la resiliencia de su grupo en clúster.

Nota:

La red del clúster no puede estar en una VLAN no de gestión.

Una red enlazada crea un enlace entre dos o más NIC para formar un único canal de alto rendimiento que su grupo en clúster puede usar para el tráfico de latido del clúster. Recomendamos encarecidamente que esta red enlazada no se utilice para ningún otro tráfico. Cree una red separada para que el grupo la use para el tráfico de gestión.

Advertencia:

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

Si su clúster se está autoaislando o enfrenta un problema en esta configuración no recomendada, el Soporte de XenServer podría pedirle que reproduzca el mismo problema en una configuración recomendada durante el curso de la investigación.

Para crear una red enlazada para usar como red de clúster GFS2:

1. Si tiene un cortafuegos entre los hosts de su grupo, asegúrese de que los hosts puedan comunicarse en la red del clúster usando los siguientes puertos:

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

   Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.

2. Abra una consola en el host de XenServer que desea que actúe como coordinador del grupo.

3. Cree una red para usar con la NIC enlazada mediante el siguiente comando:

   xe network-create name-label=bond0
   <!--NeedCopy-->
   

   Se devuelve el UUID de la nueva red.

4. Busque los UUID de las PIF que se usarán 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 de enlace LACP. Según el modo de enlace que desee usar, complete una de las siguientes acciones:

   • Para configurar el enlace en modo activo-activo (predeterminado), use el comando bond-create para crear el enlace. Usando comas para separar los parámetros, especifique el UUID de la red recién creada y los UUID de las PIF que se enlazarán:

      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 enlace dos NIC y cuatro UUID cuando enlace cuatro NIC. El UUID del enlace se devuelve después de ejecutar el comando.

   • Para configurar el enlace en modo activo-pasivo o LACP, use la misma sintaxis, agregue el parámetro opcional mode 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, cuando une otros hosts de XenServer al grupo, la información de la red y del enlace se replica automáticamente en el servidor que se une.

Para obtener más información, consulte Redes.

Nota:

• Cambiar la dirección IP de la red del clúster mediante XenCenter® requiere que el clúster y GFS2 se deshabiliten temporalmente.
• No cambie el enlace de la red de su clúster mientras el clúster esté activo y tenga máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien de forma forzada (cercado).
• Si tiene un conflicto de direcciones IP (varios hosts con la misma dirección IP) en la red de su clúster que involucre al menos un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercarse cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.

El valor de tiempo de espera del clúster de su grupo depende de cuántos hosts haya en su clúster. Ejecute el siguiente comando para encontrar el valor token-timeout 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 del enlace de red sea mayor que el valor de tiempo de espera, es posible que su infraestructura y configuración de red no sean lo suficientemente fiables como para admitir un pool en clúster.

4. Configurar un pool en clúster

Para usar el almacenamiento GFS2 compartido, el pool de recursos de XenServer debe ser un pool en clúster. Habilite la agrupación en clúster en su pool antes de crear un SR GFS2.

Un pool en clúster es un pool de hosts XenServer que están más estrechamente conectados y coordinados que los hosts en pools 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 host del clúster. Esta coordinación de hosts permite al clúster controlar el acceso a los contenidos del SR GFS2. Para garantizar que el pool en clúster 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 un host con quórum. Si un host no tiene quórum, se reinicia de forma forzada y se elimina del clúster. Esta acción se denomina ‘fencing’ (cercado).

Para obtener más información, consulte Pools en clúster.

Antes de empezar a configurar su pool en clúster, asegúrese de que se cumplen los siguientes requisitos previos:

• Planifique crear un pool de entre 3 y 16 hosts.

  Siempre que sea posible, utilice un número impar de hosts en un pool en clúster, ya que esto garantiza que los hosts siempre puedan determinar si tienen quórum. Recomendamos que utilice la agrupación en clúster solo en pools que contengan al menos tres hosts, ya que los pools de dos hosts son sensibles al auto-cercado de todo el pool.

  Los pools en clúster solo admiten hasta 16 hosts por pool.

• Todos los hosts de XenServer en el pool en clúster 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 pool 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úster.

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

1. Cree un pool de recursos de al menos tres hosts XenServer.

   Repita los siguientes pasos en cada host XenServer que se una y que no sea el coordinador del pool:

   1. Abra una consola en el host de XenServer.

   2. Una 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 parámetro master-address debe establecerse en el nombre de dominio completo del host de XenServer que es el coordinador del grupo. La password debe ser la contraseña de administrador establecida cuando se instaló el coordinador del grupo.

   Para obtener más información, consulte Hosts y grupos de recursos.

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

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

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

5. Aumente la memoria de su dominio de control

Si tiene memoria de dominio de control insuficiente en sus hosts, su grupo puede experimentar inestabilidad de red. La inestabilidad de red puede causar problemas en un grupo en clúster con SR de GFS2.

Es importante asegurarse de que su 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. Configure la multirruta de almacenamiento

Asegúrese de que la multirruta de almacenamiento esté configurada entre su grupo en clúster y su SR de GFS2.

La multirruta dirige el tráfico de almacenamiento a un dispositivo de almacenamiento a través de múltiples rutas para redundancia. Todas las rutas pueden tener tráfico activo durante el funcionamiento normal, lo que resulta en un mayor rendimiento.

Antes de habilitar el multipathing, verificar que las siguientes afirmaciones son verdaderas:

• Su conmutador Ethernet o de fibra está configurado para que haya varios destinos disponibles en su servidor de almacenamiento.

  Por ejemplo, un back-end de almacenamiento iSCSI consultado para sendtargets en un portal dado 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 el multipathing iSCSI para matrices que solo exponen un único destino. Para obtener más información, consulte Multipathing 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 con multipathing.

  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 desea cuatro rutas a su almacenamiento, debe tener cuatro NIC, cada una con una dirección IP configurada.

• Solo para iSCSI, cada destino e iniciador iSCSI tiene un IQN único.

• Solo para iSCSI, los puertos de destino iSCSI están funcionando en modo portal.

• Solo para HBA, varios HBA están conectados a la estructura del conmutador.

• Si es posible, utilice varios conmutadores redundantes.

Para habilitar el multipathing mediante la CLI de xe

Recomendamos que habilite el multipathing para todos los hosts de su grupo antes de crear el SR. Si crea el SR antes de habilitar el multipathing, debe poner sus hosts en modo de mantenimiento para habilitar el multipathing.

1. Abra una consola en el host de XenServer.

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 modo de ruta única y tienen varias rutas:

   • Migre o suspenda cualquier invitado en ejecución con discos virtuales en los SR afectados.

   • Vuelva a conectar el PBD de cualquier SR afectado para reconectarlos mediante el uso de 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. Todo el cableado y, en el caso de iSCSI, las configuraciones de subred deben coincidir con las NIC correspondientes en cada host.

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

7. Crear un SR GFS2

Cree su SR GFS2 compartido en una LUN iSCSI o HBA que sea visible para todos los hosts de XenServer en su grupo de recursos. No recomendamos usar una LUN de aprovisionamiento ligero con GFS2. Sin embargo, si elige esta configuración, debe asegurarse de que la LUN siempre tenga suficiente espacio para permitir que XenServer escriba en ella.

Puede agregar hasta 62 SR GFS2 a un grupo en clúster.

Si ha utilizado previamente su dispositivo de almacenamiento basado en bloques para el aprovisionamiento grueso con LVM, XenServer lo detecta. XenCenter le ofrece la oportunidad de usar la partición LVM existente o de formatear el disco y configurar una partición GFS2.

Crear un SR GFS2 compartido sobre iSCSI

Puede usar la CLI de xe para crear un SR GFS2 sobre iSCSI.

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

Puede encontrar los valores a utilizar para estos parámetros usando 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. Empiece ejecutando 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 posibles valores en cada paso.

2. Repita el comando, añadiendo nuevos parámetros cada vez.

3. Cuando la salida del comando comience con Found the following complete configurations that can be used to create SRs:, puede localizar el SR utilizando el comando xe sr-create y los parámetros device-config 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 una LUN específica 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>
<!--NeedCopy-->

Si el destino iSCSI no es accesible mientras los sistemas de archivos GFS2 están montados, algunos hosts del grupo en clúster podrían reiniciarse de forma forzada (fence).

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

Crear un SR GFS2 compartido sobre HBA

Puede usar la CLI de xe para crear un SR GFS2 sobre HBA.

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

Puede encontrar los valores que se usarán 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>
<!--NeedCopy-->

1. Empiece ejecutando el siguiente comando:

   xe sr-probe-ext type=gfs2 device-config:provider=hba
   <!--NeedCopy-->
   

   La salida del comando le pide que proporcione parámetros adicionales y le ofrece una lista de posibles valores en cada paso.

2. Repita el comando, añadiendo nuevos parámetros cada vez.

3. Cuando la salida del comando comience 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 parámetros device-config que especificó.

   Ejemplo de salida:

   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 una LUN específica de un destino HBA, 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=hba device-config:SCSIid=<device_scsi_id>
<!--NeedCopy-->

Para obtener más información sobre cómo trabajar con SR HBA, consulte Almacenamiento HBA de hardware.

¿Qué sigue?

Ahora que tiene su entorno GFS2 configurado, es importante que mantenga la estabilidad de su grupo en clúster asegurándose de que tenga quórum. Para obtener más información, consulte Administrar su grupo en clúster.

Si encuentra problemas con su entorno GFS2, consulte Solucionar problemas de grupos en clúster.

Puede administrar su SR GFS2 de la misma manera 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.

Restricciones

El almacenamiento GFS2 compartido tiene actualmente las siguientes restricciones:

• Intellicache™ no es compatible con las máquinas virtuales que utilizan un SR GFS2.

• Al igual que con cualquier SR de aprovisionamiento ligero, si el uso del SR GFS2 aumenta al 100%, las escrituras posteriores de las máquinas virtuales fallan. Estas escrituras fallidas pueden provocar fallos dentro de la máquina virtual, posible corrupción de datos o ambas cosas.

• XenCenter muestra una alerta cuando el uso de su SR aumenta al 80%. Asegúrese de supervisar su SR GFS2 para detectar esta alerta y tome las medidas adecuadas si la ve. En un SR GFS2, un uso elevado provoca una degradación del rendimiento. Le recomendamos que mantenga el uso de su 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 cuyos VDI se encuentran 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, use HBA).

• Trim/unmap no es compatible con los SR GFS2.

• CHAP no es compatible con los SR 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 ligero 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 recomendamos usar la deduplicación SAN con SR GFS2. Sin embargo, si elige esta configuración, debe usar una supervisión externa adecuada de la utilización de su SAN para asegurarse de que siempre haya espacio para que XenServer escriba en ella.

• Su sistema de archivos GFS2 no puede ser mayor de 100 TiB.

• No puede tener más de 62 SR de GFS2 en su pool.

• Los pools en clúster solo admiten hasta 16 hosts por pool.

• Para habilitar HA en su pool en clúster, el SR de latido debe ser un SR de GFS2.

• Para el tráfico del clúster, 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.

• Cambiar la dirección IP de la red del clúster mediante XenCenter requiere que el clúster y GFS2 se deshabiliten temporalmente.

• No cambie el enlace de su red de clúster mientras el clúster esté activo y tenga máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien de forma forzada (fence).

• Si tiene un conflicto de direcciones IP (varios hosts con la misma dirección IP) en su red de clúster que involucre al menos un host con la agrupación en clúster habilitada, el clúster no se forma correctamente y los hosts no pueden realizar el fencing cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.