Hvordan ville du have det, hvis datacentret med dit udstyr en skøn sommerdag så sådan ud?
Hej alle! Mit navn er Dmitry Samsonov, jeg arbejder som en førende systemadministrator hos "" Billedet viser et af de fire datacentre, hvor udstyret til vores projekt er installeret. Bag disse vægge er der omkring 4 tusind stykker udstyr: servere, datalagringssystemer, netværksudstyr osv. - næsten ⅓ af alt vores udstyr.
De fleste servere er Linux. Der er også flere dusin servere på Windows (MS SQL) - vores arv, som vi systematisk har opgivet i mange år.
Så den 5. juni 2019 kl. 14:35 rapporterede ingeniører på et af vores datacentre en brandalarm.
benægtelse
14:45. Mindre røghændelser i datacentre er mere almindelige, end du tror. Indikatorerne inde i hallerne var normale, så vores første reaktion var forholdsvis rolig: de indførte et forbud mod arbejde med produktion, det vil sige mod eventuelle konfigurationsændringer, udrulning af nye versioner osv., bortset fra arbejde relateret til at reparere noget.
vrede
Har du nogensinde forsøgt at finde ud af fra brandmændene præcis, hvor branden opstod på taget, eller selv at komme op på et brændende tag for at vurdere situationen? Hvad bliver graden af tillid til information modtaget gennem fem personer?
14: 50. Der er modtaget oplysninger om, at branden nærmer sig kølesystemet. Men kommer det? Den vagthavende systemadministrator fjerner ekstern trafik fra fronterne af dette datacenter.
I øjeblikket er fronterne af alle vores tjenester duplikeret i tre datacentre, balancering bruges på DNS-niveau, hvilket giver os mulighed for at fjerne adresserne på et datacenter fra DNS'en, og derved beskytte brugerne mod potentielle problemer med adgang til tjenester . Hvis der allerede er opstået problemer i datacentret, forlader det rotationen automatisk. Du kan læse mere her:
Branden har ikke påvirket os på nogen måde endnu - hverken brugere eller udstyr er taget skade. Er dette en ulykke? Det første afsnit af dokumentet "Handlingsplan for ulykker" definerer begrebet "ulykke", og afsnittet slutter således:
«Hvis der er tvivl om, hvorvidt der er sket et uheld eller ej, så er det et uheld!»
14:53. Der udpeges en beredskabskoordinator.
Koordinatoren er den person, der kontrollerer kommunikationen mellem alle deltagere, vurderer omfanget af ulykken, bruger nødhandlingsplanen, tiltrækker det nødvendige personale, overvåger gennemførelsen af reparationer og vigtigst af alt, uddelegerer eventuelle opgaver. Det er med andre ord den person, der styrer hele beredskabsprocessen.
Forhandle
15:01. Vi begynder at deaktivere servere, der ikke er relateret til produktion.
15:03. Vi slår alle reserverede tjenester korrekt fra.
Dette omfatter ikke kun fronter (som på nuværende tidspunkt brugere ikke længere har adgang til) og deres hjælpetjenester (forretningslogik, caches osv.), men også forskellige databaser med replikeringsfaktor 2 eller mere (, , , etc.).
15: 06. Der er modtaget oplysninger om, at en brand truer en af datacenterhallerne. Vi har ikke udstyr i dette rum, men det faktum, at ilden kan sprede sig fra taget til hallerne, ændrer i høj grad billedet af, hvad der sker.
(Det viste sig senere, at der ikke var nogen fysisk trussel mod hallen, da den var hermetisk lukket fra taget. Truslen var kun mod denne hals kølesystem.)
15:07. Vi tillader kommandoudførelse på servere i accelereret tilstand uden yderligere kontrol ().
15:08. Temperaturen i hallerne er inden for normale grænser.
15: 12. Der blev registreret en stigning i temperaturen i hallerne.
15:13. Mere end halvdelen af serverne i datacentret er slukket. Lad os fortsætte.
15:16. Der blev truffet beslutning om at slukke for alt udstyr.
15:21. Vi begynder at slukke for strømmen til statsløse servere uden at lukke applikationen og operativsystemet korrekt ned.
15:23. En gruppe personer, der er ansvarlige for MS SQL, tildeles (der er få af dem, afhængigheden af tjenester af dem er ikke stor, men proceduren for gendannelse af funktionalitet tager længere tid og er mere kompliceret end for eksempel Cassandra).
depression
15: 25. Der blev modtaget information om, at der blev slukket for strømmen i fire haller ud af 16 (nr. 6, 7, 8, 9). Vores udstyr er placeret i hal 7 og 8. Der er ingen oplysninger om vores to haller (nr. 1 og 3).
Normalt, under brande, slukkes strømforsyningen straks, men i dette tilfælde, takket være det koordinerede arbejde fra brandmænd og teknisk personale i datacentret, blev den ikke slukket overalt og ikke straks, men efter behov.
(Det blev senere opdaget, at strømmen ikke var slukket i hall 8 og 9.)
15:28. Vi begynder at implementere MS SQL-databaser fra backups i andre datacentre.
Hvor lang tid vil det tage? Er der tilstrækkelig netværkskapacitet til hele ruten?
15: 37. En nedlukning af nogle dele af netværket blev registreret.
Ledelsen og produktionsnetværket er fysisk isoleret fra hinanden. Hvis produktionsnetværket er tilgængeligt, kan du gå til serveren, stoppe applikationen og slukke for operativsystemet. Hvis det ikke er tilgængeligt, så kan du logge ind via IPMI, stoppe applikationen og slukke for OS. Hvis der ikke er nogen af netværkene, så kan du ikke gøre noget. "Tak, Cap!", vil du tænke.
"Og generelt er der meget uro," tænker du måske også.
Sagen er, at servere, selv uden brand, genererer en enorm mængde varme. Mere præcist, når der er afkøling, genererer de varme, og når der ikke er nogen afkøling, skaber de et helvedes inferno, som i bedste fald vil smelte en del af udstyret og slukke for en anden del, og i værste fald... forårsage en brand inde i hallen, som næsten med garanti vil ødelægge alt.
15:39. Vi løser problemer med conf-databasen.
Conf-databasen er backend for tjenesten af samme navn, som bruges af alle produktionsapplikationer til hurtigt at ændre indstillinger. Uden denne base kan vi ikke kontrollere driften af portalen, men selve portalen kan fungere.
15:41. Temperatursensorer på Core-netværksudstyr registrerer aflæsninger tæt på det maksimalt tilladte. Dette er en boks, der fylder et helt rack og sikrer driften af alle netværk inde i datacentret.
15:42. Issue tracker og wiki er ikke tilgængelige, skift til standby.
Dette er ikke produktion, men i tilfælde af en ulykke kan tilgængeligheden af enhver videnbase være kritisk.
15:50. Et af overvågningssystemerne er slukket.
Der er flere af dem, og de er ansvarlige for forskellige aspekter af ydelserne. Nogle af dem er konfigureret til at fungere autonomt inden for hvert datacenter (det vil sige, de overvåger kun deres eget datacenter), andre består af distribuerede komponenter, der transparent overlever tabet af ethvert datacenter.
I dette tilfælde holdt den op med at virke , som fungerer i master-standby-tilstand. Skift til standby.
accept
15:51. Alle servere undtagen MS SQL blev slukket via IPMI uden at lukke korrekt ned.
Er du klar til massiv serverstyring via IPMI, hvis det er nødvendigt?
Selve det øjeblik, hvor redningen af udstyr i datacentret er afsluttet på dette stadium. Alt, hvad der kunne gøres, er blevet gjort. Nogle kolleger kan hvile.
16: 13. Der er modtaget oplysninger om, at freonrør fra klimaanlæg sprænger på taget - det vil forsinke lanceringen af datacentret, efter at branden er elimineret.
16:19. Ifølge data modtaget fra datacentrets tekniske personale er stigningen i temperatur i hallerne stoppet.
17:10. Conf-databasen er blevet gendannet. Nu kan vi ændre applikationsindstillinger.
Hvorfor er dette så vigtigt, hvis alt er fejltolerant og fungerer selv uden ét datacenter?
For det første er alt ikke fejltolerant. Der er forskellige sekundære tjenester, der endnu ikke har overlevet en datacenterfejl godt nok, og der er databaser i master-standby-tilstand. Evnen til at administrere indstillinger giver dig mulighed for at gøre alt, hvad der er nødvendigt for at minimere virkningen af konsekvenserne af en ulykke på brugerne selv under vanskelige forhold.
For det andet blev det klart, at driften af datacentret ikke ville blive fuldt genoprettet i de kommende timer, så det var nødvendigt at træffe foranstaltninger for at sikre, at den langsigtede utilgængelighed af replikaer ikke førte til yderligere problemer såsom fulde diske i de resterende datacentre.
17:29. Pizza tid! Vi beskæftiger mennesker, ikke robotter.
Rehabilitering
18:02. I hall nr. 8 (vores), 9, 10 og 11 har temperaturen stabiliseret sig. En af dem, der forbliver offline (nr. 7), huser vores udstyr, og temperaturen der fortsætter med at stige.
18:31. De gav grønt lys til at starte udstyret op i hal nr. 1 og 3 - disse haller var ikke påvirket af branden.
I øjeblikket lanceres servere i hall nr. 1, 3, 8, startende med de mest kritiske. Den korrekte funktion af alle kørende tjenester kontrolleres. Der er stadig problemer med hal nr. 7.
18:44. Datacentrets tekniske personale opdagede, at i lokale nr. 7 (hvor kun vores udstyr er placeret) er mange servere ikke slukket. Ifølge vores data forbliver 26 servere online der. Efter en anden kontrol finder vi 58 servere.
20:18. Datacenterteknikere blæser luft gennem et rum uden aircondition gennem mobile kanaler, der løber gennem gangene.
23:08. Den første admin blev sendt hjem. Nogen skal sove om natten for at kunne fortsætte arbejdet i morgen. Dernæst vil vi frigive nogle flere administratorer og udviklere.
02:56. Vi lancerede alt, hvad der kunne lanceres. Vi kontrollerer meget af alle tjenester ved hjælp af automatiske tests.
03:02. Aircondition i den sidste, 7. sal er blevet restaureret.
03:36. Vi bragte fronterne i datacentret i rotation i DNS. Fra dette øjeblik begynder brugertrafik at ankomme.
Vi sender det meste af det administrative team hjem. Men vi efterlader nogle få mennesker.
Lille FAQ:
Q: Hvad skete der fra 18:31 til 02:56?
A: Efter "Katastrofehandlingsplanen" lancerer vi alle tjenester, begyndende med de vigtigste. I dette tilfælde udsteder koordinatoren i chatten tjenesten til en gratis administrator, som kontrollerer, om OS og applikation er startet, om der er fejl, og om indikatorerne er normale. Efter lanceringen er gennemført, melder han til chatten, at han er ledig og modtager en ny service fra koordinatoren.
Processen bremses yderligere af fejlslagen hardware. Selvom det gik korrekt at stoppe OS og lukke serverne, vender nogle servere ikke tilbage på grund af pludselige fejl på diske, hukommelse og chassis. Når strømmen går tabt, stiger fejlfrekvensen.
Spørgsmål: Hvorfor kan du ikke bare køre alt på én gang og derefter rette det, der kommer op i overvågningen?
A: Alt skal gøres gradvist, fordi der er afhængigheder mellem tjenester. Og alt skal kontrolleres med det samme uden at vente på overvågning - fordi det er bedre at håndtere problemer med det samme, uden at vente på, at de forværres.
7:40. Den sidste admin (koordinator) gik i seng. Den første dags arbejde er afsluttet.
8:09. De første udviklere, datacenteringeniører og administratorer (inklusive den nye koordinator) begyndte restaureringsarbejdet.
09:37. Vi begyndte at rejse hal nr. 7 (den sidste).
Samtidig fortsætter vi med at gendanne det, der ikke var rettet i andre rum: udskiftning af diske/hukommelse/servere, reparation af alt, hvad der "brænder" i overvågning, skift af roller tilbage i master-standby-ordninger og andre småting, som der er af ikke desto mindre ret meget.
17:08. Vi tillader alt almindeligt arbejde med produktion.
21:45. Anden dags arbejde er afsluttet.
09:45. I dag er det fredag. Der er stadig en del små problemer i overvågningen. Weekenden er forude, alle vil slappe af. Vi fortsætter med at reparere alt, hvad vi kan. Almindelige admin-opgaver, der kunne have været udskudt, blev udskudt. Koordinatoren er ny.
15:40. Pludselig genstartede halvdelen af Core-netværksudstyrsstakken i ET ANDET datacenter. Fronter blev taget ud af rotation for at minimere risici. Der er ingen effekt for brugerne. Det viste sig senere, at det var et defekt chassis. Koordinatoren arbejder på at udbedre to uheld på én gang.
17:17. Netværksdrift i et andet datacenter er blevet genoprettet, alt er blevet tjekket. Datacenteret sættes i rotation.
18:29. Tredjedagens arbejde og i det hele taget restaureringen efter ulykken er afsluttet.
efterskrift
04.04.2013 , "Klassekammerater" — I tre dage var portalen helt eller delvist utilgængelig. I løbet af hele denne tid har mere end 100 mennesker fra forskellige byer, fra forskellige virksomheder (igen mange tak!), eksternt og direkte i datacentre, manuelt og automatisk, repareret tusindvis af servere.
Vi har draget konklusioner. For at forhindre, at dette sker igen, har vi udført og udfører fortsat omfattende arbejde den dag i dag.
Hvad er de vigtigste forskelle mellem den aktuelle ulykke og 404?
- Vi har en "Handlingsplan for ulykker". En gang i kvartalet gennemfører vi øvelser - vi rollespiller en nødsituation, som en gruppe administratorer (alle på skift) skal eliminere ved hjælp af ”Nødhandlingsplanen”. Ledende systemadministratorer skiftes til at spille rollen som koordinator.
- Kvartalsvis, i testtilstand, isolerer vi datacentre (alle efter tur) via LAN- og WAN-netværk, hvilket giver os mulighed for omgående at identificere flaskehalse.
- Færre ødelagte diske, fordi vi har skærpet standarderne: færre driftstimer, strengere tærskler for SMART,
- Vi forlod fuldstændig BerkeleyDB, en gammel og ustabil database, der krævede meget tid at genoprette efter en servergenstart.
- Vi reducerede antallet af servere med MS SQL og reducerede afhængigheden af de resterende.
- Vi har vores egen , hvor vi aktivt har migreret alle tjenester i to år nu. Skyen forenkler i høj grad hele cyklussen med at arbejde med applikationen, og i tilfælde af en ulykke giver den så unikke værktøjer som:
- korrekt stop af alle applikationer med et enkelt klik;
- nem migrering af applikationer fra fejlbehæftede servere;
- automatisk rangeret (i prioriteret rækkefølge af tjenester) lancering af et helt datacenter.
Ulykken beskrevet i denne artikel var den største siden den 404. dag. Selvfølgelig gik alt ikke lige. For eksempel, under utilgængeligheden af et brandbeskadiget datacenter i et andet datacenter, fejlede en disk på en af serverne, det vil sige, at kun én af de tre replikaer i Cassandra-klyngen forblev tilgængelig, hvorfor 4,2 % af mobilenheder applikationsbrugere kunne ikke logge ind. Samtidig fortsatte allerede tilsluttede brugere med at arbejde. I alt blev der som følge af ulykken identificeret mere end 30 problemer - fra banale fejl til mangler i servicearkitekturen.
Men den vigtigste forskel mellem den aktuelle ulykke og den 404. er, at mens vi fjernede konsekvenserne af branden, skrev brugerne stadig sms'er og foretog videoopkald til , spillede spil, lyttede til musik, gav hinanden gaver, så videoer, tv-serier og tv-kanaler i , og også streamet ind .
Hvordan går dine ulykker?
Kilde: www.habr.com