Das Ende des ersten und der Beginn des zweiten Monats des Sommers 2019 erwiesen sich als schwierig und waren durch mehrere erhebliche Rückgänge bei den weltweiten IT-Diensten gekennzeichnet. Von den bemerkenswerten: Zwei schwerwiegende Vorfälle in der CloudFlare-Infrastruktur (der erste - mit krummen Händen und nachlässiger Haltung einiger ISPs aus den USA gegenüber BGP; der zweite - mit dem krummen Einsatz der CFs selbst betraf alle, die CF nutzen, und dies sind viele bemerkenswerte Dienste) und Instabiler Betrieb der Facebook-CDN-Infrastruktur (betrifft alle FB-Produkte, einschließlich Instagram und WhatsApp). Wir mussten auch unter die Distribution kommen, obwohl unser Ausfall auf globaler Ebene viel weniger spürbar war. Jemand hat bereits begonnen, schwarze Hubschrauber und „souveräne“ Verschwörungen einzuschleppen, daher veröffentlichen wir eine öffentliche Obduktion unseres Vorfalls.
07/03/2019, 16:05Wir haben begonnen, Ressourcenprobleme zu beheben, ähnlich wie bei einer Verletzung der internen Netzwerkkonnektivität. Nachdem sie nicht alles vollständig überprüft hatten, begannen sie, über die Funktionsfähigkeit des externen Kanals in Richtung Data Line zu sündigen, da klar wurde, dass es ein Problem mit dem Zugang des internen Netzwerks zum Internet (NAT) gab, bis sie die BGP-Sitzung in Richtung DataLine versetzten.
07/03/2019, 16:35Es stellte sich heraus, dass die Geräte, die die Netzwerkadressübersetzung und den Zugriff vom lokalen Netzwerk des Standorts auf das Internet (NAT) durchführen, fehlgeschlagen sind. Versuche, das Gerät neu zu starten, führten zu nichts. Die Suche nach alternativen Optionen für die Organisation der Konnektivität begann, bevor eine Antwort vom technischen Support einging, da dies aus Erfahrung höchstwahrscheinlich nicht helfen würde.
Das Problem wurde durch die Tatsache etwas verschärft, dass dieses Gerät auch die eingehenden Verbindungen von Client-VPN-Mitarbeitern beendete und die Durchführung von Remote-Wiederherstellungsarbeiten schwieriger wurde.
07/03/2019, 16:40Wir haben versucht, ein bereits vorhandenes NAT-Fallback-Schema wiederzubeleben, das zuvor hart gearbeitet hatte. Es wurde jedoch klar, dass eine Reihe von Umrüstungen des Netzwerks dieses System fast vollständig funktionsunfähig machte, da seine Wiederherstellung im besten Fall möglicherweise nicht funktioniert und im schlimmsten Fall das bereits funktionierende System zerstört.
Sie begannen, einige Ideen auszuarbeiten, um den Datenverkehr auf einen Komplex neuer Router zu übertragen, die das Backbone bedienen, aber sie schienen aufgrund der Besonderheiten der Verteilung der Routen im Kernnetzwerk nicht funktionsfähig zu sein.
07/03/2019, 17:05Gleichzeitig wurde ein Problem im Mechanismus zum Auflösen von Namen auf Nameservern festgestellt, das zu Fehlern beim Auflösen von Endpunkten in Anwendungen führte. Sie begannen, Hostdateien schnell mit Aufzeichnungen kritischer Dienste zu füllen.
07/03/2019, 17:27Restaurierte eingeschränkte Funktionalität von Habr.
07/03/2019, 17:43Am Ende wurde jedoch eine relativ sichere Lösung gefunden, um den Verkehr durch nur einen der Grenzrouter zu organisieren, der schnell entwurzelt wurde. Die Internetverbindung wurde wiederhergestellt.
In den nächsten Minuten erhielten Überwachungssysteme zahlreiche Benachrichtigungen über die Wiederherstellung der Arbeitskapazität von Überwachungsagenten. Einige der Dienste erwiesen sich jedoch als nicht funktionsfähig, da der Mechanismus zur Namensauflösung auf Nameservern (DNS) verletzt wurde.
07/03/2019, 17:52NS wurden neu gestartet, Cache wurde zurückgesetzt. Auflösung wiederhergestellt.
07/03/2019, 17:55Verdiente alle Dienstleistungen außer MK, Freelansim und Toaster.
07/03/2019, 18:02MK und Freelansim verdient.
07/03/2019, 18:07Brachte eine unschuldige BGP-Sitzung mit DataLine zurück.
07/03/2019, 18:25Sie begannen, Flansche an Ressourcen zu reparieren. Dies war mit einer Änderung der externen Adresse des NAT-Pools und dessen Fehlen in einer Reihe von Diensten verbunden, die schnell korrigiert wurden. Sofort verdient und Toaster.
07/03/2019, 20:30Wir haben Fehler im Zusammenhang mit Telegramm-Bots festgestellt. Es stellte sich heraus, dass sie vergessen hatten, die externe Adresse in einem acl-Paar (Proxy-Server) zu registrieren, und sie schnell korrigierten.
Schlussfolgerungen
- Die Ausrüstung fiel aus, was schon vorher Zweifel an ihrer Eignung aufkommen ließ. Es gab Pläne, es von der Arbeit auszuschließen, da es die Entwicklung des Netzwerks beeinträchtigte und Kompatibilitätsprobleme aufwies, aber gleichzeitig eine kritische Funktion ausführte, weshalb ein Austausch ohne Unterbrechung der Dienste technisch nicht einfach war. Jetzt können Sie weitermachen.
- DNS-Probleme können vermieden werden, indem sie näher an das neue Backbone-Netzwerk außerhalb des NAT-Netzwerks und gleichzeitig mit vollständiger Konnektivität zum grauen Netzwerk ohne Übersetzung (die vor dem Vorfall geplant war) verschoben werden.
- Verwenden Sie beim Zusammenstellen von RDBMS-Clustern keine Domänennamen, da das bequeme transparente Ändern der IP-Adresse nicht besonders erforderlich ist, da solche Manipulationen dennoch einen erneuten Zusammenbau von Clustern erfordern. Diese Entscheidung wird aus historischen Gründen und vor allem durch die Offensichtlichkeit der Endpunkte nach Namen in den RDBMS-Konfigurationen bestimmt. Im Allgemeinen eine klassische Falle.
- Grundsätzlich wurden Übungen durchgeführt, die mit der „Souveränisierung von Runet“ vergleichbar sind. Es gibt etwas zu bedenken, um die Möglichkeiten des autonomen Überlebens zu stärken.