Habr postmortem txostena: egunkari batean erori zen

2019ko udako lehen hilabetearen amaiera eta bigarrenaren hasiera zaila izan zen eta IT zerbitzu globalen beherakada handiek markatu zuten. Aipagarrien artean: bi gertakari larri CloudFlare azpiegituran (lehena - esku makurrekin eta AEBetako ISP batzuen aldetik BGPrekiko jarrera zabarrekin; bigarrena - CF beraiek hedapen oker batekin, CF erabiltzen duten guztiei eragiten diena. , eta zerbitzu aipagarri asko dira) eta Facebook CDN azpiegituraren funtzionamendu ezegonkorra (FB produktu guztiei eragin die, Instagram eta WhatsApp barne). Banaketan ere harrapatu behar izan genuen, nahiz eta gure etenaldia askoz gutxiago nabaritzen zen mundu osoan. Norbait dagoeneko hasi da helikoptero beltzak eta konspirazio "burujabeak" arrastaka eramaten, beraz, gure gertakariaren post mortem publikoa kaleratzen ari gara.

Habr postmortem txostena: egunkari batean erori zen

03.07.2019, 16: 05
Baliabideen arazoak erregistratzen hasi ziren, barne sareko konektibitatearen matxura baten antzera. Guztia guztiz egiaztatu ez zutenez, kanpoko kanalaren errendimenduari gaitzespenari ekin zioten DataLine-ri, argi geratu baitzen arazoa barne-sarearen Interneterako sarbidean (NAT) zegoela, BGP saioa DataLine aldera jartzeraino.

03.07.2019, 16: 35
Bistakoa zen sareko helbideen itzulpena eta guneko sare lokaletik Internetera (NAT) sarbidea ematen zuen ekipoak huts egin zuela. Ekipamendua berrabiarazteko saiakerek ez zuten ezer ekarri, konektibitatea antolatzeko aukera alternatiboen bilaketa laguntza teknikoaren erantzuna jaso aurretik hasi zen, izan ere, esperientziaren arabera, ziurrenik horrek ez zuen lagunduko.

Arazoa zertxobait areagotu zen, ekipamendu honek bezeroen VPN langileen sarrerako konexioak ere amaitu zituelako eta urruneko berreskuratze lanak egitea zailagoa zelako.

03.07.2019, 16: 40
Aurretik zegoen babeskopia NAT eskema bat berpizten saiatu ginen, aurretik ondo funtzionatu zuena. Baina argi geratu zen sareko hainbat eraberritzek eskema hori ia guztiz ez-funtzionatzen zutela, zaharberritzeak, onenean, funtzionatzen ez zezakeelako edo, txarrenean, lehendik funtzionatzen zuena hautsi zezakeelako.

Ideia pare bat lantzen hasi ginen trafikoa bizkarrezurra zerbitzatzen zuten bideratzaile berri multzo batera transferitzeko, baina bideragarriak ziruditen sare nagusiko ibilbideen banaketaren berezitasunak zirela eta.

03.07.2019, 17: 05
Aldi berean, izen-zerbitzarietako izenak ebazteko mekanismoan arazo bat identifikatu zen, eta horrek akatsak eragin zituen aplikazioetako amaierako puntuak konpontzeko, eta ostalari fitxategiak azkar betetzen hasi ziren zerbitzu kritikoen erregistroekin.

03.07.2019, 17: 27
Habr-en funtzionaltasun mugatua berreskuratu da.

03.07.2019, 17: 43
Baina, azkenean, irtenbide nahiko segurua aurkitu zen mugako bideratzaileetako baten bidez trafikoa antolatzeko, azkar instalatu zena. Interneteko konexioa berrezarri da.

Hurrengo minutuetan, monitorizazio-sistemetatik jakinarazpen asko etorri ziren monitorizazio-agenteen funtzionaltasuna berreskuratzeari buruz, baina zerbitzu batzuk funtzionatu gabe geratu ziren, izen-zerbitzarietan (dns) izenak ebazteko mekanismoa hautsi zelako.

Habr postmortem txostena: egunkari batean erori zen

03.07.2019, 17: 52
NS berrabiarazi da eta cachea garbitu da. Ebazpena leheneratu da.

03.07.2019, 17: 55
Zerbitzu guztiak hasi ziren lanean, MK, Freelansim eta Toaster izan ezik.

03.07.2019, 18: 02
MK eta Freelansim lanean hasi ziren.

03.07.2019, 18: 07
Ekarri BGP saio xalo bat DataLine-rekin.

03.07.2019, 18: 25
Baliabideekin arazoak erregistratzen hasi ziren, hau da, NAT igerilekuaren kanpoko helbidearen aldaketaren ondorioz eta zerbitzu batzuen akl-an ez zegoelako, berehala zuzendu zena. Txigorgailua berehala hasi zen lanean.

03.07.2019, 20: 30
Telegram botekin erlazionatutako erroreak nabaritu ditugu. Kanpoko helbidea akl pare batean (proxy zerbitzarietan) erregistratzea ahaztu zitzaiela gertatu zen, berehala zuzendu zena.

Habr postmortem txostena: egunkari batean erori zen

Findings

  • Aurretik bere egokitasunari buruzko zalantzak erein zituen ekipoak huts egin zuen. Lanetik kentzeko asmoa zegoen, sarearen garapena oztopatu eta bateragarritasun arazoak zituelako, baina aldi berean funtzio kritikoa betetzen zuen, horregatik edozein ordezkapena teknikoki zaila zen zerbitzuak eten gabe. Orain aurrera egin dezakezu.
  • DNS arazoa saihestu daiteke NAT saretik kanpo bizkarrezurreko sare berrira hurbilduz eta oraindik sare grisarekin konektagarritasun osoa edukitzea itzulpenik gabe (hau zen istilu aurreko plana).
  • Ez duzu domeinu-izenak erabili behar RDBMS klusterrak muntatzean, IP helbidea gardentasunez aldatzeko erosotasuna ez baita bereziki beharrezkoa, manipulazio horiek oraindik kluster-a berreraiki behar dutelako. Erabaki hori arrazoi historikoek agindu zuten eta, lehenik eta behin, RDBMS konfigurazioetan amaierako puntuen izenaren agerikotasunak. Oro har, tranpa klasikoa.
  • Printzipioz, β€œRunetaren burujabetza”-ren pareko ariketak egin dira, biziraupen autonomoaren gaitasunak indartzeko zer pentsatua dago.

Iturria: www.habr.com

Gehitu iruzkin berria