¿Qué es un testigo de cuórum?

En un clúster de conmutación por error, un testigo de cuórum es un componente que ayuda a mantener la alta disponibilidad del clúster participando en el proceso de votación de cuórum. El cuórum es un concepto que se usa para determinar el número de fallos que el clúster puede soportar mientras sigue operativo.

En un clúster, cada nodo obtiene un voto y el testigo de cuórum también puede tener un voto. El número total de votos determina el cuórum. Para que el clúster esté operativo, más de la mitad de los votos deben estar activos y en funcionamiento. Si el número de votos está por debajo de este umbral, el clúster deja de ejecutarse para evitar escenarios de cerebro dividido, donde dos partes del clúster creen que son la parte activa, lo que provoca daños en los datos.

El testigo de cuórum tiene el rol de proporcionar un voto extra para lograr o mantener la mayoría cuando hay un número par de nodos, o si algunos nodos tienen errores. Si el recuento de votos activo cae por debajo de la mayoría necesaria, el clúster deja de funcionar para evitar condiciones de "cerebro dividido". El cerebro dividido es un escenario en el que, cuando se separan secciones del clúster, cada uno cree que funcionan de forma independiente, lo que puede provocar incoherencias o daños en los datos.

Tipos de testigos de quórum

Hay tres tipos distintos de testigos de cuórum que se pueden configurar para mantener la alta disponibilidad y evitar condiciones de cerebro dividido. Cada uno sirve como un voto imparcial en la salud del cuórum de la agrupación.

• Testigo en la nube: un servicio basado en la nube como Azure Blob Storage
• Testigo de disco: un disco compartido accesible por todos los nodos
• Testigo del recurso compartido de archivos: una carpeta compartida accesible por todos los nodos

Para garantizar la operación continua y la integridad de los datos, estos testigos de cuórum ofrecen un método único para lograr una votación de mayoría para las operaciones de clúster. Como procedimiento recomendado, configure el cuórum para que tenga un número impar de elementos de votación. Si el clúster tiene un número par de nodos de votación, agregue un disco testigo o un testigo del recurso compartido de archivos. Esta configuración permite al clúster tolerar un error de nodo adicional. Además, agregar un voto de testigo garantiza que el clúster pueda seguir funcionando aunque la mitad de los nodos del clúster produzcan un error o pierdan la conectividad simultáneamente. En función de la configuración de cuórum que elija, el clúster se configura en uno de los siguientes modos de cuórum:

Modo	Descripción
Mayoría de nodo (sin testigo)	Solo los nodos tienen votos. No se ha configurado ningún testigo de cuórum. El cuórum de clúster depende de los votos de mayoría de los nodos de clúster activos.
Mayoría de nodo con testigo (disco o recurso compartido de archivos)	Los nodos tienen votos. Además, un testigo de cuórum tiene un voto. El cuórum de clúster se basa en los votos de mayoría de los nodos de clúster activos, incluidos los votos testigos. Un testigo de cuórum puede ser un testigo de disco designado o un testigo de compartición de archivos designado.
Sin mayoría (solo disco testigo)	Ningún nodo tiene votos. Solo los testigos de disco tienen un voto. El cuórum de clúster se basa en el estado del disco testigo. Por lo general, no se recomienda este modo y no se debe seleccionar porque crea un único punto de error para el clúster.

Nota:

Si utiliza un testigo de compartición de archivos o un testigo en la nube, no olvide reiniciar el servicio de clúster en el último nodo activo antes de apagar todos los nodos del clúster para realizar el mantenimiento. Esto garantiza que el clúster pueda reanudar las operaciones sin problemas al volver a estar en línea. Los tipos de testigo, como estos, no almacenan la base de datos de clúster más reciente, lo que puede provocar errores durante el inicio del dispositivo. Para más información, consulte Evento 1561.

Sugerencia

Para comprobar el voto dinámico asignado a un nodo, compruebe la propiedad DynamicWeight del nodo de clúster mediante el cmdlet Get-ClusterNode . Un valor dynamicWeight de 0 significa que el nodo no tiene un voto de cuórum, mientras que un valor de 1 indica que el nodo tiene un voto de cuórum.

Testigo en la nube

El testigo en la nube es diferente de las configuraciones tradicionales del testigo de cuórum de clúster porque usa una máquina virtual (VM) de Azure en la nube como testigo de cuórum en lugar de un centro de datos físico. El testigo en la nube usa Azure Blob Storage para leer y escribir un archivo de blob que el sistema usa como voto decidido para lograr el cuórum. En el diagrama siguiente se muestra una configuración de ejemplo que usa el testigo en la nube.

Las configuraciones de testigos en la nube no requieren un tercer centro de datos independiente y obtienen un voto adicional para evitar los apagados totales si uno de los otros centros de datos se desactiva. No necesita un sitio adicional para almacenar el testigo de cuórum y tampoco necesita el mantenimiento físico normal necesario para un centro de datos en el sitio.

Junto con la redundancia, hay otras ventajas para usar la característica de testigo en la nube:

• El uso de Azure Blob Storage elimina la sobrecarga de mantenimiento adicional que suele ser necesaria para hospedar máquinas virtuales en la nube pública.

