Infra

Hay momentos en la vida de un DBA en los que la alta disponibilidad ya no es suficiente. Hemos sobrevivido a clústeres fallidos, a discos compartidos corruptos y a réplicas que se desconectan con la gracia de una llamada de Teams a las 3 de la madrugada. En ese punto, cuando el entorno ya es exigente, el SLA nos aprieta y la palabra «disponibilidad» se queda corta, es cuando entramos en el terreno de los Availability Groups distribuidos.

Y no, no hablamos de tener un par de réplicas en distintas zonas de disponibilidad dentro del mismo centro de datos. Hablamos de desacoplar entornos completos en distintas regiones, con su propio clúster, su propia lógica de failover, y aún así, mantener la sincronización de nuestras queridas bases de datos. Bienvenidos al club.

¿Qué demonios son los AG distribuidos?

Un AG distribuido (Distributed Availability Group, para los amigos) es una especie de “supergrupo” de alta disponibilidad. No estamos montando un único AG con réplicas dispersas. Estamos conectando dos AG independientes como si fueran nodos de un mismo sistema. Y eso lo cambia todo.

Cada uno de los AG que participan en un DAG (sí, también lo llaman así) tiene su propia topología: su clúster de Windows, sus réplicas, su configuración de quórum, su failover automático. Se comportan como entornos autónomos, que además se sincronizan entre sí a través de una réplica intermedia que hace de “puente” entre ambos mundos. ¿El resultado? Podemos tener un AG en Madrid y otro en Dublín, y replicar entre ellos de forma controlada, tolerando fallos completos del entorno primario sin perder la cabeza.

No es magia. Es ingeniería. Y, como todo lo potente, requiere cabeza y experiencia.

Arquitectura de un DAG: dos mundos bien separados

La gracia del AG distribuido es que cada uno de los AG participantes se gestiona por separado. Esto nos da una ventaja brutal en términos de recuperación ante desastres: si uno se cae por completo, el otro puede activarse sin necesidad de que el primero esté en línea. No hay dependencia directa entre ellos, ni a nivel de clúster, ni de quorum, ni de discos compartidos. Cada AG es soberano en su dominio, y eso, en un mundo donde los CPDs pueden arder, es oro puro.

La configuración básica requiere lo siguiente:

• Dos AG independientes, cada uno con su propio clúster de Windows.
• Al menos una réplica en cada AG que actuará como “forwarder” (la que se conecta con el otro AG).
• Comunicación de red directa entre las réplicas forwarders (y permisos adecuados, claro).
• Certificados válidos en ambos entornos si usamos endpoints con autenticación por certificado (spoiler: casi siempre).
• DNS y nombres de servidor que no se pisen entre sí. Si tienes dos réplicas llamadas SQLSRV01 en distintas regiones, vas a llorar.

¿Resultado? Una topología que no depende de un solo clúster de Windows, que permite failover regional controlado, y que puede integrarse perfectamente con estrategias de backup y DR serias.

La sincronización es asíncrona. Y eso está bien

Una pregunta habitual: ¿puedo tener un DAG con sincronización síncrona?

Respuesta corta: no.

Respuesta larga: la sincronización entre los dos AG de un DAG siempre es asíncrona. No es negociable. Y antes de que alguien lo vea como una limitación, recordemos que estamos hablando de replicar entre regiones completas, separadas por cientos o miles de kilómetros. Pedir sincronía aquí es como pedirle baja latencia a una conexión satelital. Lo importante es entender que esto no es para alta disponibilidad de datos en tiempo real, sino para continuidad del negocio ante desastres mayores.

Si necesitamos RPO cero, esto no es para nosotros. Si podemos tolerar unos segundos (o minutos) de pérdida en caso de caída total del entorno primario, entonces un DAG puede ser nuestra mejor baza.

¿Qué se puede hacer con Always On Distribuidos?

Lo primero y más importante: podemos tener una réplica totalmente operativa en otra región, lista para convertirse en nueva primaria si la original cae. Esta réplica puede formar parte de un AG secundario completo, con su propio listener, sus propias réplicas locales, y servir tráfico de lectura si así lo queremos.

Lo segundo: la recuperación ante desastres se convierte en un proceso autónomo. Si se va la luz en todo nuestro entorno primario (sí, ha pasado), podemos activar el AG secundario sin tener que reconstruir el entorno entero o esperar a que vuelva a estar online. Y esto no solo ahorra tiempo: salva el negocio.

Y lo tercero: permite hacer actualizaciones o migraciones sin downtime completo. Podemos preparar todo en el AG secundario, sincronizar, hacer el failover distribuido, y luego ajustar el entorno primario con tranquilidad. Es una forma de reducir riesgos en cambios grandes sin jugar al funambulista con el entorno de producción.

El failover en los AG Distribuidos: aquí mandamos nosotros

