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
Clústeres de Conmutación por Error de Windows Server proporciona alta disponibilidad para las cargas de trabajo que se ejecutan en clústeres de Azure Stack HCI 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 tener quórum.
Quorum está diseñado para evitar escenarios de 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 en clústeres de conmutación, lo que obliga a que solo uno de estos grupos de nodos continúe ejecutándose y, por lo tanto, solo uno de estos grupos permanece en línea.
Quórum determina el número de errores que el clúster puede soportar mientras sigue 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 mantener el clúster activo).
- Cuórum de grupo: Esto opera a nivel de grupo (es decir, puede perder nodos y unidades y mantener el grupo en funcionamiento). 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:
| Nodos de servidor | Puede sobrevivir a un error de nodo de servidor | Puede sobrevivir a un error de nodo de servidor y, a continuación, a otro | Puede sobrevivir a dos errores simultáneos de nodo de servidor |
|---|---|---|---|
| 2 | 50/50 | No | No |
| 2 + Testigo | Sí | No | No |
| 3 | Sí | 50/50 | No |
| 3 + El Testigo | Sí | Sí | No |
| 4 | Sí | Sí | 50/50 |
| 4 + Testigo | Sí | Sí | Sí |
| 5 y versiones posteriores | Sí | Sí | Sí |
Recomendaciones de quórum de clúster
- Si tiene dos nodos, es necesario un testigo .
- Si tiene tres o cuatro nodos, se recomienda encarecidamente 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 está en un entorno de TI con otras máquinas y comparticiones de archivos, use un testigo de compartición 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 de 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 de 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:
- En primer lugar, puede subir uno al agregar un testigo con un voto adicional. Esto requiere la configuración del usuario.
- O bien, puede bajar en uno al poner a cero el voto de un nodo desafortunado (esto sucede automáticamente según sea necesario).
Siempre que los nodos supervivientes verifiquen correctamente que son la mayoría de , la definición de mayoría se actualiza para estar solo entre los supervivientes. Esto permite que el clúster pierda un nodo, luego otro, otro, etc. Este concepto de que el número total de votos se adapta después de sucesivos fracasos se conoce como cuórum dinámico.
Testigo dinámico
El testigo dinámico cambia el voto del testigo para garantizar 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 incluso número de nodos y ningún testigo, un nodo obtiene su voto con ceros. 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 de nodos y ningún testigo, todos obtienen votos.
- Si tiene un incluso número de nodos más testigo, los votos del testigo, por lo que el total es impar.
- Si tiene un número impar número 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 más en la sección cuórum de grupo de .
Ejemplos
Dos nodos sin testigo
El voto de un nodo se ha reducido a cero, por lo que la votación de mayoría se determina a partir de un total de 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 del testigo, por lo que se determina la mayoría de 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 de 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. El de mayoría de se determina de un total de 3 votos. Después de una falla, el clúster tiene dos nodos con un testigo, lo que vuelve 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, otro: Sí.
- Puede sobrevivir a dos errores de servidor a la vez: No.
Cuatro nodos sin testigo
El voto de un nodo se ha puesto a cero, por lo que la mayoría de se determina 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, otro: Sí.
- Puede sobrevivir a dos errores de servidor a la vez: cincuenta por ciento de probabilidad.
Cuatro nodos con un testigo
Todos los votos de los nodos y los votos de los testigos se cuentan, por lo que la mayoría de se determina de un total de 5 votos. Después de un error, estás en el escenario 4. Después de dos errores simultáneos, pase al escenario 2.
- Puede sobrevivir a un error de servidor: Sí.
- Puede sobrevivir a un error de servidor y, a continuación, 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. Storage Spaces Direct no puede manejar más de dos nodos caídos en cualquier caso, por lo que en este momento, no se necesita ni resulta útil un testigo.
- Puede sobrevivir a un error de servidor: Sí.
- Puede sobrevivir a un error de servidor y, a continuación, 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: el almacenamiento de blobs en Azure es accesible para 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 Compartición de Archivos SMB: un recurso compartido de archivos SMB configurado 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 de Almacenamiento disponible del clúster. Este disco es de alta disponibilidad y puede conmutar automáticamente entre los nodos. Contiene una copia de la base de datos del clúster. no se admite un testigo de disco con Storage Spaces Direct.
Visión general del quórum del pool
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 del grupo de almacenamiento, que opera a nivel de grupo de almacenamiento (es decir, puede perder nodos y unidades de almacenamiento y hacer que el grupo siga operativo). 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:
| Nodos de servidor | Puede sobrevivir a un error de nodo de servidor | Puede sobrevivir a un error de nodo de servidor y, a continuación, a otro | Puede sobrevivir a dos errores simultáneos de 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 versiones posteriores | 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 sobrevivientes que hospedan metadatos deben comprobar que constituyen la mayoría de del conjunto para permanecer en línea. Si no pueden comprobarlo, se desconectarán. El grupo es la entidad que se queda sin conexión o permanece en línea en función de si tiene suficientes discos para el cuórum (50% + 1). La base de datos de clúster puede ser considerada como +1 siempre que el propio clúster tenga quó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 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 dos también tiene un voto (ya que es el propietario del recurso del grupo). La mayoría de se determina a partir de un total de 16 votos. Si los nodos tres y cuatro fallan, el subconjunto superviviente tiene 8 unidades y el propietario del recurso del grupo posee 9 de los 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, 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 (ya que es el propietario del recurso grupal). La mayoría de se determina de un total de 16 votos. En primer lugar, la unidad 7 baja. Si los nodos tres y cuatro fallan, el subconjunto superviviente tiene 7 unidades y el grupo cuenta con el propietario del recurso, que tiene 8 de 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 de cuórum de conjunto
- Asegúrese de que cada nodo del clúster esté simétrico (cada nodo tiene el mismo número de unidades).
- Habilite la paridad dual o el reflejo triple para que se puedan tolerar dos fallos de nodo y mantener los discos virtuales en línea.
- 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.