Crear un servidor SQL Server redundado en tiempo real involucra implementar una solución de alta disponibilidad que asegure la continuidad del servicio ante fallos de hardware, software o de red.

Existen varias estrategias que puedes considerar, incluyendo Clúster de Failover (FCI), Grupos de Disponibilidad Always On (AG), y la Réplica de Datos Log (Log Shipping). Aquí te explico los pasos generales para configurar una solución de alta disponibilidad usando Grupos de Disponibilidad Always On, que es una de las opciones más robustas para lograr redundancia en tiempo real.

Configurar una solución de alta disponibilidad utilizando Grupos de Disponibilidad Always On (AG) en SQL Server es una excelente manera de asegurar que tus bases de datos estén constantemente disponibles y protegidas contra fallos. Aquí te presento una guía general de los pasos necesarios para configurar esta solución:

1. Requisitos previos

– SQL Server Edition: Asegúrate de tener SQL Server Enterprise Edition, ya que los Grupos de Disponibilidad Always On son una característica de esta edición.
– Sistema Operativo: Es recomendable utilizar una versión de Windows Server que soporte Clústeres de Failover.

• Windows Server 2019: Incluye mejoras en áreas como el rendimiento, la escalabilidad y la seguridad. Windows Server 2019 también introdujo características como los Clústeres de Failover sin dominio, que permiten una mayor flexibilidad en escenarios de nube híbrida y multi-nube.
• Windows Server 2022: Esta versión continúa con las mejoras en seguridad, con características como el cifrado HTTPS y TLS 1.3 habilitados por defecto. Los Clústeres de Failover en Windows Server 2022 ofrecen mejoras en la escalabilidad y la fiabilidad, además de soportar nuevas tecnologías como Azure Arc para la administración de servidores híbridos.

Para las versiones Standard y Datacenter de estas ediciones, los Clústeres de Failover están disponibles y ofrecen una amplia gama de funcionalidades, aunque algunas características avanzadas pueden estar limitadas a la edición Datacenter.

Es importante tener en cuenta que cada nueva versión de Windows Server generalmente introduce mejoras en los Clústeres de Failover, por lo que se recomienda revisar la documentación específica de la versión que estás considerando para obtener detalles sobre las capacidades y requisitos exactos. Además, asegúrate de cumplir con todos los requisitos de hardware y software para configurar un Clúster de Failover correctamente, incluyendo configuraciones de red y almacenamiento compatibles.

– Clúster de Failover de Windows Server (WSFC): Necesitarás configurar un WSFC con todos los nodos que planeas incluir en tu solución de alta disponibilidad.

2. Preparar el entorno de SQL Server

– Instalar SQL Server: Instala SQL Server en todos los nodos que serán parte del grupo de disponibilidad.
– Configurar Instancias de SQL Server: Asegúrate de que cada instancia pueda comunicarse con las demás a través de la red.

3. Habilitar Grupos de Disponibilidad Always On

– Habilitar la característica: Ve al SQL Server Configuration Manager y habilita la característica de Grupos de Disponibilidad Always On en las propiedades del servicio de SQL Server.
– Reiniciar el servicio: Después de habilitar esta característica, es necesario reiniciar el servicio de SQL Server.

4. Configurar el Clúster de Failover de Windows

– Validar la configuración del clúster: Utiliza el Asistente de Validación de Clústeres para asegurarte de que tu configuración cumple con los requisitos necesarios.
– Crear el clúster: Utiliza el Administrador de Clústeres de Failover para crear el clúster, añadiendo todos los nodos que formarán parte del mismo.

5. Crear un Grupo de Disponibilidad Always On

– Crear el Grupo de Disponibilidad: En SQL Server Management Studio (SSMS), conecta a la instancia que hospedará la réplica primaria, navega a «Always On High Availability» > «New Availability Group Wizard».
– Configurar el Grupo de Disponibilidad: Sigue los pasos del asistente para nombrar tu grupo de disponibilidad, seleccionar las bases de datos para incluir, y configurar las réplicas y opciones de sincronización de datos.

6. Configurar las Réplicas de Disponibilidad

– Añadir Réplicas: Añade las instancias de SQL Server que actuarán como réplicas secundarias y configura las opciones de sincronización de datos, failover automático y políticas de backup.
– Configurar Listeners: Configura un Listener del Grupo de Disponibilidad para permitir a los clientes conectarse al grupo de disponibilidad mediante un único punto de acceso.

 7. Validar la Configuración

– Realizar Pruebas de Failover: Realiza pruebas de failover manual para asegurarte de que el sistema se comporta como se espera en caso de un fallo.
– Monitorear el Grupo de Disponibilidad: Utiliza las herramientas de monitoreo de SQL Server y del Clúster de Failover de Windows para supervisar el estado y el rendimiento de tu solución de alta disponibilidad.

Consideraciones Finales

– Revisar la Documentación Oficial: Siempre es recomendable revisar la documentación oficial de Microsoft para obtener detalles específicos y recomendaciones actualizadas.
– Considerar el Licenciamiento: Ten en cuenta las implicaciones de licenciamiento al utilizar características de alta disponibilidad en SQL Server.

