Cloud Edición diaria
CLOUD AZURE
Azure obliga a elegir: dos zonas bastan a veces, tres sólo cuando el servicio lo exige
La resiliencia zonal no es una casilla que se marca para toda la aplicación. Microsoft propone decidir componente a componente, con dos zonas cuando cumplen el objetivo y tres cuando la arquitectura, el quórum o el servicio administrado lo requieren.
La recomendación más útil publicada esta semana por Microsoft no es desplegar siempre en tres zonas, sino dejar de tratar la resiliencia como una propiedad uniforme. Una aplicación bancaria puede combinar una base de datos administrada con réplica síncrona, máquinas virtuales zonales, un balanceador regional y servicios que todavía no ofrecen el mismo patrón en todas las regiones. Cada componente tiene su propio modo de fallo. Por eso la pregunta correcta no es cuántas zonas usa la aplicación, sino qué ocurre con cada camino crítico cuando desaparece una de ellas.
Azure distingue entre recursos zone-redundant, cuya distribución y conmutación administra el proveedor, y recursos zonales, fijados a una ubicación concreta. En el segundo caso, el cliente debe crear las réplicas, repartir tráfico, detectar el fallo, conservar capacidad y ejecutar la recuperación. Dos instancias en dos zonas pueden satisfacer un objetivo modesto si cualquiera de ellas soporta toda la carga y el balanceador retira la que falla. Pero la misma pareja es insuficiente cuando una actualización, una avería previa o el mantenimiento reducen la capacidad disponible.
La tercera zona es especialmente valiosa para sistemas con quórum. Permite mantener mayoría mientras una zona se pierde y otra réplica atraviesa una operación de mantenimiento o una degradación. También facilita separar réplicas de lectura, nodos de control y capacidad de recuperación. Sin embargo, no es gratis: añade cómputo, almacenamiento, tráfico entre zonas, más observabilidad y una matriz de pruebas mayor. En cargas sensibles a la latencia, la distribución puede penalizar escrituras síncronas. En otras, el servicio administrado decide internamente la topología y el cliente no controla todos los detalles.
La tercera zona aporta margen, pero también coste, latencia y más estados de fallo
El marco práctico empieza por el impacto, no por el diagrama. Para cada componente hay que fijar RTO y RPO, dependencia de datos, capacidad mínima y comportamiento de las sesiones. Después se comprueba si el servicio está disponible en la región elegida, si permite selección de zona, si la réplica es síncrona o asíncrona y qué SLA contractual aplica. Una arquitectura que sobrevive técnicamente pero pierde más datos de los permitidos, agota conexiones o necesita una hora de intervención manual no cumple el objetivo aunque siga dibujada en verde.
También conviene evitar que la palabra zona oculte el riesgo regional. Las zonas son grupos separados de centros de datos con energía, refrigeración y red independientes, pero siguen perteneciendo a una región. Un error de configuración, una dependencia global, una actualización defectuosa o un incidente regional puede atravesar ese límite. Las cargas de misión crítica necesitan decidir además si requieren otra región, cómo replicarán secretos y datos, quién autoriza la conmutación y cuánto tiempo pueden operar lejos de su ubicación primaria.
La factura debe modelarse durante el fallo. Si una zona desaparece, las restantes tienen que absorber tráfico sin depender de una ampliación inmediata que quizá no consiga capacidad. Reservas, discos replicados, direcciones, gateways y transferencia interzonal forman parte del coste real. La tentación de ahorrar dejando las réplicas pequeñas produce una resiliencia de escaparate. La alternativa tampoco es triplicar todo: dos zonas pueden ser razonables para componentes sin quórum, con recuperación rápida y capacidad N+1 demostrada; tres se reservan para estados distribuidos o tolerancias más exigentes.
La conclusión operativa es incómoda y saludable: no existe un número mágico. El equipo debe construir una tabla por componente, asignar propietario, ejecutar fallos controlados y registrar la evidencia. Hay que vigilar la disponibilidad regional de los servicios, la evolución del agente de resiliencia de Azure, todavía en vista previa, y cualquier cambio en precios o SLA. La arquitectura madura no presume de tres zonas; puede explicar por qué eligió dos o tres, cuánto cuesta esa decisión y qué prueba reciente demuestra que la aplicación sigue funcionando cuando una de ellas deja de estar disponible.
Etiquetas
- Azure
- zonas de disponibilidad
- Resiliencia
- FinOps
- arquitectura cloud
BOLDERROR Edición diaria Rubén Campoy