Un punto clave en los AG distribuidos es que no hay failover automático entre los dos AG. Esto es deliberado. No estamos hablando de un nodo que se cae por una hora y queremos rebotarlo automáticamente. Estamos hablando de fallos graves, donde lo último que queremos es que el sistema tome decisiones por su cuenta sin entender el contexto.

Por eso, el failover entre AGs distribuidos es manual. Y eso está bien. Podemos automatizarlo con scripts, orquestarlo con herramientas de gestión, y tenerlo documentado al detalle. Pero el botón rojo lo apretamos nosotros, cuando hemos validado que el entorno primario está realmente muerto y no va a levantarse en los próximos 5 minutos.

Una vez hacemos el failover, el AG secundario se convierte en el nuevo primario del DAG. Desde ahí, podemos operar normalmente, restaurar backups, servir peticiones y mantener el negocio en marcha. Cuando el entorno primario vuelva, podremos reintegrarlo en el DAG, pero el proceso no es automático ni trivial. Hay que hacerlo bien, con scripts preparados, sin improvisar.

AG Distribuidos en la nube: promesas, realidades y facturas

Cuando nos movemos a la nube —sea Azure, AWS o cualquier otro proveedor que venda disponibilidad como si fuera pan caliente—, los DAG siguen siendo perfectamente viables, pero el terreno cambia. En Azure, por ejemplo, podemos montar un DAG entre dos regiones usando máquinas virtuales con clústeres de Windows tradicionales o bien utilizando SQL Server en instancias de Azure VM con ILB (Internal Load Balancer) para simular el listener. Lo mismo ocurre en AWS, donde los DAG pueden desplegarse entre zonas de disponibilidad o incluso regiones distintas, aunque allí la gestión de redes, rutas y permisos puede volverse un pequeño infierno si no se domina bien el entorno VPC.

La ventaja clara en la nube es la infraestructura: tenemos latencias razonables entre regiones, almacenamiento redundante, y posibilidad de automatizar el despliegue completo con plantillas (CloudFormation, Terraform u otro, según tus gustos). Pero también hay que tener en cuenta que el coste de mantener dos entornos completos sincronizados no es trivial. Especialmente si se usan discos premium, réplicas activas y tráfico constante entre regiones.

Además, muchos se olvidan de que en la nube no hay testigos compartidos para el quórum, lo que obliga a diseñar bien la lógica de los clústeres para evitar split-brain. Y ojo con los nombres DNS y los certificados: en la nube, los nombres internos de las máquinas cambian, los certificados caducan cuando nadie mira, y el tráfico entre regiones puede requerir ajustes de firewall que no siempre están bien documentados. En resumen: se puede, se debe, pero hay que saber lo que se está haciendo. Porque aquí, equivocarse cuesta dinero. Literalmente.

Otra opción sería tener un AG en local y el distribuido en la nube. De esta manera reducimos costes y tenemos lo mejor de ambos mundos, la infraestructura local controlada y con menor latencia desde nuestra red y la copia segura en la nube replicada casi en tiempo real. Lista para una actuación de emergencia, como ese seguro de viajes que pagas pero deseas no tener que usar nunca.

Cosas que pueden salir mal (y lo harán)

Como todo en SQL Server que involucra clústeres, redes y nombres, hay margen para el desastre elegante. Algunas perlas:

• Si los certificados no están bien configurados en ambos lados, la réplica forwarder no podrá conectar. Y lo descubrirás justo cuando más prisa tengas.
• Si los nombres de los nodos se repiten en ambas regiones, los endpoints fallarán y la sincronización no se iniciará.
• Si los puertos necesarios están bloqueados por firewalls, los AG estarán técnicamente configurados pero no replicarán una coma.
• Si no documentas el proceso de failover, nadie sabrá qué hacer cuando llegue el momento. Especialmente tú, bajo presión.

Por eso, cualquier DAG serio necesita una prueba completa de recuperación. Hay que simular la caída del entorno primario, validar el failover al secundario, probar el listener, comprobar la latencia, y luego revertir. Si no has hecho esto al menos una vez, tu DAG es una promesa. No una solución.

Conclusión

Un AG distribuido no es para todo el mundo. Tiene complejidad, tiene costes y tiene curva de aprendizaje. Pero si lo que queremos es resiliencia real frente a desastres a nivel de región, y si nuestro negocio no se puede permitir estar horas (o días) sin SQL Server, entonces es una de las mejores inversiones técnicas que podemos hacer.

Eso sí: que nadie lo monte “porque queda bien en el diagrama”. Un DAG sin pruebas, sin documentación y sin monitoreo adecuado es una trampa. Pero bien hecho, es una fortaleza. Una que sigue operativa cuando el resto del castillo se cae.

Y en tiempos de incertidumbre, eso vale más que cualquier SLA firmado con letra bonita.

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!