Ang pagtatapos ng una at simula ng ikalawang buwan ng tag-init 2019 ay naging mahirap at minarkahan ng ilang malalaking pagbaba sa mga pandaigdigang serbisyo sa IT. Kabilang sa mga kapansin-pansin: dalawang seryosong insidente sa imprastraktura ng CloudFlare (ang una - na may baluktot na mga kamay at pabaya sa BGP sa bahagi ng ilang mga ISP mula sa USA; ang pangalawa - na may baluktot na deployment ng CF mismo, na nakaapekto sa lahat ng gumagamit ng CF , at ito ay maraming kapansin-pansing serbisyo) at hindi matatag na operasyon ng imprastraktura ng Facebook CDN (naapektuhan ang lahat ng produkto ng FB, kabilang ang Instagram at WhatsApp). Kinailangan din naming mahuli sa pamamahagi, kahit na ang aming pagkawala ay hindi gaanong kapansin-pansin laban sa pandaigdigang background. May nagsimula nang mag-drag sa mga itim na helicopter at "sovereign" conspiracies, kaya naglalabas kami ng pampublikong post mortem ng aming insidente.
03.07.2019, 16: 05
Ang mga problema sa mga mapagkukunan ay nagsimulang maitala, katulad ng isang pagkasira sa panloob na koneksyon sa network. Dahil hindi pa ganap na nasuri ang lahat, sinimulan nilang sisihin ang pagganap ng panlabas na channel patungo sa DataLine, dahil naging malinaw na ang problema ay sa pag-access ng panloob na network sa Internet (NAT), hanggang sa punto ng paglalagay ng BGP session patungo sa DataLine.
03.07.2019, 16: 35
Ito ay naging malinaw na ang kagamitan na nagbibigay ng network address translation at access mula sa lokal na network ng site sa Internet (NAT) ay nabigo. Ang mga pagtatangka na i-reboot ang kagamitan ay hindi humantong sa anumang bagay; ang paghahanap para sa mga alternatibong opsyon para sa pag-aayos ng koneksyon ay nagsimula bago makatanggap ng tugon mula sa teknikal na suporta, dahil mula sa karanasan, malamang na hindi ito makakatulong.
Ang problema ay medyo pinalubha ng katotohanan na ang kagamitang ito ay tinapos din ang mga papasok na koneksyon ng mga empleyado ng VPN ng kliyente, at ang remote na pagbawi ay naging mas mahirap na isagawa.
03.07.2019, 16: 40
Sinubukan naming buhayin ang dati nang backup na NAT scheme na gumana nang maayos dati. Ngunit naging malinaw na ang isang bilang ng mga pagsasaayos ng network ay ginawa ang pamamaraang ito na halos ganap na hindi gumana, dahil ang pagpapanumbalik nito ay maaaring, sa pinakamabuting kalagayan, ay hindi gumana, o, sa pinakamasama, masira kung ano ang gumagana na.
Nagsimula kaming magtrabaho sa isang pares ng mga ideya upang ilipat ang trapiko sa isang hanay ng mga bagong router na nagsisilbi sa backbone, ngunit tila hindi ito magagawa dahil sa mga kakaibang pamamahagi ng mga ruta sa pangunahing network.
03.07.2019, 17: 05
Kasabay nito, natukoy ang isang problema sa mekanismo ng paglutas ng pangalan sa mga server ng pangalan, na humantong sa mga error sa paglutas ng mga endpoint sa mga application, at sinimulan nilang mabilis na punan ang mga file ng host ng mga talaan ng mga kritikal na serbisyo.
03.07.2019, 17: 27
Ang limitadong paggana ng Habr ay naibalik.
03.07.2019, 17: 43
Ngunit sa huli, isang medyo ligtas na solusyon ang natagpuan para sa pag-aayos ng trapiko sa pamamagitan ng isa sa mga border router, na mabilis na na-install. Ang pagkakakonekta sa internet ay naibalik.
Sa susunod na ilang minuto, maraming notification ang nagmula sa mga monitoring system tungkol sa pagpapanumbalik ng functionality ng mga monitoring agent, ngunit ang ilan sa mga serbisyo ay naging hindi maoperahan dahil nasira ang mekanismo ng paglutas ng pangalan sa mga name server (dns).
03.07.2019, 17: 52
Na-restart ang NS at na-clear ang cache. Ang paglutas ay naibalik.
03.07.2019, 17: 55
Nagsimulang gumana ang lahat ng serbisyo maliban sa MK, Freelansim at Toaster.
03.07.2019, 18: 02
Nagsimulang magtrabaho sina MK at Freelansim.
03.07.2019, 18: 07
Ibalik ang isang inosenteng BGP session sa DataLine.
03.07.2019, 18: 25
Nagsimula silang magtala ng mga problema sa mga mapagkukunan, na dahil sa pagbabago sa panlabas na address ng NAT pool at kawalan nito sa acl ng isang bilang ng mga serbisyo, na agad na naitama. Ang Toaster ay nagsimulang gumana kaagad.
03.07.2019, 20: 30
Napansin namin ang mga error na nauugnay sa mga bot ng Telegram. Ito ay lumabas na nakalimutan nilang irehistro ang panlabas na address sa isang pares ng mga acl (proxy server), na agad na naitama.
Natuklasan
- Nabigo ang kagamitan, na dati nang naghasik ng mga pagdududa tungkol sa pagiging angkop nito. May mga plano na alisin ito mula sa trabaho, dahil nakakasagabal ito sa pag-unlad ng network at nagkaroon ng mga problema sa pagiging tugma, ngunit sa parehong oras ay nagsagawa ito ng isang kritikal na pag-andar, kaya naman ang anumang kapalit ay teknikal na mahirap nang hindi nakakaabala sa mga serbisyo. Ngayon ay maaari kang magpatuloy.
- Ang isyu sa DNS ay maiiwasan sa pamamagitan ng paglipat sa kanila ng mas malapit sa bagong backbone network sa labas ng NAT network at mayroon pa ring ganap na koneksyon sa gray na network nang walang pagsasalin (na siyang plano bago ang insidente).
- Hindi ka dapat gumamit ng mga domain name kapag nag-assemble ng mga cluster ng RDBMS, dahil ang kaginhawaan ng malinaw na pagbabago ng IP address ay hindi partikular na kinakailangan, dahil ang mga naturang manipulasyon ay nangangailangan pa rin ng muling pagtatayo ng cluster. Ang desisyong ito ay idinikta ng mga makasaysayang dahilan at, una sa lahat, sa pagiging malinaw ng mga endpoint ayon sa pangalan sa mga pagsasaayos ng RDBMS. Sa pangkalahatan, isang klasikong bitag.
- Sa prinsipyo, ang mga pagsasanay na maihahambing sa "sovereignization ng Runet" ay isinagawa; mayroong isang bagay na dapat isipin sa mga tuntunin ng pagpapalakas ng mga kakayahan ng autonomous survival.
Pinagmulan: www.habr.com