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

  • Artículo

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 Grupos de disponibilidad AlwaysOn no depende de los clústeres de conmutación por error de SQL Server , se puede utilizar una instancia de clústeres de conmutación por error (FCI) para hospedar una réplica de disponibilidad para un grupo de disponibilidad. Es importante conocer el rol de cada tecnología de clústeres y saber qué consideraciones son necesarias cuando se diseña el entorno de Grupos de disponibilidad AlwaysOn .

Nota

Para obtener información sobre los conceptos de grupos de disponibilidad Always On, consulte Información general de los grupos de disponibilidad Always On (SQL Server).

Grupos de disponibilidad y clústeres de conmutación por error de Windows Server

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 testigo en Grupos de disponibilidad AlwaysOn.

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 de WSFC y sobre el cuórum de WSFC, consulte Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server.

SQL Server Instancias de clúster de conmutación por error (FCI) 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 réplica de disponibilidad se puede hospedar en una instancia independiente de SQL Server o una instancia de FCI. 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.

Grupos de disponibilidad AlwaysOn no depende 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 la sección «Requisitos previos y restricciones para usar una instancia de clúster de conmutación por error (FCI) de SQL Server para hospedar una réplica de disponibilidad» de Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad Always On (SQL Server).

Comparación de las instancias de clúster de conmutación por error y los 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

Mientras que las réplicas de un grupo de disponibilidad no comparten almacenamiento, una réplica hospedada por una FCI usa una solución de almacenamiento compartido de acuerdo con 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 se ejecutan siempre en las instancias respectivas de SQL Server , los nodos secundarios de una FCI no han iniciado realmente las instancias respectivas 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 de FCI activo, cuando una base de datos hospedada por FCI pertenece a un grupo de disponibilidad, si la réplica de disponibilidad local se ejecuta como réplica secundaria legible, la base de datos es legible.

**La configuración de la directiva de conmutación por error del grupo de disponibilidad se aplica a todas las réplicas, ya estén hospedadas en una instancia independiente o una instancia de FCI.

Nota

Para obtener más información sobre el número de nodos en FCI y los grupos de disponibilidad Always On en otras ediciones de SQL Server, consulte Características compatibles con las ediciones de SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).

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

Importante

Si tiene previsto 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 de host de Windows Server 2008 cumplen los requisitos previos y las 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).

SQL Server Las instancias de clúster de conmutación por error (FCI) no admiten la conmutación automática por error de grupos de disponibilidad; por lo tanto, todas las réplicas de disponibilidad hospedadas por un FCI solo se pueden configurar para la conmutación por error manual.

Es posible que necesite configurar un WSFC para incluir los 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 instancia de clúster de conmutación por error (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 otro centro de datos 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 puede hacer que un único nodo de 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:

Marcel configura un WSFC con dos nodos, NODE01 y NODE02. Instala una instancia de clúster de conmutación por error de SQL Server , fciInstance1, en NODE01 y NODE02 , donde NODE01 es el propietario actual de fciInstance1.
En NODE02, Marcel instala otra instancia de SQL Server, Instance3, que es una instancia independiente.
En NODE01, Marcel habilita fciInstance1 para Grupos de disponibilidad AlwaysOn. En NODE02, habilita Instance3 para Grupos de disponibilidad AlwaysOn. A continuación, configura un grupo de disponibilidad para el que fciInstance1 hospeda la réplica principal e Instance3 hospeda la réplica secundaria.
En algún momento fciInstance1 deja de estar disponible en NODE01 y el WSFC produce una conmutación por error de fciInstance1 en 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 se presenta en este escenario, la instancia independiente, Instance3, debe residir en otro nodo del mismo WSFC que NODE01 y NODE02.

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

Restricciones en el uso del Administrador de clústeres de conmutación por error 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 cambie las propiedades de los grupos de disponibilidad, como los propietarios posibles 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 los grupos de disponibilidad a otros nodos o para conmutar los grupos de disponibilidad. El Administrador de clústeres de conmutación por error no conoce el estado de sincronización de las réplicas de disponibilidad y hacer esto puede conducir a un tiempo de inactividad extendido. Debe usar Transact-SQL o SQL Server Management Studio.

Advertencia

Si usa el 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, podría provocar la pérdida de la réplica del grupo de disponibilidad, impidiendo que se ponga en línea en el nodo de destino. Un único nodo de un clúster de conmutación por error no puede hospedar más de una réplica para el mismo grupo de disponibilidad. Para más información sobre cómo sucede esto y cómo recuperarse de este problema, eche un vistazo a la entrada de blog Réplica dejada inesperadamente en grupo de disponibilidad.

Contenido relacionado

Consulte también

Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Habilitar y deshabilitar grupos de disponibilidad AlwaysOn (SQL Server)
Supervisar grupos de disponibilidad (Transact-SQL)
Instancias de clúster de conmutación por error de AlwaysOn (SQL Server)