XenServer

Almacenamiento en bloque GFS2 compartido de aprovisionamiento fino

January 31, 2025

Contribución de:

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, XenServer requiere que utilice un grupo en clúster con su SR de GFS2. También se recomienda diseñar el entorno y configurar las funciones de XenServer para proporcionar la mayor resistencia y redundancia posible.

Antes de configurar el grupo de XenServer para que funcione con SR de GFS2, revise los siguientes requisitos y recomendaciones para un entorno de 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 de XenServer 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 XenServer.
Abra una consola en el host de XenServer que desee que actúe como coordinador del 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 bond-create para crear el enlace. 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 activo-pasivo o enlace 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
 
```

Después de crear la red enlazada en el coordinador del grupo, cuando se unen 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 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 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 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 GFS2 compartido, el grupo de recursos de XenServer debe ser un grupo en clúster. Habilite la agrupación en clústeres en su grupo antes de crear un SR GFS2.

Un grupo agrupado en clúster es un grupo de hosts de XenServer que están más 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 hosts de XenServer del grupo en clúster 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 hosts de XenServer.

Repita los siguientes pasos en cada host de XenServer que se una y que no sea el coordinador del grupo:
1. Abra una consola en el host de XenServer.
2. Únase 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>

```
  El valor del parámetro master-address debe establecerse en el nombre de dominio completo del host XenServer que es el coordinador del grupo. El contraseña 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.
Para cada PIF que pertenece 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 host de XenServer del 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 host de XenServer del 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 host de XenServer.
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 del parámetro multipathing `` en verdadero utilizando 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 el SR de GFS2 compartido en un iSCSI o un LUN de HBA que sea visible para todos los hosts de XenServer del 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 XenServer 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, XenServer 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 a utilizar para estos parámetros utilizando 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 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 ubicar el SR usando 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 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 a utilizar para el parámetro SCSIid utilizando 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 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.
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 XenServer 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 la SAN para asegurarse de que siempre haya espacio para que XenServer 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?