2019 m. vasaros pirmojo ir antrojo mėnesio pabaiga buvo sunki ir paženklinta keliais dideliais pasaulinių IT paslaugų nuosmukiais. Tarp žymesnių: du rimti incidentai CloudFlare infrastruktūroje (pirmasis – su kreivomis rankomis ir aplaidžiu kai kurių interneto paslaugų teikėjų iš JAV požiūriu į BGP; antrasis – su kreivu pačių CF dislokavimu, palietęs visus CF besinaudojančius , ir tai yra daug pastebimų paslaugų) ir nestabilus Facebook CDN infrastruktūros veikimas (paveikė visus FB produktus, įskaitant Instagram ir WhatsApp). Mes taip pat turėjome patekti į platinimą, nors mūsų gedimas buvo daug mažiau pastebimas pasaulio fone. Kažkas jau pradėjo tempti juodus malūnsparnius ir „suverenius“ sąmokslus, todėl skelbiame viešą mūsų incidento post mortem.
03.07.2019, 16: 05
Buvo pradėtos fiksuoti problemos su ištekliais, panašiai kaip vidinio tinklo ryšio sutrikimas. Visko iki galo nepatikrinus, jie pradėjo daryti klaidas dėl išorinio kanalo, nukreipto į DataLine, veikime, nes paaiškėjo, kad problema yra vidinio tinklo prieiga prie interneto (NAT), iki BGP seanso nukreipimo link. DataLine.
03.07.2019, 16: 35
Tapo akivaizdu, kad sugedo įranga, teikianti tinklo adresų vertimą ir prieigą iš svetainės vietinio tinklo į internetą (NAT). Bandymai iš naujo paleisti įrangą nieko nedavė, alternatyvių ryšio organizavimo galimybių buvo pradėta ieškoti dar negavus atsakymą iš techninės pagalbos, nes iš patirties tai greičiausiai nebūtų padėję.
Problemą kiek apsunkino tai, kad ši įranga nutraukė ir klientų VPN darbuotojų įeinančius ryšius, o nuotolinio atkūrimo darbai tapo sunkiau atliekami.
03.07.2019, 16: 40
Bandėme atgaivinti anksčiau turėtą atsarginę NAT schemą, kuri gerai veikė anksčiau. Tačiau tapo aišku, kad dėl daugelio tinklo atnaujinimų ši schema beveik visiškai neveikė, nes jos atkūrimas geriausiu atveju gali neveikti arba, blogiausiu, sugadinti tai, kas jau veikia.
Pradėjome dirbti su keliomis idėjomis, kaip perkelti srautą į naujų maršrutizatorių rinkinį, aptarnaujantį pagrindinį tinklą, tačiau jie atrodė neįgyvendinami dėl maršrutų paskirstymo pagrindiniame tinkle ypatumų.
03.07.2019, 17: 05
Tuo pačiu metu buvo nustatyta vardų serverių vardų sprendimo mechanizmo problema, dėl kurios atsirado klaidų sprendžiant programų galinius taškus, ir jie pradėjo greitai užpildyti pagrindinio kompiuterio failus svarbių paslaugų įrašais.
03.07.2019, 17: 27
Ribotas Habro funkcionalumas buvo atkurtas.
03.07.2019, 17: 43
Tačiau galiausiai buvo rastas gana saugus sprendimas organizuoti eismą per vieną iš pasienio maršrutizatorių, kuris buvo greitai įdiegtas. Interneto ryšys buvo atkurtas.
Per ateinančias kelias minutes iš stebėjimo sistemų atėjo daug pranešimų apie stebėjimo agentų funkcionalumo atkūrimą, tačiau kai kurios paslaugos pasirodė neveikiančios, nes vardų serveriuose (dns) sugedo vardų sprendimo mechanizmas.
03.07.2019, 17: 52
NS buvo paleistas iš naujo, o talpykla išvalyta. Sprendimas buvo atkurtas.
03.07.2019, 17: 55
Pradėjo veikti visos paslaugos, išskyrus MK, Freelansim ir Toaster.
03.07.2019, 18: 02
MK ir Freelansim pradėjo dirbti.
03.07.2019, 18: 07
Sugrąžinkite nekaltą BGP seansą su DataLine.
03.07.2019, 18: 25
Jie pradėjo fiksuoti problemas, susijusias su ištekliais, atsiradusias dėl NAT telkinio išorinio adreso pasikeitimo ir jo nebuvimo daugelio paslaugų acl, o tai buvo nedelsiant ištaisyta. Skrudintuvas pradėjo veikti iš karto.
03.07.2019, 20: 30
Pastebėjome klaidų, susijusių su „Telegram“ robotais. Paaiškėjo, kad jie pamiršo užregistruoti išorinį adresą poroje acl (proxy serverių), kuris buvo skubiai ištaisytas.
išvados
- Sugedo įranga, anksčiau sėjusi abejonių dėl jos tinkamumo. Buvo planų jį pašalinti iš darbo, nes jis trukdė tinklo plėtrai ir turėjo suderinamumo problemų, tačiau tuo pat metu atliko kritinę funkciją, todėl bet koks pakeitimas buvo techniškai sudėtingas nenutraukiant paslaugų. Dabar galite judėti toliau.
- DNS problemos galima išvengti perkeliant juos arčiau naujojo pagrindinio tinklo už NAT tinklo ribų ir vis tiek bus pilnas ryšys su pilkuoju tinklu be vertimo (tai buvo planas prieš incidentą).
- Surinkdami RDBMS grupes neturėtumėte naudoti domenų vardų, nes patogumas skaidriai pakeisti IP adresą nėra ypač reikalingas, nes atliekant tokias manipuliacijas vis tiek reikia atkurti klasterį. Tokį sprendimą padiktavo istorinės priežastys ir, visų pirma, galutinių taškų akivaizdumas pagal pavadinimą RDBMS konfigūracijose. Apskritai, klasikiniai spąstai.
- Iš principo buvo surengtos pratybos, panašios į „Runet suverenumą“, yra apie ką galvoti apie savarankiško išgyvenimo galimybių stiprinimą.
Šaltinis: www.habr.com