Descripción del cuórum de clúster y grupo
Se aplica a: Azure Stack HCI, versiones 22H2 y 21H2; Windows Server 2022, Windows Server
Importante
Azure Stack HCI ahora forma parte de Azure Local. El cambio de nombre de la documentación del producto está en curso. Sin embargo, las versiones anteriores de Azure Stack HCI, por ejemplo, 22H2 seguirán haciendo referencia a Azure Stack HCI y no reflejarán el cambio de nombre. Más información.
Los clústeres de conmutación por error de Windows Server proporcionan alta disponibilidad para las cargas de trabajo que se ejecutan en clústeres de Azure Stack HCI y de Windows Server. Estos recursos se consideran de alta disponibilidad si los nodos que los hospedan están activos; sin embargo, el clúster necesita generalmente que más de la mitad de los nodos estén en ejecución, es decir, que tengan 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 impide con el concepto de cuórum de clústeres de conmutación por error, lo 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 Stack HCI 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 hacer que el clúster permanezca activo).
- Cuórum de grupo: Funciona en el nivel de grupo (es decir, puede perder nodos y unidades y hacer que el grupo se mantenga activo). Los bloques de almacenamiento se diseñaron para usarse en escenarios agrupados y no agrupados, por lo que tienen un mecanismo de cuórum diferente.
Introducción al cuórum de clúster
En la tabla siguiente se proporciona información general sobre los resultados del cuórum de clúster por escenario:
| Nodos de servidor | Pueden sobrevivir a un error del nodo de servidor | Pueden sobrevivir a un error del nodo de servidor y luego a otro | Pueden sobrevivir a dos errores simultáneos del nodo de servidor |
|---|---|---|---|
| 2 | 50/50 | No | No |
| 2 + testigo | Sí | No | No |
| 3 | Sí | 50/50 | No |
| 3 + testigo | Sí | Sí | No |
| 4 | Sí | Sí | 50/50 |
| 4 + testigo | Sí | Sí | Sí |
| 5 y más | Sí | Sí | Sí |
Recomendaciones para el cuórum de clúster
- Si tiene dos nodos, se requiere un testigo.
- Si tiene tres o cuatro nodos, se recomienda firmemente un testigo.
- Si tiene cinco nodos o más, no es necesario un testigo ya que este no proporcionaría 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 un subconjunto de nodos pierde contacto con otro, los nodos supervivientes deben comprobar que conforman la mayoría del clúster para permanecer en línea. Si no pueden comprobarlo, se desconectan.
Pero el concepto de mayoría solo funciona correctamente cuando el número total de nodos del clúster es impar (por ejemplo, tres nodos en un clúster de cinco). Por lo tanto, ¿qué sucede 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 impar:
- En primer lugar, puede activar uno agregando un testigo con un voto adicional. Esto requiere la configuración del usuario.
- O bien, puede desactivar uno si pone a cero el voto de un nodo menos afortunado (se realiza 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, después 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 un 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 usará el voto del testigo en función del número de nodos votantes 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 del cuórum dinámico
- Si tiene un número par de nodos y ningún testigo, un nodo pone su voto a 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 una 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 un testigo, el testigo vota, por lo que el total es impar.
- Si tiene un númeroimpar de nodos más un testigo, el testigo no vota.
El cuórum dinámico ofrece la posibilidad de asignar un voto a un nodo de forma dinámica para evitar la pérdida de la mayoría de los votos y permitir que el clúster se ejecute con un nodo (el último que queda). Vamos a tomar como ejemplo un clúster de cuatro nodos. Supongamos que el cuórum necesita tres votos.
En este caso, el clúster se habría vuelto inactivo si ha perdido dos nodos.
Sin embargo, el cuórum dinámico evita que esto suceda. El número total de votos necesario para el cuórum se determina ahora según el 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 habilitado Espacios de almacenamiento directo. Sin embargo, cuando Espacios de almacenamiento directo está habilitado, el clúster solo puede admitir dos errores del nodo. Esto se explica con más detalle en la sección sobre el cuórum de grupo.
Ejemplos
Dos nodos sin un testigo
El voto de un nodo se pone a cero, por lo que la mayoría de votos se determina a partir de un total de 1 voto. Si el nodo que no vota se vuelve inactivo de manera inesperada, el superviviente tiene 1/1 y el clúster sobrevive. Si el nodo votante se vuelve inactivo de manera inesperada, el superviviente tiene 0/1 y el clúster deja de funcionar. Si el nodo votante 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 del servidor: Cincuenta por ciento de probabilidad.
- Puede sobrevivir a un error del servidor y luego a otro: No.
- Puede sobrevivir a dos errores seguidos del servidor: No.
Dos nodos con un testigo
Ambos nodos votan, además de los votos del testigo, por lo que la mayoría se determina a partir de un total de 3 votos. Si uno de los nodos se vuelve inactivo, el superviviente tiene 2/3 y el clúster sobrevive.
- Puede sobrevivir a un error del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: No.
- Puede sobrevivir a dos errores seguidos del servidor: No.
Tres nodos sin un testigo
Todos los nodos votan, por lo que la mayoría se determina a partir de un total de 3 votos. Si un nodo deja de funcionar, los supervivientes son 2/3 y el clúster sobrevive. El clúster pasa a tener dos nodos sin testigo: en ese momento, estaría en el escenario 1.
- Puede sobrevivir a un error del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Cincuenta por ciento de probabilidad.
- Puede sobrevivir a dos errores seguidos del servidor: No.
Tres nodos con un testigo
Todos los nodos votan, por lo que el testigo no vota inicialmente. La mayoría se determina a partir de 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 del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Sí.
- Puede sobrevivir a dos errores seguidos del servidor: No.
Cuatro nodos sin un testigo
El voto de un nodo se pone a cero, por lo que la mayoría se determina a partir de un total de 3 votos. Después de un error, el clúster pasa a tener tres nodos y se encontraría en el escenario 3.
- Puede sobrevivir a un error del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Sí.
- Puede sobrevivir a dos errores seguidos del servidor: Cincuenta por ciento de probabilidad.
Cuatro nodos con un testigo
Todos los nodos y el testigo votan, por lo que la mayoría se determina a partir 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 del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Sí.
- Puede sobrevivir a dos errores seguidos del servidor: Sí.
Cinco nodos y más
Todos los nodos votan, o todos menos uno, lo que hace que el total sea impar. Espacios de almacenamiento directo no puede controlar más de dos nodos de todos modos, por lo que en este momento, no se necesita ningún testigo ni resulta útil.
- Puede sobrevivir a un error del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Sí.
- Puede sobrevivir a dos errores seguidos del servidor: Sí.
Ahora que sabemos cómo funciona el cuórum, echemos un vistazo a los tipos de testigos de cuórum.
Tipos de testigo de cuórum
Los clústeres de conmutación por error admiten tres tipos de testigos de cuórum:
- Testigo en la nube : todos los nodos del clúster pueden acceder al almacenamiento de blobs de Azure. Este testigo mantiene la información de la 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. Este testigo mantiene la información de la 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 es de 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 bloques 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 de grupo por escenario:
| Nodos de servidor | Pueden sobrevivir a un error del nodo de servidor | Pueden sobrevivir a un error del nodo de servidor y luego a otro | Pueden sobrevivir a dos errores simultáneos del nodo de servidor |
|---|---|---|---|
| 2 | Sí | No | No |
| 2 + testigo | Sí | No | No |
| 3 | Sí | No | No |
| 3 + testigo | Sí | No | No |
| 4 | Sí | No | No |
| 4 + testigo | Sí | Sí | Sí |
| 5 y más | Sí | Sí | Sí |
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 desconectan. 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 ser +1 siempre que el propio clúster sea quorate.
Sin embargo, el cuórum de grupo funciona de forma diferente al 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 de clúster para interrumpir los vínculos
- El grupo no tiene quórum dinámico
- El grupo no implementa su propia versión de eliminación de un voto
Ejemplos
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. Por lo tanto, el grupo sobrevive.
- Puede sobrevivir a un error del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: Sí.
- Puede sobrevivir a dos errores seguidos del servidor: Sí.
Cuatro nodos con un diseño simétrico y un error de unidad
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 del servidor: Sí.
- Puede sobrevivir a un error del servidor y luego a otro: No.
- Puede sobrevivir a dos errores seguidos del servidor: 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 la paridad dual o reflejo triple para que pueda tolerar dos errores de nodo y mantener los discos virtuales en línea.
- Si hay más de dos nodos inactivos, o dos nodos y un disco de 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 desconecten y no estén disponibles. Se recomienda devolver los servidores o reemplazar los discos rápidamente para garantizar la mayor resistencia de todos los datos del volumen.