Resumen
- Una actualización de configuración de red de Google Cloud interrumpió los clústeres extendidos (stretched clusters) de VMware Engine en Sídney, Melbourne y Fráncfort durante casi 12 horas.
- Los servicios de cómputo y almacenamiento siguieron estando disponibles, pero la pérdida de conectividad entre las zonas de los clústeres y el testigo (witness) aisló a algunas máquinas virtuales.
El incidente
Una actualización de configuración de red de Google Cloud interrumpió los clústeres extendidos de VMware Engine en Sídney, Melbourne y Fráncfort el 14 de julio. El incidente duró 11 horas y 46 minutos. Google restableció el servicio revirtiendo la configuración a la última versión válida conocida.
Google declaró que el cómputo y el almacenamiento parecieron seguir disponibles, pero la conectividad entre las zonas de los clústeres falló. Las zonas afectadas también perdieron la conexión con el dispositivo testigo (witness appliance), lo que impidió que los clústeres sincronizaran su estado de manera segura. Algunas máquinas virtuales quedaron aisladas y corrieron el riesgo de quedarse sin datos de escritura. Google aconsejó a los clientes consultar al servicio de soporte antes de migrar las cargas de trabajo afectadas al lado sano del clúster.
Evaluación
El incidente afectó a los clientes que utilizan clústeres extendidos para mantener la alta disponibilidad entre zonas. El cómputo y el almacenamiento continuaron funcionando, pero fallaron las conexiones de red y de testigo necesarias para coordinar los clústeres. Para los equipos de nube y de continuidad de negocio de las empresas, esto significó que las cargas de trabajo podían seguir activas mientras el sistema encargado de mantener ambos lados sincronizados ya no operaba con normalidad.
Los clústeres extendidos de VMware Engine ubican los nodos de datos en dos zonas y utilizan un testigo en una tercera zona. Una vez que se perdió la conectividad entre ellos, algunas máquinas virtuales quedaron aisladas y corrieron el riesgo de perder el acceso a los datos de escritura. Google recomendó migrar las cargas de trabajo afectadas al lado sano siempre que fuera posible, pero también instó a los clientes a consultar al servicio de soporte debido a los riesgos de fallo en la conmutación (failover) y a la incertidumbre sobre el estado de la zona secundaria.
Por lo tanto, la recuperación dependió tanto del diseño del clúster como de la respuesta operativa de Google.
Para los lectores de BTW, la distribución de cargas de trabajo entre zonas no independiza cada parte del servicio. Los clientes siguen dependiendo de la red del proveedor y del servicio de testigo para mantener esas zonas funcionando como un único clúster. Los planes de continuidad deben contemplar la pérdida de esta ruta de comunicación, incluyendo cómo migrar las cargas de trabajo y cuándo se requiere la asistencia del soporte del proveedor.
Qué vigilar
Esté atento al informe final de Google sobre la causa raíz, los cambios en sus controles de actualización de red y cualquier directriz de recuperación revisada para fallos que afecten a la conectividad entre zonas o al testigo.