Configuración de grupos de alta disponibilidad siempre activos en SQL Server

En este artículo, lo guiaremos a través de una guía paso a paso sobre cómo instalar y configurar grupos de disponibilidad Always On en SQL Server que se ejecuta en Windows Server 2019, discutir escenarios de conmutación por error y algunos otros Temas relacionados.

Los grupos de disponibilidad siempre activos brindan alta disponibilidad en Microsoft SQL Server. Always On apareció en la versión de MSSQL 2012.

Características de los grupos de disponibilidad siempre activos en SQL Server

¿Para qué puede usar los grupos de disponibilidad de SQL Server?

• MS SQL de alta disponibilidad y conmutación por error automática;

• Equilibrio de carga de consultas SELECT entre nodos (las réplicas secundarias pueden ser legibles);

• Copia de seguridad desde réplicas secundarias;

• Redundancia de datos. Cada réplica conserva copias de la base de datos del grupo de disponibilidad.

Always On se basa en Windows Server Failover Cluster (WSFC). WSFC supervisa los nodos del grupo de disponibilidad y proporciona conmutación por error automática. A partir de MS SQL Server 2017, Always On se puede usar sin WSFC y también en hosts Linux. Al crear un clúster basado en Linux, puede usar Pacemaker en lugar de WSFC.

Always On está disponible en la edición Standard, pero tiene algunas restricciones:

• Está limitado a 2 réplicas (primaria y secundaria);

• La réplica secundaria no se puede utilizar para leer datos;

• La réplica secundaria no se puede utilizar para realizar una copia de seguridad de MS SQL;

• Solo se admite 1 base de datos por grupo de disponibilidad.

No hay restricciones en la edición Enterprise.
Consideremos los términos.

• Always On Availability Group es un conjunto de réplicas y bases de datos;

• Réplica es una instancia de SQL Server en el grupo de disponibilidad. Una réplica puede ser primaria o secundaria. Cada réplica puede contener una o más bases de datos.

Siempre activado se basa en WSFC. Cada nodo del grupo de disponibilidad debe ser miembro de un clúster de conmutación por error de Windows. Cada instancia de SQL Server puede tener varios grupos de disponibilidad. Cada grupo de disponibilidad puede tener hasta 8 réplicas secundarias.

Si falla una réplica principal, el clúster votará por una nueva réplica principal y Always On convertirá una de las réplicas secundarias en principal. Dado que los usuarios se conectan al Listener (una dirección IP de clúster especial y el nombre DNS correspondiente) cuando trabajan con Always On, será posible ejecutar consultas de escritura nuevamente. El Listener también es responsable de equilibrar las consultas SELECT entre las réplicas secundarias.

Configurar el clúster de conmutación por error de Windows para el grupo de disponibilidad AlwaysOn

En primer lugar, debemos configurar un clúster de conmutación por error en todos los nodos utilizados por Always On.

Aquí está mi configuración:

• 2 máquinas virtuales que ejecutan Windows Server 2019

• 2 instancias de SQL Server 2019 Enterprise

• Los nombres de host de los nodos son testnode1 y testnode2. Los nombres de las instancias de SQL Server son nodo1 y nodo2.

Agregue el rol Failover Clustering usando el Administrador del servidor o instálelo a través de PowerShell:

Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

La instalación es automática y no necesitas configurar nada todavía. Ejecute el complemento Failover Cluster Manager (

FailoverClusters.SnapInHelper.msc

) y cree un nuevo clúster.

Agregue los nombres de los hosts que desea unir a su clúster.

Luego, el mago se ofrece a realizar algunas pruebas. Para hacerlo, seleccione el primer elemento.

Especifique el nombre del clúster, seleccione una red y una dirección IP del clúster. El nombre del clúster aparecerá en DNS automáticamente; no necesita crear un registro DNS manualmente. En mi caso, el nombre del clúster es ClusterAG.

Desmarque las opciones Agregar todo el almacenamiento elegible al clúster ya que podemos agregar discos más tarde.

