Always On Availability Groups (AG) es una funcionalidad avanzada de SQL Server que proporciona alta disponibilidad, recuperación ante desastres y replicación. Tradicionalmente, esta tecnología se implementa utilizando Windows Server Failover Cluster (WSFC). Sin embargo, existe una alternativa que elimina la dependencia de WSFC, simplificando la infraestructura en ciertos entornos y adaptándose mejor a escenarios específicos. En este artículo, y a raíz de una petición vuestra en un comentario a uno de mis videos en youtube, os explicaré cómo configurar AG en Windows sin cluster, sus características, limitaciones y casos de uso, además de los scripts necesarios para su administración.
Introducción a Always On sin WSFC
La configuración de Always On sin WSFC, también conocida como grupos de Disponibilidad de Escala de Lectura (Read-Scale Availability Groups, RSAG), es ideal en entornos donde no es posible o necesario implementar un cluster. Esta arquitectura, disponible desde SQL Server 2017, permite que las réplicas de SQL Server funcionen de manera independiente, conectándose directamente entre sí para mantener la sincronización de los datos. A diferencia de la configuración tradicional, no existe una gestión centralizada del Quórum ni un mecanismo de failover automático. En su lugar, los DBA asumimos un papel activo en la supervisión, configuración y administración de los failovers, listeners y otros elementos. Aunque este modelo elimina parte de la complejidad asociada a los clusters, también requiere conocimientos avanzados para garantizar un funcionamiento eficiente y seguro.
Características de Always On sin WSFC
La autonomía de las réplicas es una de las principales características de esta configuración. Cada instancia de SQL Server opera de forma independiente y no depende de un cluster subyacente para coordinar sus roles. El failover, por otro lado, debe realizarse manualmente o mediante scripts personalizados, lo que otorga flexibilidad pero requiere una monitorización constante. Los listeners, que en un entorno con WSFC se configuran automáticamente, aquí deben implementarse manualmente utilizando soluciones externas como balanceadores de carga o DNS, lo que puede agregar complejidad operativa.
En términos de sincronización, esta configuración solo admite el modo asíncrono, lo que prioriza el rendimiento pero, sumado a la falta de balanceo automático, descarta su uso como solución de alta disponibilidad para todos los escenarios. Además, aunque al eliminar la necesidad de WSFC, la infraestructura se simplifica, reduciendo los costes asociados sigue siendo necesario licenciar ambas instancias con una edición Enterprise lo que eleva los costes.
Ventajas y Limitaciones
La eliminación del cluster de Windows en esta configuración aporta beneficios significativos, como la reducción de costes al no requerir licencias adicionales ni configuraciones complejas asociadas a WSFC. Esto hace que sea una solución atractiva para entornos de pruebas y desarrollo. Además, la autonomía de las réplicas facilita la implementación en sistemas más simples, evitando la necesidad de depender de un cluster para mantener la alta disponibilidad.
Sin embargo, esta configuración también tiene limitaciones importantes. La ausencia de un mecanismo de quorum aumenta el riesgo de situaciones de split-brain (ocurre cuando uno o más nodos de un clúster experimentan la desconexión de los otros nodos, lo que resulta en la formación de subclústeres), especialmente en escenarios donde no se monitoriza adecuadamente el estado de las réplicas. Por otro lado, la falta de un listener nativo complica la integración con aplicaciones que dependen de un punto de acceso único para conectarse al nodo activo. La escalabilidad también es más limitada en comparación con un entorno gestionado por WSFC, lo que la hace menos adecuada para infraestructuras complejas o con muchos nodos.
Casos de Uso
Always On sin cluster en Windows es una solución especialmente útil en entornos de pruebas y desarrollo, donde la alta disponibilidad no es crítica pero la replicación de datos es necesaria para realizar simulaciones y validaciones. También es una opción adecuada para aquellos escenarios que no requieren failover automático, pero necesitan una forma de mantener datos sincronizados entre varias instancias para dividir las cargas de trabajo, por ejemplo replicas de solo lectura para análisis en tiempo real.
En sistemas autónomos, donde las réplicas pueden operar independientemente, esta arquitectura también encuentra un buen uso. Asimismo, es una alternativa viable cuando se dispone de soluciones externas avanzadas, como balanceadores de carga o gestión de DNS, que pueden mitigar las limitaciones asociadas a la falta de listeners nativos.
Configuración de Always On sin WSFC
La configuración comienza habilitando Always On en cada instancia de SQL Server desde el Configuration Manager, asegurándose de que las bases de datos estén en modo de recuperación completa. Los endpoints deben configurarse manualmente en cada réplica para permitir la comunicación entre ellas. Una vez configurados los endpoints, se procede a crear el grupo de disponibilidad desde la réplica primaria utilizando T-SQL, definiendo las bases de datos y réplicas participantes, junto con sus modos de sincronización.
En las réplicas secundarias, las bases de datos deben restaurarse en modo de recuperación incompleta (NORECOVERY) antes de añadirlas al grupo de disponibilidad. Finalmente, los listeners deben configurarse manualmente si es necesario, ya sea mediante un DNS dedicado o un balanceador de carga externo, lo que permite redirigir el tráfico al nodo activo.
Gestión y Scripts de Administración
La administración de Always On sin WSFC depende en gran medida de scripts personalizados ya que no dispondremos del dashboard de Always On. Por ejemplo, el estado de sincronización de las réplicas puede verificarse con consultas a las vistas dinámicas sys.dm_hadr_database_replica_states. Además, algunas columnas de esta DMV relacionadas con el clúster pueden mostrar datos sobre un clúster predeterminado interno. Estas columnas son solo para uso interno y se pueden ignorar.
El failover manual, que es una tarea común en esta configuración, se realiza utilizando el comando ALTER AVAILABILITY GROUP … FAILOVER. Además, tras un failover, es necesario reanudar las bases de datos en la nueva réplica primaria con el comando ALTER DATABASE … SET HADR RESUME.
Conclusión
Always On Availability Groups sin cluster en Windows es una alternativa poderosa para entornos específicos, especialmente aquellos donde los costes o la complejidad de WSFC no son aceptables. Aunque su implementación y administración requieren habilidades avanzadas y mayor supervisión, esta configuración ofrece flexibilidad y simplicidad en infraestructura, siendo especialmente adecuada para entornos de pruebas, desarrollo y réplicas de solo lectura. Sin embargo, su uso en producción debe evaluarse cuidadosamente, teniendo en cuenta sus limitaciones en términos de Quórum, failover automático y escalabilidad.
Con una correcta planificación y monitorización, esta arquitectura puede proporcionar una solución eficaz para mantener datos sincronizados en escenarios específicos. Si se implementa correctamente, Always On sin cluster puede ser un recurso invaluable para arquitecturas modernas y simplificadas.
Te invito a seguirnos en el canal de YouTube donde pronto trataré de mostrar la configuración paso a paso de este tipo de Always On.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