• Puede usar la misma cuenta de Azure Storage para varios clústeres. Los únicos requisitos son que solo use un blob por clúster y asigne al archivo de blob el nombre del identificador único del clúster.

• Reduzca los costos continuos de la cuenta de almacenamiento, ya que el archivo de blob no necesita muchos datos y se actualiza solo cuando cambia el estado del nodo de clúster.

• Azure incluye un tipo de recurso testigo en la nube integrado.

• Un testigo en la nube no almacena una copia de la base de datos del clúster.

Testigo de disco

Un disco testigo es un tipo de testigo de cuórum usado en un clúster de conmutación por error para ayudar a mantener la alta disponibilidad del clúster. Un testigo de disco es un disco compartido al que todos los nodos del clúster tienen acceso. El disco testigo contiene una pequeña cantidad de espacio de almacenamiento que se usa para almacenar la base de datos de configuración del clúster. Este espacio de almacenamiento incluye información importante sobre el clúster, como el estado de cada nodo y la propiedad de los recursos del clúster. Así es como funciona:

• El disco testigo se configura como un almacenamiento compartido al que pueden acceder todos los nodos, pero solo un nodo escribe en un momento dado.

• Cuando se inicia el servicio de clúster, cada nodo se comunica con el testigo de disco para leer la configuración de clúster más reciente.

• El disco testigo participa en el proceso de votación del cuórum. Si se produce un error en un nodo, el testigo de disco proporciona un voto adicional, lo que puede ayudar a evitar un escenario de cerebro dividido.

• Si hay una partición de red, el lado de la partición con acceso al disco testigo que tiene la mayoría de los votos sigue ejecutándose, manteniendo la integridad del clúster.

El disco testigo es útil en clústeres con un número par de nodos, donde puede actuar como un desempate para asegurarse de que siempre hay un voto de mayoría. También resulta útil en escenarios en los que se produce un error simultáneo de varios nodos, ya que el testigo de disco puede ayudar a mantener el cuórum.

La ventaja clave de usar un testigo de disco es que proporciona un método coherente y confiable para que todos los nodos acepten el estado actual del clúster. La coherencia es fundamental para garantizar el funcionamiento adecuado de un clúster de conmutación por error. Es importante tener en cuenta que el testigo de disco no almacena datos de usuario o aplicación; sirve únicamente para la base de datos de configuración del clúster y la votación del quórum.

Testigo de recurso compartido de archivos

Cuando un clúster incluye un número par de nodos con capacidad de votación, debe configurar un testigo. Si se agrega un voto de testigo, el clúster seguirá ejecutándose si la mitad de los nodos de clúster se desactivan o desconectan de forma simultánea. Un testigo de recurso compartido de archivos es un tipo de testigo de quórum que utiliza un recurso compartido de archivos de bloque de mensajes de servidor (SMB) para mantener la información del clúster en un archivo de registro. Este recurso compartido de archivos se puede hospedar en un servidor, almacenamiento USB o almacenamiento conectado a la red (NAS).

El testigo de compartición de archivos también es beneficioso para clústeres de varios sitios con almacenamiento replicado. Puede usar un testigo de recurso compartido de archivos cuando:

• No se puede usar un testigo en la nube porque los nodos del clúster no tienen una conexión confiable a Internet ni una conectividad a Internet.

• Cuando no se puede usar un testigo de disco porque no hay unidades compartidas que se puedan usar para un testigo de disco. Por ejemplo, un clúster de Espacios de almacenamiento directo, Grupos de disponibilidad AlwaysOn (AG) de SQL Server o un Grupo de disponibilidad de base de datos de Exchange (DAG). Ninguno de estos tipos de clústeres usa discos compartidos.

Este ejemplo es una configuración simplificada con dos nodos en dos centros de datos locales. En los clústeres típicos, cada nodo tiene un voto, un testigo de recurso compartido de archivos, que da un voto extra al testigo de quórum. Este voto adicional permite al clúster seguir ejecutándose aunque uno de los centros de datos se desactive. En el ejemplo, el cuórum de clúster tiene cinco posibles votos y solo necesita tres votos para continuar ejecutándose.

Sin embargo, es posible que observe que, además de los dos centros de datos, también hay un tercer centro de datos que actúa como testigo de uso compartido de archivos . Este centro de datos se mantiene separado de los otros dos sitios y hospeda un servidor de archivos que realiza una copia de seguridad del recurso compartido de archivos del sistema. El testigo de recurso compartido de archivos funciona como testigo de cuórum en esta configuración del cuórum de clúster, lo que garantiza que el sistema siga ejecutándose aunque uno de los centros de datos se apague inesperadamente.

Tener un testigo de recurso compartido de archivos proporciona redundancia suficiente para mantener la alta disponibilidad del servidor de archivos. Sin embargo, debe recordar que hospedar el testigo de recurso compartido de archivos en otro servidor de un sitio independiente requiere configuración, mantenimiento regular y conectividad independiente con los demás sitios.

Configuración de testigos

