Hvordan ville du følt det om datasenteret med utstyret ditt så slik ut en vakker sommerdag?
Hei alle sammen! Mitt navn er Dmitry Samsonov, jeg jobber som en ledende systemadministrator på "" Bildet viser et av de fire datasentrene hvor utstyret som betjener prosjektet vårt er installert. Bak disse veggene er det omtrent 4 tusen utstyrsdeler: servere, datalagringssystemer, nettverksutstyr, etc. - nesten ⅓ av alt utstyret vårt.
De fleste servere er Linux. Det er også flere titalls servere på Windows (MS SQL) - vår arv, som vi systematisk har forlatt i mange år.
Så 5. juni 2019 klokken 14:35 rapporterte ingeniører ved et av datasentrene våre en brannalarm.
Negasjon
14:45. Mindre røykhendelser i datasentre er mer vanlig enn du tror. Indikatorene inne i hallene var normale, så vår første reaksjon var relativt rolig: de innførte et forbud mot arbeid med produksjon, det vil si på eventuelle konfigurasjonsendringer, på å rulle ut nye versjoner osv., bortsett fra arbeid knyttet til å fikse noe.
Sinne
Har du noen gang forsøkt å finne ut fra brannvesenet nøyaktig hvor brannen oppsto på taket, eller å komme deg opp på et brennende tak selv for å vurdere situasjonen? Hva vil være graden av tillit til informasjon mottatt gjennom fem personer?
14: 50. Det er mottatt informasjon om at brannen nærmer seg kjøleanlegget. Men kommer det? Systemadministratoren på vakt fjerner ekstern trafikk fra frontene til dette datasenteret.
For øyeblikket er frontene til alle våre tjenester duplisert i tre datasentre, balansering brukes på DNS-nivå, som lar oss fjerne adressene til ett datasenter fra DNS, og dermed beskytte brukere mot potensielle problemer med tilgang til tjenester . Hvis det allerede har oppstått problemer i datasenteret, forlater det rotasjonen automatisk. Du kan lese mer her:
Brannen har ikke påvirket oss på noen måte ennå - verken brukere eller utstyr er skadet. Er dette en ulykke? Den første delen av dokumentet "Handlingsplan for ulykker" definerer begrepet "ulykke", og avsnittet ender slik:
«Er det noen tvil om det er en ulykke eller ikke, så er det en ulykke!»
14:53. Det oppnevnes en beredskapskoordinator.
Koordinatoren er personen som kontrollerer kommunikasjonen mellom alle deltakerne, vurderer omfanget av ulykken, bruker nødhandlingsplanen, tiltrekker nødvendig personell, overvåker gjennomføringen av reparasjoner, og viktigst av alt, delegerer eventuelle oppgaver. Dette er med andre ord personen som styrer hele beredskapsprosessen.
Handel
15:01. Vi begynner å deaktivere servere som ikke er relatert til produksjon.
15:03. Vi slår av alle reserverte tjenester på riktig måte.
Dette inkluderer ikke bare fronter (som på dette tidspunkt brukere ikke lenger har tilgang) og deres hjelpetjenester (forretningslogikk, cacher, etc.), men også ulike databaser med replikeringsfaktor 2 eller mer (, , , etc.).
15: 06. Det er mottatt informasjon om at en brann truer en av datasenterhallene. Vi har ikke utstyr i dette rommet, men det faktum at brannen kan spre seg fra taket til hallene endrer i stor grad bildet av hva som skjer.
(Det viste seg senere at det ikke var noen fysisk trussel mot hallen, siden den var hermetisk forseglet fra taket. Trusselen var kun mot kjølesystemet til denne hallen.)
15:07. Vi tillater kommandokjøring på servere i akselerert modus uten ytterligere kontroller ().
15:08. Temperaturen i salene er innenfor normale grenser.
15: 12. Det ble registrert en økning i temperatur i salene.
15:13. Mer enn halvparten av serverne i datasenteret er slått av. La oss fortsette.
15:16. Det ble tatt en beslutning om å slå av alt utstyr.
15:21. Vi begynner å slå av strømmen til statsløse servere uten å slå av applikasjonen og operativsystemet på riktig måte.
15:23. En gruppe personer som er ansvarlige for MS SQL er tildelt (det er få av dem, avhengigheten av tjenester av dem er ikke stor, men prosedyren for å gjenopprette funksjonalitet tar lengre tid og er mer komplisert enn for eksempel Cassandra).
Депрессия
15: 25. Det ble mottatt informasjon om strømavbrudd i fire saler av 16 (nr. 6, 7, 8, 9). Vårt utstyr er plassert i hall 7 og 8. Det er ingen informasjon om våre to haller (nr. 1 og 3).
Vanligvis, under branner, blir strømforsyningen umiddelbart slått av, men i dette tilfellet, takket være det koordinerte arbeidet til brannmenn og teknisk personell i datasenteret, ble den ikke slått av overalt og ikke umiddelbart, men etter behov.
(Det ble senere oppdaget at strømmen ikke var slått av i hall 8 og 9.)
15:28. Vi begynner å distribuere MS SQL-databaser fra sikkerhetskopier i andre datasentre.
Hvor lang tid vil det ta? Er det nok nettverkskapasitet for hele ruten?
15: 37. En nedleggelse av enkelte deler av nettverket ble registrert.
Ledelsen og produksjonsnettverket er fysisk isolert fra hverandre. Hvis produksjonsnettverket er tilgjengelig, kan du gå til serveren, stoppe applikasjonen og slå av operativsystemet. Hvis den ikke er tilgjengelig, kan du logge på via IPMI, stoppe applikasjonen og slå av OS. Hvis det ikke er noen av nettverkene, kan du ikke gjøre noe. "Takk, Cap!", tenker du.
"Og generelt er det mye uro," tenker du kanskje også.
Saken er at servere, selv uten brann, genererer en enorm mengde varme. Mer presist, når det er kjøling, genererer de varme, og når det ikke er noen kjøling, skaper de et helvetes inferno, som i beste fall vil smelte en del av utstyret og slå av en annen del, og i verste fall... forårsake en brann inne i hallen, som nesten garantert vil ødelegge alt.
15:39. Vi fikser problemer med conf-databasen.
Conf-databasen er backend for tjenesten med samme navn, som brukes av alle produksjonsapplikasjoner for raskt å endre innstillinger. Uten denne basen kan vi ikke kontrollere driften av portalen, men selve portalen kan fungere.
15:41. Temperatursensorer på kjernenettverksutstyr registrerer avlesninger nær det maksimalt tillatte. Dette er en boks som opptar et helt rack og sikrer driften av alle nettverk inne i datasenteret.
15:42. Problemsporing og wiki er utilgjengelig, bytt til standby.
Dette er ikke produksjon, men i tilfelle en ulykke kan tilgjengeligheten til enhver kunnskapsbase være kritisk.
15:50. Et av overvåkingssystemene er slått av.
Det er flere av dem, og de har ansvar for ulike sider ved tjenestene. Noen av dem er konfigurert til å operere autonomt innenfor hvert datasenter (det vil si at de kun overvåker sitt eget datasenter), andre består av distribuerte komponenter som transparent overlever tapet av et datasenter.
I dette tilfellet sluttet det å fungere , som fungerer i master-standby-modus. Byttet til standby.
Adopsjon
15:51. Alle servere unntatt MS SQL ble slått av via IPMI uten å slå seg av på riktig måte.
Er du klar for massiv serveradministrasjon via IPMI om nødvendig?
Selve øyeblikket når redningen av utstyr i datasenteret er fullført på dette stadiet. Alt som kunne gjøres er gjort. Noen kolleger kan hvile.
16: 13. Det er mottatt informasjon om at freonrør fra klimaanlegg sprakk på taket - dette vil forsinke lanseringen av datasenteret etter at brannen er eliminert.
16:19. Ifølge data mottatt fra teknisk personell i datasenteret har temperaturøkningen i hallene stoppet opp.
17:10. Conf-databasen er gjenopprettet. Nå kan vi endre applikasjonsinnstillinger.
Hvorfor er dette så viktig hvis alt er feiltolerant og fungerer selv uten ett datasenter?
For det første er ikke alt feiltolerant. Det er ulike sekundære tjenester som ennå ikke har overlevd en datasentersvikt godt nok, og det er databaser i master-standby-modus. Evnen til å administrere innstillinger lar deg gjøre alt som er nødvendig for å minimere virkningen av konsekvensene av en ulykke på brukere selv under vanskelige forhold.
For det andre ble det klart at driften av datasenteret ikke ville bli fullstendig gjenopprettet i løpet av de kommende timene, så det var nødvendig å iverksette tiltak for å sikre at langvarig utilgjengelighet av replikaer ikke førte til ytterligere problemer som fulle disker i de resterende datasentrene.
17:29. Pizza tid! Vi ansetter mennesker, ikke roboter.
Rehabilitering
18:02. I hall nr. 8 (vår), 9, 10 og 11 har temperaturen stabilisert seg. En av de som forblir offline (nr. 7) huser utstyret vårt, og temperaturen der fortsetter å stige.
18:31. De ga klarsignal til å starte opp utstyret i hall nr. 1 og 3 - disse hallene ble ikke berørt av brannen.
For tiden lanseres servere i hall nr. 1, 3, 8, og starter med de mest kritiske. Riktig drift av alle kjørende tjenester kontrolleres. Det er fortsatt problemer med hall nr. 7.
18:44. Det tekniske personalet i datasenteret oppdaget at i rom nr. 7 (der kun utstyret vårt er plassert) er mange servere ikke slått av. I følge våre data forblir 26 servere online der. Etter en ny sjekk finner vi 58 servere.
20:18. Datasenterteknikere blåser luft gjennom et rom uten luftkondisjonering gjennom mobile kanaler som går gjennom gangene.
23:08. Den første admin ble sendt hjem. Noen må sove om natten for å fortsette å jobbe i morgen. Deretter vil vi gi ut noen flere administratorer og utviklere.
02:56. Vi lanserte alt som kunne lanseres. Vi sjekker mye av alle tjenester ved hjelp av automatiske tester.
03:02. Aircondition i den siste, 7. hallen er restaurert.
03:36. Vi brakte frontene i datasenteret i rotasjon i DNS. Fra dette øyeblikket begynner brukertrafikken å komme.
Vi sender det meste av det administrative teamet hjem. Men vi legger igjen noen få personer.
Liten FAQ:
Spørsmål: Hva skjedde fra 18:31 til 02:56?
A: Etter «Katastrofehandlingsplanen» lanserer vi alle tjenestene, og starter med de viktigste. I dette tilfellet utsteder koordinatoren i chatten tjenesten til en gratis administrator, som sjekker om operativsystemet og applikasjonen har startet, om det er noen feil og om indikatorene er normale. Etter at lanseringen er gjennomført, melder han fra til chatten at han er ledig og får en ny tjeneste fra koordinatoren.
Prosessen bremses ytterligere av feil maskinvare. Selv om det å stoppe operativsystemet og slå av serverne gikk riktig, returnerer ikke noen servere på grunn av plutselig feil på disker, minne og chassis. Når strømmen går, øker feilfrekvensen.
Spørsmål: Hvorfor kan du ikke bare kjøre alt på en gang, og deretter fikse det som kommer opp i overvåking?
A: Alt må gjøres gradvis, fordi det er avhengigheter mellom tjenester. Og alt bør sjekkes med en gang, uten å vente på overvåking - fordi det er bedre å håndtere problemer med en gang, uten å vente på at de skal forverres.
7:40. Den siste admin (koordinator) gikk og la seg. Første dags arbeid er unnagjort.
8:09. De første utviklerne, datasenteringeniørene og administratorene (inkludert den nye koordinatoren) begynte restaureringsarbeidet.
09:37. Vi begynte å heve hall nr. 7 (den siste).
Samtidig fortsetter vi å gjenopprette det som ikke var fikset i andre rom: bytte ut disker/minne/servere, fikse alt som «brenner» i overvåking, bytte roller tilbake i master-standby-opplegg og andre småting som det finnes av. likevel ganske mye.
17:08. Vi tillater alt vanlig arbeid med produksjon.
21:45. Arbeidet med den andre dagen er fullført.
09:45. I dag er det fredag. Det er fortsatt en del små problemer med overvåking. Helgen står foran, alle vil slappe av. Vi fortsetter å massivt reparere alt vi kan. Vanlige adminoppgaver som kunne vært utsatt ble utsatt. Koordinatoren er ny.
15:40. Plutselig startet halvparten av kjernenettverksutstyrsstabelen i ET ANNET datasenter på nytt. Fronter ble tatt ut av rotasjon for å minimere risiko. Det er ingen effekt for brukerne. Det viste seg senere at det var et defekt chassis. Koordinatoren jobber med å reparere to ulykker samtidig.
17:17. Nettverksdrift i et annet datasenter er gjenopprettet, alt er sjekket. Datasenteret settes i rotasjon.
18:29. Arbeidet med den tredje dagen og generelt sett restaureringen etter ulykken er fullført.
etterord
04.04.2013 , "Klassekamerater" — I tre dager var portalen helt eller delvis utilgjengelig. Gjennom hele denne tiden har mer enn 100 personer fra forskjellige byer, fra forskjellige selskaper (mange takk igjen!), eksternt og direkte i datasentre, manuelt og automatisk, reparert tusenvis av servere.
Vi har trukket konklusjoner. For å unngå at dette skjer igjen, har vi utført og utfører et omfattende arbeid frem til i dag.
Hva er hovedforskjellene mellom den nåværende ulykken og 404?
- Vi har en «Handlingsplan for ulykker». En gang i kvartalet gjennomfører vi øvelser - vi rollespiller en nødssituasjon, som en gruppe administratorer (alle etter tur) må eliminere ved hjelp av "Emergency Action Plan". Ledende systemadministratorer bytter på å spille rollen som koordinator.
- Kvartalsvis, i testmodus, isolerer vi datasentre (alle etter tur) via LAN- og WAN-nettverk, noe som lar oss raskt identifisere flaskehalser.
- Færre ødelagte disker, fordi vi har skjerpet standardene: færre driftstimer, strengere terskler for SMART,
- Vi forlot BerkeleyDB fullstendig, en gammel og ustabil database som krevde mye tid å gjenopprette etter en omstart av serveren.
- Vi reduserte antall servere med MS SQL og reduserte avhengigheten av de resterende.
- Vi har vår egen , hvor vi aktivt har migrert alle tjenester i to år nå. Skyen forenkler i stor grad hele syklusen med å jobbe med applikasjonen, og i tilfelle en ulykke gir den så unike verktøy som:
- riktig stopp av alle applikasjoner med ett klikk;
- enkel migrering av applikasjoner fra mislykkede servere;
- automatisk rangert (i prioritert rekkefølge av tjenester) lansering av et helt datasenter.
Ulykken beskrevet i denne artikkelen var den største siden den 404. dagen. Selvfølgelig gikk ikke alt på skinner. For eksempel, under utilgjengelighet av et brannskadet datasenter i et annet datasenter, sviktet en disk på en av serverne, det vil si at bare én av de tre kopiene i Cassandra-klyngen forble tilgjengelig, og det er grunnen til at 4,2 % av mobilen applikasjonsbrukere kunne ikke logge på. Samtidig fortsatte allerede tilkoblede brukere å jobbe. Totalt, som følge av ulykken, ble det identifisert mer enn 30 problemer - fra banale feil til mangler i tjenestearkitekturen.
Men den viktigste forskjellen mellom den nåværende ulykken og den 404. er at mens vi eliminerte konsekvensene av brannen, sendte brukere fortsatt tekstmeldinger og foretok videosamtaler til , spilte spill, hørte på musikk, ga hverandre gaver, så på videoer, TV-serier og TV-kanaler i , og også strømmet inn .
Hvordan går ulykkene dine?
Kilde: www.habr.com