Tormentas en la Nube

Tormentas en la Nube

Tormenta en la nube

Un espacio donde te contamos historias interesantes de todo lo que puede salir mal en la nube

¡Porque todo anda…hasta que no anda! Entérate qué fue lo que causó la caída de GitHub.

Vamos a inaugurar la sección comentando sobre la reciente caída de GitHub por 24 horas y 11 minutos a fines de Octubre. Como muchas caídas masivas esta empezó, por supuesto, durante un mantenimiento programado que generó un corte (adrede) de CUARENTA Y TRES SEGUNDOS entre dos centros de datos de GitHub, uno en la costa este de EEUU y otro en la costa oeste. Esos 43” desencadenaron una serie de eventos que terminó tirando muchos de sus servicios abajo durante más de un día.

¿Qué fue lo que pasó?

Vamos a hacer una sobre simplificación de lo que está muy bien reportado por ellos mismos, en el artículo post-mortem que publicaron rápidamente en su blog.

GitHub maneja su infraestructura en centros de datos propios, principalmente en 2 locaciones en las costas opuestas de EEUU. Esta distancia, medida en milisegundos de latencia, está en cerca de 60ms. Tienen clústers de MySQL, pero para simplificar imaginemos simplemente que tienen un MySQL Master de un lado, donde realizan todas las operaciones de escritura y desde donde manejan la mayor parte del tráfico para sus servicios, y un MySQL Slave del otro, que les sirve de redundancia y para escalar la capacidad de lectura.

GitHub simplifica su estructura con este gráfico, pero la realidad es un poco más complicada.

 

 

Durante el reemplazo de un equipo de red de 100Gbps, los dos centros de datos dejaron de estar comunicados entre sí por un lapso de 43”. Durante este tiempo, el sistema (Orchestrator) asumió el que MySQL Master estaba caído y reconfiguró rápidamente todos los servicios para que el Slave pasara a comportarse como Master. Es decir, todas las escrituras se derivaron directo hacia allí, junto con todo el tráfico.

Es decir, se sumó un aumento repentino del tráfico más un aumento drástico de la latencia para acceso MySQL (de <1ms dentro del propio centro de datos a 60ms al ir de una costa a otra y vuelta). Por si eso fuera poco, los 43” de escrituras al (viejo) Master no fueron enviadas nunca al (nuevo) Master, por lo cual empezó a escribir información nueva, pero con un “bache” de 43” de datos. Aun habiendo detectado el origen del problema, los ingenieros de GitHub quedaron en una situación compleja: no podían revertir los servicios MySQL a su configuración original (y evitar así la latencia que estaba degradando severamente la performance de sus servicios) ya que los servicios MySQL ya no eran más consistentes entre sí.

¿Qué fue lo que hicieron para resolverlo?

Tomaron una decisión rápida y dura: iban a cortar los servicios por completo y frenar la sangría. Una vez hecho esto, comenzarían la restauración desde los backups más recientes.

Estos backups se hacen de forma rutinaria cada 4 horas, pero están alojados en un servicio externo en la nube, y por esta razón, demoraron varias horas en copiar los terabytes de información a través de Internet. Luego descomprimirlos, comprobarlos e importarlos en los servidores MySQL. Validar consistencia, procesar los diferenciales y sincronizar otra vez los servidores Master-Slave.

24 horas y algunos minutos después GitHub logró restaurar sus servicios. Pero debieron asumir que 954 escrituras “quedaron colgadas” sin ejecutarse durante esa ventana de 43”, que debieron ser ejecutadas manualmente y procesadas una a una. Los ingenieros podrían haber optado por perder esas escrituras y restaurar en mucho menos tiempo el servicio, pero no lo hicieron, y esto es un claro indicador del foco en la integridad de datos que manejan en GitHub.

Teniendo más de 100 millones de repositorios, es interesante conocer a través de estos incidentes, un poco más sobre el funcionamiento interno de las grandes redes y kudos para Microsoft, que habiendo adquirido GitHub recientemente les permitió mantener su independencia y apertura en la información.

Antes de despedirnos, en el enlace al blog de GitHub  linkeado en el comienzo de esta nota, pueden leer en detalle la explicación de lo sucedido, mucho más extensa y sin las simplificaciones reduccionistas de este post.

 

Saludos!

Related Post

LAYOUT

SAMPLE COLOR

Please read our documentation file to know how to change colors as you want

BACKGROUND COLOR

BACKGROUND TEXTURE