Descripción del cuórum de clúster y grupo

Los clústeres de conmutación por error de Windows Server proporcionan alta disponibilidad para cargas de trabajo que se ejecutan en clústeres de Azure Local y Windows Server. Estos recursos se consideran de alta disponibilidad si los nodos que hospedan recursos están activos; Sin embargo, el clúster suele requerir que se ejecuten más de la mitad de los nodos, lo que se conoce como cuórum.

Cuórum está diseñado para evitar escenarios de cerebro dividido que pueden ocurrir cuando hay una partición en la red y los subconjuntos de nodos no se pueden comunicar entre sí. Esto puede provocar que ambos subconjuntos de nodos intenten poseer la carga de trabajo y escribir en el mismo disco, lo que puede provocar numerosos problemas. Sin embargo, esto se evita con el concepto de cuórum de clústeres de conmutación por error, que obliga a que solo uno de estos grupos de nodos continúe ejecutándose, por lo que solo uno de estos grupos permanece en línea.

El cuórum determina el número de errores que puede aguantar el clúster mientras permanece en línea. Quorum está diseñado para controlar el escenario cuando hay un problema con la comunicación entre subconjuntos de nodos de clúster, de modo que varios servidores no intenten hospedar simultáneamente un grupo de recursos y escribir en el mismo disco al mismo tiempo. Al tener este concepto de cuórum, el clúster obliga a que el servicio de clúster se detenga en uno de los subconjuntos de nodos para asegurarse de que solo haya un verdadero propietario de un grupo de recursos determinado. Los nodos que se han detenido pueden volver a comunicarse con el grupo principal de nodos y se volverán a unir automáticamente al clúster e iniciarán su servicio de clúster.

En Azure Local y Windows Server 2019, hay dos componentes del sistema que tienen sus propios mecanismos de cuórum:

• Cuórum de clúster: funciona en el nivel de clúster (es decir, puede perder nodos y mantener el clúster activo).
• Cuórum de grupo: funciona en el nivel de grupo (es decir, puede perder nodos y unidades y hacer que el grupo permanezca al día). Los grupos de almacenamiento se diseñaron para usarse en escenarios agrupados y no agrupados, por lo que tienen un mecanismo de cuórum diferente.

Visión general del quórum de clúster

En la tabla siguiente se proporciona información general sobre los resultados del cuórum de clúster por escenario:

Recomendaciones para el cuórum de clúster

• Si tiene dos nodos, se requiere un testigo.
• Si tiene tres o cuatro nodos, se recomienda encarecidamente el testigo.
• Si tiene cinco nodos o más, no se necesita un testigo y no proporciona resistencia adicional.
• Si tiene acceso a Internet, use un testigo en la nube.
• Si se encuentra en un entorno de TI con otras máquinas y recursos compartidos de archivos, use un testigo de recurso compartido de archivos.

Funcionamiento del cuórum de clúster

Cuando se produce un error en los nodos o cuando algún subconjunto de nodos pierde el contacto con otro subconjunto, los nodos supervivientes deben comprobar que constituyen la mayoría del clúster para permanecer en línea. Si no pueden comprobarlo, se desconectarán.

Pero el concepto de mayoría solo funciona limpiamente cuando el número total de nodos del clúster es impar (por ejemplo, tres nodos en un clúster de cinco nodos). Por lo tanto, ¿qué ocurre con los clústeres con un número par de nodos (por ejemplo, un clúster de cuatro nodos)?

Hay dos maneras en que el clúster puede hacer que el número total de votos sea un número impar:

1. En primer lugar, puede subir uno agregando un testigo con un voto adicional. Esto requiere la configuración del usuario.
2. O bien, puede bajar uno al cero el voto de un nodo desafortunado (se produce automáticamente según sea necesario).

Siempre que los nodos supervivientes comprueben correctamente que son la mayoría, la definición de la mayoría se actualiza para que esté entre solo los supervivientes. Esto permite que el clúster pierda un nodo, luego otro, otro, etc. Este concepto de la adaptación del número total de votos después de errores sucesivos se conoce como cuórum dinámico.

Testigo dinámico

El testigo dinámico alterna el voto del testigo para asegurarse de que el número total de votos sea impar. Si hay un número impar de votos, el testigo no tiene voto. Si hay un número par de votos, el testigo tiene un voto. El testigo dinámico reduce significativamente el riesgo de que el clúster deje de funcionar debido a un error de testigo. El clúster decide si se debe usar el voto del testigo en función del número de nodos de votación que están disponibles en el clúster.