Solo hay dos nodos en el clúster, por lo que debe configurar Cluster Quorum. El Quórum del Grupo es un voto de calidad. Por ejemplo, si uno de los nodos del clúster deja de estar disponible, el clúster debe detectar qué nodos están realmente en línea y pueden verse entre sí. El Quórum del clúster proporciona consistencia del clúster (Cluster -> More Actions -> Configure Cluster Quorum Settings).

Seleccione la opción de testigo de quórum.

A continuación, seleccione el tipo de testigo: un testigo de recurso compartido de archivos.

Especifique una ruta UNC a la carpeta compartida. Cree el directorio usted mismo. Debe estar presente en un servidor fuera de su clúster de conmutación por error.

Cuando configura su clúster, es posible que vea el siguiente error:

There was an error configuring the file share witness. Unable to save property changes for File Share Witness. The system cannot find the file specified.

Es probable que una cuenta de usuario, bajo la cual se ejecuta el clúster, no tenga permisos NTFS para acceder a la carpeta compartida. De forma predeterminada, el clúster se ejecuta con una cuenta de usuario local. Puede otorgar privilegios en la carpeta a todos los equipos del clúster o cambiar la cuenta del servicio de clúster y otorgarle los privilegios correspondientes.

La configuración básica del clúster de conmutación por error de Windows ha terminado.

Configuración del grupo de disponibilidad AlwaysOn en MS SQL Server

Después de la instalación típica de la instancia de SQL Server, puede habilitar y configurar los grupos de disponibilidad AlwaysOn. Habilítelos en las propiedades de la instancia de Administrador de configuración de SQL Server. Como puede ver en la captura de pantalla, SQL Server ya ha detectado que pertenece a un clúster WSFC. Marque Habilitar grupos de disponibilidad siempre activos y reinicie el servicio de instancia de MSSQL. Haz lo mismo para la segunda instancia.

Ejecute SQL Server Management Studio, conéctese a su host, haga clic en Siempre en alta disponibilidad y ejecute el Asistente para nuevo grupo de disponibilidad.

Especifique un nombre para su grupo de disponibilidad Always On y seleccione Detección de estado de nivel de base de datos. Con esta opción, Always On podrá detectar cuándo una base de datos no está en buen estado.

Seleccione las bases de datos de SQL Server para agregarlas a su grupo de disponibilidad Always On.

Haga clic en Agregar réplica y conecte el segundo servidor SQL. Por lo tanto, puede agregar hasta 8 servidores.

• Rol inicial es un rol de réplica en el momento en que se crea un grupo. Puede ser Primaria o Secundaria;

• Failover automático: si una base de datos deja de estar disponible, Always On moverá la función principal a otra réplica. Marque este artículo;

• Modo de disponibilidad permite seleccionar Confirmación síncrona o Confirmación asíncrona. Si selecciona un modo síncrono, las transacciones que lleguen a la réplica principal se enviarán a todas las demás réplicas secundarias con el modo síncrono. La réplica principal finaliza la transacción solo después de que otras réplicas la hayan escrito en el disco. Por lo tanto, se elimina la pérdida de datos si falla la réplica principal. En el modo asíncrono, la réplica principal escribe los cambios inmediatamente sin esperar la respuesta de otras réplicas.

• Readable Secondary es un parámetro que permite ejecutar consultas SELECT en las réplicas secundarias. Si el valor es sí, los clientes podrán obtener acceso de solo lectura incluso si se conectan sin

  ApplicationIntent=readonly

• Réplicas secundarias sincronizadas requeridas para confirmar es el número de réplicas secundarias sincronizadas para finalizar la transacción. Configúrelo según el número de réplicas, lo configuraré en 1.

No edite nada en la pestaña Punto final.

En la pestaña Preferencias de copia de seguridad, puede seleccionar desde dónde se realizarán las copias de seguridad. Deje la configuración predeterminada aquí: Preferir secundario.

