Hablar de alta disponibilidad en entornos SQL Server es como entrar en un congreso de arquitectos y preguntar por el hormigón armado: todo el mundo tiene una opinión, pero no todos entienden lo que hace que no se les caiga el edificio. Desde que apareció Azure SQL Managed Instance, muchos han querido comparar su Failover Group con el clásico y reputado Always On Availability Groups (AO AG) de SQL Server. Spoiler: no son lo mismo. Ni en arquitectura, ni en control, ni en flexibilidad. Y por mucho que Microsoft los presente como soluciones “equivalentes” en diferentes contextos, la verdad está en los detalles. Ahí donde el marketing calla y el diagrama de red grita.
¿Qué es un Failover Group en Azure SQL Managed Instance?
El Failover Group (FOG, para los amigos) en Managed Instance es un servicio de Azure PaaS que nos permite tener una réplica automática en otra región, con conmutación por error (failover) automática o manual. No hay que gestionar clústeres, ni certificados, ni configurar endpoints: todo se cocina dentro de la infraestructura de Azure. ¿Ventajas? Sencillez. ¿Limitaciones? También las hay, pero menos de lo que algunos creen.
El Failover Group actúa a nivel de instancia. Replica automáticamente todas las bases de datos del grupo seleccionado, manteniendo sincronización asincrónica entre regiones. Y aunque históricamente tenía fama de ser unidireccional y sin opciones de lectura secundaria, eso ya no es cierto: podemos habilitar acceso de solo lectura a la réplica secundaria a través del listener. Eso sí, solo una réplica, y nada de topologías a medida. Pero para muchos escenarios de DR, es más que suficiente.
¿Y qué hace SQL Server con su Always On Availability Groups?
Aquí volvemos al SQL Server clásico, el de verdad, el que instalamos en máquinas (físicas o virtuales), con clústeres de Windows, certificados, endpoints, y todo lo que da gusto configurar a las tres de la mañana cuando algo falla. El AO AG es un modelo de alta disponibilidad y recuperación ante desastres (HA/DR) basado en grupos de disponibilidad, con réplicas sincronizadas (para HA) y asincrónicas (para DR). Admite múltiples réplicas, balanceo de lectura, conmutación automática o manual, y una flexibilidad que muchos aún no saben que están mal usando.
¿Requiere trabajo? Mucho. ¿Te da control absoluto? También. Y eso, en infraestructuras exigentes, marca la diferencia entre diseñar alta disponibilidad y simplemente esperar que Azure haga lo suyo.
Diferencias técnicas clave
Aquí es donde empieza lo interesante. El Failover Group en MI está limitado por diseño: solo una réplica secundaria, sincronización asincrónica entre regiones y sin opción a topologías complejas. Pero lo compensa con gestión simplificada, y sí, un listener que permite direccionar tráfico de lectura y escritura de forma bastante transparente. El parámetro ApplicationIntent=ReadOnly funciona como esperamos, siempre que tengamos configurado el grupo correctamente.
AO AG, por su parte, permite hasta ocho réplicas, elegir sincronización o asincronía según la necesidad, distribuir la carga de lectura, gestionar failover policies con precisión quirúrgica y hasta usar clusterless AGs para entornos que no necesitan HA pero sí replicación. También nos permite ajustar los parámetros internos de cada réplica, implementar scripts personalizados ante fallos y mantener una visibilidad completa del estado del clúster.
La diferencia crítica sigue siendo el acceso al entorno. En SQL Server AO AG tienes control del sistema operativo, del almacenamiento, de la red y del motor de base de datos en sí. En Managed Instance estás dentro de una caja cerrada: puedes administrar lo que te dejan, y cuando algo se rompe, dependes completamente del soporte de Azure. Que sí, son majos. Pero a veces el SLA no consuela cuando tienes al CTO respirando en la nuca.
Ventajas y limitaciones prácticas
El Failover Group de Azure Managed Instance es ideal para quienes quieren alta disponibilidad sin complicaciones, sin pelearse con Windows Server Failover Clustering, sin pensar en discos compartidos ni quorum. Y con la posibilidad de lectura secundaria, gana puntos en escenarios de DR que también exigen analítica o reporting en caliente.
AO AG, por su parte, permite arquitecturas híbridas, complejas y a medida. Pero requiere un nivel de experiencia y de mantenimiento que no todos los equipos pueden asumir. No es para todos, pero en manos expertas es una bestia formidable. Eso sí, como toda bestia, necesita cuidado constante y algo de cariño (o miedo). Cuidado con meterte en esta solución tan compleja si tu equipo no está preparado o tendrás el caldo de cultivo perfecto para un problema grave.
¿Qué debemos elegir para nuestro entorno?
La decisión real no es entre Failover Group y Always On, sino entre PaaS y IaaS (o on-premises). Si tu equipo no puede o no quiere gestionar infraestructura, el Failover Group en Azure MI es una solución más que decente. Pero si necesitas múltiples réplicas, balanceo de lectura avanzado, configuración personalizada o integración con entornos complejos… entonces AO AG sigue siendo la referencia.
También hay que mirar la criticidad del sistema. ¿Puedes tolerar unos minutos de pérdida de servicio mientras Azure detecta y conmuta? ¿O necesitas failover inmediato y con cero pérdida de datos? El RPO y RTO no son iguales, y en algunos casos eso marca la diferencia entre continuidad del negocio y justificación al comité de crisis.
Los precios de ambas soluciones también son decisivos, en Azure Managed Instance tienes que pagar todos los meses depende del tamaño de tu servidor y eso a la larga puede salir caro. Always On, por su parte, no se queda corto ya que vas a necesitar licencias SQL Server Enterprise y, eso no es barato precisamente.
Casos reales y decisiones que duelen
Recientemente, en un proyecto de consultoría, el cliente tenía que mover un entorno crítico de Always On a Azure MI. Las restricciones del Failover Group se hicieron evidentes al tercer día, cuando se dieron cuenta de que no podían controlar la latencia ni ajustar parámetros finos de sincronización. ¿Solución? Replantear parte de la arquitectura y asumir limitaciones. ¿Resultado? Un entorno funcional, sí, pero menos flexible. Y con la sensación de haber pasado de un Fórmula 1 a un coche automático: cómodo, sí. Pero que no te deja cambiar de marcha cuando más lo necesitas.
Conclusión
Failover Group en Azure MI no es el sucesor espiritual de Always On. Es una solución distinta, pensada para escenarios distintos. Si necesitas control, flexibilidad y múltiples réplicas, Always On sigue siendo el rey. Si priorizas simplicidad y mantenimiento mínimo, Failover Group cumple su papel. Y ahora, con acceso de lectura en la réplica secundaria, es más potente de lo que muchos creen.
Pero no confundamos comodidad con equivalencia. Porque cuando llegue el fallo, lo que importa no es la tecnología, sino cómo responde. Y en ese momento, más vale haber elegido bien. ¿Quieres alta disponibilidad sin sustos? Elige con cabeza, no con prisas. Porque lo único peor que una base de datos caída… es una mal diseñada que no sabe caer.
