Kako bi se počutili, če bi nekega lepega poletnega dne podatkovni center z vašo opremo izgledal takole?
Pozdravljeni vsi skupaj! Moje ime je Dmitry Samsonov, delam kot vodilni sistemski administrator v "" Na fotografiji je eden od štirih podatkovnih centrov, kjer je nameščena oprema, ki služi našemu projektu. Za temi zidovi je približno 4 tisoč kosov opreme: strežniki, sistemi za shranjevanje podatkov, omrežna oprema itd. - skoraj ⅓ vse naše opreme.
Večina strežnikov je Linux. Obstaja tudi več deset strežnikov na Windows (MS SQL) - naša dediščina, ki smo jo že vrsto let načrtno opuščali.
Tako so 5. junija 2019 ob 14 inženirji v enem od naših podatkovnih centrov prijavili požarni alarm.
Zavrnitev
14:45. Manjši dimni incidenti v podatkovnih centrih so pogostejši, kot si mislite. Indikatorji v dvoranah so bili normalni, zato je bila naša prva reakcija razmeroma mirna: uvedli so prepoved dela s produkcijo, torej kakršnih koli sprememb konfiguracije, uvajanja novih različic itd., Razen dela, povezanega s popravljanjem nečesa.
Jeza
Ste že kdaj poskušali od gasilcev izvedeti, kje točno je na strehi zagorelo, ali sami stopiti na gorečo streho in oceniti situacijo? Kakšna bo stopnja zaupanja v informacije, prejete prek petih ljudi?
14: 50. Prejeta je bila informacija, da se ogenj približuje hladilnemu sistemu. Toda ali bo prišlo? Dežurni sistemski administrator odstrani zunanji promet s sprednjih strani tega podatkovnega centra.
Trenutno so fronte vseh naših storitev podvojene v treh podatkovnih centrih, uporablja se uravnoteženje na DNS nivoju, kar nam omogoča, da odstranimo naslove enega podatkovnega centra iz DNS in s tem zaščitimo uporabnike pred morebitnimi težavami pri dostopu do storitev. . Če so se v podatkovnem centru že pojavile težave, ta samodejno zapusti rotacijo. Več si lahko preberete tukaj:
Požar nas še ni nič prizadel – poškodovani niso niti uporabniki niti oprema. Je to nesreča? Prvi razdelek dokumenta »Načrt ukrepanja ob nesreči« opredeljuje pojem »nesreča«, razdelek pa se konča takole:
«Če obstaja kakršen koli dvom, ali je nesreča ali ne, potem je nesreča!»
14:53. Imenuje se koordinator za nujne primere.
Koordinator je oseba, ki nadzoruje komunikacijo med vsemi udeleženci, oceni obseg nesreče, uporablja akcijski načrt za nujne primere, pritegne potrebno osebje, spremlja dokončanje popravil in, kar je najpomembneje, delegira morebitne naloge. Z drugimi besedami, to je oseba, ki vodi celoten proces ukrepanja v sili.
Ugodno
15:01. Začnemo onemogočati strežnike, ki niso povezani s proizvodnjo.
15:03. Vse rezervirane storitve pravilno izklopimo.
To ne vključuje le front (do katerih uporabniki na tej točki nimajo več dostopa) in njihovih pomožnih storitev (poslovna logika, predpomnilniki itd.), ampak tudi različne baze podatkov s faktorjem podvajanja 2 ali več (, , , itd.).
15: 06. Prispela je informacija, da eni od dvoran podatkovnega centra grozi požar. V tem prostoru nimamo opreme, a dejstvo, da se ogenj lahko razširi s strehe na hale, močno spremeni sliko dogajanja.
(Pozneje se je izkazalo, da fizične nevarnosti za dvorano ni bilo, saj je bila hermetično zaprta s strehe. Ogrožen je bil le hladilni sistem te dvorane.)
15:07. Omogočamo izvajanje ukazov na strežnikih v pospešenem načinu brez dodatnih preverjanj ().
15:08. Temperatura v dvoranah je v mejah normale.
15: 12. Zabeležen je bil dvig temperature v dvoranah.
15:13. Več kot polovica strežnikov v podatkovnem centru je izklopljenih. Nadaljujmo.
15:16. Sprejet je bil sklep o izklopu vse opreme.
15:21. Začnemo izklapljati napajanje strežnikov brez stanja, ne da bi pravilno zaustavili aplikacijo in operacijski sistem.
15:23. Dodeljena je skupina ljudi, odgovornih za MS SQL (malo jih je, odvisnost storitev od njih ni velika, vendar postopek za obnovitev funkcionalnosti traja dlje in je bolj zapleten kot na primer Cassandra).
Depresija
15: 25. Prejeta je bila informacija o izklopu električne energije v štirih dvoranah od 16 (št. 6, 7, 8, 9). Naša oprema se nahaja v hali 7 in 8. O naših dveh dvoranah (št. 1 in 3) ni podatkov.
Običajno se ob požarih napajanje takoj izklopi, v tem primeru pa zaradi usklajenega dela gasilcev in tehničnega osebja podatkovnega centra ni bilo izklopljeno povsod in ne takoj, ampak po potrebi.
(Kasneje je bilo ugotovljeno, da v hali 8 in 9 elektrika ni bila izklopljena.)
15:28. Začenjamo uvajati baze podatkov MS SQL iz varnostnih kopij v drugih podatkovnih centrih.
Kako dolgo bo to trajalo? Ali je dovolj zmogljivosti omrežja za celotno pot?
15: 37. Zabeležen je bil izpad nekaterih delov omrežja.
Vodstvo in proizvodno omrežje sta fizično izolirana drug od drugega. Če je proizvodno omrežje na voljo, lahko greste na strežnik, zaustavite aplikacijo in izklopite OS. Če ni na voljo, se lahko prijavite prek IPMI, zaustavite aplikacijo in izklopite OS. Če ni nobenega od omrežij, potem ne morete storiti ničesar. "Hvala, Cap!", si boste mislili.
"In na splošno je veliko nemira," bi lahko tudi pomislili.
Stvar je v tem, da strežniki tudi brez ognja proizvajajo ogromno toplote. Natančneje, ko je hlajenje, proizvajajo toploto, ko hlajenja ni, pa ustvarijo peklenski pekel, ki bo v najboljšem primeru stopil del opreme in izklopil drug del, v najslabšem pa ... povzročil požar v dvorani, ki bo skoraj zagotovo uničil vse.
15:39. Odpravljamo težave z bazo podatkov conf.
Baza podatkov conf je zaledje istoimenske storitve, ki jo uporabljajo vse produkcijske aplikacije za hitro spreminjanje nastavitev. Brez te baze ne moremo nadzorovati delovanja portala, lahko pa deluje sam portal.
15:41. Temperaturni senzorji na opremi jedrnega omrežja beležijo odčitke blizu največjega dovoljenega. To je škatla, ki zavzame celotno stojalo in zagotavlja delovanje vseh omrežij znotraj podatkovnega centra.
15:42. Sledilnik težav in wiki nista na voljo, preklopite v stanje pripravljenosti.
To ni proizvodnja, vendar je v primeru nesreče razpoložljivost kakršne koli baze znanja lahko kritična.
15:50. Eden od nadzornih sistemov se je izklopil.
Teh je več in so odgovorni za različne vidike storitev. Nekateri med njimi so konfigurirani tako, da delujejo avtonomno znotraj posameznega podatkovnega centra (to pomeni, da spremljajo samo svoj podatkovni center), drugi so sestavljeni iz porazdeljenih komponent, ki transparentno preživijo izgubo katerega koli podatkovnega centra.
V tem primeru je prenehal delovati , ki deluje v glavnem stanju pripravljenosti. Preklop v stanje pripravljenosti.
Sprejem
15:51. Vsi strežniki razen MS SQL so bili izklopljeni prek IPMI, ne da bi se pravilno zaustavili.
Ali ste pripravljeni na obsežno upravljanje strežnika prek IPMI, če je potrebno?
Prav tisti trenutek, ko je v tej fazi zaključeno reševanje opreme v podatkovnem centru. Vse, kar se je dalo narediti, je bilo narejeno. Nekateri kolegi si lahko oddahnejo.
16: 13. Prejete so bile informacije, da so freonske cevi iz klimatskih naprav počile na strehi - to bo odložilo zagon podatkovnega centra po odpravi požara.
16:19. Po podatkih tehničnega osebja podatkovnega centra se je dvigovanje temperature v dvoranah ustavilo.
17:10. Baza podatkov conf je bila obnovljena. Zdaj lahko spremenimo nastavitve aplikacije.
Zakaj je to tako pomembno, če je vse odporno na napake in deluje tudi brez enega podatkovnega centra?
Prvič, vse ni odporno na napake. Obstajajo različne sekundarne storitve, ki še niso dovolj dobro prestale napake v podatkovnem centru, in obstajajo baze podatkov v glavnem stanju pripravljenosti. Možnost upravljanja nastavitev vam omogoča, da naredite vse, kar je potrebno, da zmanjšate vpliv posledic nesreče na uporabnike tudi v težkih razmerah.
Drugič, postalo je jasno, da delovanje podatkovnega centra v prihodnjih urah ne bo v celoti vzpostavljeno, zato je bilo treba sprejeti ukrepe, da dolgotrajna nedostopnost replik ne bo povzročila dodatnih težav, kot so polni diski v preostale podatkovne centre.
17:29. Čas za pico! Zaposlujemo ljudi, ne robotov.
Rehabilitacija
18:02. V halah št. 8 (naša), 9, 10 in 11 se je temperatura ustalila. V eni od tistih, ki ostanejo izklopljene (št. 7), je naša oprema in tam temperatura še naprej narašča.
18:31. Dali so zeleno luč za zagon naprav v halah št. 1 in 3 - teh halah požar ni prizadel.
Trenutno se zaženejo strežniki v halah št. 1, 3, 8, začenši z najbolj kritičnimi. Preveri se pravilno delovanje vseh delujočih storitev. Še vedno so težave s dvorano št.
18:44. Tehnično osebje podatkovnega centra je ugotovilo, da v sobi št. 7 (kjer se nahaja samo naša oprema) številni strežniki niso izklopljeni. Po naših podatkih je tam še vedno na spletu 26 strežnikov. Po drugem preverjanju najdemo 58 strežnikov.
20:18. Tehniki podatkovnega centra vpihajo zrak skozi neklimatiziran prostor skozi mobilne kanale, ki potekajo skozi hodnike.
23:08. Prvega admina so poslali domov. Nekdo mora ponoči spati, da lahko jutri nadaljuje delo. Nato bomo izdali še nekaj skrbnikov in razvijalcev.
02:56. Lansirali smo vse, kar se je dalo lansirati. Vse storitve veliko preverjamo z avtomatskimi testi.
03:02. Obnovljena je klimatizacija v zadnji, 7. dvorani.
03:36. Fronte v podatkovnem centru smo prenesli v rotacijo v DNS. Od tega trenutka začne prihajati uporabniški promet.
Večino administrativne ekipe pošiljamo domov. Nekaj ljudi pa pustimo za sabo.
Mala pogosta vprašanja:
V: Kaj se je zgodilo od 18:31 do 02:56?
O: Po »akcijskem načrtu za nesreče« zaženemo vse storitve, začenši z najpomembnejšimi. V tem primeru koordinator v klepetu izda storitev brezplačnemu skrbniku, ki preveri, ali sta se operacijski sistem in aplikacija zagnala, ali obstajajo napake in ali so indikatorji normalni. Po končanem zagonu sporoči klepetu, da je prost in od koordinatorja prejme novo storitev.
Proces dodatno upočasni okvarjena strojna oprema. Tudi če sta zaustavitev OS in zaustavitev strežnikov potekala pravilno, se nekateri strežniki ne vrnejo zaradi nenadne okvare diskov, pomnilnika in ohišja. Ob izpadu električne energije se stopnja napak poveča.
V: Zakaj ne morete zagnati vsega naenkrat in nato popraviti, kar se prikaže pri spremljanju?
O: Vse je treba narediti postopoma, ker obstajajo odvisnosti med storitvami. In vse je treba preveriti takoj, brez čakanja na spremljanje - ker je bolje, da se s težavami spopademo takoj, ne da čakamo, da se poslabšajo.
7:40. Zadnji admin (koordinator) je šel spat. Delo prvega dne je zaključeno.
8:09. Prvi razvijalci, inženirji podatkovnih centrov in skrbniki (vključno z novim koordinatorjem) so začeli z obnovitvenimi deli.
09:37. Začeli smo dvigovati dvorano št. 7 (zadnjo).
Hkrati pa nadaljujemo z obnavljanjem tistega, kar ni bilo popravljeno v drugih prostorih: zamenjava diskov/pomnilnika/strežnikov, popravljanje vsega, kar “gori” pri nadzoru, zamenjava vlog nazaj v master-standby shemah in druge malenkosti, ki jih je. vseeno precej.
17:08. Omogočamo vsa redna dela s proizvodnjo.
21:45. Delo drugega dne je zaključeno.
09:45. Danes je petek. Pri spremljanju je še kar nekaj manjših težav. Vikend je pred nami, vsi si želijo sprostitve. Še naprej množično popravljamo vse, kar se da. Redna skrbniška opravila, ki bi jih lahko preložili, so bila odložena. Koordinator je nov.
15:40. Nenadoma se je polovica sklada jedrne omrežne opreme v DRUGEM podatkovnem centru znova zagnala. Fronte so bile umaknjene iz rotacije, da bi zmanjšali tveganja. Za uporabnike ni učinka. Kasneje se je izkazalo, da je šlo za pokvarjeno podvozje. Koordinator dela na sanaciji dveh nesreč hkrati.
17:17. Delovanje omrežja v drugem podatkovnem centru je bilo obnovljeno, vse je bilo preverjeno. Podatkovni center se začne rotirati.
18:29. Dela tretjega dne in nasploh obnova po nesreči so končana.
spremna beseda
04.04.2013 , "Sošolci" — portal je bil tri dni popolnoma ali delno nedostopen. V vsem tem času je več kot 100 ljudi iz različnih mest, iz različnih podjetij (še enkrat najlepša hvala!), na daljavo in neposredno v podatkovnih centrih, ročno in avtomatsko, popravilo na tisoče strežnikov.
Potegnili smo zaključke. Da se to ne bi več dogajalo, smo izvedli in izvajamo obsežna dela še danes.
Katere so glavne razlike med trenutno nesrečo in 404?
- Imamo "akcijski načrt za nesreče". Enkrat na četrtletje izvajamo vaje - igramo vloge izrednih razmer, ki jih mora skupina skrbnikov (vsi po vrsti) odpraviti s pomočjo »Načrta ukrepanja v sili«. Vodilni sistemski administratorji se izmenjujejo v vlogi koordinatorja.
- Četrtletno v testnem načinu izoliramo podatkovne centre (vse po vrsti) preko omrežij LAN in WAN, kar nam omogoča sprotno prepoznavanje ozkih grl.
- Manj poškodovanih diskov, ker smo poostrili standarde: manj obratovalnih ur, strožje mejne vrednosti za S.M.A.R.T.,
- Popolnoma smo opustili BerkeleyDB, staro in nestabilno bazo podatkov, ki je zahtevala veliko časa za obnovitev po ponovnem zagonu strežnika.
- Zmanjšali smo število strežnikov z MS SQL in zmanjšali odvisnost od preostalih.
- Imamo svoje , kamor že dve leti aktivno selimo vse storitve. Oblak močno poenostavi celoten cikel dela z aplikacijo, v primeru nesreče pa nudi edinstvena orodja, kot so:
- pravilna zaustavitev vseh aplikacij z enim klikom;
- enostavna selitev aplikacij iz okvarjenih strežnikov;
- samodejno razvrščen (po prioriteti storitev) zagon celotnega podatkovnega centra.
Nesreča, opisana v tem članku, je bila največja po 404. dnevu. Seveda ni šlo vse gladko. Tako je na primer med nedosegljivostjo v požaru poškodovanega podatkovnega centra v drugem podatkovnem centru odpovedal disk na enem od strežnikov, kar pomeni, da je ostala dostopna le ena od treh replik v gruči Cassandra, zato je 4,2 % mobilnih uporabniki aplikacije se niso mogli prijaviti. Hkrati so že povezani uporabniki nadaljevali z delom. Skupno je bilo zaradi nesreče ugotovljenih več kot 30 težav - od banalnih hroščev do pomanjkljivosti v arhitekturi storitev.
Najpomembnejša razlika med sedanjo nesrečo in 404. pa je v tem, da so uporabniki med odpravljanjem posledic požara še vedno pošiljali sporočila in video klice na , igrali igrice, poslušali glasbo, si dajali darila, gledali videe, TV serije in TV kanale v , in tudi pretočen .
Kako potekajo vaše nesreče?
Vir: www.habr.com