El final del primer y el comienzo del segundo mes del verano de 2019 resultó ser difícil y estuvo marcado por varias caídas importantes en los servicios mundiales de TI. De los más notables: dos incidentes graves en la infraestructura de CloudFlare (el primero, con manos torcidas y actitud descuidada hacia BGP por parte de algunos ISP de EE. UU.; El segundo, con el despliegue torcido de los mismos CF, afectó a todos los que usan CF, y estos son muchos servicios notables) y funcionamiento inestable de la infraestructura CDN de Facebook (afectó a todos los productos de FB, incluidos Instagram y WhatsApp). También tuvimos que pasar a la distribución, aunque nuestra interrupción fue mucho menos notable en un contexto global. Alguien ya ha comenzado a arrastrar helicópteros negros y conspiraciones "soberanas", por lo tanto, estamos publicando una publicación pública de nuestro incidente.
07/03/2019, 16:05Comenzamos a solucionar problemas de recursos, similar a una violación de la conectividad de la red interna. Al no haber verificado completamente todo, comenzaron a fallar en la operabilidad del canal externo en la dirección de la línea de datos, ya que quedó claro que había un problema con el acceso de la red interna a Internet (NAT), hasta el punto de que pusieron la sesión BGP en la dirección de DataLine.
07/03/2019, 16:35Se hizo evidente que el equipo que realizaba la traducción de direcciones de red y el acceso desde la red local del sitio a Internet (NAT) fallaba. Los intentos de reiniciar el equipo no condujeron a nada, la búsqueda de opciones alternativas para organizar la conectividad comenzó antes de recibir una respuesta del soporte técnico, ya que por experiencia esto probablemente no ayudaría.
El problema se agravó un poco por el hecho de que este equipo también terminó las conexiones entrantes de los empleados de VPN del cliente, el trabajo de restauración remota se volvió más difícil de llevar a cabo.
07/03/2019, 16:40Intentamos reanimar un esquema de reserva NAT preexistente que había funcionado antes. Pero quedó claro que varios reequipamientos de la red hicieron que este esquema fuera casi completamente inoperante, ya que su restauración podría no funcionar en el mejor de los casos, y en el peor de los casos, romper el que ya funciona.
Comenzaron a elaborar un par de ideas para transferir el tráfico a un complejo de nuevos enrutadores que sirven a la red troncal, pero parecían inoperantes debido a las peculiaridades de la distribución de rutas en la red central.
07/03/2019, 17:05Al mismo tiempo, se reveló un problema en el mecanismo para resolver nombres en los servidores de nombres, lo que condujo a errores al resolver puntos finales en las aplicaciones; comenzaron a llenar rápidamente los archivos de host con registros de servicios críticos.
07/03/2019, 17:27Restaurada la funcionalidad limitada de Habr.
07/03/2019, 17:43Pero al final, se encontró una solución relativamente segura para organizar el tráfico que pasa a través de uno de los enrutadores fronterizos, que fue rápidamente desarraigado. La conectividad a Internet se ha recuperado.
En los siguientes minutos, los sistemas de monitoreo recibieron muchas notificaciones sobre la restauración de la capacidad de trabajo de los agentes de monitoreo, pero algunos de los servicios resultaron inoperantes, ya que se violó el mecanismo de resolución de nombres en los servidores de nombres (dns).
07/03/2019, 17:52NS se reiniciaron, el caché se restableció. Resolviendo recuperado.
07/03/2019, 17:55Obtuve todos los servicios excepto MK, Freelansim y Toaster.
07/03/2019, 18:02Gana MK y Freelansim.
07/03/2019, 18:07Trajo una sesión de BGP inocente con DataLine.
07/03/2019, 18:25Comenzaron a arreglar bridas en los recursos, se asoció con un cambio en la dirección externa del grupo NAT y su ausencia en la lista de varios servicios, se corrigió rápidamente. Inmediatamente ganado y tostadora.
07/03/2019, 20:30Notamos errores relacionados con los bots de Telegram. Resultó que se olvidaron de registrar la dirección externa en un par de acl (servidores proxy), lo corrigieron rápidamente.
Conclusiones
- El equipo falló, lo que incluso antes de eso había puesto en duda su idoneidad. Había planes para excluirlo del trabajo, ya que interfería con el desarrollo de la red y tenía problemas de compatibilidad, pero al mismo tiempo desempeñaba una función crítica, por lo que cualquier reemplazo no era técnicamente fácil sin la interrupción de los servicios. Ahora puedes seguir adelante.
- Los problemas de DNS se pueden evitar acercándolos a la nueva red troncal fuera de la red NAT y al mismo tiempo con conectividad total a la red gris sin traducción (que se planeó antes del incidente).
- No use nombres de dominio al ensamblar clústeres RDBMS, ya que la conveniencia de cambiar de forma transparente la dirección IP no es particularmente necesaria, ya que, de todos modos, tales manipulaciones requieren el reensamblaje del clúster. Esta decisión está dictada por razones históricas y, en primer lugar, por la obviedad de los puntos finales por nombre en las configuraciones RDBMS. En general, una trampa clásica.
- En principio, se han llevado a cabo ejercicios comparables a la "soberanización de Runet", hay algo en lo que pensar desde el punto de vista del fortalecimiento de las posibilidades de supervivencia autónoma.