Compartir a través de

Clústeres de conmutación por error y grupos de disponibilidad Always On (SQL Server)

Se aplica a:SQL Server: solo Windows

Grupos de disponibilidad AlwaysOn, la solución de alta disponibilidad y recuperación ante desastres introducida en SQL Server 2012 (11.x), requiere clústeres de conmutación por error de Windows Server (WSFC). Además, aunque los grupos de disponibilidad Always On no dependen de los clústeres de conmutación por error de SQL Server, puede usar una instancia de clúster de conmutación por error (FCI) para alojar una réplica de disponibilidad para un grupo de disponibilidad. Es importante conocer el rol de cada tecnología de agrupación en clústeres y saber qué consideraciones son necesarias al diseñar el entorno de grupos de disponibilidad AlwaysOn.

Nota

Para obtener información sobre los conceptos de los grupos de disponibilidad AlwaysOn, consulte ¿Qué es un grupo de disponibilidad AlwaysOn?

Clústeres de conmutación por error de Windows Server y grupos de disponibilidad

La implementación de Grupos de disponibilidad AlwaysOn requiere un Clúster de conmutación por error de Windows Server (WSFC). Para que una instancia de Grupos de disponibilidad AlwaysOn se habilite para SQL Server, debe residir en un nodo de WSFC, y WSFC y el nodo deben estar en línea. Además, cada réplica de disponibilidad de un determinado grupo de disponibilidad debe residir en otro nodo del mismo WSFC. La única excepción es que mientras se migra a otro WSFC, un grupo de disponibilidad puede ocupar temporalmente dos clústeres.

Grupos de disponibilidad AlwaysOn se basa en el Clúster de conmutación por error de Windows Server (WSFC) para supervisar y administrar los roles actuales de las réplicas de disponibilidad que pertenecen a un grupo de disponibilidad concreto, así como para determinar cómo afecta un evento de conmutación por error a las réplicas de disponibilidad. Por cada grupo de disponibilidad que cree, se creará un grupo de recursos de WSFC. El WSFC supervisa este grupo de recursos para evaluar el estado de la réplica principal.

El cuórum para Grupos de disponibilidad AlwaysOn se basa en todos los nodos del WSFC independientemente de si un nodo de clúster determinado hospeda alguna réplica de disponibilidad. A diferencia de la creación de reflejo de la base de datos, no hay ningún rol de testigo en los grupos de disponibilidad Always On.

Los votos de cuórum de nodos del clúster determinan el estado general de un WSFC. Si el WSFC se queda sin conexión debido a un desastre no planeado, o a un error persistente de hardware o de comunicaciones, se necesita la intervención manual del administrador. Un administrador de Windows Server o de WSFC tendrá que forzar un cuórum y volver a poner en línea los nodos del clúster superviviente en una configuración sin tolerancia a errores.

Importante

Las claves del Registro de Grupos de disponibilidad AlwaysOn son subclaves del WSFC. Si elimina y vuelve a crear un WSFC, tendrá que deshabilitar y volver a habilitar la característica de Grupos de disponibilidad AlwaysOn en cada instancia de SQL Server que hospedaba una réplica de disponibilidad en el WSFC original.

Para obtener información sobre cómo ejecutar SQL Server en nodos del clúster WSFC y sobre el cuórum de WSFC, vea Clústeres de conmutación por error de Windows Server con SQL Server.

Instancias de clúster de conmutación por error (FCI) de SQL Server y grupos de disponibilidad

Puede configurar un segundo nivel de conmutación por error en el nivel de instancia de servidor si implementa SQL Server y FCI junto con el WSFC. Una instancia independiente de SQL Server o una instancia de FCI puede hospedar una réplica de disponibilidad. Solo un asociado de FCI puede hospedar una réplica para un grupo de disponibilidad dado. Cuando una réplica de disponibilidad se ejecuta en una instancia de clúster de conmutación por error (FCI), la lista de posibles propietarios del grupo de disponibilidad contendrá solo el nodo de FCI activo.

Los grupos de disponibilidad AlwaysOn no dependen de ninguna forma de almacenamiento compartido. Sin embargo, si usa una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una o varias réplicas de disponibilidad, cada una de las FCI requerirá almacenamiento compartido según la instalación típica de la instancia de clúster de conmutación por error de SQL Server.

Para obtener más información sobre los requisitos previos adicionales, consulte Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn (SQL Server).

Comparación de instancias de clúster de conmutación por error y grupos de disponibilidad

Independientemente del número de nodos de la FCI, una FCI completa hospeda una sola réplica en un grupo de disponibilidad. En la tabla siguiente se describen las diferencias conceptuales entre los nodos en una FCI y las réplicas en un grupo de disponibilidad.

Nodos en una FCI Réplicas en un grupo de disponibilidad
Usa WSFC Sí Sí
Nivel de protección Instancia Base de datos
Tipo de almacenamiento Compartido No compartidos

Aunque las réplicas de un grupo de disponibilidad no comparten el almacenamiento, una réplica hospedada por una FCI usa una solución de almacenamiento compartido según lo requiera esa FCI. La solución de almacenamiento es compartida solo por los nodos en la FCI y no entre las réplicas del grupo de disponibilidad.
Soluciones de almacenamiento Se adjuntan directamente, SAN, puntos de montaje, SMB Depende del tipo de nodo
Réplicas secundarias legibles No* Sí
Opciones aplicables de la directiva de conmutación por error Quórum de WSFC

Específico de FCI

Configuración de grupo de disponibilidad**		 Quórum de WSFC

