Clúster de conmutación por error y grupos de disponibilidad de AlwaysOn (SQL Server)
Grupos de disponibilidad AlwaysOn, la solución de alta disponibilidad y recuperación ante desastres introducida en SQL Server 2012, 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 más información acerca de los conceptos de Grupos de disponibilidad AlwaysOn, vea Información general de los grupos de disponibilidad AlwaysOn (SQL Server).
En este tema:
Clústeres de conmutación por error de Windows Server
Clústeres de conmutación por error de SQL Server
Restricciones en el uso del Administrador de clústeres de conmutación por error de WSFC con grupos de disponibilidad
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 WSFC (clústeres de conmutación por error de Windows Server). Para que una instancia de SQL Server se habilite para Grupos de disponibilidad AlwaysOn, debe residir en un nodo de WSFC y el clúster y el nodo de WSFC 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 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.
Grupos de disponibilidad AlwaysOn se basa en el clúster de Clústeres 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 concreto, y 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 clúster de WSFC supervisa este grupo de recursos para evaluar el estado de la réplica principal.
El quorum para 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 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 quórum de nodos del clúster determinan el estado general de un clúster de WSFC. Si el clúster de 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 clústeres de Windows Server o de WSFC necesitará forzar un quórum y volver a poner en línea los nodos del clúster superviviente en una configuración sin tolerancia a errores.
.gif "Nota importante") Importante |
|---|
Las claves del Registro de Grupos de disponibilidad AlwaysOn son subclaves del clúster de WSFC. Si elimina y vuelve a crear un clúster de WSFC, debe deshabilitar y volver a habilitar la característica Grupos de disponibilidad AlwaysOn en cada instancia de SQL Server que hospedaba una réplica de disponibilidad en el clúster de WSFC original. |
Para obtener información acerca de cómo ejecutar SQL Server en nodos de Clústeres de conmutación por error de Windows Server (WSFC) y sobre el quórum de WSFC, vea Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server.
.gif "Icono de flecha usado con el vínculo Volver al principio")
[Arriba]
Migración entre clústeres de grupos de disponibilidad AlwaysOn para la actualización del sistema operativo
A partir de SQL Server 2012 SP1, Grupos de disponibilidad AlwaysOn admite la migración entre clústeres de grupos de disponibilidad para las 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 de WSFC de destino con un tiempo de inactividad mínimo. El proceso de migración entre clústeres le 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 de WSFC de destino. El éxito de una migración entre clústeres depende de un planeamiento y una preparación exhaustivos del clúster de WSFC de destino.
Para obtener más información, vea Migración entre clústeres de grupos de disponibilidad AlwaysOn para la actualización del sistema operativo.
Instancias de clúster de conmutación por error (FCI) y grupos de disponibilidad de SQL Server
Puede configurar un segundo nivel de conmutación por error en el nivel de instancia de servidor si implementa los 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.
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, vea “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.
Nodos en una FCI |
Réplicas en un grupo de disponibilidad |
|
|---|---|---|
Usa el clúster de WSFC |
Sí |
Sí |
Nivel de protección |
Instance |
Base de datos |
Tipo de almacenamiento |
Compartidos |
No compartidas1 |
Soluciones de almacenamiento |
Se adjuntan directamente, SAN, puntos de montaje, SMB |
Depende del tipo de nodo |
Secundarios legibles |
No2 |
Sí |
Opciones aplicables de la directiva de conmutación por error |
|
|
Recursos conmutados por error |
Servidor, instancia y base de datos |
Solo base de datos |
1Mientras 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.
2Mientras 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.
3La 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 acerca del número de nodos en los clústeres de conmutación por error y los grupos de disponibilidad AlwaysOn en diferentes ediciones de SQL Server, vea 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 con los requisitos previos y las restricciones de AlwaysOn para las instancias de clúster de conmutación por error (FCI). Para obtener más información, vea 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 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 clúster de conmutación por error de Windows Server (WSFC) para incluir los 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ú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 clúster 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 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 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 clúster de WSFC produce 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 AlwaysOn que 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 este escenario produce, 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, vea Instancias de clúster de conmutación por error de AlwaysOn (SQL Server).
[Arriba]
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 del servicio clúster (grupo de recursos) para el grupo de disponibilidad.
No cambie las propiedades de ningún grupo de disponibilidad, como los posibles propietarios y los propietarios preferidos. Estas propiedades son establecidas de forma automática por el grupo de disponibilidad.
No use el Administrador de clústeres de conmutación por error para pasar grupos de disponibilidad a nodos diferentes o para conmutar por error 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 ello puede provocar el incremento del tiempo de inactividad. Debe usar Transact-SQL o SQL Server Management Studio.
[Principio]
Contenido relacionado
**Blogs: **
Blogs del equipo de AlwaysOn de SQL Server: el blog oficial del equipo de AlwaysOn de SQL Server
**Notas del producto: **
Notas del producto de Microsoft para SQL Server 2012
Notas del producto del equipo de asesoramiento al cliente de SQL Server
[Arriba]
Vea también
Conceptos
Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
Habilitar y deshabilitar grupos de disponibilidad de AlwaysOn (SQL Server)
Supervisar grupos de disponibilidad (Transact-SQL)
Instancias de clúster de conmutación por error de AlwaysOn (SQL Server)