El final del primer y el comienzo del segundo mes del verano de 2019 resultaron difíciles y estuvieron marcados por varias caídas importantes en los servicios globales de TI. Entre los más notables: dos incidentes graves en la infraestructura de CloudFlare (el primero, con manos torcidas y una actitud negligente hacia BGP por parte de algunos ISP de EE. UU.; el segundo, con un despliegue torcido de CF, que afectó a todos los usuarios de CF). , y estos son muchos servicios notables) y el funcionamiento inestable de la infraestructura CDN de Facebook (afectó a todos los productos de FB, incluidos Instagram y WhatsApp). También tuvimos que caer en la distribución, aunque nuestra interrupción fue mucho menos notoria en el contexto global. Alguien ya ha comenzado a arrastrar helicópteros negros y conspiraciones "soberanas", por lo que publicamos una autopsia pública de nuestro incidente.
03.07.2019, 16: 05
Se comenzaron a registrar problemas con los recursos, similares a una falla en la conectividad de la red interna. Al no haber verificado todo completamente, comenzaron a criticar el desempeño del canal externo hacia DataLine, ya que quedó claro que el problema estaba en el acceso a Internet (NAT) de la red interna, hasta el punto de poner la sesión BGP hacia DataLine.
03.07.2019, 16: 35
Se hizo evidente que el equipo que proporcionaba la traducción de direcciones de red y el acceso desde la red local del sitio a Internet (NAT) había fallado. Los intentos de reiniciar el equipo no llevaron a nada, la búsqueda de opciones alternativas para organizar la conectividad comenzó antes de recibir respuesta del soporte técnico, ya que por experiencia, lo más probable es que esto no hubiera ayudado.
El problema se agravó un poco por el hecho de que este equipo también interrumpía las conexiones entrantes de los empleados de VPN del cliente y el trabajo de recuperación remota se volvió más difícil de realizar.
03.07.2019, 16: 40
Intentamos revivir un esquema NAT de respaldo previamente existente que había funcionado bien antes. Pero quedó claro que una serie de renovaciones de la red hicieron que este esquema fuera casi completamente inoperante, ya que su restauración podría, en el mejor de los casos, no funcionar o, en el peor, romper lo que ya estaba funcionando.
Comenzamos a trabajar en un par de ideas para transferir tráfico a un conjunto de nuevos enrutadores que sirven a la red troncal, pero parecían impracticables debido a las peculiaridades de la distribución de rutas en la red central.
03.07.2019, 17: 05
Al mismo tiempo, se identificó un problema en el mecanismo de resolución de nombres en los servidores de nombres, lo que provocó errores en la resolución de puntos finales en las aplicaciones, y comenzaron a llenar rápidamente los archivos de hosts con registros de servicios críticos.
03.07.2019, 17: 27
Se ha restaurado la funcionalidad limitada de Habr.
03.07.2019, 17: 43
Pero al final se encontró una solución relativamente segura para organizar el tráfico a través de uno de los enrutadores fronterizos, que se instaló rápidamente. Se ha restablecido la conectividad a Internet.
Durante los siguientes minutos, llegaron muchas notificaciones de los sistemas de monitoreo sobre la restauración de la funcionalidad de los agentes de monitoreo, pero algunos de los servicios resultaron inoperables porque el mecanismo de resolución de nombres en los servidores de nombres (dns) estaba roto.
03.07.2019, 17: 52
Se reinició NS y se borró el caché. La resolución ha sido restaurada.
03.07.2019, 17: 55
Todos los servicios empezaron a funcionar excepto MK, Freelansim y Toaster.
03.07.2019, 18: 02
MK y Freelansim empezaron a trabajar.
03.07.2019, 18: 07
Recupera una sesión BGP inocente con DataLine.
03.07.2019, 18: 25
Comenzaron a registrar problemas con los recursos, lo que se debió a un cambio en la dirección externa del pool NAT y su ausencia en el acl de varios servicios, lo que se corrigió rápidamente. La tostadora empezó a funcionar de inmediato.
03.07.2019, 20: 30
Notamos 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 cual se corrigió rápidamente.
Hallazgos
- El equipo, que hasta entonces había sembrado dudas sobre su idoneidad, falló. Había planes para eliminarlo del trabajo, ya que interfería en el desarrollo de la red y tenía problemas de compatibilidad, pero al mismo tiempo cumplía una función crítica, por lo que cualquier sustitución era técnicamente difícil sin interrumpir los servicios. Ahora puedes seguir adelante.
- El problema del DNS se puede evitar acercándolos a la nueva red troncal fuera de la red NAT y aún teniendo conectividad total a la red gris sin traducción (que era el plan antes del incidente).
- No debe utilizar 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 tales manipulaciones aún requieren reconstruir el clúster. Esta decisión fue 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 realizado ejercicios comparables a la "soberanización de Runet", hay algo en qué pensar en términos de fortalecer las capacidades de supervivencia autónoma.
Fuente: habr.com