La fin du premier et le début du deuxième mois de l’été 2019 se sont révélé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 de la part de certains FAI américains ; le second - avec un déploiement tordu de CF eux-mêmes, qui a affecté tous les utilisateurs de CF , et ce sont de nombreux services notables) et le fonctionnement instable de l'infrastructure CDN de Facebook (affecté tous les produits FB, y compris Instagram et WhatsApp). Nous avons également dû nous rattraper au niveau de la distribution, même si notre panne a été beaucoup moins perceptible dans le contexte mondial. Quelqu’un a déjà commencé à attirer des hélicoptères noirs et des conspirations « souveraines », c’est pourquoi nous publions une autopsie publique de notre incident.
03.07.2019, 16: 05
Des problèmes de ressources ont commencé à être enregistrés, semblables à une panne de connectivité du réseau interne. N'ayant pas tout vérifié, ils ont commencé à critiquer les performances du canal externe vers DataLine, car il est devenu clair que le problème venait de l'accès du réseau interne à Internet (NAT), au point de mettre la session BGP vers DataLine.
03.07.2019, 16: 35
Il est devenu évident que l’équipement assurant la traduction des 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 par expérience, cela 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 du client VPN, et le travail de récupération à distance est devenu plus difficile à effectuer.
03.07.2019, 16: 40
Nous avons essayé de relancer un schéma NAT de sauvegarde existant qui fonctionnait bien auparavant. Mais il est devenu évident qu'un certain nombre de rénovations du réseau ont rendu ce projet presque totalement inopérant, puisque sa restauration pourrait, au mieux, ne pas fonctionner, ou, au pire, briser ce qui fonctionnait déjà.
Nous avons commencé à travailler sur quelques idées pour transférer le trafic vers un ensemble de nouveaux routeurs desservant le backbone, mais elles semblaient irréalisables en raison des particularités de la répartition des routes dans le réseau central.
03.07.2019, 17: 05
Dans le même temps, un problème a été identifié dans le mécanisme de résolution de noms sur les serveurs de noms, ce qui a entraîné des erreurs dans la résolution des points de terminaison dans les applications, et ils ont commencé à remplir rapidement les fichiers hôtes avec des enregistrements de services critiques.
03.07.2019, 17: 27
La fonctionnalité limitée de Habr a été restaurée.
03.07.2019, 17: 43
Mais finalement, une solution relativement sûre a été trouvée pour organiser le trafic via l'un des routeurs frontaliers, qui a été rapidement installé. La connectivité Internet a été rétablie.
Au cours des minutes suivantes, de nombreuses notifications sont venues des systèmes de surveillance concernant la restauration des fonctionnalités des agents de surveillance, mais certains services se sont révélés inutilisables en raison d'un dysfonctionnement du mécanisme de résolution de noms sur les serveurs de noms (DNS).
03.07.2019, 17: 52
NS a été redémarré et le cache a été vidé. La résolution a été restaurée.
03.07.2019, 17: 55
Tous les services ont commencé à fonctionner à l'exception de MK, Freelansim et Toaster.
03.07.2019, 18: 02
MK et Freelansim ont commencé à travailler.
03.07.2019, 18: 07
Ramenez une session BGP innocente avec DataLine.
03.07.2019, 18: 25
Ils ont commencé à enregistrer des problèmes de ressources, dus à un changement d'adresse externe du pool NAT et à son absence dans l'ACL d'un certain nombre de services, qui ont été rapidement corrigés. Le grille-pain a immédiatement commencé à fonctionner.
03.07.2019, 20: 30
Nous avons remarqué des erreurs liées aux robots Telegram. Il s'est avéré qu'ils avaient oublié d'enregistrer l'adresse externe dans quelques acl (serveurs proxy), ce qui a été rapidement corrigé.
résultats
- L'équipement, qui avait auparavant semé le doute sur son adéquation, est tombé en panne. Il était prévu de l'éliminer du travail, car il interférait avec le développement du réseau et présentait des problèmes de compatibilité, mais en même temps il remplissait une fonction critique, c'est pourquoi tout remplacement était techniquement difficile sans interrompre les services. Maintenant, vous pouvez passer à autre chose.
- Le problème DNS peut être évité en les rapprochant du nouveau réseau fédérateur en dehors du réseau NAT tout en conservant une connectivité complète au réseau gris sans traduction (ce qui était prévu avant l'incident).
- Vous ne devez pas utiliser de noms de domaine lors de l'assemblage de clusters SGBDR, car la commodité de changer de manière transparente l'adresse IP n'est pas particulièrement nécessaire, car de telles manipulations nécessitent toujours la reconstruction du cluster. Cette décision a été dictée par des raisons historiques et, tout d'abord, par l'évidence du nom des points de terminaison dans les configurations SGBDR. En général, un piège classique.
- En principe, des exercices comparables à la « souverainisation du Runet » ont été menés ; il y a matière à réflexion en termes de renforcement des capacités de survie autonome.
Source: habr.com