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

Grupos de disponibilidad AlwaysOn, la solución de alta disponibilidad y recuperación ante desastres introducida en SQL Server 2014 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.

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

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

Los Grupos de Disponibilidad Always On se basan en el clúster de conmutación por error de Windows (WSFC) para supervisar y administrar los roles actuales de las réplicas de disponibilidad que pertenecen a un grupo de disponibilidad determinado y 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 clúster de WSFC supervisa este grupo de recursos para evaluar el estado de la réplica principal.

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

El estado general de un clúster de WSFC viene determinado por los votos del cuórum de nodos del clúster. Si el clúster de WSFC se desconecta debido a un desastre no planeado o debido a un error persistente de hardware o comunicaciones, se requiere la intervención administrativa manual. Un administrador de clústeres de Windows Server o WSFC tendrá que forzar un cuórum y, a continuación, volver a poner los nodos de clúster supervivientes en línea en una configuración no tolerante a errores.

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

Migración entre clústeres de grupos de disponibilidad AlwaysOn para la actualización del sistema operativo

A partir de SQL Server 2012 SP1, los grupos de disponibilidad AlwaysOn admiten la migración entre clústeres de grupos de disponibilidad para implementaciones en un nuevo clúster de clústeres de conmutación por error de Windows Server (WSFC). Una migración entre clústeres mueve un grupo de disponibilidad o un lote de grupos de disponibilidad al nuevo clúster WSFC de destino con un tiempo de inactividad mínimo. El proceso de migración entre clústeres permite mantener los contratos de nivel de servicio (SLA) al actualizar a un clúster de Windows Server 2012. SQL Server 2012 SP1 (o una versión posterior) debe estar instalado y habilitado para AlwaysOn en el clúster WSFC de destino. El éxito de una migración entre clústeres depende de la planeación y preparación exhaustivas del clúster WSFC de destino.

Para obtener más información, consulte Migración entre clústeres de grupos de disponibilidad AlwaysOn para la actualización del sistema operativo.

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

Puede configurar una segunda capa de conmutación por error en el nivel de instancia de servidor mediante la implementación de clústeres de conmutación por error de SQL Server junto con el clúster de 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.

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, vea 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 AlwaysOn (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.

*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.

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

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 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 tenga que configurar un clúster de conmutación por error de Windows Server (WSFC) para incluir discos compartidos que no estén disponibles en todos los nodos. Por ejemplo, considere un clúster de WSFC en dos centros de datos con tres nodos. Dos de los nodos hospedan una instancia de clústeres 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 del clúster 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 clúster de 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 Always On. En NODE02, habilita Instance3 para Grupos de Disponibilidad Always On. 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 NODE01y el clúster de 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 Always On que se ejecuta bajo el rol principal en NODE02. Sin embargo, Instance3 reside ahora en el mismo nodo de WSFC que fciInstance1. Esto infringe la restricción de los Grupos de disponibilidad Always On.
Para corregir el problema que presenta este escenario, la instancia independiente, Instance3, debe residir en otro nodo del mismo clúster de WSFC que NODE01 y NODE02.

Para obtener más información sobre los clústeres de conmutación por error de SQL Server, consulte Instancias de clúster de conmutación por error AlwaysOn (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.

Contenido relacionado

• Blogs:

  Configurar el clúster de conmutación por error de Windows para SQL Server (grupo de disponibilidad o FCI) con seguridad limitada

  Blogs del equipo alwaysOn de SQL Server: blog oficial del equipo alwaysOn de SQL Server

  Blogs de los ingenieros de SQL Server de CSS

• Notas del producto:

  Guía de arquitectura de AlwaysOn: Creación de una solución de alta disponibilidad y recuperación ante desastres mediante instancias de clúster de conmutación por error y grupos de disponibilidad

  Guía de soluciones AlwaysOn de Microsoft SQL Server para alta disponibilidad y recuperación ante desastres

  Notas del producto de Microsoft para SQL Server 2012

  Notas del producto del equipo de asesoramiento al cliente de SQL Server

Véase también

Introducción a 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 AlwaysOn (SQL Server)