Configurar Grupos de Disponibilidad Always On puede ser complejo, pero seguir estos pasos te ayudará a establecer una sólida solución de alta disponibilidad para tus bases de datos SQL Server.

Sobre conexión desde un cliente

Cuando usas los Grupos de Disponibilidad Always On de SQL Server, la conexión desde un cliente, independientemente del lenguaje de programación, se maneja de manera transparente a través del «oyente» del grupo de disponibilidad. Este oyente es una dirección de red virtual (VNN) que proporciona un punto de acceso único a los clientes, sin importar cuál réplica del grupo de disponibilidad está actuando como primaria en ese momento. Esto significa que tu cadena de conexión en la aplicación cliente apuntará al oyente, y no directamente a una instancia específica de SQL Server.

Uso del DSN para la Conexión

DSN (Data Source Name) es un nombre de origen de datos que almacena la información de conexión necesaria para acceder a una base de datos. Si estás utilizando un DSN para conectarte a SQL Server, deberás configurarlo para que utilice el nombre del oyente del grupo de disponibilidad como el servidor en la cadena de conexión.

Aquí hay un ejemplo general de cómo podrías configurar y utilizar un DSN para conectarte a un grupo de disponibilidad Always On en SQL Server:

1. Configuración del DSN: Dependiendo del sistema operativo y el entorno, la configuración del DSN puede variar. Por lo general, en Windows, puedes usar el Administrador de Orígenes de Datos ODBC para crear un nuevo DSN, seleccionando el driver apropiado para SQL Server y especificando el nombre del oyente del grupo de disponibilidad como el servidor en la configuración del DSN.

2. Cadena de Conexión en la Aplicación:
– Ejemplo en C# (usando ODBC):

En c#

