Ako by ste sa cítili, keby jedného pekného letného dňa vyzeralo dátové centrum s vaším vybavením takto?
Ahojte všetci! Moje meno je Dmitrij Samsonov, pracujem ako vedúci systémový administrátor v "" Na fotografii je jedno zo štyroch dátových centier, kde je nainštalované zariadenie slúžiace nášmu projektu. Za týmito stenami sa nachádza asi 4 XNUMX kusov zariadení: servery, systémy na ukladanie údajov, sieťové zariadenia atď. - takmer ⅓ všetkého nášho vybavenia.
Väčšina serverov je Linux. Existuje aj niekoľko desiatok serverov na Windows (MS SQL) – naše dedičstvo, od ktorého sa už dlhé roky systematicky upúšťame.
Takže 5. júna 2019 o 14:35 inžinieri v jednom z našich dátových centier nahlásili požiarny poplach.
popretie
14:45. Drobné dymové incidenty v dátových centrách sú bežnejšie, ako si myslíte. Ukazovatele vo vnútri hál boli v norme, takže naša prvá reakcia bola relatívne pokojná: zaviedli zákaz práce s výrobou, teda akýchkoľvek zmien konfigurácie, nasadzovania nových verzií atď., okrem prác spojených s opravou.
Hnev
Skúšali ste niekedy od hasičov zistiť, kde presne na streche došlo k požiaru, alebo sa sami dostať na horiacu strechu, aby ste zhodnotili situáciu? Aký bude stupeň dôvery v informácie prijaté prostredníctvom piatich ľudí?
14: 50. Boli prijaté informácie, že požiar sa blíži k chladiacemu systému. Ale príde to? Službukonajúci správca systému odstráni externý prenos z prednej časti tohto dátového centra.
V súčasnosti sú fronty všetkých našich služieb duplikované v troch dátových centrách, používa sa vyvažovanie na úrovni DNS, čo nám umožňuje odstrániť adresy jedného dátového centra z DNS, čím chránime používateľov pred potenciálnymi problémami s prístupom k službám. . Ak sa už v dátovom centre vyskytli problémy, opustí rotáciu automaticky. Viac si môžete prečítať tu:
Požiar sa nás zatiaľ nijako nedotkol – nedošlo k poškodeniu používateľov ani zariadenia. Je to nehoda? Prvá časť dokumentu „Akčný plán nehody“ definuje pojem „nehoda“ a časť končí takto:
«Ak existujú pochybnosti, či došlo k nehode alebo nie, potom je to nehoda!»
14:53. Je vymenovaný núdzový koordinátor.
Koordinátor je osoba, ktorá riadi komunikáciu medzi všetkými účastníkmi, posudzuje rozsah nehody, využíva havarijný akčný plán, priťahuje potrebný personál, sleduje dokončenie opráv a hlavne deleguje prípadné úlohy. Inými slovami, je to osoba, ktorá riadi celý proces núdzovej reakcie.
aukcie
15:01. Začneme deaktivovať servery, ktoré nesúvisia s výrobou.
15:03. Správne vypíname všetky vyhradené služby.
To zahŕňa nielen fronty (ku ktorým už používatelia nemajú prístup) a ich pomocné služby (obchodná logika, vyrovnávacie pamäte atď.), ale aj rôzne databázy s replikačným faktorom 2 alebo vyšším (, , , atď.).
15: 06. Boli prijaté informácie, že požiar ohrozuje jednu z hál dátového centra. V tejto miestnosti nemáme vybavenie, ale skutočnosť, že oheň sa môže šíriť zo strechy do hál, výrazne mení obraz toho, čo sa deje.
(Neskôr sa ukázalo, že k žiadnemu fyzickému ohrozeniu haly nedošlo, keďže bola hermeticky uzavretá zo strechy. Ohrozenie bolo len pre chladiaci systém tejto haly.)
15:07. Umožňujeme vykonávanie príkazov na serveroch v zrýchlenom režime bez dodatočných kontrol ().
15:08. Teplota v halách je v medziach normy.
15: 12. Bol zaznamenaný nárast teploty v halách.
15:13. Viac ako polovica serverov v dátovom centre je vypnutá. Pokračujme.
15:16. Bolo prijaté rozhodnutie vypnúť všetky zariadenia.
15:21. Začneme vypínať napájanie bezstavových serverov bez správneho vypnutia aplikácie a operačného systému.
15:23. Je vyčlenená skupina ľudí zodpovedných za MS SQL (je ich málo, závislosť služieb od nich nie je veľká, ale postup obnovy funkčnosti trvá dlhšie a je komplikovanejší ako napríklad Cassandra).
depresie
15: 25. Bola prijatá informácia o vypnutí prúdu v štyroch sálach zo 16 (č. 6, 7, 8, 9). Naše vybavenie sa nachádza v halách 7 a 8. O našich dvoch halách (č. 1 a 3) nie sú žiadne informácie.
Zvyčajne sa pri požiaroch okamžite vypne napájanie, ale v tomto prípade vďaka koordinovanej práci hasičov a technického personálu dátového centra nebolo vypnuté všade a nie okamžite, ale podľa potreby.
(Neskôr sa zistilo, že v halách 8 a 9 nebolo vypnuté napájanie.)
15:28. Začíname nasadzovať MS SQL databázy zo záloh v iných dátových centrách.
Ako dlho to trvá? Je dostatočná kapacita siete pre celú trasu?
15: 37. Bolo zaznamenané odstavenie niektorých častí siete.
Manažment a produkčná sieť sú od seba fyzicky izolované. Ak je produkčná sieť k dispozícii, môžete prejsť na server, zastaviť aplikáciu a vypnúť OS. Ak nie je k dispozícii, môžete sa prihlásiť cez IPMI, zastaviť aplikáciu a vypnúť OS. Ak neexistuje žiadna zo sietí, nemôžete robiť nič. "Ďakujem, Cap!", pomyslíte si.
"A vo všeobecnosti je tu veľa nepokojov," možno si tiež myslíte.
Ide o to, že servery aj bez ohňa generujú obrovské množstvo tepla. Presnejšie, pri chladení vytvárajú teplo a keď nechladí, vytvárajú pekelné peklo, ktoré v najlepšom prípade roztopí časť zariadenia a vypne inú časť a v horšom... spôsobí vo vnútri požiar halu, ktorá takmer zaručene všetko zničí.
15:39. Opravujeme problémy s databázou conf.
Databáza conf je backend pre službu s rovnakým názvom, ktorú používajú všetky produkčné aplikácie na rýchlu zmenu nastavení. Bez tejto základne nemôžeme kontrolovať chod portálu, no samotný portál fungovať môže.
15:41. Snímače teploty na zariadení základnej siete zaznamenávajú hodnoty blízke maximálnej prípustnej hodnote. Ide o box, ktorý zaberá celý rack a zabezpečuje chod všetkých sietí vo vnútri dátového centra.
15:42. Sledovač problémov a wiki nie sú k dispozícii, prepnite do pohotovostného režimu.
Toto nie je výroba, ale v prípade nehody môže byť dostupnosť akejkoľvek vedomostnej základne kritická.
15:50. Jeden z monitorovacích systémov sa vypol.
Je ich niekoľko a zodpovedajú za rôzne aspekty služieb. Niektoré z nich sú nakonfigurované tak, aby fungovali autonómne v rámci každého dátového centra (to znamená, že monitorujú len svoje vlastné dátové centrum), iné pozostávajú z distribuovaných komponentov, ktoré transparentne prežijú stratu akéhokoľvek dátového centra.
V tomto prípade to prestalo fungovať , ktorý pracuje v režime master-standby. Prepnuté do pohotovostného režimu.
prijatie
15:51. Všetky servery okrem MS SQL boli vypnuté cez IPMI bez správneho vypnutia.
Ste pripravení na masívnu správu servera cez IPMI v prípade potreby?
Práve ten moment, kedy je v tejto fáze ukončená záchrana zariadení v dátovom centre. Všetko, čo sa dalo urobiť, bolo urobené. Niektorí kolegovia si môžu oddýchnuť.
16: 13. Dostali sa informácie, že na streche praskli freónové rúrky z klimatizácií – to oneskorí spustenie dátového centra po likvidácii požiaru.
16:19. Podľa údajov získaných od technického personálu dátového centra sa zvyšovanie teploty v halách zastavilo.
17:10. Databáza conf bola obnovená. Teraz môžeme zmeniť nastavenia aplikácie.
Prečo je to také dôležité, ak je všetko odolné voči chybám a funguje aj bez jedného dátového centra?
Po prvé, nie všetko je odolné voči chybám. Existujú rôzne sekundárne služby, ktoré ešte dostatočne neprežili zlyhanie dátového centra a existujú databázy v režime master-standby. Schopnosť spravovať nastavenia vám umožňuje urobiť všetko potrebné na minimalizáciu dopadu následkov nehody na používateľov aj v náročných podmienkach.
Po druhé, bolo jasné, že prevádzka dátového centra nebude v najbližších hodinách úplne obnovená, preto bolo potrebné prijať opatrenia, aby dlhodobá nedostupnosť replík neviedla k ďalším problémom, ako sú plné disky v zostávajúce dátové centrá.
17:29. Čas na pizzu! Zamestnávame ľudí, nie robotov.
Rehabilitácia
18:02. V halách č.8 (naša), 9, 10 a 11 sa teplota ustálila. V jednom z tých, ktoré zostávajú offline (č. 7), sa nachádza naše zariadenie a teplota tam stále stúpa.
18:31. Dali súhlas na spustenie techniky v halách č. 1 a 3 - tieto haly požiar nezasiahol.
V súčasnosti sa spúšťajú servery v halách č. 1, 3, 8, počnúc tými najkritickejšími. Kontroluje sa správna činnosť všetkých spustených služieb. S halou č.7 sú stále problémy.
18:44. Technický personál dátového centra zistil, že v miestnosti č. 7 (kde sa nachádza len naše zariadenie) nie je vypnutých veľa serverov. Podľa našich údajov tam zostáva online 26 serverov. Po druhej kontrole nájdeme 58 serverov.
20:18. Technici dátového centra fúkajú vzduch cez neklimatizovanú miestnosť cez mobilné potrubia vedúce cez chodby.
23:08. Prvý admin bol poslaný domov. Niekto potrebuje v noci spať, aby mohol zajtra pokračovať v práci. Ďalej uvoľníme ďalších správcov a vývojárov.
02:56. Spustili sme všetko, čo sa spustiť dalo. Vykonávame veľa kontroly všetkých služieb pomocou automatických testov.
03:02. V poslednej, 7. hale bola obnovená vzduchotechnika.
03:36. Uviedli sme fronty v dátovom centre do rotácie v DNS. Od tohto momentu začína prichádzať návštevnosť používateľov.
Väčšinu administratívneho tímu posielame domov. Ale nechávame tu pár ľudí.
Malé časté otázky:
O: Čo sa stalo od 18:31 do 02:56?
Odpoveď: Podľa „Akčného plánu pre katastrofy“ spúšťame všetky služby, počnúc tými najdôležitejšími. V tomto prípade koordinátor v chate odovzdá službu bezplatnému správcovi, ktorý skontroluje, či sa OS a aplikácia spustili, či nie sú nejaké chyby a či sú indikátory normálne. Po dokončení spustenia nahlási chatu, že je voľný a dostane od koordinátora novú službu.
Proces ďalej spomaľuje zlyhaný hardvér. Aj keď zastavenie OS a vypnutie serverov prebehlo správne, niektoré servery sa nevrátia z dôvodu náhleho zlyhania diskov, pamäte a šasi. Pri výpadku napájania sa zvyšuje poruchovosť.
Otázka: Prečo nemôžete spustiť všetko naraz a potom opraviť to, čo sa objaví pri monitorovaní?
A: Všetko treba robiť postupne, pretože medzi službami sú závislosti. A všetko by sa malo skontrolovať ihneď, bez čakania na monitorovanie - pretože je lepšie riešiť problémy hneď, bez čakania na ich zhoršenie.
7:40. Posledný admin (koordinátor) išiel spať. Práca prvého dňa bola dokončená.
8:09. Prví vývojári, inžinieri a správcovia dátových centier (vrátane nového koordinátora) začali s obnovou.
09:37. Začali sme dvíhať halu č. 7 (poslednú).
Zároveň pokračujeme v obnove toho, čo nebolo opravené v iných miestnostiach: výmena diskov/pamätí/serverov, oprava všetkého, čo „horí“ pri monitorovaní, prepínanie rolí späť v schémach master-standby a ďalšie drobnosti, ktorých je napriek tomu dosť veľa.
17:08. Umožňujeme všetky bežné práce s výrobou.
21:45. Práca na druhý deň je dokončená.
09:45. Dnes je Piatok. V monitorovaní je stále dosť malých problémov. Víkend je pred nami, každý si chce oddýchnuť. Naďalej masívne opravujeme všetko, čo sa dá. Bežné úlohy správcu, ktoré mohli byť odložené, boli odložené. Koordinátor je nový.
15:40. Zrazu sa reštartovala polovica zásobníka základných sieťových zariadení v INOM dátovom centre. Predné časti boli vyradené z rotácie, aby sa minimalizovali riziká. Pre používateľov to nemá žiadny účinok. Neskôr sa ukázalo, že išlo o chybný podvozok. Koordinátor pracuje na oprave dvoch nehôd naraz.
17:17. Prevádzka siete v inom dátovom centre bola obnovená, všetko bolo skontrolované. Dátové centrum je uvedené do rotácie.
18:29. Práce tretieho dňa a vo všeobecnosti obnova po nehode bola dokončená.
Doslov
04.04.2013 , "Spolužiaci" — tri dni bol portál úplne alebo čiastočne nedostupný. Počas celej tejto doby viac ako 100 ľudí z rôznych miest, z rôznych spoločností (ešte raz veľká vďaka!), na diaľku a priamo v dátových centrách, manuálne a automaticky, opravilo tisíce serverov.
Vyvodili sme závery. Aby sa to už neopakovalo, vykonali sme a vykonávame rozsiahle práce dodnes.
Aké sú hlavné rozdiely medzi súčasnou nehodou a 404?
- Máme „Akčný plán pre nehody“. Raz za štvrťrok robíme cvičenia – hráme rolu v núdzovej situácii, ktorú musí skupina administrátorov (všetci postupne) odstrániť pomocou „Núdzového akčného plánu“. V úlohe koordinátora sa striedajú poprední správcovia systému.
- Štvrťročne v testovacom režime izolujeme dátové centrá (všetky postupne) prostredníctvom sietí LAN a WAN, čo nám umožňuje rýchlo identifikovať úzke miesta.
- Menej rozbitých diskov, pretože sme sprísnili štandardy: menej prevádzkových hodín, prísnejšie prahové hodnoty pre SMART,
- Úplne sme opustili BerkeleyDB, starú a nestabilnú databázu, ktorá si vyžadovala veľa času na obnovenie po reštarte servera.
- Znížili sme počet serverov s MS SQL a znížili závislosť na zvyšných.
- My máme vlastné , kde už dva roky aktívne migrujeme všetky služby. Cloud výrazne zjednodušuje celý cyklus práce s aplikáciou a v prípade nehody poskytuje také unikátne nástroje ako:
- správne zastavenie všetkých aplikácií jedným kliknutím;
- jednoduchá migrácia aplikácií zo zlyhaných serverov;
- automatické zoradené (v poradí podľa priority služieb) spustenie celého dátového centra.
Nehoda opísaná v tomto článku bola najväčšia od 404. dňa. Samozrejme, nie všetko išlo hladko. Napríklad počas nedostupnosti požiarom poškodeného dátového centra v inom dátovom centre zlyhal disk na jednom zo serverov, to znamená, že prístupná zostala len jedna z troch replík v klastri Cassandra, čo je dôvod, prečo 4,2 % mobilných používatelia aplikácie sa nemohli prihlásiť . Zároveň pokračovali v práci už pripojení používatelia. Celkovo sa v dôsledku nehody zistilo viac ako 30 problémov - od banálnych chýb po nedostatky v architektúre služby.
Najdôležitejším rozdielom medzi súčasnou nehodou a 404-tou je však to, že kým sme odstraňovali následky požiaru, používatelia stále posielali textové správy a uskutočňovali videohovory hrali hry, počúvali hudbu, dávali si darčeky, pozerali videá, televízne seriály a televízne kanály , a tiež streamované .
Ako prebiehajú vaše nehody?
Zdroj: hab.com