Resumen

  • Los incidentes de Cloud Storage del 8 y 9 de octubre sumaron 18 horas y 11 minutos en us-central1 y us-central1-b; los síntomas publicados se concentraron en las escrituras.
  • Google atribuye el primer episodio a una optimización de enrutamiento que eludió la lógica sensible a la capacidad, y la recurrencia a una reversión incompleta; no identifica clientes ni cuantifica pérdidas.

Una caída de almacenamiento en la nube suele plantearse como una pregunta sobre dónde se guardan las copias. El informe de Google apunta a otra: ¿por qué ruta pasa una solicitud de escritura antes de convertirse en un objeto almacenado? El 8 de octubre, los clientes de Cloud Storage que utilizaban us-central1 sufrieron más latencia y errores de escritura durante 12 horas y 30 minutos. El problema reapareció al día siguiente en la zona us-central1-b durante 5 horas y 41 minutos. Google suma 18 horas y 11 minutos, pero fueron dos episodios con una recurrencia, no una interrupción continua de 18 horas.

Los síntomas que publicó Google son concretos. Los clientes observaron sobre todo respuestas HTTP 503 UNAVAILABLE en operaciones WriteObject y tiempos de espera agotados en el cliente; las escrituras que sí concluían tardaban más. El informe final afirma que las otras regiones de Cloud Storage y los demás servicios de Google Cloud no resultaron afectados por este evento concreto. Una sección preliminar mencionaba un efecto menor en las lecturas, aunque el resumen final de impacto no lo cuantifica.

Por tanto, el registro respalda una descripción acotada de un problema en la ruta de escritura de una región y, durante la recurrencia, de una zona. No demuestra que todos los clientes de la región estuvieran afectados, que fallaran todas las escrituras ni que se perdieran objetos almacenados.

Google sitúa el primer desencadenante en un cambio de configuración de clasificación del tráfico, pensado para abordar restricciones locales de capacidad. La optimización eludió la lógica habitual de enrutamiento que tiene en cuenta la capacidad. Una pequeña fracción de los nodos de almacenamiento con poca capacidad de servicio recibió una parte desproporcionada del tráfico de escritura. Esos nodos agotaron sus recursos; los servicios de ingestión de objetos empezaron a agotar el tiempo de espera; y las solicitudes dirigidas a ellos se ralentizaron o no se completaron.

Un problema aparte de la base de datos añadió errores en el procesamiento de metadatos durante parte del primer episodio. Es una cadena causal por capas: una decisión de balanceo cambió la distribución de solicitudes, concentró la carga y coincidió con un fallo secundario de metadatos.

La recurrencia del día siguiente es la parte más reveladora del registro operativo. Google la atribuye a una reversión incompleta de una función de planificación de cargas, que rompió el balanceo y sobrecargó nodos de almacenamiento más pequeños. La primera mitigación no había restaurado por completo el estado de seguridad anterior. Esto no demuestra que toda reversión sea poco fiable ni que se produjera una caída regional más amplia. Sí muestra por qué el cierre del incidente y el estado real de la configuración son cosas distintas: el servicio puede parecer recuperado mientras un cambio residual deja abierta la misma vía de fallo.

El relato de recuperación también contiene un límite que los operadores deberían considerar. Google intentó primero añadir capacidad de emergencia, pero dice que los límites regionales de capacidad lo impidieron. Los ingenieros drenaron tráfico de los nodos sobrecargados, desactivaron o revirtieron la optimización, retiraron una actualización distinta de la base de datos y redirigieron tráfico. Cuando la carga y el uso se estabilizaron, los nodos drenados volvieron al servicio.

La capacidad adicional no siempre es una salida de emergencia; el enrutamiento, el aislamiento del tráfico y la precisión de las reversiones pueden ser los controles disponibles cuando una región no puede crecer de inmediato.

La arquitectura publicada de Cloud Storage ayuda a encuadrar el incidente sin exagerarlo. Google dice que un bucket regional almacena los datos de forma redundante en al menos dos zonas de la región elegida. Los buckets birregionales y multirregionales replican entre regiones de forma asíncrona después de que la escritura inicial se almacena en una región y en dos zonas. Google describe el servicio automático desde otra región durante una caída regional para esas ubicaciones más amplias, aunque advierte que la replicación es asíncrona. La documentación de consistencia dice que un objeto escrito correctamente se puede leer de inmediato.

Estos documentos no establecen qué ubicaciones de bucket usaban los clientes afectados.

La distinción es importante. El informe no dice que fallara la replicación multirregional, que se perdieran datos o que dejaran de estar disponibles las copias geográficas. Documenta un cuello de botella en la ruta que acepta nuevas escrituras. La redundancia geográfica puede reducir la exposición a un fallo localizado, pero el diseño también debe considerar los controles de software y capacidad que comparte el servicio de escritura.

La resiliencia del almacenamiento no es una sola propiedad: la durabilidad de las copias, la ingestión correcta, el procesamiento de metadatos, el acceso de lectura y la recuperación de aplicaciones dependen de componentes distintos.

Las medidas preventivas que Google anuncia siguen esa cadena. La empresa dice que probará los cambios de balanceo en regiones más pequeñas antes de desplegarlos en otras grandes y muy utilizadas; que hará cumplir los límites de capacidad para que la lógica de tráfico no eluda las salvaguardas previas de distribución; y que mejorará el movimiento interno de datos en celdas de almacenamiento con mucha carga. Son acciones futuras descritas por Google, no controles cuya finalización se haya verificado de forma independiente.

El registro público no aporta resultados de pruebas, volumen de solicitudes afectadas, nombres de clientes, mezcla de ubicaciones de buckets ni pérdidas medidas. La conclusión útil es más precisa: una optimización de enrutamiento y una reversión incompleta pudieron anular dos veces una salvaguarda local de capacidad, mientras que la cuestión de la redundancia geográfica seguía siendo distinta.

Fuentes: informe final de Google, disponibilidad y durabilidad de Cloud Storage, ubicaciones de buckets, consistencia, estrategia de reintentos.