Base de Datos en una Sola Zona: lo Que el Fallo del 20 de Octubre en Londres Enseña Sobre Alta Disponibilidad
Una zona de Google Cloud en Londres estuvo seis horas sin energía, y también hubo impacto en zonas que no la perdieron. La alta disponibilidad de una base de datos no se prueba en el diseño de la arquitectura: se prueba con un cambio de zona cronometrado.
El 20 de octubre, una zona de Google Cloud en Londres estuvo seis horas y diez minutos sin energía. La red eléctrica falló, las baterías sostuvieron la carga y los generadores no arrancaron. Había dos sistemas de automatización para encenderlos, el principal y el de respaldo. Ninguno de los dos dio la orden.
El caso es el de un centro de datos, pero la pregunta que plantea es de arquitectura: dónde funciona la base de datos principal, y qué ocurre cuando esa zona deja de existir durante toda una mañana.
Qué pasó el 20 de octubre
Según el informe preliminar de Google Cloud, el incidente tuvo lugar en la región europe-west2 (Londres) entre las 07:00 y las 13:10, hora de Londres, con una duración total de 6 horas y 10 minutos. Una falla en la red eléctrica afectó al centro de datos que aloja la zona europe-west2-b. La carga pasó a las baterías mientras arrancaban los generadores diésel.
El sistema de automatización de los generadores, tanto el principal como el de respaldo, no consiguió iniciar la transferencia automática. Cuando se agotaron las reservas de las baterías, los servidores físicos, la red y el almacenamiento local de la zona perdieron energía y quedaron fuera de servicio.
Conviene leer el informe como lo que es: preliminar. El informe final puede cambiar detalles de la causa, y este artículo se actualizará si eso ocurre.
El detalle que importa: el impacto fuera de la zona
El mismo informe dice que algunos clientes con cargas en zonas que no perdieron energía, europe-west2-a y europe-west2-c, también sufrieron impacto. Las causas indicadas fueron picos repentinos de demanda sobre la capacidad de cómputo de las zonas sanas y dependencias de validación del plano de control que cruzan las fronteras entre zonas.
Al mismo tiempo, el informe señala que Cloud SQL, AlloyDB, Memorystore for Redis y Cloud Bigtable pasaron, durante el incidente, a zonas cercanas que no fueron afectadas. Hubo, por tanto, bases de datos que cambiaron de zona y siguieron funcionando.
De aquí se desprenden dos lecturas. La primera es que una réplica en otra zona marca la diferencia. La segunda es que una réplica en otra zona no exime del impacto: cuando una zona cae, las demás reciben la carga que ya no cabe en la primera y comparten servicios de control con ella. Este segundo punto es una lectura de xGrowth a partir del informe, no una conclusión de Google.
Zona, región, proveedor: tres niveles de fallo
Una base de datos puede fallar a tres escalas, y cada una pide una respuesta distinta.
- Fallo de zona. Una zona deja de estar disponible, como en Londres. La respuesta es tener una réplica en otra zona de la misma región y un proceso de promoción probado.
- Fallo de región. Varias zonas, o la región entera, resultan afectadas. La respuesta es tener una réplica en otra región, con el coste y la latencia que eso implica.
- Fallo del proveedor. El problema cruza regiones o está al otro lado del contrato. La respuesta es tener una copia fuera del proveedor, que permita reconstruir el servicio en otro lugar.
El artículo sobre la caída del proveedor cloud y la recuperación ante desastres trata el tercer nivel. Londres obliga a mirar el primero, que es el más frecuente y el más subestimado: una base de datos que funciona en una sola zona no tiene adónde migrar.
Por qué casi nadie prueba
Tener una réplica dibujada en el diagrama no es lo mismo que saber cuánto se tarda en usarla.
El caso de Londres es la versión a gran escala del mismo hábito. Los generadores y los dos sistemas de automatización existían. El informe no dice cuándo se probaron por última vez los controladores, y este artículo no afirma que no se hayan probado. Lo que el informe muestra es que existir y funcionar cuando hace falta son cosas distintas.
Cómo empezar a probar
Una prueba de cambio de zona no exige herramientas nuevas. Exige una ventana y un cronómetro.
Empezar fuera de producción. En una copia del entorno, apagar o aislar la zona donde funciona la base de datos principal.
Cronometrar de principio a fin. Desde el momento en que cae la zona hasta que la aplicación vuelve a atender solicitudes. Ese número, medido y no estimado, es el tiempo de recuperación real (RTO).
Verificar la aplicación. Promover la réplica no basta. La aplicación debe volver a conectarse sola a la nueva base de datos, sin que alguien edite una configuración a las tres de la madrugada.
Anotar lo que falló. Cada sorpresa de la prueba es una corrección que no habrá que descubrir durante un fallo real.
Repetir antes de cada pico de carga. Para el comercio, el próximo es el Black Friday, el 27 de noviembre. Faltan algo más de cuatro semanas, tiempo suficiente para una primera prueba.
Preguntas frecuentes
¿Una réplica en otra zona garantiza que no habrá parada? No. Reduce el riesgo de que la base de datos quede indisponible cuando falla una zona, pero siempre hay un tiempo de promoción, y el informe de Londres muestra que las zonas vecinas también pueden sufrir impacto. La garantía solo existe cuando el tiempo se ha medido.
¿Hace falta una segunda región? Depende de lo que cuesta una hora de parada de cada servicio. Para muchas cargas, una réplica probada en otra zona cubre la mayor parte del riesgo. La segunda región se justifica cuando el coste de un fallo regional supera el coste de mantenerla.
¿Quién debe decidir el cambio de zona? Alguien con autoridad, y un suplente designado, antes del incidente. Un cambio que exige reunir a un comité en mitad de un fallo pierde el tiempo que la réplica debía ahorrar.
Conclusión
El fallo del 20 de octubre afectó a una zona y aun así tuvo consecuencias fuera de ella. La redundancia de la infraestructura existía, pero no funcionó cuando hizo falta. Lo mismo puede ocurrir con una réplica de base de datos que nunca se ha usado a propósito.
Para medir el tiempo real de recuperación de la base de datos principal y preparar la primera prueba de cambio de zona, es posible reservar una Sesión de Orientación, sin compromiso, sobre fiabilidad de sistemas (SRE) y de bases de datos (DBRE).