Pools en clúster GFS2
La agrupación en clúster GFS2 proporciona funciones adicionales que son necesarias para los pools de recursos que utilizan SR GFS2. Para obtener más información sobre GFS2, consulte Configurar almacenamiento.
Un clúster GFS2 es un pool de hasta 16 hosts XenServer® que están más estrechamente conectados y coordinados que los hosts en pools no agrupados. Los hosts del clúster GFS2 mantienen una comunicación constante entre sí en una red seleccionada. Todos los hosts del clúster GFS2 conocen el estado de cada host del clúster GFS2. Esta coordinación de hosts permite que el clúster GFS2 controle el acceso al contenido del SR GFS2.
Nota:
La función de agrupación en clúster GFS2 solo beneficia a los pools que contienen un SR GFS2. Si su pool no contiene un SR GFS2, no habilite la agrupación en clúster GFS2 en su pool.
Quórum
Cada host de un clúster GFS2 debe estar siempre en comunicación con la mayoría de los hosts del clúster GFS2 (incluido él mismo). Este estado se conoce como un host con quórum. Si un host no tiene quórum, ese host se auto-aísla.
El número de hosts que deben estar en comunicación para lograr el quórum inicialmente puede ser diferente al número de hosts que un clúster GFS2 requiere para mantener el quórum.
La siguiente tabla resume este comportamiento. El valor de n es el número total de hosts en el pool en clúster GFS2.
| Número de hosts necesarios para lograr el quórum | Número de hosts necesarios para mantener el quórum | |
|---|---|---|
| Número impar de hosts en el pool | (n+1)/2 | (n+1)/2 |
| Número par de hosts en el pool | (n/2)+1 | n/2 |
Para un pool en clúster GFS2, puede comprobar si el pool tiene quórum consultando el parámetro is-quorate del clúster GFS2:
xe cluster-list params=is-quorate uuid=<cluster_id>
Para ver cuántos hosts del clúster GFS2 están activos, ejecute el siguiente comando:
xe cluster-list params=live-hosts uuid=<cluster_id>
Para ver cuántos hosts activos se requieren para que el clúster GFS2 logre el quórum, ejecute el siguiente comando:
xe cluster-list params=quorum uuid=<cluster_id>
Cuando se crea el clúster GFS2, el número de hosts activos debe ser mayor o igual que este valor. Para mantener el quórum, el número de hosts requerido puede ser diferente al valor devuelto por este comando, dependiendo de si el clúster GFS2 contiene un número impar o par de hosts.
Pools con número impar de hosts
Para alcanzar el valor de quórum para un pool con número impar de hosts, se requiere la mitad de uno más que el número total de hosts en el clúster GFS2: (n+1)/2. Este es también el número mínimo de hosts que deben permanecer accesibles para que el pool mantenga el quórum.
Por ejemplo, en un pool en clúster GFS2 de 5 hosts, 3 hosts deben estar accesibles para que el clúster GFS2 se active y mantenga el quórum [(5+1)/2 = 3].
Siempre que sea posible, se recomienda utilizar un número impar de hosts en un pool en clúster GFS2, ya que esto garantiza que los hosts siempre puedan determinar si tienen un conjunto con quórum.
Pools con número par de hosts
Cuando un pool en clúster GFS2 con número par de hosts se inicia desde cero, (n/2)+1 hosts deben estar disponibles antes de que los hosts tengan quórum. Una vez que los hosts tienen quórum, el clúster GFS2 se activa.
Sin embargo, un pool activo con número par de hosts puede mantener el quórum si el número de hosts accesibles es al menos n/2. Como resultado, es posible que un clúster GFS2 en ejecución con un número par de hosts se divida exactamente por la mitad. El clúster GFS2 en ejecución decide qué mitad del clúster GFS2 se auto-cerca y qué mitad del clúster GFS2 tiene quórum. La mitad del clúster GFS2 que contiene el nodo con el ID más bajo que se consideró activo antes de la división del clúster GFS2 permanece activa y la otra mitad del clúster GFS2 se auto-cerca.
Por ejemplo, en un pool en clúster GFS2 de 4 hosts, 3 hosts deben estar accesibles para que el clúster GFS2 se active [4/2 + 1 = 3]. Una vez que el clúster GFS2 está activo, para mantener el quórum, solo 2 hosts deben estar accesibles [4/2 = 2] y ese conjunto de hosts debe incluir el host con el ID de nodo más bajo que se sepa que está activo.
Auto-cercado
Si un host detecta que no tiene quórum, se auto-aísla en unos segundos. Cuando un host se auto-aísla, se reinicia inmediatamente. Todas las máquinas virtuales que se ejecutan en el host se detienen inmediatamente porque el host realiza un apagado forzado. En un grupo en clúster GFS2 que utiliza alta disponibilidad, XenServer reinicia las máquinas virtuales según su configuración de reinicio en otros miembros del grupo. El host que se auto-aisló se reinicia e intenta unirse de nuevo al clúster GFS2.
Si el número de hosts activos en el clúster GFS2 es inferior al valor de quórum, todos los hosts restantes pierden el quórum.
En un escenario ideal, su grupo en clúster GFS2 siempre tiene más hosts activos de los necesarios para el quórum y XenServer nunca se aísla. Para hacer que este escenario sea más probable, considere las siguientes recomendaciones al configurar su grupo en clúster GFS2:
-
Asegúrese de tener una buena redundancia de hardware.
-
Utilice una red enlazada dedicada para la red del clúster GFS2. Asegúrese de que las NIC enlazadas estén en el mismo segmento L2. Para obtener más información, consulte Redes.
-
Configure la multiruta de almacenamiento entre el grupo y el SR GFS2. Para obtener más información, consulte Multiruta de almacenamiento.
Crear un grupo en clúster GFS2
Antes de empezar, asegúrese de que se cumplen los siguientes requisitos previos:
-
Todos los hosts de XenServer en el grupo en clúster GFS2 deben tener al menos 2 GiB de memoria de dominio de control.
Dependiendo de su entorno, sus hosts podrían requerir más memoria de dominio de control que esta. 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 a un grupo en clúster GFS2 con SR GFS2. 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.
-
Todos los hosts del clúster GFS2 deben usar direcciones IP estáticas para la red del clúster GFS2.
-
Recomendamos que utilice el clúster GFS2 solo en grupos que contengan al menos tres hosts, ya que los grupos de dos hosts son sensibles a que todo el grupo se auto-aísle.
-
Los grupos en clúster GFS2 solo admiten hasta 16 hosts por grupo.
- Si tiene un firewall entre los hosts de su grupo, asegúrese de que los hosts puedan comunicarse en la red del clúster GFS2 utilizando los siguientes puertos:
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.
-
Si va a agregar la agrupación en clústeres GFS2 a 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 GFS2.
- Recomendamos encarecidamente que utilice una red enlazada para su grupo en clústeres GFS2 que no se utilice para ningún otro tráfico.
Si lo prefiere, puede configurar la agrupación en clústeres GFS2 en su grupo mediante XenCenter. Para obtener más información, consulte la documentación del producto XenCenter.
Para usar la CLI de xe para crear un grupo en clústeres GFS2:
-
Cree una red enlazada para usarla como red de clúster GFS2.
Nota:
Recomendamos encarecidamente que utilice una red enlazada dedicada para su grupo en clústeres GFS2. No utilice esta red para ningún otro tráfico.
En el host de XenServer que desea que sea el coordinador del grupo, complete los siguientes pasos:
-
Abra una consola en el host de XenServer.
-
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.
-
Busque los UUID de los PIF que se usarán en el enlace mediante el siguiente comando:
xe pif-list <!--NeedCopy--> -
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), utilice el comando
bond-createpara crear el enlace. Utilizando comas para separar los parámetros, especifique el UUID de la red recién creada y los UUID de los PIF que se van a enlazar: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 esté enlazando dos NIC y cuatro UUID cuando esté enlazando cuatro NIC. El UUID del enlace se devuelve después de ejecutar el comando.
-
Para configurar el enlace en modo activo-pasivo o LACP, utilice la misma sintaxis, añada el parámetro opcional
modey especifiquelacpoactive-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 haber creado la red enlazada en el coordinador del pool, cuando una otros hosts de XenServer al pool, 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.
-
-
Cree un pool de recursos de al menos tres hosts de XenServer.
Repita los siguientes pasos en cada host de XenServer que sea miembro (no maestro) del pool:
- Abra una consola en el host de XenServer.
-
Una el host de XenServer al pool en el coordinador del pool utilizando el siguiente comando:
xe pool-join master-address=master_address master-username=administrators_username master-password=password <!--NeedCopy-->El valor del parámetro
master-addressdebe establecerse en el nombre de dominio completo del host de XenServer que es el coordinador del pool. Elpassworddebe ser la contraseña de administrador establecida cuando se instaló el coordinador del pool.
Para obtener más información, consulte Hosts y pools de recursos.
-
Para cada PIF que pertenezca a esta red, establezca
disallow-unplug=true.-
Busque los UUID de los PIF que pertenecen a la red utilizando el siguiente comando:
xe pif-list <!--NeedCopy--> -
Ejecute el siguiente comando en un host de XenServer de su pool de recursos:
xe pif-param-set disallow-unplug=true uuid=<pif_uuid> <!--NeedCopy-->
-
-
Habilite la agrupación en clústeres GFS2 en su pool. Ejecute el siguiente comando en un host de XenServer de su pool de recursos:
xe cluster-pool-create network-uuid=<network_uuid> <!--NeedCopy-->Proporcione el UUID de la red enlazada que creó en un paso anterior.
Deshabilitar el clúster GFS2
Puede deshabilitar el clúster GFS2. Después de deshabilitar el clúster GFS2, el pool sigue existiendo, pero ya no es un clúster GFS2 y ya no puede usar SR GFS2.
Para deshabilitar el clúster GFS2, ejecute el siguiente comando:
xe cluster-pool-destroy cluster-uuid=<uuid>
Administre su pool en clúster GFS2
Al administrar su pool en clúster GFS2, las siguientes prácticas pueden disminuir el riesgo de que el pool pierda el quórum.
Agregar o quitar un host en un pool en clúster GFS2
Al agregar o quitar un host en un pool en clúster GFS2, asegúrese de que todos los hosts del clúster GFS2 estén en línea.
Puede agregar o quitar un host en un pool en clúster GFS2 mediante XenCenter. Para obtener más información, consulte Agregar un servidor a un pool y Quitar un servidor de un pool.
También puede agregar o quitar un host en un pool en clúster GFS2 mediante la CLI de xe. Para obtener más información, consulte Agregar un host a un pool mediante la CLI de xe y Quitar hosts de XenServer de un pool de recursos.
Asegúrese de que los hosts se apaguen correctamente
Cuando un host se apaga correctamente, se elimina temporalmente del clúster GFS2 hasta que se vuelve a iniciar. Mientras el host está apagado, no cuenta para el quórum del clúster GFS2. La ausencia del host no hace que otros hosts pierdan el quórum. Para obtener más información, consulte Apagar un host de XenServer.
Sin embargo, si un host se apaga de forma forzada o inesperada, no se elimina del clúster GFS2 antes de que se desconecte. Este host sí cuenta para el valor de quórum del clúster GFS2. Su apagado puede hacer que otros hosts pierdan el quórum.
Si es necesario apagar un host de forma forzada, primero compruebe cuántos hosts activos hay en el clúster GFS2. Puede hacerlo con el comando corosync-quorumtool. En la salida del comando, el número de hosts activos es el valor de Total votes: y el número de hosts activos necesarios para mantener el quórum es el valor de Quorum:.
-
Si el número de hosts activos es el mismo que el número de hosts necesarios para mantener el quórum, no apague el host de forma forzada. Si lo hace, todo el clúster GFS2 se aislará.
En su lugar, intente recuperar otros hosts y aumentar el número de hosts activos antes de apagar el host a la fuerza.
-
Si el número de hosts activos está cerca del número de hosts necesarios para mantener el quórum, puede apagar el host a la fuerza. Sin embargo, esto hace que el clúster GFS2 sea más vulnerable a un cercado completo si otros hosts del pool tienen problemas.
Intente siempre reiniciar el host apagado lo antes posible para aumentar la resiliencia de su clúster GFS2.
Usar el modo de mantenimiento
Antes de realizar una acción en un host que pueda hacer que ese host pierda el quórum, ponga el host en modo de mantenimiento. Cuando un host está en modo de mantenimiento, las máquinas virtuales en ejecución se migran de él a otro host del pool. Además, si ese host era el coordinador del pool, ese rol se transfiere a un host diferente del pool. Si sus acciones hacen que un host en modo de mantenimiento se auto-cercado, no perderá ninguna máquina virtual ni su conexión a XenCenter® con el pool.
Los hosts en modo de mantenimiento siguen contando para el valor de quórum del clúster GFS2.
Solo puede cambiar la dirección IP de un host que forma parte de un pool en clúster GFS2 cuando ese host está en modo de mantenimiento. Cambiar la dirección IP de un host hace que el host abandone el clúster GFS2. Cuando la dirección IP se ha cambiado correctamente, el host se reincorpora al clúster GFS2. Después de que el host se reincorpore al clúster GFS2, puede sacarlo del modo de mantenimiento.
Recuperar hosts que se han auto-cercado o están sin conexión
Es importante recuperar los hosts que se han auto-cercado. Mientras estos miembros del clúster GFS2 están sin conexión, cuentan para el número de quórum del clúster GFS2 y disminuyen el número de miembros del clúster GFS2 que son contactables. Esta situación aumenta el riesgo de que un fallo posterior del host haga que el clúster GFS2 pierda el quórum y se apague por completo.
Tener hosts sin conexión en su clúster GFS2 también le impide realizar ciertas acciones. En un pool en clúster GFS2, cada miembro del pool debe aceptar cada cambio de membresía del pool antes de que el cambio pueda ser exitoso. Si un miembro del clúster GFS2 no es contactable, XenServer impide las operaciones que cambian la membresía del clúster GFS2 (como agregar o eliminar un host).
Marcar hosts como irrecuperables
Si uno o más hosts sin conexión no se pueden recuperar, puede indicar al pool en clúster GFS2 que los olvide. Estos hosts se eliminan permanentemente del pool. Una vez que los hosts se eliminan del pool en clúster GFS2, ya no cuentan para el valor de quórum.
Para marcar un host como irrecuperable, utilice el siguiente comando:
xe host-forget uuid=<host_uuid>
Recuperar un host olvidado
Después de que se le indica a un pool en clúster GFS2 que olvide un host, el host no se puede volver a agregar al pool.
Para volver a unirse al grupo en clúster GFS2, debe reinstalar XenServer en el host para que aparezca como un nuevo host en el grupo. A continuación, puede unir el host al grupo en clúster GFS2 de la forma habitual.
Solucionar problemas de su grupo en clúster GFS2
Si encuentra problemas con su grupo en clúster GFS2, consulte Solucionar problemas de grupos en clúster GFS2.
Restricciones
- Los grupos en clúster GFS2 solo admiten hasta 16 hosts por grupo.
- Para habilitar HA en su grupo en clúster GFS2, el SR de latido debe ser un SR GFS2.
- Para el tráfico de clúster GFS2, 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 de clúster GFS2 mediante XenCenter requiere que el clúster GFS2 y todos los SR GFS2 se deshabiliten temporalmente.
- No cambie el enlace de su red de clúster GFS2 mientras el clúster GFS2 esté activo y tenga máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster GFS2 se reinicien de forma forzada (cercado).
- Si tiene un conflicto de direcciones IP (varios hosts con la misma dirección IP) en su red de clúster GFS2 que involucre al menos un host con el clúster GFS2 habilitado, el clúster GFS2 no se forma correctamente y los hosts no pueden cercarse cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.