Share via


Configuración de los votos y modos de quórum WSFC (SQL Server)

Tanto SQL Server Grupos de disponibilidad AlwaysOn como las instancias de clúster de conmutación por error (FCI) AlwaysOn sacan provecho del Clúster de conmutación por error de Windows Server (WSFC) como tecnología de plataforma. WSFC usa un método basado en quórum para supervisar el estado general del clúster y maximizar la tolerancia a errores en el nivel de nodo. Entender los modos de quórum WSFC y la configuración de las votaciones en los nodos es muy importante para el diseño, el funcionamiento y la solución de problemas de una solución de recuperación de desastres AlwaysOn de alta disponibilidad.

En este tema:

  • Detección del estado de clúster por quórum

  • Modos de quórum

  • Nodos que votan y nodos que no votan

  • Ajustes recomendados para la votación de quórum

  • Tareas relacionadas

  • Contenido relacionado

Detección del estado de clúster por quórum

Cada nodo de un clúster WSFC participa en la comunicación periódica de latido para compartir el estado de mantenimiento del nodo con los demás nodos. Los nodos que no responden se consideran que se encuentran en estado de error.

Un conjunto de nodos de quórum es una mayoría de los nodos con derecho a voto y testigos en el clúster WSFC. Un voto de quórum periódico determina el estado general de un clúster WSFC. La presencia de un quórum significa que el clúster es correcto y puede proporcionar tolerancia a errores de nivel de nodo.

La ausencia de un quórum indica que el clúster no es correcto. El estado general del clúster WSFC debe mantenerse para asegurarse de que los nodos secundarios sanos correctos disponibles para que los nodos primarios puedan conmutar por error. Si el voto de quórum da error, el clúster WSFC se pondrá sin conexión como medida preventiva. También hará que todas las instancias de SQL Server registradas con el clúster se detengan.

Nota importanteImportante

Si un clúster WSFC se pone sin conexión debido a un error del quórum, se requiere una intervención manual para volver a ponerlo en conexión.

Para obtener más información, vea Recuperación ante desastres del clúster WSFC mediante quórum forzado (SQL Server)

[Arriba]

Modos de quórum

Un modo de quórum se configura en el nivel de clúster WSFC que dicta la metodología que se usa para los votos de quórum. La utilidad Administrador de clústeres de conmutación por error recomendará un modo de quórum basándose en el número de nodos del clúster.

Los siguientes modos de quórum se pueden usar para determinar qué constituye un quórum de votos:

  • Mayoría de nodos. Más de la mitad de los nodos que votan en el clúster deben votar afirmativamente para que el clúster sea correcto.

  • Nodo y mayoría de recurso compartido de archivos. Similar al modo de quórum Mayoría de nodos, excepto en que un recurso compartido de archivos remoto también se configura como testigo de la votación y la conectividad de cualquier nodo para ese recurso compartido también se cuenta como voto afirmativo. Más de la mitad de los votos posibles debe ser afirmativa para que el clúster sea correcto.

    Como práctica recomendada, el recurso compartido de archivos testigo no debe residir en ningún nodo del clúster y debe ser visible para todos los nodos del clúster.

  • Nodo y mayoría de disco. Similar al modo de quórum Mayoría de nodos, excepto en que un recurso de clúster de disco compartido también se designa como testigo de la votación y la conectividad de cualquier nodo con ese disco compartido también se considera voto afirmativo. Más de la mitad de los votos posibles debe ser afirmativa para que el clúster sea correcto.

  • Solo disco. Un recurso de clúster de disco compartido se designa como testigo y la conectividad de cualquier nodo a ese disco compartido se considera voto afirmativo.

SugerenciaSugerencia

Al utilizar una configuración asimétrica de almacenamiento para Grupos de disponibilidad AlwaysOn, normalmente debe usar el modo de quórum Mayoría de nodos cuando tenga un número impar de nodos que votan o el modo de quórum Mayoría de recurso compartido de archivo y nodo cuando tiene un número par de nodos que votan.

[Arriba]

Nodos que votan y nodos que no votan

De forma predeterminada, cada nodo del clúster WSFC se incluye como miembro del quórum del clúster; cada nodo tiene un único voto para determinar el estado general del clúster y cada nodo intentará continuamente establecer un quórum. La discusión del quórum hasta este punto ha calificado cuidadosamente el conjunto de nodos de clúster WSFC que votan sobre el estado del clúster como nodos que votan.

Ningún nodo individual en un clúster WSFC puede determinar definitivamente que el clúster como conjunto sea correcto o incorrecto. En un momento dado, desde la perspectiva de cada nodo, puede parecer que alguno de los otros nodos están sin conexión, en el proceso de conmutar por error o que no responden debido a un error de comunicación de red. Una función clave del voto de quórum es determinar si el estado aparente de cada uno de los nodos del clúster WSFC es de hecho ese estado real de los nodos.