El cuórum dinámico funciona con el testigo dinámico de la manera que se describe a continuación.

Comportamiento de cuórum dinámico

• Si tiene un número par de nodos y ningún testigo, un nodo obtiene su voto en cero. Por ejemplo, solo tres de los cuatro nodos obtienen votos, por lo que el número total de votos es tres y dos supervivientes con votos se consideran mayoría.
• Si tiene un número impar de nodos y ningún testigo, todos obtienen votos.
• Si tiene un número par de nodos más testigo, el testigo vota, por lo que el total es impar.
• Si tiene un número impar de nodos más testigo, el testigo no vota.

El cuórum dinámico permite asignar un voto a un nodo dinámicamente para evitar perder la mayoría de los votos y permitir que el clúster se ejecute con un nodo (conocido como last-man standing). Vamos a tomar un clúster de cuatro nodos como ejemplo. Supongamos que el cuórum requiere 3 votos.

En este caso, el clúster habría desaparecido si perdiera dos nodos.

Sin embargo, el cuórum dinámico impide que esto suceda. El número total de votos necesario para el cuórum ahora se determina en función del número de nodos disponibles. Por lo tanto, con el cuórum dinámico, el clúster permanece activo incluso si pierde tres nodos.

El escenario anterior se aplica a un clúster general que no tiene espacios de almacenamiento directo habilitado. Sin embargo, cuando se habilita Storage Spaces Direct, el clúster solo puede admitir dos errores de nodo. Esto se explica con más detalle en la sección sobre el cuórum de grupo.

Examples

Dos nodos sin testigo

El voto de un nodo está a cero, por lo que el voto mayoritario se determina a partir de un total de 1 voto. Si el nodo que no es de votación deja de funcionar inesperadamente, el sobreviviente tiene 1/1 y el clúster sobrevive. Si el nodo de votación deja de funcionar inesperadamente, el superviviente tiene 0/1 y el clúster deja de funcionar. Si el nodo de votación se apaga correctamente, el voto se transfiere al otro nodo y el clúster sobrevive. Este es el motivo por el que es fundamental configurar un testigo.

• Puede sobrevivir a un error de servidor: cincuenta por ciento de probabilidad.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: No.
• Puede sobrevivir a dos errores de servidor a la vez: No.

Dos nodos con un testigo

Ambos nodos votan, además de los votos testigos, por lo que la mayoría se determina de un total de 3 votos. Si alguno de los nodos deja de funcionar, el superviviente tiene 2/3 y el clúster sobrevive.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: No.
• Puede sobrevivir a dos errores de servidor a la vez: No.

Tres nodos sin testigo

Todos los nodos votan, por lo que la mayoría se determina de un total de 3 votos. Si algún nodo deja de funcionar, los supervivientes son 2/3 y el clúster sobrevive. El clúster se convierte en dos nodos sin un testigo; en ese punto, estás en el escenario 1.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: cincuenta por ciento de probabilidad.
• Puede sobrevivir a dos errores de servidor a la vez: No.

Tres nodos con un testigo

Todos los nodos votan, por lo que el testigo no vota inicialmente. La mayoría se determina en un total de 3 votos. Después de un error, el clúster tiene dos nodos con un testigo, lo que supone la vuelta al escenario 2. Por lo tanto, ahora los dos nodos y el testigo votan.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: Sí.
• Puede sobrevivir a dos errores de servidor a la vez: No.

Cuatro nodos sin testigo

El voto de un nodo está cero, por lo que la mayoría se determina fuera de un total de 3 votos. Después de un error, el clúster se convierte en tres nodos y se encuentra en el escenario 3.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: Sí.
• Puede sobrevivir a dos errores de servidor a la vez: cincuenta por ciento de probabilidad.

Cuatro nodos con un testigo

Todos los nodos votan y los votos testigos, por lo que la mayoría se determina de un total de 5 votos. Después de un error, se encontraría en el escenario 4. Después de dos errores simultáneos, pasaría directamente al escenario 2.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: Sí.
• Puede sobrevivir a dos errores de servidor a la vez: Sí.

Cinco nodos y más allá

Todos los nodos votan, o todos menos un voto, lo que haga que el total sea impar. De todos modos, Espacios de almacenamiento directo no puede controlar más de dos nodos inactivos, por lo que en este momento ningún testigo es necesario o útil.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: Sí.
• Puede sobrevivir a dos errores de servidor a la vez: Sí.