Configuración de grupos de disponibilidad
Recursos conmutados por error Servidor, instancia y base de datos Solo base de datos

*Mientras que las réplicas secundarias sincrónicas de un grupo de disponibilidad siempre se ejecutan en sus respectivas instancias de SQL Server, los nodos secundarios de una FCI realmente no han iniciado sus respectivas instancias de SQL Server y, por lo tanto, no son legibles. En una FCI, un nodo secundario inicia la instancia de SQL Server cuando la propiedad del grupo de recursos se le transfiere durante una conmutación por error de FCI. Sin embargo, en el nodo FCI activo, cuando una base de datos hospedada por FCI pertenece a un grupo de disponibilidad, la base de datos se puede leer si la réplica de disponibilidad local se ejecuta como una réplica secundaria legible.

**La configuración de la política de conmutación por error del grupo de disponibilidad es aplicable a todas las réplicas, ya sea que estén alojadas en una instancia independiente o en una instancia de FCI.

Consideraciones para hospedar una réplica de disponibilidad en una FCI

Importante

Si planea hospedar una réplica de disponibilidad en una instancia de clúster de conmutación por error (FCI) de SQL Server, asegúrese de que los nodos host de Windows Server 2008 cumplen los requisitos previos y restricciones de AlwaysOn para las instancias de clúster de conmutación por error (FCI). Para más información, consulte Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn (SQL Server).

Las instancias de clúster de conmutación por error (FCI) de SQL Server no admiten la conmutación automática por error de grupos de disponibilidad, por lo que cualquier réplica de disponibilidad alojada por un FCI solo se puede configurar para la conmutación por error manual.

Es posible que tenga que configurar un WSFC para incluir discos compartidos que no están disponibles en todos los nodos. Por ejemplo, considere un WSFC en dos centros de datos con tres nodos. Dos de los nodos hospedan una FCI de SQL Server en el centro de datos principal y tienen acceso a los mismos discos compartidos. El tercer nodo hospeda una instancia independiente de SQL Server en un centro de datos diferente y no tiene acceso a los discos compartidos desde el centro de datos principal. Esta configuración de WSFC admite la implementación de un grupo de disponibilidad si la FCI hospeda la réplica principal y la instancia independiente hospeda la réplica secundaria.

Al elegir una FCI para hospedar una réplica de disponibilidad para un grupo de disponibilidad determinado, asegúrese de que una conmutación por error de FCI no podría provocar que un único nodo WSFC intente hospedar dos réplicas de disponibilidad para el mismo grupo de disponibilidad.

El escenario de ejemplo siguiente muestra cómo podría producir problemas esta configuración:

  • Configure un WSFC con dos nodos, NODE01 y NODE02.
  • Se instala una instancia de clúster de conmutación de SQL Server, fciInstance1, tanto en NODE01 como en NODE02, donde NODE01 es el propietario actual de fciInstance1.
  • En NODE02, se instala otra instancia de SQL Server, , Instance3que es una instancia independiente.
  • En NODE01, se habilita fciInstance1 para grupos de disponibilidad Always On. En NODE02, se habilita Instance3 para grupos de disponibilidad Always On. A continuación, configurará un grupo de disponibilidad para el que fciInstance1 hospeda la réplica principal y Instance3 hospeda la réplica secundaria.
  • En algún momento, fciInstance1 deja de estar disponible en NODE01 y el WSFC provoca una conmutación por error de fciInstance1 a NODE02. Después de la conmutación por error, fciInstance1 es una instancia habilitada para Grupos de disponibilidad AlwaysOnque se ejecuta en el rol principal de NODE02. Sin embargo, Instance3 reside ahora en el mismo nodo de WSFC que fciInstance1. Esto infringe la restricción de Grupos de disponibilidad AlwaysOn .

Para corregir el problema que presenta este escenario, la instancia independiente, Instance3, debe residir en otro nodo del mismo WSFC que NODE01 y NODE02.

Para obtener más información sobre las FCI de SQL Server, vea Instancias de clúster de conmutación por error AlwaysOn (SQL Server).

Restricciones sobre el uso del Administrador de WSFC con grupos de disponibilidad

No use el Administrador de clústeres de conmutación por error para manipular grupos de disponibilidad. Por ejemplo:

  • No agregue ni quite recursos en el servicio en clúster (grupo de recursos) para el grupo de disponibilidad.

  • No modifique ninguna propiedad del grupo de disponibilidad, como los posibles propietarios y los propietarios preferidos. El grupo de disponibilidad establece automáticamente estas propiedades.

  • No use el Administrador de clústeres de conmutación por error para mover grupos de disponibilidad a distintos nodos o para conmutar por error los grupos de disponibilidad. El Administrador de clústeres de conmutación por error no tiene conocimiento del estado de sincronización de las réplicas de disponibilidad, lo que puede provocar un tiempo de inactividad prolongado. Debe usar Transact-SQL o SQL Server Management Studio.

Advertencia

El uso del Administrador de clústeres de conmutación por error para mover una instancia de clúster de conmutación por error que hospeda un grupo de disponibilidad a un nodo que ya hospeda una réplica del mismo grupo de disponibilidad puede provocar la pérdida de la réplica del grupo de disponibilidad, lo que impide que se conecte en el nodo de destino. Un único nodo de un clúster de conmutación por error no puede alojar más de una réplica para el mismo grupo de disponibilidad. Para obtener más información sobre cómo se produce y cómo recuperarlo, consulte el blog Réplica eliminada inesperadamente en el grupo de disponibilidad.

Contenido relacionado

  • Last updated on