Diagrama de arquitectura de recuperación ante desastres: RPO, RTO y cuatro estrategias

La alta disponibilidad mantiene un sistema en marcha cuando falla un servidor o una zona de disponibilidad. La recuperación ante desastres trata de los fallos grandes: una región entera caída, una base de datos corrupta, una cuenta borrada, un ransomware. El plan para esos casos tiene que existir antes de que ocurran, y la arquitectura decide cuántos datos pierdes y cuánto tiempo estás caído.

Este artículo define los dos números de los que parte todo diseño de recuperación ante desastres (DR), repasa las cuatro estrategias estándar con sus costes y dibuja un warm standby en dos regiones.

RPO y RTO

• Objetivo de punto de recuperación (RPO): cuántos datos puedes permitirte perder, medido en tiempo. Un RPO de 5 minutos significa que es aceptable perder los últimos 5 minutos de escrituras.
• Objetivo de tiempo de recuperación (RTO): cuánto tiempo puede estar caído el servicio antes de volver a funcionar.

Los dos vienen del negocio, no de ingeniería, y los dos cuestan dinero: cada paso hacia cero pérdida de datos y cero caída multiplica la infraestructura y el trabajo de operación. Pregunta cuánto cuesta una hora de caída y qué datos no se pueden recrear, y elige el diseño más barato que cumpla esos números. Las distintas partes de un mismo sistema suelen tener objetivos distintos: el checkout puede necesitar minutos y el almacén de datos de informes, un día.

Cuatro estrategias

El whitepaper de AWS sobre recuperación ante desastres agrupa la DR en cuatro estrategias, ordenadas por coste y velocidad de recuperación. Las mismas ideas se aplican en cualquier nube o en tus propios centros de datos.

Backup and restore reconstruye todo a partir de copias de seguridad y código de infraestructura. Basta para muchos sistemas internos, siempre que la restauración se haya probado y la infraestructura pueda recrearse desde código.

Pilot light mantiene vivos los datos (bases de datos replicadas, buckets replicados), pero deja el cómputo apagado o a cero. Recuperar significa arrancar los servicios y escalarlos.

Warm standby mantiene en marcha una copia pequeña pero funcional. Puede atender tráfico de inmediato con capacidad reducida y escala durante el failover. Como está siempre en marcha, también es fácil de probar.

Activo/activo atiende a los usuarios desde los dos sitios todo el tiempo. El failover es sobre todo un cambio de enrutamiento, pero las escrituras en dos regiones obligan a gestionar conflictos o a un diseño con un solo escritor, y el coste es el de dos entornos de producción.

Elegir para un sistema: un ejemplo

Una tienda online que recibe 2.000 pedidos por hora pide para el checkout un RPO de 5 minutos y un RTO de 30 minutos. Backup and restore no cumple el RPO: los snapshots nocturnos pueden perder un día de pedidos, y reconstruir la pila lleva horas. Pilot light cumple el RPO con la replicación de la base de datos, pero arrancar y calentar los servicios, las cachés y el índice de búsqueda en otra región suele llevar más de 30 minutos la primera vez que alguien lo intenta. Warm standby cumple ambos: la réplica va unos segundos por detrás y los servicios reducidos ya están en marcha, así que el failover consiste en promover, escalar y cambiar el DNS. Activo/activo reduciría aún más el RTO, pero duplica el coste y añade conflictos de escritura que la tienda no necesita resolver. La respuesta: warm standby para el checkout y backup and restore para el almacén de datos de informes.

Las copias de seguridad siguen siendo necesarias

La replicación también copia los errores. Si alguien borra una tabla o un ransomware cifra los datos, la réplica lo sigue en segundos. Guarda copias de seguridad a un punto en el tiempo que la replicación no pueda tocar:

• Snapshots y logs de transacciones conservados durante días o semanas.
• Copias en una cuenta separada, con credenciales distintas, para que una sola cuenta comprometida no pueda borrar ambas.
• Copias inmutables o bloqueadas, donde tu plataforma lo permita.
• Pruebas de restauración periódicas. Una copia que nadie ha restaurado es una esperanza, no una copia de seguridad.

La secuencia de failover

Escribe los pasos y mantenlos cortos:

1. Decidir. Quién puede declarar un desastre y con qué señal. El failover automático de una región entera es arriesgado; muchos equipos automatizan la detección y dejan la decisión en manos de una persona.
2. Promover la réplica de la base de datos de la región de respaldo a principal.
3. Escalar el cómputo en la región de respaldo hasta la capacidad completa.
4. Mover el tráfico cambiando los registros DNS de failover o los pesos del balanceador global. Ten en cuenta los TTL del DNS y los clientes que guardan caché.
5. Verificar con comprobaciones sintéticas y después anunciarlo.
6. Planificar la vuelta. Volver al sitio original es una segunda migración y necesita el mismo cuidado.

El diagrama de arquitectura

Cómo leerlo:

• Arriba: los usuarios llegan al enrutamiento DNS con failover. Hoy envía todo el tráfico a la región principal; la arista discontinua muestra adónde va el tráfico tras el failover.
• Izquierda, la región principal: un balanceador de carga, seis instancias de la aplicación, almacenamiento de objetos y la base de datos principal.
• Derecha, la región de respaldo: la misma forma a menor escala: dos instancias de la aplicación, una réplica alimentada por replicación asíncrona y objetos replicados. Las aristas discontinuas marcan los caminos que solo llevan tráfico tras el failover.
• Abajo: los snapshots diarios van a una bóveda de copias en otra cuenta, la protección frente a la corrupción y el borrado que la replicación no puede dar.
• El bloque Markdown indica los objetivos que debe cumplir el diseño.

Pruebas

Los planes de DR fallan en los detalles: un certificado caducado en la región de respaldo, un endpoint escrito a mano en el código, un secreto que falta, un TTL de DNS de un día. La única solución es ejecutar el failover. Programa simulacros, empieza por un solo servicio y mide el RTO real frente al objetivo. Un warm standby lo hace barato, y esa es una de sus mayores ventajas sobre el pilot light.

Qué poner en un diagrama de DR

• Los dos sitios, con lo que se ejecuta en cada uno y a qué escala.
• Las rutas de replicación y su modo, síncrona o asíncrona, porque eso fija el RPO.
• El conmutador de tráfico, y si es automático.
• Copias de seguridad fuera del radio de impacto, incluido el límite de la cuenta.
• Los objetivos, escritos junto al diseño.

Para la parte de red multirregión, consulta el diagrama de arquitectura multirregión en AWS. El diagrama de replicación de bases de datos explica con más detalle el retraso de replicación y el failover, y el diagrama de flujo de respuesta a incidentes cubre cómo declarar y gestionar el incidente en sí.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade dos marcos Región del pack Nube, uno para la principal y otro para la de respaldo.
3. Dentro de cada uno, añade un Balanceador de carga en la nube, un nodo Instancia de cómputo para la aplicación, un nodo Almacenamiento de objetos y una Base de datos administrada. Pon el número de instancias en las etiquetas.
4. Añade una Persona del pack Modelo C4 y un nodo DNS del pack Red encima de las regiones, y otro nodo Almacenamiento de objetos debajo para la bóveda de copias.
5. Dibuja la replicación entre regiones, haz discontinuos los caminos que solo se usan en el failover y añade un bloque Markdown del pack Básico con el RPO y el RTO.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué diferencia hay entre RPO y RTO? El RPO es cuántos datos puedes perder, medido en tiempo antes del fallo. El RTO es cuánto se tarda en volver a dar servicio después.

¿La alta disponibilidad es lo mismo que la recuperación ante desastres? No. La alta disponibilidad gestiona de forma automática y continua los fallos de componentes y de zonas. La recuperación ante desastres trata eventos mayores, como la caída de una región o la corrupción de datos, a menudo con un failover deliberado.

¿Sigo necesitando copias de seguridad si replico a otra región? Sí. La replicación copia los borrados y la corrupción casi de inmediato. Las copias en una cuenta separada protegen frente a eso.

¿Qué estrategia de recuperación ante desastres debo elegir? La más barata que cumpla el RPO y el RTO que el negocio necesita para ese sistema. El warm standby es un término medio habitual porque es asequible y fácil de probar.

¿Con qué frecuencia debo probar la recuperación ante desastres? Con la suficiente para que el runbook siga siendo cierto: a menudo cada trimestre en los sistemas críticos, y después de cualquier cambio importante de arquitectura.

Empieza gratis — un puesto, sin tarjeta de crédito.