Para todos los modelos de quórum excepto “Solo disco”, la eficacia de un voto de quórum depende de que las comunicaciones entre todos los nodos que votan del clúster sean confiables. Las comunicaciones de red entre los nodos de la misma subred física se deben considerar predecibles; el voto de quórum debe ser de confianza.

Sin embargo, si un nodo de otra subred se considera que no responde en un voto de quórum, pero realmente está en conexión y es correcta, es más probable que se deba a un error de comunicaciones de red entre las subredes. Según la topología de clúster, el modo de quórum y la configuración de directivas de migración tras error, ese error de comunicaciones de red puede crear en efecto más de un conjunto (o subconjunto) de nodos que votan.

Cuando más de un subconjunto de nodos que votan puede establecer un quórum por sí solo, lo que se conoce como escenario de división de cerebro. En este escenario, los nodos de los quórums independientes pueden comportarse de forma diferente y en conflicto entre sí.

[!NOTA]

El escenario de división de cerebro solo es posible si un administrador del sistema realiza manualmente una operación forzada de quórum o, en circunstancias muy poco habituales, una conmutación por error forzada; subdividiendo explícitamente el conjunto de nodos de quórum.

Para simplificar la configuración del quórum y aumentar el tiempo de actividad, puede ser aconsejable ajustar el valor de NodeWeight de cada nodo para que el voto del nodo no se cuente en el quórum.

Nota importanteImportante

Para usar la configuración de NodeWeight, se debe aplicar la siguiente revisión a todos los servidores del clúster de WSFC:

KB2494036: hay disponible una revisión para permitir configurar un nodo de clúster que no tiene votos de quórum en Windows Server 2008 y en Windows Server 2008 R2

[Arriba]

Ajustes recomendados para la votación de quórum

Al habilitar o deshabilitar el voto de un nodo WSFC determinado, siga estas instrucciones:

  • No hay ningún voto de forma predeterminada. Suponga que cada nodo no debe votar sin una justificación explícita.

  • Incluya todas las réplicas principales. Cada nodo WSFC que hospeda una réplica principal de grupo de disponibilidad o es el propietario preferido de un FCI debe tener un voto.

  • Incluya los posibles propietarios de la conmutación automática por error. Cada nodo que puede hospedar una réplica de disponibilidad principal, como resultado de una conmutación por error de FCI o de grupo de disponibilidad, debe tener un voto. Si solo hay un grupo de disponibilidad en el clúster WSFC y las réplicas de disponibilidad solo son hospedadas por instancias independientes, esta regla solo incluye la réplica secundaria que es el destino de la conmutación por error automática.

  • Excluye los nodos secundarios del sitio. En general, no proporcione votos a los nodos WSFC que residen en un sitio secundario de recuperación de desastres. No desea que los nodos del sitio secundario contribuyan a la decisión de poner el clúster fuera de conexión cuando no hay ningún problema con el sitio principal.

  • Número impar de votos. Si es necesario, agregue un recurso compartido de archivos testigo, un nodo testigo o un disco testigo al clúster y ajuste el modo de quórum para evitar posibles empates en el voto de quórum.

  • Vuelva a valorar las asignaciones de votos después de la conmutación por error. No es conveniente realizar la conmutación por error en una configuración de clúster que no admita un quórum correcto.

Nota importanteImportante

Al validar la configuración de los votos de cuórum WSFC, el Asistente para grupos de disponibilidad AlwaysOn muestra una advertencia si alguna de las condiciones siguientes se cumple:

  • El nodo de clúster que hospeda la réplica principal no tiene un voto

  • Una réplica secundaria se configura para la conmutación por error automática y su nodo de clúster no tiene un voto.

  • KB2494036 no se instala en todos los nodos de clúster que hospedan las réplicas de disponibilidad. Esta revisión se requiere para agregar o quitar votos para los nodos de clúster en implementaciones de varios sitios. Sin embargo, en implementaciones en un solo sitio, suele no ser necesario y puede omitir la advertencia.

SugerenciaSugerencia

SQL Server expone varias vistas de administración dinámica (DMV) del sistema que pueden ayudarle a administrar la configuración de clúster WSFC relacionada y la votación del cuórum de los nodos.

Para obtener más información, vea: sys.dm_hadr_cluster, sys.dm_hadr_cluster_members, sys.dm_os_cluster_nodes, sys.dm_hadr_cluster_networks

[Arriba]

Tareas relacionadas

Contenido relacionado

[Arriba]

Vea también

Conceptos

Recuperación ante desastres del clúster WSFC mediante quórum forzado (SQL Server)

Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server