– Ejemplo en Python (usando pyodbc):
«`python

En estos ejemplos, `myDsnName` es el nombre del DSN que configuraste, que debe apuntar al oyente del grupo de disponibilidad. `myUsername` y `myPassword` son tus credenciales de autenticación para la base de datos.

 Consideraciones Importantes

– Transparente para la Aplicación: La belleza de usar el oyente del grupo de disponibilidad es que la failover y la conmutación entre réplicas primarias y secundarias son transparentes para la aplicación. La aplicación simplemente se conecta al DSN configurado sin preocuparse de qué servidor está actualmente activo como primario.
– Configuración de Seguridad: Asegúrate de configurar adecuadamente la seguridad y los permisos tanto en el servidor SQL Server como en el DSN para proteger el acceso a los datos.
– Pruebas de Failover: Es recomendable realizar pruebas de failover para asegurar que tu aplicación maneja correctamente la reconexión y continúa operando sin interrupciones en caso de fallo de la réplica primaria.

Utilizar un DSN que apunta al oyente del grupo de disponibilidad simplifica la gestión de las conexiones de base de datos en aplicaciones que utilizan SQL Server Always On, facilitando una alta disponibilidad y una recuperación ante desastres más robusta.

Caso práctico

Para configurar un Grupo de Disponibilidad Always On (AG) en SQL Server con dos máquinas llamadas «palentino» y «palentino2«, sigue estos pasos generales.

Esta configuración asume que ya tienes SQL Server instalado en ambas máquinas y que ambas están bajo el mismo dominio de Windows. Además, asegúrate de que ambas máquinas tengan acceso de red entre ellas y cumplan con los requisitos para Always On AG, incluido el sistema operativo compatible y las ediciones de SQL Server.

Paso 1: Preparativos

– Asegúrate de que ambos servidores, «palentino» y «palentino2», tienen SQL Server instalado con el mismo nivel de actualización.
– Configura la comunicación de red entre ambos servidores y verifica que pueden comunicarse entre sí.
– Prepara un testigo de quórum si decides utilizar uno para el clúster de Windows Server Failover Clustering (WSFC), aunque esto es opcional para un entorno de dos nodos.

 Paso 2: Configurar Windows Server Failover Clustering (WSFC)

1. En «palentino» y «palentino2»:
– Instala la característica de Clustering de Failover a través del Administrador del Servidor o PowerShell.
– Configura los nombres y las direcciones IP que serán usadas por el clúster.

2. Crear el Clúster:
– Utiliza el Administrador de Clústeres de Conmutación por Error para crear un nuevo clúster. Incluye ambos servidores, «palentino» y «palentino2», en el clúster.
– Realiza las pruebas de validación recomendadas y crea el clúster.

 Paso 3: Habilitar Always On Availability Groups

1. En SQL Server Configuration Manager en ambos servidores, habilita la característica «Always On Availability Groups».
2. Reinicia el servicio SQL Server en ambos nodos.

 Paso 4: Configurar el Grupo de Disponibilidad Always On

1. En «palentino» (que actuará como el servidor primario inicialmente):
– Abre SQL Server Management Studio (SSMS) y conecta a la instancia de SQL Server.
– En el Explorador de Objetos, haz clic derecho en «Always On High Availability» > «New Availability Group Wizard».
– Sigue el asistente para crear el nuevo grupo de disponibilidad. Asigna un nombre al grupo de disponibilidad, por ejemplo, «AG_Palentino».
– Selecciona las bases de datos para incluir en el grupo de disponibilidad. Las bases de datos deben estar en modo de recuperación completa.
– Especifica «palentino2» como réplica secundaria y configura las opciones de sincronización de datos. Para alta disponibilidad, selecciona «Synchronous commit».
– Configura un oyente para el grupo de disponibilidad si es necesario, lo que facilita la conexión de las aplicaciones al grupo de disponibilidad.

2. Validar la Configuración:
– Completa el asistente y revisa la configuración. SQL Server Management Studio configurará el grupo de disponibilidad en ambos servidores.

Paso 5: Validar y Probar el Entorno de AG

– Realizar un Failover Manual: Prueba el failover manualmente para asegurarte de que funciona como se espera. En SSMS, puedes hacer esto haciendo clic derecho en el grupo de disponibilidad y seleccionando «Failover».
– Conexión a través del Oyente (si configuraste uno): Asegúrate de que las aplicaciones cliente pueden conectarse al grupo de disponibilidad usando el nombre del oyente.

Paso 6: Monitoreo y Mantenimiento

– Monitorea el estado de salud del grupo de disponibilidad y las réplicas regularmente a través de SSMS.
– Planifica y realiza mantenimientos periódicos, asegurándote de aplicar parches y actualizaciones de manera coordinada para evitar incompatibilidades.

Este es un resumen general de los pasos para configurar un Grupo de Disponibilidad Always On entre dos servidores, «palentino» y «palentino2».

Ten en cuenta que los pasos específicos pueden variar dependiendo de tu versión de SQL Server y la configuración exacta de tu entorno. Es crucial referirse a la documentación oficial de Microsoft SQL Server y realizar pruebas exhaustivas antes de implementar en un entorno de producción.

En un Clúster de Failover, si un servidor (nodo) falla o se «cuelga», el sistema está diseñado para que otro servidor del clúster asuma automáticamente las responsabilidades del servidor caído. Este proceso se conoce como «failover». El objetivo de un Clúster de Failover es garantizar la alta disponibilidad de las aplicaciones y servicios críticos, minimizando el tiempo de inactividad y manteniendo la continuidad del negocio.

Necesidad de un Grupo Always On

Un Grupo de Disponibilidad Always On (AG) en SQL Server entra en juego en varias situaciones críticas para asegurar la alta disponibilidad y la protección de datos de las aplicaciones y bases de datos. Aquí detallo algunas de las circunstancias más comunes:

1. Fallo en la Réplica Primaria
Cuando la réplica primaria de un Grupo de Disponibilidad sufre un fallo, ya sea por problemas de hardware, de red o del sistema operativo, el mecanismo de failover automático o manual se activa para trasladar las operaciones a una de las réplicas secundarias designadas. Esto asegura una interrupción mínima del servicio.

2. Mantenimiento Programado
Durante el mantenimiento programado de la infraestructura de TI, como actualizaciones de hardware o software en la réplica primaria, se puede realizar un failover manual a una réplica secundaria para mantener la disponibilidad del servicio. Una vez completado el mantenimiento, se puede revertir el proceso, trasladando las operaciones de vuelta a la réplica primaria.

3. Balanceo de Carga de Lectura
Los Grupos de Disponibilidad Always On también se pueden utilizar para balancear la carga de lectura entre las réplicas primarias y secundarias. Esto es especialmente útil en entornos con grandes volúmenes de consultas de lectura, donde dirigir parte de estas operaciones a las réplicas secundarias puede ayudar a mejorar el rendimiento general del sistema.

4. Recuperación ante Desastres
En el caso de un desastre que afecte el centro de datos principal, como un incendio, inundación o un fallo de energía masivo, los AG permiten una rápida recuperación al permitir que una réplica secundaria en una ubicación geográfica diferente tome el rol de réplica primaria, minimizando así el tiempo de inactividad y la pérdida de datos.

5. Pruebas de Conmutación por Error (Failover)
Para garantizar que el sistema de alta disponibilidad funciona correctamente, las organizaciones realizan pruebas de conmutación por error. Estas pruebas implican realizar un failover manual a una réplica secundaria para verificar que el proceso y los mecanismos de recuperación funcionan como se espera.

6. Cumplimiento de Objetivos de Nivel de Servicio (SLAs)
Las empresas que tienen objetivos de nivel de servicio estrictos en términos de tiempo de inactividad y pérdida de datos pueden utilizar los AG para cumplir con estos requisitos, garantizando que las bases de datos estén disponibles y protegidas contra fallos.

Los Grupos de Disponibilidad Always On son una herramienta poderosa dentro de SQL Server para asegurar que las aplicaciones y los datos críticos permanezcan disponibles y seguros ante una amplia variedad de escenarios adversos.