Especifique el nombre, el puerto y la dirección IP del agente de escucha del grupo de disponibilidad.

Deje la configuración de Enrutamiento de solo lectura sin cambios.

Seleccione el tipo de sincronización de réplica. Dejo el primer ítem (Sembrado automático) marcado.

Entonces su configuración debe ser validada. Si no hay errores, haga clic en Finalizar para aplicar los cambios.

En mi caso, todas las pruebas han sido exitosas, pero en el paso Resultados después de la instalación, el asistente mostró un error al crear el grupo de disponibilidad. El error EVENTID 1194 apareció en los registros de eventos del clúster:

Cluster network name resource failed to create its associated computer object in the domain.

Significa que el clúster no tiene suficientes permisos para crear un oyente. La documentación establece que es suficiente otorgar un privilegio para crear objetos de tipo computadora al objeto de su clúster. Es más fácil hacerlo mediante la delegación de privilegios en AD (o una variante rápida, pero insegura, es agregar temporalmente el objeto CLUSTERAG$al grupo de administradores de dominio).

Como creé el grupo de disponibilidad, pero no el oyente, lo agregué manualmente. Abra el menú contextual de su grupo de disponibilidad y haga clic en Agregar agente de escucha.

Especifique la dirección IP, el puerto y el nombre DNS del agente de escucha.

Asegúrate de que el Oyente haya aparecido en la sección Oyentes del grupo de disponibilidad de tu grupo Siempre activo.

Por lo tanto, ha completado la configuración básica de un grupo de disponibilidad Always On.

SQL Server siempre activo: Comprobación de operatividad y conmutación por error

Echemos un vistazo al Panel de grupo de disponibilidad (Mostrar panel).

Está bien, el grupo ha sido creado y está funcionando.

Intentemos hacer que node2 sea una instancia principal manualmente. Haga clic con el botón derecho en el grupo de disponibilidad y seleccione Conmutación por error.

Anote el valor en Failover Readiness. Sin pérdida de datos significa que no se perderán datos.

Conéctese al nodo2.

Haga clic en Finalizar.

Asegúrese de que el nodo 2 se haya convertido en la réplica principal (instancia principal) en el grupo de disponibilidad.

Asegúrese de que el oyente esté funcionando correctamente. Especifique el nombre y el puerto DNS del oyente separados por una coma en el SSMS:

ag1-listener-1,1445

Ejecute consultas SQL sencillas de inserción, selección y actualización en su base de datos.

A continuación, compruebe la conmutación por error automática de la réplica principal. Simplemente elimine el proceso sqlservr.exe en TESTNODE2.

Compruebe el estado del grupo de disponibilidad en el nodo restante: TESTNODE1\NODE1.

El clúster ha cambiado automáticamente el testnode1 estado de ode1 a primario desde testnode2 ode2 dejó de estar disponible.

Verifique el estado del oyente ya que los clientes lo usarán para conectarse.

En mi caso, me conecté con el oyente con éxito, pero al intentar acceder a la base de datos, recibí este error:

Unable to access database 'TestDatabase' because it lacks a quorum of nodes for high availability. Try the operation again later.

El error apareció debido a la opción Secundarios sincronizados requeridos para confirmar. Dado que establecemos su valor en 1 al configurarlo, Always On no permite que se conecte a la base de datos, porque solo nos queda una réplica principal.

Establezca el valor en 0 e intente ejecutar la consulta nuevamente.

Testnode1 mantuvo el estado de instancia principal, mientras que testnode2 se convirtió en secundario. Los datos que cambiamos en testnode1 cuando se apagó testnode2 se sincronizaron correctamente después de encender la computadora.

Por lo tanto, nos hemos asegurado de que todo funcione correctamente y que los datos estén disponibles para lectura/escritura en caso de una falla crítica.

Puede configurar fácilmente grupos de disponibilidad AlwaysOn. Si desea crear una solución de conmutación por error basada en SQL Server, los grupos de disponibilidad la administrarán bien.