Kako biste se osjećali da jednog lijepog ljetnog dana podatkovni centar s vašom opremom izgleda ovako?
Bok svima! Moje ime je Dmitry Samsonov, radim kao vodeći sistemski administrator u "" Na fotografiji je prikazan jedan od četiri podatkovna centra u kojima je instalirana oprema koja služi našem projektu. Iza ovih zidova nalazi se oko 4 tisuće komada opreme: poslužitelji, sustavi za pohranu podataka, mrežna oprema itd. - gotovo ⅓ sve naše opreme.
Većina poslužitelja je Linux. Tu je i nekoliko desetaka poslužitelja na Windowsima (MS SQL) - naše nasljeđe koje sustavno napuštamo dugi niz godina.
Tako su 5. lipnja 2019. u 14:35 inženjeri u jednom od naših podatkovnih centara prijavili požarni alarm.
poricanje
14:45 sati. Manji dimni incidenti u podatkovnim centrima češći su nego što mislite. Indikatori unutar dvorana bili su normalni, pa je naša prva reakcija bila relativno mirna: uveli su zabranu rada s produkcijom, odnosno bilo kakvih promjena konfiguracije, izbacivanja novih verzija itd., osim radova vezanih uz popravljanje nečega.
Ljutnja
Jeste li ikad pokušali od vatrogasaca saznati gdje je točno izbio požar na krovu ili sami popeti se na gorući krov kako biste procijenili situaciju? Koliki će biti stupanj povjerenja u informacije primljene preko pet osoba?
14: 50. Zaprimljena je informacija da se vatra približava sustavu hlađenja. Ali hoće li doći? Dežurni administrator sustava uklanja vanjski promet s pročelja ovog podatkovnog centra.
Trenutačno su frontovi svih naših servisa duplicirani u tri podatkovna centra, balansiranje se koristi na DNS razini, što nam omogućuje uklanjanje adresa jednog podatkovnog centra iz DNS-a, čime štitimo korisnike od potencijalnih problema s pristupom uslugama . Ako je već došlo do problema u podatkovnom centru, on automatski izlazi iz rotacije. Više možete pročitati ovdje:
Požar nas još nije zahvatio ni na koji način – nema štete ni na korisnicima ni na opremi. Je li ovo nesreća? Prvi odjeljak dokumenta „Akcijski plan za nesreću” definira pojam „nesreće”, a odjeljak završava ovako:
«Ako postoji sumnja ima li nesreće ili ne, onda je nesreća!»
14:53. Imenuje se koordinator za hitne slučajeve.
Koordinator je osoba koja kontrolira komunikaciju između svih sudionika, procjenjuje razmjere nesreće, koristi Plan djelovanja u hitnim slučajevima, privlači potrebno osoblje, prati završetak popravaka i što je najvažnije, delegira sve zadatke. Drugim riječima, to je osoba koja upravlja cijelim procesom hitnog odgovora.
Nagodba
15:01 sati. Počinjemo onemogućavati poslužitelje koji nisu povezani s proizvodnjom.
15:03 sati. Ispravno isključujemo sve rezervirane usluge.
Ovo ne uključuje samo frontove (kojima do sada korisnici više ne pristupaju) i njihove pomoćne usluge (poslovnu logiku, predmemorije itd.), već i razne baze podataka s faktorom replikacije 2 ili više (, , , itd.).
15: 06. Pristigla je informacija da požar prijeti jednoj od hala podatkovnog centra. Nemamo opremu u ovoj prostoriji, ali činjenica da se vatra može proširiti s krova na hale uvelike mijenja sliku onoga što se događa.
(Kasnije se pokazalo da fizičke opasnosti za dvoranu nije bilo, jer je bila hermetički zatvorena s krova. Prijetnja je bila samo za sustav hlađenja ove dvorane.)
15:07. Dopuštamo izvršavanje naredbi na poslužiteljima u ubrzanom načinu rada bez dodatnih provjera ().
15:08 sati. Temperatura u dvoranama je u granicama normale.
15: 12. Zabilježen je porast temperature u dvoranama.
15:13. Više od polovice poslužitelja u podatkovnom centru je isključeno. Nastavimo.
15:16. Donesena je odluka da se sva oprema isključi.
15:21. Počinjemo isključivati napajanje poslužitelja bez statusa bez pravilnog gašenja aplikacije i operativnog sustava.
15:23. Dodijeljena je grupa ljudi odgovornih za MS SQL (malo ih je, ovisnost servisa o njima nije velika, ali postupak vraćanja funkcionalnosti traje dulje i kompliciraniji je od npr. Cassandre).
depresija
15: 25. Zaprimljena je informacija o isključenju struje u četiri dvorane od 16 (br. 6, 7, 8, 9). Naša oprema se nalazi u halama 7 i 8. Nema podataka o naše dvije dvorane (br. 1 i 3).
Obično se tijekom požara napajanje odmah isključi, ali u ovom slučaju, zahvaljujući koordiniranom radu vatrogasaca i tehničkog osoblja podatkovnog centra, nije isključeno svugdje i ne odmah, već po potrebi.
(Kasnije se pokazalo da u halama 8 i 9 nije isključena struja.)
15:28. Počinjemo implementirati MS SQL baze podataka iz sigurnosnih kopija u drugim podatkovnim centrima.
Koliko će to trajati? Ima li dovoljno mrežnog kapaciteta za cijelu rutu?
15: 37. Zabilježeno je gašenje nekih dijelova mreže.
Uprava i proizvodna mreža fizički su izolirane jedna od druge. Ako je proizvodna mreža dostupna, možete otići na poslužitelj, zaustaviti aplikaciju i isključiti OS. Ako nije dostupan, možete se prijaviti putem IPMI-ja, zaustaviti aplikaciju i isključiti OS. Ako nema niti jedne mreže, ne možete ništa učiniti. “Hvala, Cap!”, pomislit ćete.
"I općenito, ima puno previranja", također možete pomisliti.
Stvar je u tome što serveri, čak i bez požara, stvaraju ogromnu količinu topline. Točnije, kad ima hlađenja stvaraju toplinu, a kad ga nema stvaraju pakleni pakao, koji će u najboljem slučaju otopiti dio opreme i isključiti drugi dio, au najgorem... izazvati požar unutar dvorane, koji će gotovo zajamčeno uništiti sve.
15:39 sati. Rješavamo probleme s conf bazom podataka.
Conf baza podataka je backend za istoimeni servis, koji koriste sve proizvodne aplikacije za brzu promjenu postavki. Bez ove baze ne možemo kontrolirati rad portala, ali sam portal može funkcionirati.
15:41. Senzori temperature na opremi jezgrene mreže bilježe očitanja blizu maksimalno dopuštenih. Ovo je kutija koja zauzima cijeli rack i osigurava rad svih mreža unutar podatkovnog centra.
15:42. Praćenje problema i wiki nisu dostupni, prijeđite u stanje pripravnosti.
Ovo nije proizvodnja, ali u slučaju nesreće dostupnost bilo koje baze znanja može biti kritična.
15:50 sati. Jedan od sustava za nadzor se isključio.
Ima ih nekoliko, a odgovorni su za različite aspekte usluga. Neki od njih su konfigurirani za autonomni rad unutar svakog podatkovnog centra (odnosno, nadziru samo svoj podatkovni centar), drugi se sastoje od distribuiranih komponenti koje transparentno preživljavaju gubitak bilo kojeg podatkovnog centra.
U ovom slučaju je prestao raditi , koji radi u glavnom stanju pripravnosti. Prebačeno u stanje pripravnosti.
Posvajanje
15:51. Svi poslužitelji osim MS SQL-a isključeni su putem IPMI-ja bez pravilnog gašenja.
Jeste li spremni za masovno upravljanje poslužiteljem putem IPMI-ja ako je potrebno?
Sam trenutak kada je u ovoj fazi završeno spašavanje opreme u podatkovnom centru. Učinjeno je sve što se moglo učiniti. Neki kolege mogu odmoriti.
16: 13. Primljene su informacije da su freonske cijevi iz klima uređaja pukle na krovu - to će odgoditi pokretanje podatkovnog centra nakon uklanjanja požara.
16:19. Prema podacima dobivenim od tehničkog osoblja podatkovnog centra, porast temperature u dvoranama je zaustavljen.
17:10. Conf baza podataka je vraćena. Sada možemo promijeniti postavke aplikacije.
Zašto je to toliko važno ako je sve otporno na greške i radi čak i bez jednog podatkovnog centra?
Prvo, nije sve otporno na greške. Postoje razne sekundarne usluge koje još nisu dovoljno dobro preživjele kvar podatkovnog centra, a postoje i baze podataka u glavnom-pripravnom načinu rada. Mogućnost upravljanja postavkama omogućuje vam da učinite sve što je potrebno kako biste smanjili utjecaj posljedica nesreće na korisnike čak iu teškim uvjetima.
Drugo, postalo je jasno da rad podatkovnog centra neće biti u potpunosti uspostavljen u nadolazećim satima, pa je bilo potrebno poduzeti mjere kako dugotrajna nedostupnost replika ne bi dovela do dodatnih problema poput punih diskova u preostali podatkovni centri.
17:29. Vrijeme je za pizzu! Zapošljavamo ljude, a ne robote.
Rehabilitacija
18:02 sati. U halama broj 8 (naša), 9, 10 i 11 temperatura se stabilizirala. U jednoj od onih koja ostaje offline (br. 7) nalazi se naša oprema, a tamo temperatura i dalje raste.
18:31. Dali su odobrenje za pokretanje opreme u halama broj 1 i 3 - te hale nisu bile zahvaćene požarom.
Trenutno se puštaju serveri u halama br. 1, 3, 8, počevši od onih najkritičnijih. Provjerava se ispravan rad svih pokrenutih servisa. I dalje ima problema s dvoranom broj 7.
18:44 sati. Tehničko osoblje podatkovnog centra otkrilo je da u sobi br. 7 (u kojoj se nalazi samo naša oprema) mnogi poslužitelji nisu isključeni. Prema našim podacima, 26 servera je ostalo online. Nakon druge provjere nalazimo 58 poslužitelja.
20:18. Tehničari podatkovnog centra upuhuju zrak kroz neklimatiziranu prostoriju kroz mobilne kanale koji prolaze kroz hodnike.
23:08. Prvi admin je poslan kući. Netko mora spavati noću da bi sutra nastavio s radom. Zatim ćemo pustiti još neke administratore i programere.
02:56. Pokrenuli smo sve što se moglo pokrenuti. Puno provjeravamo sve usluge pomoću automatskih testova.
03:02. U posljednjoj, 7. hali je obnovljena klimatizacija.
03:36. Počeli smo rotirati fronte u podatkovnom centru u DNS-u. Od ovog trenutka počinje pristizati promet korisnika.
Većinu administrativnog tima šaljemo kući. Ali ostavljamo nekoliko ljudi iza sebe.
Mali FAQ:
P: Što se dogodilo od 18:31 do 02:56?
O: Prateći “Akcijski plan za katastrofe”, pokrećemo sve usluge, počevši od onih najvažnijih. U tom slučaju koordinator u chatu izdaje uslugu besplatnom administratoru, koji provjerava jesu li OS i aplikacija pokrenuti, ima li grešaka i jesu li indikatori normalni. Nakon što je lansiranje završeno, javlja chatu da je slobodan i prima novu uslugu od koordinatora.
Proces dodatno usporava neispravan hardver. Čak i ako je zaustavljanje OS-a i gašenje poslužitelja prošlo ispravno, neki se poslužitelji ne vraćaju zbog iznenadnog kvara diskova, memorije i šasije. Kada nestane struje, stopa kvarova se povećava.
P: Zašto jednostavno ne možete pokrenuti sve odjednom, a zatim popraviti ono što se pojavi u praćenju?
O: Sve se mora raditi postupno, jer postoje ovisnosti između usluga. I sve treba provjeriti odmah, ne čekajući praćenje - jer bolje je riješiti probleme odmah, ne čekati da se pogoršaju.
7:40. Zadnji admin (koordinator) je otišao na spavanje. Prvi radni dan je završen.
8:09. Prvi programeri, inženjeri i administratori podatkovnih centara (uključujući novog koordinatora) započeli su radove obnove.
09:37 sati. Počeli smo podizati halu broj 7 (posljednju).
Istovremeno, nastavljamo vraćati ono što nije popravljeno u drugim sobama: zamjena diskova/memorije/servera, popravljanje svega što “gori” u nadzoru, prebacivanje uloga natrag u master-standby shemama i ostale sitnice, kojih ima ipak dosta.
17:08 sati. Omogućavamo sav redovan rad s proizvodnjom.
21:45 sati. Radovi drugog dana su završeni.
09:45 sati. Danas je petak. Ima još dosta malih problema u praćenju. Vikend je pred nama, svi se žele opustiti. Nastavljamo masovno popravljati sve što možemo. Redovni administratorski zadaci koji su mogli biti odgođeni su odgođeni. Koordinator je novi.
15:40 sati. Odjednom se polovica hrpe opreme jezgrene mreže u DRUGOM podatkovnom centru ponovno pokrenula. Fronte su izbačene iz rotacije kako bi se rizici sveli na minimum. Nema učinka za korisnike. Kasnije se pokazalo da je riječ o neispravnoj šasiji. Koordinator radi na sanaciji dvije nesreće odjednom.
17:17. Rad mreže u drugom podatkovnom centru je obnovljen, sve je provjereno. Data centar se stavlja u rotaciju.
18:29. Radovi trećeg dana i općenito obnova nakon nesreće su završeni.
pogovor
04.04.2013 , "Kolege" — tri dana portal je bio potpuno ili djelomično nedostupan. Kroz cijelo ovo vrijeme, više od 100 ljudi iz različitih gradova, iz različitih tvrtki (veliko hvala još jednom!), daljinski i direktno u podatkovnim centrima, ručno i automatski, popravljalo je tisuće servera.
Izvukli smo zaključke. Kako se to više ne bi dogodilo, proveli smo i provodimo opsežne radove do danas.
Koje su glavne razlike između sadašnje nesreće i 404?
- Imamo “Akcijski plan za nesreće”. Jednom tromjesečno provodimo vježbe - igramo izvanrednu situaciju, koju grupa administratora (svi redom) mora ukloniti pomoću "Plana djelovanja u hitnim slučajevima". Vodeći administratori sustava izmjenjuju se u ulozi koordinatora.
- Tromjesečno, u testnom načinu, izoliramo podatkovne centre (sve redom) putem LAN i WAN mreža, što nam omogućuje promptnu identifikaciju uskih grla.
- Manje pokvarenih diskova, jer smo pooštrili standarde: manje radnih sati, stroži pragovi za SMART,
- Potpuno smo napustili BerkeleyDB, staru i nestabilnu bazu podataka koja je nakon ponovnog pokretanja poslužitelja zahtijevala dosta vremena za oporavak.
- Smanjili smo broj poslužitelja s MS SQL-om i smanjili ovisnost o preostalima.
- Imamo svoje , gdje već dvije godine aktivno migriramo sve usluge. Cloud uvelike pojednostavljuje cijeli ciklus rada s aplikacijom, au slučaju nezgode pruža jedinstvene alate kao što su:
- ispravno zaustavljanje svih aplikacija jednim klikom;
- jednostavna migracija aplikacija s pokvarenih poslužitelja;
- automatsko rangirano (prema prioritetu usluge) pokretanje cijelog podatkovnog centra.
Nesreća opisana u ovom članku bila je najveća od 404. dana. Naravno, nije sve išlo glatko. Primjerice, za vrijeme nedostupnosti podatkovnog centra oštećenog požarom u drugom podatkovnom centru došlo je do kvara diska na jednom od poslužitelja, odnosno ostala je dostupna samo jedna od tri replike u klasteru Cassandra, zbog čega je 4,2% mobilnih korisnici aplikacije nisu se mogli prijaviti. Istodobno, već povezani korisnici nastavili su s radom. Ukupno je kao posljedica nesreće identificirano više od 30 problema - od banalnih grešaka do nedostataka u arhitekturi usluge.
No, najvažnija razlika između sadašnje nesreće i 404. je ta što su korisnici, dok smo mi otklanjali posljedice požara, još uvijek slali poruke i video pozive na , igrali igrice, slušali glazbu, davali jedni drugima darove, gledali videa, TV serije i TV kanale u , a također je streamano .
Kako prolaze vaše nezgode?
Izvor: www.habr.com