Cargas con Estado y Almacenamiento¶
Las aplicaciones sin estado son naturalmente fáciles de distribuir entre regiones. Las aplicaciones con estado exigen que la ubicación del dato se trate como parte de la arquitectura — un volumen que existe en una región no está automáticamente disponible en las demás.
El cómputo puede distribuirse. El dato exige una estrategia de disponibilidad compatible con esa distribución.
Movilidad de cómputo ≠ ubicación del dato¶
Esta es la distinción central de cualquier arquitectura multi-región:
| Cargas sin estado | Cargas con estado | |
|---|---|---|
| Dónde se ejecutan | Cualquier zona con capacidad | Donde está el dato |
| Cómo se recuperan | Nueva réplica en otro nodo | Promoción de una réplica con dato consistente |
| Qué necesita saber el planificador | Recursos y distribución | Topología del volumen |
| Costo de equivocarse | Un pod reiniciado | Pérdida o divergencia de datos |
Kubernetes usa la información de topología del almacenamiento para impedir que una carga inicie en una región donde su volumen no existe. Eso es protección, no limitación: una base que arranca sin su dato es peor que una base que no arranca.
La replicación es responsabilidad de la tecnología de datos¶
Para que una aplicación sobreviva a la pérdida completa de una región, la replicación debe hacerla la propia aplicación o la tecnología de almacenamiento — cada región mantiene su almacenamiento, y quien entiende el dato controla la replicación.
Tecnologías que operamos en este modelo:
- bases relacionales replicadas — MySQL y PostgreSQL;
- bases distribuidas con escritura local en varias regiones — CockroachDB;
- plataformas de cola y streaming — Kafka;
- búsqueda y análisis — Elasticsearch / OpenSearch, ClickHouse;
- plataformas de almacenamiento con replicación regional.
Replicación continua, no transferencia de emergencia
El error clásico es suponer que, si la región cae, los datos se copiarán a la otra. Mover volúmenes grandes por la WAN después de que la región ya falló no es un plan de continuidad. La replicación debe estar corriendo antes del incidente.
Alta disponibilidad de cargas con estado¶
Cuando la aplicación debe sobrevivir a la pérdida de una región, el arreglo mínimo es un primario en una región y una réplica en la otra, cada una con su propio almacenamiento — por ejemplo, PostgreSQL en br-sp-1 replicando hacia br-sp-2, o un primario en InteSys replicando hacia una nube pública.
Según la tecnología, la replicación y la elección de líder quedan a cargo de la aplicación, del motor de base de datos o de la plataforma de almacenamiento. Lo que no cambia son los requisitos que la arquitectura debe cumplir:
- quórum con número impar de votantes;
- elección de líder determinista;
- fencing del primario antiguo antes de cualquier promoción;
- prevención de split-brain ante una partición de red;
- monitoreo de lag — una réplica que se quedó atrás en silencio no es una réplica.
El detalle por tecnología — modos de replicación, RPO de cada arreglo, secuencia de failover — está en la sección de Administración de Bases de Datos.
La copia de seguridad sigue siendo obligatoria¶
La replicación entre regiones cubre fallos de infraestructura. No cubre DROP TABLE, un despliegue con error, corrupción lógica ni ransomware — esos se replican fielmente a todas las réplicas, en segundos.
Por eso, incluso en una arquitectura multi-región, el clúster lleva copia de seguridad con restauración probada y recuperación a un punto en el tiempo, almacenada fuera de los nodos que protege.
Soberanía de datos¶
Una topología entre br-sp-1 y br-sp-2 mantiene el dato primario, las réplicas, los logs y las copias dentro de Brasil, bajo jurisdicción brasileña y sin transferencia internacional de datos personales.
Cuando la arquitectura incluye una región fuera del país, eso pasa a ser una decisión de cumplimiento — documentada en el diseño de la solución, limitada a lo que realmente necesita salir, y nunca un valor por defecto de la plataforma.
Páginas Relacionadas¶
- Multi-Región y Multi-Cloud — Planificación por topología y balanceo global
- Modelos de Despliegue — Dónde pueden estar los workers
- Replicación — Modos, topologías y el RPO de cada uno
- Recuperación ante Desastres — RPO, RTO, failover y failback
- Copias de Seguridad y Restauración — PITR y restauración probada