La fin du premier et le début du deuxième mois de l'été 2019 se sont avérés difficiles et ont été marqués par plusieurs baisses importantes des services informatiques mondiaux. Parmi les plus notables: deux incidents graves dans l'infrastructure CloudFlare (le premier - avec des mains tordues et une attitude négligente envers BGP par certains FAI des États-Unis; le second - avec un déploiement tordu des FC eux-mêmes, a affecté tous ceux qui utilisent CF, et ce sont de nombreux services notables) et fonctionnement instable de l'infrastructure Facebook CDN (touché tous les produits FB, y compris Instagram et WhatsApp). Nous avons également dû passer sous la distribution, bien que notre panne ait été beaucoup moins perceptible à l'échelle mondiale. Quelqu'un a déjà commencé à traîner des hélicoptères noirs et des complots «souverains», nous publions donc un post mortem public de notre incident.
07/03/2019, 16:05Nous avons commencé à résoudre des problèmes de ressources, similaires à une violation de la connectivité réseau interne. N'ayant pas tout vérifié complètement, ils ont commencé à pécher sur l'opérabilité du canal externe en direction de Data Line, car il est devenu clair qu'il y avait un problème d'accès du réseau interne à Internet (NAT), au point de mettre la session BGP en direction de DataLine.
07/03/2019, 16:35Il est devenu évident que l'équipement effectuant la traduction d'adresses réseau et l'accès du réseau local du site à Internet (NAT) était en panne. Les tentatives de redémarrage de l'équipement n'ont abouti à rien, la recherche d'options alternatives pour organiser la connectivité a commencé avant de recevoir une réponse du support technique, car l'expérience n'aurait probablement pas aidé.
Le problème a été quelque peu aggravé par le fait que cet équipement a également interrompu les connexions entrantes des employés VPN clients, les travaux de restauration à distance sont devenus plus difficiles à effectuer.
07/03/2019, 16:40Nous avons essayé de réanimer un schéma de secours NAT préexistant qui avait travaillé dur auparavant. Mais il est devenu clair qu'un certain nombre de rééquipements du réseau ont rendu ce schéma presque complètement inopérant, car sa restauration pourrait ne pas fonctionner dans le meilleur des cas, et dans le pire, casser celui qui fonctionnait déjà.
Ils ont commencé à trouver quelques idées pour transférer le trafic vers un complexe de nouveaux routeurs desservant la dorsale, mais ils semblaient inopérants en raison des particularités de la distribution des routes dans le réseau central.
07/03/2019, 17:05Dans le même temps, un problème a été révélé dans le mécanisme de résolution des noms sur les serveurs de noms, ce qui a conduit à des erreurs dans la résolution des points de terminaison dans les applications; ils ont commencé à remplir rapidement les fichiers hôtes avec des enregistrements de services critiques.
07/03/2019, 17:27Restauration des fonctionnalités limitées de Habr.
07/03/2019, 17:43Mais finalement, une solution relativement sûre a été trouvée pour organiser le trafic passant par un seul des routeurs frontaliers, qui a été rapidement déraciné. La connectivité Internet s'est rétablie.
Au cours des prochaines minutes, les systèmes de surveillance ont reçu de nombreuses notifications concernant la restauration de la capacité de travail des agents de surveillance, mais certains services se sont révélés inopérants, car le mécanisme de résolution de noms sur les serveurs de noms (DNS) a été violé.
07/03/2019, 17:52NS a été redémarré, le cache a été réinitialisé. Résolution récupérée.
07/03/2019, 17:55A gagné tous les services sauf MK, Freelansim et Toaster.
07/03/2019, 18:02Gagné MK et Freelansim.
07/03/2019, 18:07Ramené une session BGP innocente avec DataLine.
07/03/2019, 18:25Ils ont commencé à fixer des brides sur les ressources, cela a été associé à un changement d'adresse externe du pool NAT et à son absence dans l'acl d'un certain nombre de services, rapidement corrigée. Immédiatement gagné et grille-pain.
07/03/2019, 20:30Nous avons remarqué des erreurs liées aux robots Telegram. Il s'est avéré qu'ils avaient oublié d'enregistrer l'adresse externe dans une paire d'acl (serveurs proxy), ils l'ont rapidement corrigée.
Conclusions
- L'équipement est tombé en panne, ce qui, avant cela, avait mis en doute sa pertinence. Il était prévu de l'exclure du travail, car il interférait avec le développement du réseau et posait des problèmes de compatibilité, mais remplissait en même temps une fonction critique, c'est pourquoi tout remplacement n'était techniquement pas facile sans interruption de services. Vous pouvez maintenant continuer.
- Les problèmes DNS peuvent être évités en les rapprochant du nouveau réseau de base en dehors du réseau NAT et en même temps avec une connectivité complète au réseau gris sans traduction (ce qui était prévu avant l'incident).
- N'utilisez pas de noms de domaine lors de l'assemblage de grappes RDBMS, car la commodité de changer l'adresse IP de manière transparente n'est pas particulièrement nécessaire, car de telles manipulations nécessitent tout de même un réassemblage de grappe. Cette décision est dictée par des raisons historiques et, tout d'abord, par l'évidence des points de terminaison par nom dans les configurations SGBDR. En général, un piège classique.
- En principe, des exercices ont été réalisés comparables à la «souveraineté de Runet», il y a quelque chose à penser du point de vue du renforcement des possibilités de survie autonome.