Het einde van de eerste en het begin van de tweede zomermaand van 2019 bleek lastig en werd gekenmerkt door een aantal grote dalingen in de mondiale IT-diensten. Onder de opmerkelijke: twee ernstige incidenten in de CloudFlare-infrastructuur (de eerste - met kromme handen en een nalatige houding ten opzichte van BGP van de kant van sommige ISP's uit de VS; de tweede - met een scheve inzet van CF zelf, die iedereen trof die CF gebruikte , en dit zijn veel opmerkelijke diensten) en de onstabiele werking van de Facebook CDN-infrastructuur (beïnvloedde alle FB-producten, inclusief Instagram en WhatsApp). Ook wij moesten ons bezighouden met de distributie, al viel onze storing tegen de mondiale achtergrond veel minder op. Iemand is al begonnen met het binnenhalen van zwarte helikopters en ‘soevereine’ samenzweringen, dus geven we een openbare postmortem van ons incident vrij.
03.07.2019, 16: 05
Er begonnen problemen met bronnen te worden geregistreerd, vergelijkbaar met een storing in de interne netwerkconnectiviteit. Omdat ze niet alles volledig hadden gecontroleerd, begonnen ze kritiek te leveren op de prestaties van het externe kanaal richting DataLine, toen duidelijk werd dat het probleem te maken had met de toegang van het interne netwerk tot internet (NAT), tot het punt waarop de BGP-sessie naar DataLine werd verplaatst.
03.07.2019, 16: 35
Het werd duidelijk dat de apparatuur die de vertaling van netwerkadressen en toegang vanaf het lokale netwerk van de site tot internet (NAT) verzorgde, defect was. Pogingen om de apparatuur opnieuw op te starten leidden tot niets, de zoektocht naar alternatieve opties voor het organiseren van connectiviteit begon voordat een reactie van technische ondersteuning werd ontvangen, aangezien dit uit ervaring hoogstwaarschijnlijk niet zou hebben geholpen.
Het probleem werd enigszins verergerd door het feit dat deze apparatuur ook inkomende verbindingen van VPN-medewerkers van klanten verbrak, waardoor herstelwerkzaamheden op afstand moeilijker uit te voeren waren.
03.07.2019, 16: 40
We hebben geprobeerd een eerder bestaand back-up-NAT-schema, dat al goed werkte, nieuw leven in te blazen. Maar het werd duidelijk dat een aantal renovaties van het netwerk dit plan vrijwel volledig onbruikbaar maakten, omdat het herstel ervan in het beste geval niet zou kunnen werken, of in het slechtste geval zou kunnen breken wat al werkte.
We begonnen te werken aan een aantal ideeën om verkeer over te dragen naar een reeks nieuwe routers die de backbone bedienen, maar deze leken onwerkbaar vanwege de eigenaardigheden van de distributie van routes in het kernnetwerk.
03.07.2019, 17: 05
Tegelijkertijd werd een probleem geïdentificeerd in het naamresolutiemechanisme op naamservers, wat leidde tot fouten bij het oplossen van eindpunten in applicaties, en ze begonnen hosts-bestanden snel te vullen met records van kritieke services.
03.07.2019, 17: 27
De beperkte functionaliteit van Habr is hersteld.
03.07.2019, 17: 43
Maar uiteindelijk werd er een relatief veilige oplossing gevonden om het verkeer te organiseren via een van de grensrouters, die snel werd geïnstalleerd. De internetverbinding is hersteld.
In de daaropvolgende minuten kwamen er veel meldingen van de monitoringsystemen over het herstel van de functionaliteit van de monitoringagents, maar sommige services bleken onbruikbaar omdat het naamresolutiemechanisme op de naamservers (dns) kapot was.
03.07.2019, 17: 52
NS is opnieuw opgestart en de cache is gewist. Het oplossen is hersteld.
03.07.2019, 17: 55
Alle services begonnen te werken behalve MK, Freelansim en Toaster.
03.07.2019, 18: 02
MK en Freelansim gingen aan de slag.
03.07.2019, 18: 07
Breng een onschuldige BGP-sessie terug met DataLine.
03.07.2019, 18: 25
Ze begonnen problemen met bronnen vast te leggen, wat te wijten was aan een verandering in het externe adres van de NAT-pool en de afwezigheid ervan in de acl van een aantal services, wat onmiddellijk werd gecorrigeerd. De broodrooster begon meteen te werken.
03.07.2019, 20: 30
We hebben fouten opgemerkt met betrekking tot Telegram-bots. Het bleek dat ze waren vergeten het externe adres in een paar acl (proxyservers) te registreren, wat onmiddellijk werd gecorrigeerd.
Bevindingen
- De apparatuur, die eerder twijfels had gezaaid over de geschiktheid ervan, faalde. Er waren plannen om het van het werk te verwijderen, omdat het de ontwikkeling van het netwerk verstoorde en compatibiliteitsproblemen had, maar tegelijkertijd een cruciale functie vervulde, waardoor elke vervanging technisch moeilijk was zonder de services te onderbreken. Nu kun je verder gaan.
- Het DNS-probleem kan worden vermeden door ze dichter bij het nieuwe backbone-netwerk buiten het NAT-netwerk te plaatsen en toch volledige connectiviteit met het grijze netwerk te hebben zonder vertaling (wat het plan was vóór het incident).
- U mag geen domeinnamen gebruiken bij het samenstellen van RDBMS-clusters, omdat het gemak van het transparant wijzigen van het IP-adres niet bijzonder noodzakelijk is, aangezien dergelijke manipulaties nog steeds het opnieuw opbouwen van het cluster vereisen. Deze beslissing werd ingegeven door historische redenen en in de eerste plaats door de vanzelfsprekendheid van eindpunten bij naam in RDBMS-configuraties. Over het algemeen een klassieke valstrik.
- In principe zijn er oefeningen uitgevoerd die vergelijkbaar zijn met de ‘soevereinisering van de Runet’; er is iets om over na te denken in termen van het versterken van de mogelijkheden van autonoom overleven.
Bron: www.habr.com