El caos del segundo de ajuste (leap second bug)
Hoy me di cuenta que los sitios que acostumbro a visitar en la web (Reddit, FourSquare, LinkedIn, Google, Gawker y StumbleUpon entre otros) estaban lentos y en algunos casos retornaban errores 500 aleatoriamente.
La raíz de este problema puede variar mucho entre una pagina y otra pero el factor común es el Segundo de Ajuste o Segundo Bisiesto introducido a todos los relojes atómicos. El segundo se introdujo la noche del 30 de Junio justo antes de la media noche para estar sincronizados con la rotación de la tierra.
Este “Segundo de Ajuste” consintió en esperar un segundo adicional justo antes de cambiar a Julio 1ero 00:00 (UTC) y muchos de los sistemas que periódicamente actualizan su fecha y hora desde servidores NTP tuvieron problemas manejando este cambio, esto sumado con que algunas webs tienen paste de su infraestructura en la nube de Amazon que apenas se están recuperando de una falla eléctrica ocasionada el día anterior no hace sino empeorar la situación.
El leap second bug no estaba en el kernel
Por experiencia propia puedo asegurar que la mayoría de estos sitios no se vieron afectados por negligentes, todos hicieron pruebas, parcharon el kernel o actualizaron, en algunos casos se hicieron pruebas sacando servidores del pool y artificialmente se le indujo este cambio meses antes de la desastrosa noche del 29 de Junio.
¿Si se hicieron todas estas pruebas, por que fallaron hoy? la respuesta tiene que ver con una serie de factores que sucedieron al mismo tiempo. Trare de explicarlos de forma muy generalizada.
- Amazon cloud aun no estaba 100% recuperada.
- Muchos sitios web no pueden probar estos cambios con el trafico de producción.
- Nadie se imagino que algo aparte del kernel pudiese verse afectado.
Como lo mencione anteriormente muchas de estas webs tienen servicios que dependen del Amazon Cloud y esta no estaba 100% recuperada por lo que asumo que algunos estarían corriendo con menos instancias de las que deberían confiándose que era un fin de semana. Esto trae como consecuencia mas carga para las instancias que están activas y el resto de la infraestructura relacionada con estos nodos.
Algunos sitios suelen hacer pruebas de carga usando sistemas que general el trafico artificialmente y aunque se ha avanzado mucho para simular e incluso grabar y repetir el trafico de un determinado momento, no todos los sistemas se pueden probar de esta forma por corrupción de data y de haberlos probado de esta forma no hay forma en que pudiesen predecir el patrón de trafico de anoche.
Muchos asumieron que seria solo el sistema operativo el que se vería afectado y trabajaron arduamente en esto para evitar un kernel panic o algún otro comportamiento errático. DevOps y dueños de servicios revisaron sus apps y el código en producción para asegurarse que nada se fuese a ver afectado por esta espera de un segundo pero siempre hay algo que se pasa por alto o que no falla si no es bajo alta carga y circunstancias especificas como fue el caso con la mayoría de los sitios que corrían servicios con Java.
El problema va mas allá una simple app, no se trata de que si estuvieran usando Ruby y Rails esto no hubiese pasado pues Hadoop y Cassandra dependen de Java también. La mayoría de estas webs tienen por lo menos sus cimientos enlazados a Java.
¿Quienes se vieron afectados?
Como lo mencione anteriormente, todos los servicios que corran Java se vieron afectados Hadoop, Cassandra y Elasticsearch fueron algunos de los sistemas que ocasionaron que la carga del CPU se fuera a las nubes en sitios web como FourSquare, Yelp, LinkedIn, Gawker, StumbleUpon, Reddit, Mozilla, Facebook y algunos servicios de Google entre otros.
El leap second bug o el bug del segundo de ajuste azota la internet justo cuando la nube se esta recuperando, los resultados fueron desastrosos.
Aparte de Java, me llego un rumor de que algunas versiones de Ubuntu Server -que francamente no se quien usaría ubuntu en producción- tenían un bug en el Kernel relacionado con el “Leap Second Bug”
La solución al leap second bug o segundo de ajuste
Nada bueno surge del pánico y decisiones aceleradas pero por ahora algunas versiones de Java requieren que se ejecute este comando que fácilmente se puede hacer vía puppet:
/etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date
Otras versiones de Java solo requieren que se reinicie el servicio, lo que algunos conocemos como un “rolling restart” donde se reinicia en una maquina, se espera unos segundos y se pasa a reiniciar el servicio en otra maquina hasta que se completen todos lo que funciona para la mayoría de los servicios pero quizás no sea tan fácil para aquellos que tienen el bug en Cassandra o Hadoop donde una reiniciada puede tomar varias decenas de minutos.
El caos del segundo de ajuste (leap second bug) es un articulo de: orvtech.com
