Slutten av den første og begynnelsen av den andre måneden sommeren 2019 viste seg å være vanskelig og var preget av flere store fall i globale IT-tjenester. Blant de bemerkelsesverdige: to alvorlige hendelser i CloudFlare-infrastrukturen (den første - med skjeve hender og uaktsom holdning til BGP fra noen Internett-leverandører fra USA; den andre - med en skjev utplassering av CF selv, som påvirket alle som brukte CF , og dette er mange bemerkelsesverdige tjenester) og ustabil drift av Facebook CDN-infrastrukturen (påvirket alle FB-produkter, inkludert Instagram og WhatsApp). Vi måtte også bli fanget opp i distribusjonen, selv om strømbruddet vårt var mye mindre merkbart mot den globale bakgrunnen. Noen har allerede begynt å dra inn svarte helikoptre og "suverene" konspirasjoner, så vi gir ut en offentlig post mortem av hendelsen vår.
03.07.2019, 16: 05
Problemer med ressurser begynte å bli registrert, likt et sammenbrudd i intern nettverkstilkobling. Etter å ikke ha sjekket alt, begynte de å gi feil på ytelsen til den eksterne kanalen mot DataLine, da det ble klart at problemet var med det interne nettverkets tilgang til Internett (NAT), til det punktet å sette BGP-økten mot DataLine.
03.07.2019, 16: 35
Det ble åpenbart at utstyret som ga nettverksadresseoversettelse og tilgang fra nettstedets lokale nettverk til Internett (NAT) hadde sviktet. Forsøk på å starte utstyret på nytt førte ikke til noe, søket etter alternative alternativer for å organisere tilkobling begynte før man fikk svar fra teknisk støtte, siden erfaringsmessig ville dette mest sannsynlig ikke ha hjulpet.
Problemet ble noe forverret av det faktum at dette utstyret også avsluttet innkommende tilkoblinger til klient VPN-ansatte, og fjerngjenopprettingsarbeid ble vanskeligere å utføre.
03.07.2019, 16: 40
Vi prøvde å gjenopplive en tidligere eksisterende backup NAT-ordning som hadde fungert godt før. Men det ble klart at en rekke nettverksoppussinger gjorde denne ordningen nesten helt uvirksom, siden restaureringen av den i beste fall ikke kunne fungere, eller i verste fall bryte det som allerede fungerte.
Vi begynte å jobbe med et par ideer for å overføre trafikk til et sett med nye rutere som betjener ryggraden, men de virket ubrukelige på grunn av særegenhetene ved distribusjonen av ruter i kjernenettverket.
03.07.2019, 17: 05
Samtidig ble det identifisert et problem i navneløsningsmekanismen på navneservere, som førte til feil ved å løse endepunkter i applikasjoner, og de begynte raskt å fylle vertsfiler med registreringer av kritiske tjenester.
03.07.2019, 17: 27
Habrs begrensede funksjonalitet er gjenopprettet.
03.07.2019, 17: 43
Men til slutt ble det funnet en relativt sikker løsning for å organisere trafikken gjennom en av grenseruterene, som raskt ble installert. Internett-tilkoblingen er gjenopprettet.
I løpet av de neste minuttene kom det mange varsler fra overvåkingssystemene om gjenoppretting av overvåkingsagentenes funksjonalitet, men noen av tjenestene viste seg å være ubrukelige fordi navneløsningsmekanismen på navneserverne (dns) var ødelagt.
03.07.2019, 17: 52
NS ble startet på nytt og cachen ble tømt. Løsningen er gjenopprettet.
03.07.2019, 17: 55
Alle tjenester begynte å fungere bortsett fra MK, Freelansim og Toaster.
03.07.2019, 18: 02
MK og Freelansim begynte å jobbe.
03.07.2019, 18: 07
Få tilbake en uskyldig BGP-økt med DataLine.
03.07.2019, 18: 25
De begynte å registrere problemer med ressurser, noe som skyldtes en endring i den eksterne adressen til NAT-poolen og dens fravær i acl-en til en rekke tjenester, som umiddelbart ble korrigert. Brødristeren begynte å fungere med en gang.
03.07.2019, 20: 30
Vi la merke til feil relatert til Telegram-roboter. Det viste seg at de glemte å registrere den eksterne adressen i et par acl (proxy-servere), som raskt ble rettet.
Funn
- Utstyret, som tidligere hadde sådd tvil om egnetheten, sviktet. Det var planer om å eliminere det fra jobben, siden det forstyrret utviklingen av nettverket og hadde kompatibilitetsproblemer, men samtidig utførte det en kritisk funksjon, og derfor var enhver erstatning teknisk vanskelig uten å avbryte tjenestene. Nå kan du gå videre.
- DNS-problemet kan unngås ved å flytte dem nærmere det nye ryggradsnettverket utenfor NAT-nettverket og fortsatt ha full tilkobling til det grå nettverket uten oversettelse (som var planen før hendelsen).
- Du bør ikke bruke domenenavn når du setter sammen RDBMS-klynger, siden bekvemmeligheten av transparent endring av IP-adressen ikke er spesielt nødvendig, siden slike manipulasjoner fortsatt krever gjenoppbygging av klyngen. Denne avgjørelsen ble diktert av historiske årsaker og først av alt av åpenheten av endepunkter ved navn i RDBMS-konfigurasjoner. Generelt en klassisk felle.
- I prinsippet er det gjennomført øvelser som kan sammenlignes med «suvereniseringen av Runet», det er noe å tenke på når det gjelder å styrke evnene til autonom overlevelse.
Kilde: www.habr.com