Kako biste se osjećali da jednog lijepog ljetnog dana data centar sa vašom opremom izgleda ovako?
Zdravo svima! Moje ime je Dmitrij Samsonov, radim kao vodeći sistem administrator u "" Na fotografiji je jedan od četiri data centra u kojima je instalirana oprema koja služi našem projektu. Iza ovih zidova nalazi se oko 4 hiljade komada opreme: serveri, sistemi za skladištenje podataka, mrežna oprema itd. - skoro ⅓ sve naše opreme.
Većina servera je LinuxTakođer postoji nekoliko desetina servera na Windows (MS SQL) je naše naslijeđe, koje smo sistematski napuštali dugi niz godina.
Dakle, 5. juna 2019. u 14:35, inženjeri jednog od naših data centara prijavili su požarni alarm.
Denial
14:45. Manji incidenti s dimom u podatkovnim centrima češći su nego što mislite. Indikatori u halama bili su normalni, tako da je naša prva reakcija bila relativno mirna: uveli su zabranu rada sa proizvodnjom, odnosno bilo kakve promjene konfiguracije, puštanja novih verzija itd., osim radova vezanih za popravku nečega.
Gnev
Da li ste ikada pokušali da od vatrogasaca saznate gde je tačno došlo do požara na krovu, ili da sami dođete na krov koji gori da procenite situaciju? Koliki će biti stepen povjerenja u informacije primljene od pet osoba?
14: 50. Pristigla je informacija da se vatra približava rashladnom sistemu. Ali hoće li doći? Dežurni sistem administrator uklanja eksterni saobraćaj sa frontova ovog data centra.
Trenutno su frontovi svih naših servisa duplirani u tri data centra, balansiranje se koristi na nivou DNS-a, što nam omogućava da uklonimo adrese jednog data centra sa DNS-a, čime štitimo korisnike od potencijalnih problema sa pristupom uslugama. . Ako su se problemi već pojavili u podatkovnom centru, on automatski napušta rotaciju. Više možete pročitati ovdje:
Požar nas još ni na koji način nije zahvatio – nisu oštećeni ni korisnici ni oprema. Je li ovo nesreća? Prvi deo dokumenta „Akcioni plan u slučaju nesreće“ definiše pojam „Nesreća“, a deo se završava ovako:
«Ako postoji bilo kakva sumnja da li je došlo do nesreće ili ne, onda je to nesreća!»
14:53. Imenovan je koordinator za hitne slučajeve.
Koordinator je osoba koja kontroliše komunikaciju između svih učesnika, procjenjuje razmjere nesreće, koristi Plan akcije za hitne slučajeve, privlači potrebno osoblje, prati završetak popravki, i što je najvažnije, delegira sve zadatke. Drugim riječima, to je osoba koja upravlja cijelim procesom hitne reakcije.
Bargaining
15:01. Počinjemo da onemogućavamo servere koji nisu povezani sa proizvodnjom.
15:03. Ispravno isključujemo sve rezervisane usluge.
Ovo uključuje ne samo frontove (kojima korisnici do ovog trenutka više ne pristupaju) i njihove pomoćne usluge (poslovna logika, keš memorije, itd.), već i razne baze podataka sa faktorom replikacije 2 ili više (, , , itd.).
15: 06. Pristigla je informacija da požar prijeti jednoj od hala data centra. Nemamo opremu u ovoj prostoriji, ali činjenica da se vatra može proširiti sa krova na hodnike uvelike mijenja sliku onoga što se dešava.
(Kasnije se ispostavilo da nije bilo fizičke opasnosti po halu, jer je bila hermetički zatvorena sa krova. Prijetnja je bila samo za rashladni sistem ove hale.)
15:07. Dozvoljavamo izvršavanje naredbi na serverima u ubrzanom načinu rada bez dodatnih provjera ().
15:08. Temperatura u halama je u granicama normale.
15: 12. Zabilježen je porast temperature u salama.
15:13. Više od polovine servera u data centru je isključeno. Hajde da nastavimo.
15:16. Doneta je odluka da se sva oprema isključi.
15:21. Počinjemo da isključujemo napajanje servera bez stanja bez ispravnog gašenja aplikacije i operativnog sistema.
15:23. Dodijeljena je grupa ljudi odgovornih za MS SQL (malo ih je, ovisnost servisa o njima nije velika, ali procedura vraćanja funkcionalnosti traje duže i složenija je od, na primjer, Cassandre).
Depresija
15: 25. Pristigle su informacije o isključenju struje u četiri od ukupno 16 sala (br. 6, 7, 8, 9). Naša oprema se nalazi u halama 7 i 8. Za naše dvije sale (br. 1 i 3) nema podataka.
Obično se tokom požara napajanje odmah isključuje, ali u ovom slučaju, zahvaljujući koordinisanom radu vatrogasaca i tehničkog osoblja data centra, nije isključeno svuda i ne odmah, već po potrebi.
(Kasnije je otkriveno da struja nije isključena u halama 8 i 9.)
15:28. Počinjemo sa implementacijom MS SQL baza podataka iz rezervnih 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 pojedinih dijelova mreže.
Menadžment i proizvodna mreža su fizički izolovani jedno od drugog. Ako je proizvodna mreža dostupna, onda možete otići na server, zaustaviti aplikaciju i isključiti OS. Ako nije dostupan, možete se prijaviti putem IPMI-ja, zaustaviti aplikaciju i isključiti OS. Ako ne postoji nijedna od mreža, onda ne možete ništa učiniti. "Hvala, Kape!", pomislićete.
„I generalno, ima mnogo previranja“, takođe biste mogli pomisliti.
Stvar je u tome da serveri, čak i bez požara, generišu ogromnu količinu toplote. Tačnije, kada postoji hlađenje generišu toplotu, a kada nema hlađenja stvaraju pakleni pakao, koji će u najboljem slučaju istopiti deo opreme i isključiti drugi deo, au najgorem... izazvati vatra u sali, koja će gotovo garantovano uništiti sve.
15:39. Rješavamo probleme sa conf bazom podataka.
conf baza podataka je backend za uslugu istog imena, koju koriste sve proizvodne aplikacije za brzu promjenu postavki. Bez ove baze ne možemo kontrolirati rad portala, ali sam portal može raditi.
15:41. Senzori temperature na opremi Core mreže bilježe očitanja blizu maksimalno dozvoljenog. Ovo je kutija koja zauzima cijeli rack i osigurava rad svih mreža unutar data centra.
15:42. Praćenje problema i wiki su nedostupni, prebacite se u stanje pripravnosti.
Ovo nije proizvodnja, ali u slučaju nesreće dostupnost bilo koje baze znanja može biti kritična.
15:50. Jedan od sistema za nadzor se isključio.
Ima ih nekoliko i oni su odgovorni za različite aspekte usluga. Neki od njih su konfigurisani da rade autonomno unutar svakog data centra (odnosno, nadgledaju samo svoj data centar), drugi se sastoje od distribuiranih komponenti koje transparentno preživljavaju gubitak bilo kog data centra.
U ovom slučaju je prestao da radi , koji radi u master-standby modu. Prebačen u stanje pripravnosti.
Usvajanje
15:51. Svi serveri osim MS SQL-a su isključeni preko IPMI-ja bez ispravnog gašenja.
Da li ste spremni za masovno upravljanje serverom putem IPMI-ja ako je potrebno?
Upravo trenutak kada je u ovoj fazi završeno spašavanje opreme u data centru. Sve što se moglo uraditi je urađeno. Neke kolege mogu da se odmore.
16: 13. Pristigle su informacije da su freonske cijevi iz klima uređaja pucale na krovu - to će odgoditi pokretanje data centra nakon što se požar eliminiše.
16:19. Prema podacima dobijenim od tehničkog osoblja data centra, porast temperature u halama je prestao.
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 data centra?
Prvo, nije sve tolerantno na greške. Postoje razne sekundarne usluge koje još nisu dovoljno dobro preživjele kvar podatkovnog centra, a postoje i baze podataka u master-standby modu. Mogućnost upravljanja postavkama omogućava vam da učinite sve što je potrebno da minimizirate utjecaj posljedica nesreće na korisnike čak iu teškim uvjetima.
Drugo, postalo je jasno da rad data centra neće biti u potpunosti obnovljen u narednim satima, pa je bilo potrebno preduzeti mjere da dugoročna nedostupnost replika ne dovede do dodatnih problema kao što su puni diskovi u preostalih podatkovnih centara.
17:29. Vrijeme za pizzu! Zapošljavamo ljude, a ne robote.
Rehabilitacija
18:02. U halama br. 8 (naša), 9, 10 i 11 temperatura se stabilizovala. U jednoj od onih koja ostaje van mreže (br. 7) nalazi se naša oprema, a temperatura tamo nastavlja rasti.
18:31. Dali su zeleno svjetlo za puštanje u rad opreme u halama br. 1 i 3 - ove hale nisu bile zahvaćene požarom.
Trenutno su u puštanju servera u halama br. 1, 3, 8, počevši od onih najkritičnijih. Provjerava se ispravan rad svih pokrenutih usluga. I dalje ima problema sa halom broj 7.
18:44. Tehničko osoblje data centra je otkrilo da u prostoriji broj 7 (gdje se nalazi samo naša oprema) mnogi serveri nisu isključeni. Prema našim podacima, tamo je 26 servera na mreži. Nakon druge provjere nalazimo 58 servera.
20:18. Tehničari iz data centra upućuju vazduh kroz neklimatizovanu prostoriju kroz mobilne kanale koji prolaze kroz hodnike.
23:08. Prvi admin je poslan kući. Neko treba da spava noću da bi sutra nastavio sa radom. Zatim ćemo objaviti još neke administratore i programere.
02:56. Pokrenuli smo sve što se moglo pokrenuti. Vršimo dosta provjeravanja svih usluga koristeći automatske testove.
03:02. Renovirana je klima u posljednjoj, 7. sali.
03:36. Doveli smo frontove u data centru u rotaciju u DNS-u. Od ovog trenutka počinje pristizati korisnički promet.
Većinu administrativnog tima šaljemo kući. Ali ostavljamo nekoliko ljudi iza sebe.
Mala FAQ:
P: Šta se dogodilo od 18:31 do 02:56?
O: Prateći “Akcioni plan za katastrofu”, pokrećemo sve usluge, počevši od onih najvažnijih. U tom slučaju koordinator u chatu izdaje uslugu besplatnom administratoru, koji provjerava da li su OS i aplikacija pokrenuti, da li ima grešaka i da li su indikatori normalni. Nakon što je lansiranje završeno, javlja u chat da je slobodan i prima novu uslugu od koordinatora.
Proces dodatno usporava neispravan hardver. Čak i ako je zaustavljanje OS-a i gašenje servera prošlo ispravno, neki serveri se ne vraćaju zbog iznenadnog kvara diskova, memorije i šasije. Kada se energija izgubi, 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 postepeno, jer postoje zavisnosti između servisa. I sve treba provjeriti odmah, bez čekanja na praćenje - jer je bolje riješiti probleme odmah, bez čekanja da se pogoršaju.
7:40. Zadnji admin (koordinator) je otišao u krevet. Radovi prvog dana su završeni.
8:09. Prvi programeri, inženjeri i administratori centara podataka (uključujući novog koordinatora) započeli su radove na restauraciji.
09:37. Počeli smo podizati halu br. 7 (posljednju).
Istovremeno nastavljamo sa obnavljanjem onoga što nije popravljeno u drugim prostorijama: zamjenom diskova/memorije/servera, popravkom svega što “gori” u nadzoru, prebacivanjem uloga natrag u master-standby shemama i drugim sitnicama kojih ima ipak dosta.
17:08. Dozvoljavamo sav redovan rad sa proizvodnjom.
21:45. Rad drugog dana je završen.
09:45. Danas je petak. Još uvijek postoji dosta malih problema u praćenju. Vikend je pred nama, svi žele da se opuste. Nastavljamo da masovno popravljamo sve što možemo. Odgođeni su redovni administratorski zadaci koji su mogli biti odgođeni. Koordinator je nov.
15:40. Odjednom se ponovo pokrenula polovina stog opreme Core mreže u DRUGOM data centru. Frontovi su izvučeni iz rotacije kako bi se rizici sveli na minimum. Nema efekta za korisnike. Kasnije se ispostavilo da je u pitanju bila neispravna šasija. Koordinator radi na saniranju dvije nesreće odjednom.
17:17. Mrežni rad u drugom data centru je vraćen, sve je provjereno. Data centar je stavljen u rotaciju.
18:29. Radovi trećeg dana i generalno restauracija nakon havarije su završeni.
Posle reči
04.04.2013 , "Kolege iz razreda" —tri dana portal je bio potpuno ili djelimično nedostupan. Za sve to vrijeme, više od 100 ljudi iz različitih gradova, iz različitih kompanija (još jednom veliko hvala!), daljinski i direktno u data centrima, ručno i automatski, popravilo je hiljade servera.
Izvukli smo zaključke. Da se ovo više ne bi ponovilo, izveli smo i nastavljamo da radimo obimne radove do danas.
Koje su glavne razlike između trenutne nesreće i 404?
- Imamo „Akcioni plan u slučaju nesreće“. Jednom u tromjesečju izvodimo vježbe – igramo ulogu u vanrednoj situaciji, koju grupa administratora (svi redom) moraju eliminisati koristeći „Plan akcije za hitne slučajeve“. Vodeći sistem administratori naizmjenično igraju ulogu koordinatora.
- Tromjesečno, u test modu, izoliramo podatkovne centre (sve redom) putem LAN i WAN mreža, što nam omogućava da promptno identificiramo uska grla.
- Manje oštećenih diskova, jer smo pooštrili standarde: manje radnih sati, strože granične vrijednosti za S.M.A.R.T.,
- Potpuno smo napustili BerkeleyDB, staru i nestabilnu bazu podataka kojoj je bilo potrebno mnogo vremena za oporavak nakon ponovnog pokretanja servera.
- Smanjili smo broj servera sa MS SQL-om i smanjili ovisnost o preostalim.
- Imamo svoje , gdje već dvije godine aktivno migriramo sve usluge. Oblak uvelike pojednostavljuje cijeli ciklus rada s aplikacijom, a u slučaju nesreće pruža takve jedinstvene alate kao što su:
- ispravno zaustavljanje svih aplikacija jednim klikom;
- laka migracija aplikacija sa pokvarenih servera;
- automatsko rangirano (po redu prioriteta usluga) pokretanje cijelog data centra.
Nesreća opisana u ovom članku bila je najveća od 404. dana. Naravno, nije sve išlo glatko. Na primjer, za vrijeme nedostupnosti požarom oštećenog podatkovnog centra u drugom podatkovnom centru, otkazao je disk na jednom od servera, odnosno ostala je dostupna samo jedna od tri replike u klasteru Cassandra, zbog čega je 4,2% mobilnih korisnici aplikacije nisu se mogli prijaviti. Istovremeno, već povezani korisnici su nastavili sa radom. Ukupno, kao rezultat nesreće, identifikovano je više od 30 problema - od banalnih grešaka do nedostataka u arhitekturi servisa.
No, najvažnija razlika između trenutne nesreće i 404. je u tome što su, dok smo otklanjali posljedice požara, korisnici i dalje slali poruke i upućivali video pozive na , igrali igrice, slušali muziku, darivali jedni druge, gledali video zapise, TV serije i TV kanale u , a također je strimovao .
Kako prolaze vaše nesreće?
izvor: www.habr.com