Ahora que entendemos cómo funciona el cuórum, echemos un vistazo a los tipos de testigos de cuórum.

Tipos de testigos de quórum

Los clústeres de conmutación por error admiten tres tipos de testigos de cuórum:

• Testigo en la nube: Blob Storage en Azure accesible por todos los nodos del clúster. Mantiene la información de agrupación en clústeres en un archivo witness.log, pero no almacena una copia de la base de datos del clúster.
• Testigo de recurso compartido de archivos: un recurso compartido de archivos de SMB que se configura en un servidor de archivos que ejecuta Windows Server. Mantiene la información de agrupación en clústeres en un archivo witness.log, pero no almacena una copia de la base de datos del clúster.
• Testigo de disco : un pequeño disco en clúster que se encuentra en el grupo Almacenamiento disponible del clúster. Este disco presenta alta disponibilidad y puede conmutar por error entre nodos. Contiene una copia de la base de datos del clúster. No se admite un testigo de disco con Espacios de almacenamiento directo.

Introducción al cuórum de grupo

Acabamos de hablar sobre el cuórum de clúster, que funciona en el nivel de clúster. Ahora, vamos a profundizar en el cuórum de grupo, que funciona en el nivel de grupo (es decir, puede perder nodos y unidades, y hacer que el grupo se mantenga activo). Los grupos de almacenamiento se diseñaron para usarse en escenarios agrupados y no agrupados, por lo que tienen un mecanismo de cuórum diferente.

En la tabla siguiente se proporciona información general sobre los resultados del cuórum del grupo por escenario:

Funcionamiento del cuórum de grupo

Cuando se produce un error en las unidades, o cuando algún subconjunto de unidades pierde el contacto con otro subconjunto, las unidades de supervivencia que hospedan metadatos deben comprobar que constituyen la mayoría del grupo para permanecer en línea. Si no pueden comprobarlo, se desconectarán. El grupo es la entidad que se desconecta o permanece en línea según si tiene discos suficientes para el cuórum (50 % + 1). La base de datos de clúster puede considerarse como +1 siempre y cuando el propio clúster tenga cuórum.

Pero el cuórum de grupo funciona de forma diferente del cuórum de clúster de las siguientes maneras:

• El grupo selecciona un subconjunto de unidades por nodo para hospedar metadatos.
• El grupo usa la base de datos del clúster para priorizar en caso de igualdad.
• El grupo no tiene quórum dinámico
• El grupo no implementa su propia versión de quitar un voto.

Examples

Cuatro nodos con un diseño simétrico

Cada una de las 16 unidades tiene un voto y el nodo 2 también tiene un voto (puesto que es el propietario del recurso del grupo). La mayoría se determina a partir de un total de 16 votos. Si los nodos 3 y 4 están inactivos, el subconjunto superviviente tiene 8 unidades y el propietario del recurso del grupo, lo que suma 9/16 votos. Así que la piscina sobrevive.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: Sí.
• Puede sobrevivir a dos errores de servidor a la vez: Sí.

Cuatro nodos con un diseño simétrico y un fallo de disco.

Cada una de las 16 unidades tiene un voto y el nodo 2 también tiene un voto (puesto que es el propietario del recurso del grupo). La mayoría se determina a partir de un total de 16 votos. En primer lugar, la unidad 7 deja de funcionar. Si los nodos 3 y 4 están inactivos, el subconjunto superviviente tiene 7 unidades y el propietario del recurso del grupo, lo que suma 8/16 votos. Por lo tanto, el grupo no tiene mayoría y deja de funcionar.

• Puede sobrevivir a un error de servidor: Sí.
• Puede sobrevivir a un error de servidor y, a continuación, a otro: No.
• Puede sobrevivir a dos errores de servidor a la vez: No.

Recomendaciones para los cuórums de grupo

• Asegúrese de que cada nodo del clúster sea simétrico (mismo número de unidades).
• Habilite el reflejo triple o la paridad dual para que pueda tolerar errores de dos nodos y mantener en línea los discos virtuales.
• Si hay más de dos nodos inactivos o dos nodos y un disco en otro nodo están inactivos, es posible que los volúmenes no tengan acceso a las tres copias de sus datos y, por tanto, se desconecte y no estén disponibles. Se recomienda restaurar los servidores o reemplazar los discos rápidamente para garantizar la máxima resiliencia de todos los datos del volumen.

Pasos siguientes

• Configurar y administrar el cuórum
• Configura un testigo de clúster