Compartir a través de


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

Tanto SQL ServerAlways en grupos de disponibilidad como instancias de clúster de conmutación por error AlwaysOn (FCI) aprovechan los clústeres 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

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órumperió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.

Importante

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 más información, consulte: Recuperación ante desastres del clúster WSFC mediante cuórum forzado (SQL Server).

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.

Sugerencia

Al usar una configuración de almacenamiento asimétrica para Always On grupos de disponibilidad, generalmente debe usar el modo de cuórum mayoría de nodo cuando tenga un número impar de nodos de votación, o el modo de cuórum mayoría de nodo y recurso compartido de archivos cuando tenga un número par de nodos de votación.

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 cuó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 cuó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 cuórum.

Importante

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

Ajustes recomendados para la votación de quórum

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

  • Sin 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 una 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 principal, como resultado de una conmutación automática por error de la FCI o del grupo de disponibilidad, debe tener un voto. Si solo hay un grupo de disponibilidad en el clúster de WSFC y las réplicas de disponibilidad están hospedadas en instancias independientes, esta regla incluye solo la réplica secundaria que es el destino de la conmutación por error automática.

  • Excluya los nodos secundarios del sitio. En general, no proporcione votos a los nodos de 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.

Importante

Al validar el voto de quórum de WSFC, el Asistente para grupo de disponibilidad de AlwaysOn muestra una advertencia si se cumple cualquiera de las siguientes condiciones:

  • El nodo de clúster que hospeda la réplica principal no tiene un voto
  • Una réplica secundaria está configurada para la conmutación automática por error y su nodo de clúster no tiene un voto.
  • KB2494036 no está instalado en todos los nodos de clúster que hospedan las réplicas de disponibilidad. Esta revisión es necesaria para agregar o quitar los votos de nodos de clúster en las implementaciones de varios sitios. Sin embargo, no suele ser necesaria en las implementaciones de un solo sitio y la advertencia puede omitirse de forma segura.

Sugerencia

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 más información, consulte: sys.dm_hadr_cluster, sys.dm_hadr_cluster_members, sys.dm_os_cluster_nodes y sys.dm_hadr_cluster_networks

Related Tasks

Contenido relacionado

Consulte también

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