Como procedimiento recomendado, configure el cuórum para que tenga un número impar de elementos de votación. Si el clúster tiene un número par de nodos de votación, agregue un testigo de disco o un testigo de compartición de archivos para garantizar la alta disponibilidad. Esta configuración permite al clúster tolerar el error de un nodo adicional. Además, agregar un voto de testigo garantiza que el clúster pueda seguir funcionando aunque la mitad de los nodos del clúster produzcan un error o pierdan conectividad simultáneamente.

Normalmente, se recomienda un testigo de disco cuando todos los nodos del clúster tienen acceso al disco compartido. Por otro lado, se prefiere un testigo de uso compartido de archivos para escenarios de recuperación ante desastres multisitio que implican almacenamiento replicado. La configuración de un testigo de disco con almacenamiento replicado solo es factible si la solución de almacenamiento admite el acceso de lectura y escritura desde todos los sitios al almacenamiento replicado. Para más información sobre los tipos de configuración de testigos, consulte Implementación de un testigo de cuórum.

Asignación de voto de nodo

En configuraciones avanzadas de cuórum, puede asignar o quitar votos de cuórum para nodos individuales. De forma predeterminada, a cada nodo del clúster se le asigna un voto. Sin embargo, incluso si se quita el voto de un nodo, sigue participando en el clúster, recibe actualizaciones de la base de datos del clúster y sigue siendo capaz de hospedar aplicaciones.

En escenarios específicos de recuperación ante desastres, puede considerar la posibilidad de quitar votos de determinados nodos. Por ejemplo, en un clúster multisitio, puede quitar votos de los nodos ubicados en un sitio de copia de seguridad para evitar que influyen en los cálculos de cuórum. Este enfoque se recomienda normalmente solo cuando se planifica la conmutación por error manual entre sitios. No se recomienda asignar votos de nodo para garantizar un número impar de nodos de votación. En su lugar, debe configurar un testigo de disco o un testigo de compartición de archivos.

Administración dinámica de cuórum

La administración dinámica de cuórum es una opción de configuración avanzada que permite al clúster ajustar dinámicamente sus requisitos de mayoría de cuórum. Esta característica permite que el clúster permanezca operativo incluso cuando los nodos se apaguen secuencialmente, lo que permite que el clúster se ejecute en el último nodo superviviente.

La administración dinámica de cuórum proporciona una mayor flexibilidad y resistencia para los clústeres de conmutación por error, lo que lo convierte en una característica valiosa para mantener la alta disponibilidad en entornos dinámicos. Con la administración dinámica de quórum habilitada, el clúster puede ajustar automáticamente los votos asignados a los nodos en función del estado actual del clúster, lo que garantiza que el clúster pueda soportar fallos de nodos o apagados planificados mientras mantiene el quórum. Si la administración de cuórum dinámico está habilitada, solo los nodos configurados para tener asignados votos de nodo pueden tener asignados sus votos o quitarlos dinámicamente.

Consideraciones clave:

• La administración dinámica del cuórum no permite que el clúster sobreviva al error simultáneo de la mayoría de los miembros con derecho a voto. En el momento de un error o apagado de nodo, el clúster todavía debe tener una mayoría de cuórum para seguir ejecutándose.
• Si el voto de un nodo se quita explícitamente, el clúster no puede agregar ni quitar ese voto dinámicamente.
• En clústeres con Espacios de almacenamiento directo habilitado, el clúster solo puede tolerar hasta dos errores de nodo.

Recomendaciones generales para la configuración de cuórum

El software de clúster determina automáticamente la configuración de cuórum de un nuevo clúster en función del número de nodos y de la disponibilidad del almacenamiento compartido. Esta configuración predeterminada suele ser la más adecuada para el clúster. Se recomienda revisar la configuración del cuórum después de crear el clúster y antes de implementarla en un entorno de producción.

Para examinar la configuración detallada del cuórum, puede usar el Asistente para validar una configuración o el cmdlet Test-Cluster para ejecutar la prueba de Validar configuración de cuórum. En Failover Cluster Manager, la configuración básica del quórum está visible en la sección de resumen del clúster seleccionado. Como alternativa, puede recuperar información detallada sobre los recursos de cuórum mediante la ejecución del cmdlet Get-ClusterQuorum .

En cualquier momento, puede ejecutar la prueba Validar configuración de cuórum para asegurarse de que la configuración del cuórum es óptima para el clúster. Los resultados de la prueba indican si se recomienda un cambio de configuración y proporciona la configuración óptima. Si se necesitan ajustes, puede aplicar los cambios recomendados mediante el Asistente para configurar el cuórum del clúster. Una vez que el clúster está en producción, evite modificar la configuración del cuórum a menos que evalúe exhaustivamente y confirme que el cambio es necesario para los requisitos específicos del clúster. Es posible que quiera considerar la posibilidad de cambiar la configuración del cuórum en las situaciones siguientes:

• Agregar o expulsar nodos
• Adición o eliminación del almacenamiento
• En caso de errores de nodos o testigos de larga duración
• Recuperación de un clúster en un escenario de recuperación ante desastres multisitio

Consulte también

• Configuración de un testigo de clúster en Azure Local

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

• Validar hardware para un clúster de conmutación por error