Hur skulle du känna om en vacker sommardag datacentret med din utrustning såg ut så här?
Hej alla! Jag heter Dmitry Samsonov, jag arbetar som ledande systemadministratör på "" Bilden visar ett av de fyra datacenter där utrustningen för vårt projekt är installerad. Bakom dessa väggar finns cirka 4 tusen utrustningar: servrar, datalagringssystem, nätverksutrustning, etc. - nästan ⅓ av all vår utrustning.
De flesta servrar är Linux. Det finns också flera dussin servrar på Windows (MS SQL) - vårt arv, som vi systematiskt har övergett i många år.
Så den 5 juni 2019 klockan 14:35 rapporterade ingenjörer vid ett av våra datacenter ett brandlarm.
Negation
14:45. Mindre rökincidenter i datacenter är vanligare än man tror. Indikatorerna inne i hallarna var normala, så vår första reaktion var relativt lugn: de införde ett förbud mot arbete med produktion, det vill säga mot eventuella konfigurationsändringar, att rulla ut nya versioner, etc., förutom arbete relaterat till att fixa något.
Ilska
Har du någonsin försökt ta reda på från brandmän exakt var branden inträffade på taket, eller själv ta dig upp på ett brinnande tak för att bedöma situationen? Hur stor blir förtroendet för information som tas emot av fem personer?
14: 50. Information har inkommit om att branden närmar sig kylsystemet. Men kommer det? Systemadministratören i tjänst tar bort extern trafik från fronterna av detta datacenter.
För tillfället är fronterna för alla våra tjänster duplicerade i tre datacenter, balansering används på DNS-nivå, vilket gör att vi kan ta bort adresserna till ett datacenter från DNS, och därigenom skydda användare från potentiella problem med åtkomst till tjänster . Om problem redan har uppstått i datacentret lämnar det rotationen automatiskt. Du kan läsa mer här:
Branden har inte påverkat oss på något sätt ännu - varken användare eller utrustning har skadats. Är detta en olycka? Det första avsnittet i dokumentet "Accident Action Plan" definierar begreppet "olycka", och avsnittet slutar så här:
«Om det råder någon tvekan om det är en olycka eller inte, så är det en olycka!»
14:53. En beredskapssamordnare utses.
Samordnaren är den person som kontrollerar kommunikationen mellan alla deltagare, bedömer omfattningen av olyckan, använder nödåtgärdsplanen, lockar till sig nödvändig personal, övervakar slutförandet av reparationer och viktigast av allt, delegerar alla uppgifter. Det är med andra ord den person som sköter hela beredskapsprocessen.
auktion
15:01. Vi börjar inaktivera servrar som inte är relaterade till produktion.
15:03. Vi stänger korrekt av alla reserverade tjänster.
Detta inkluderar inte bara fronter (som vid det här laget inte längre har tillgång till användare) och deras hjälptjänster (affärslogik, cachar, etc.), utan också olika databaser med replikeringsfaktor 2 eller mer (, , , etc.).
15: 06. Information har inkommit om att en brand hotar en av datacenterhallarna. Vi har ingen utrustning i det här rummet, men det faktum att branden kan sprida sig från taket till hallarna förändrar i hög grad bilden av vad som händer.
(Det visade sig senare att det inte fanns något fysiskt hot mot hallen, eftersom den var hermetiskt tillsluten från taket. Hotet gällde endast kylsystemet i denna hall.)
15:07. Vi tillåter kommandoexekvering på servrar i accelererat läge utan ytterligare kontroller ().
15:08. Temperaturen i hallarna ligger inom normala gränser.
15: 12. En ökning av temperaturen i hallarna noterades.
15:13. Mer än hälften av servrarna i datacentret är avstängda. Låt oss fortsätta.
15:16. Beslut togs att stänga av all utrustning.
15:21. Vi börjar stänga av strömmen till tillståndslösa servrar utan att korrekt stänga av applikationen och operativsystemet.
15:23. En grupp personer som ansvarar för MS SQL tilldelas (det finns få av dem, beroendet av tjänster av dem är inte stort, men proceduren för att återställa funktionalitet tar längre tid och är mer komplicerad än till exempel Cassandra).
Депрессия
15: 25. Information inkom om strömavstängning i fyra hallar av 16 (nr 6, 7, 8, 9). Vår utrustning finns i hall 7 och 8. Det finns ingen information om våra två hallar (nr 1 och 3).
Vanligtvis, under bränder, stängs strömförsörjningen omedelbart av, men i det här fallet, tack vare det samordnade arbetet från brandmän och teknisk personal i datacentret, stängdes den inte av överallt och inte omedelbart, utan vid behov.
(Det upptäcktes senare att strömmen inte var avstängd i hall 8 och 9.)
15:28. Vi börjar distribuera MS SQL-databaser från säkerhetskopior i andra datacenter.
Hur lång tid tar det? Finns det tillräckligt med nätverkskapacitet för hela sträckan?
15: 37. En avstängning av vissa delar av nätverket registrerades.
Ledningen och produktionsnätverket är fysiskt isolerade från varandra. Om produktionsnätverket är tillgängligt kan du gå till servern, stoppa applikationen och stänga av operativsystemet. Om det inte är tillgängligt kan du logga in via IPMI, stoppa applikationen och stänga av operativsystemet. Om det inte finns något av nätverken kan du inte göra någonting. "Tack, Cap!", tänker du.
"Och i allmänhet är det mycket kaos," kanske du också tänker.
Grejen är att servrar, även utan brand, genererar en enorm mängd värme. Närmare bestämt, när det finns kyla, genererar de värme, och när det inte finns någon kylning skapar de ett helvetiskt inferno, som i bästa fall kommer att smälta en del av utrustningen och stänga av en annan del, och i värsta fall... orsaka en eld inne i hallen, vilket nästan garanterat kommer att förstöra allt.
15:39. Vi fixar problem med conf-databasen.
Conf-databasen är backend för tjänsten med samma namn, som används av alla produktionsapplikationer för att snabbt ändra inställningar. Utan denna bas kan vi inte styra driften av portalen, men själva portalen kan fungera.
15:41. Temperatursensorer på Core-nätverksutrustning registrerar avläsningar nära det högsta tillåtna. Detta är en box som upptar ett helt rack och säkerställer driften av alla nätverk inne i datacentret.
15:42. Issue tracker och wiki är inte tillgängliga, växla till standby.
Det här är inte produktion, men i händelse av en olycka kan tillgången på någon kunskapsbas vara avgörande.
15:50. Ett av övervakningssystemen har stängts av.
Det finns flera av dem, och de ansvarar för olika aspekter av tjänsterna. Vissa av dem är konfigurerade att fungera autonomt inom varje datacenter (det vill säga de övervakar endast sitt eget datacenter), andra består av distribuerade komponenter som transparent överlever förlusten av vilket datacenter som helst.
I det här fallet slutade det fungera , som fungerar i master-standby-läge. Växlade till standby.
Antagande
15:51. Alla servrar utom MS SQL stängdes av via IPMI utan att stängas av korrekt.
Är du redo för massiv serverhantering via IPMI om det behövs?
Just det ögonblick då räddningen av utrustningen i datacentret är klar i detta skede. Allt som kunde göras har gjorts. Vissa kollegor kan vila.
16: 13. Information har mottagits om att freonrör från luftkonditioneringsapparater sprängs på taket - detta kommer att försena lanseringen av datacentret efter att branden eliminerats.
16:19. Enligt uppgifter från datacentrets tekniska personal har temperaturökningen i hallarna upphört.
17:10. Conf-databasen har återställts. Nu kan vi ändra applikationsinställningar.
Varför är detta så viktigt om allt är feltåligt och fungerar även utan ett datacenter?
För det första är inte allt feltolerant. Det finns olika sekundära tjänster som ännu inte har överlevt ett datacenterfel tillräckligt bra, och det finns databaser i master-standby-läge. Möjligheten att hantera inställningar gör att du kan göra allt som behövs för att minimera konsekvenserna av en olycka på användarna även under svåra förhållanden.
För det andra stod det klart att driften av datacentret inte skulle återställas helt under de kommande timmarna, så det var nödvändigt att vidta åtgärder för att säkerställa att den långvariga otillgängligheten av repliker inte ledde till ytterligare problem såsom fulla diskar i återstående datacenter.
17:29. Pizzadags! Vi anställer människor, inte robotar.
Rehabilitering
18:02. I hall nr 8 (vår), 9, 10 och 11 har temperaturen stabiliserats. En av de som förblir offline (nr 7) rymmer vår utrustning, och temperaturen där fortsätter att stiga.
18:31. De gav klartecken att starta upp utrustningen i hall nr 1 och 3 - dessa hallar var inte påverkade av branden.
För närvarande lanseras servrar i hall nr 1, 3, 8, med början i de mest kritiska. Korrekt funktion av alla pågående tjänster kontrolleras. Det är fortfarande problem med hall nr 7.
18:44. Datacentrets tekniska personal upptäckte att i rum nr 7 (där endast vår utrustning finns) är många servrar inte avstängda. Enligt våra uppgifter finns 26 servrar kvar online där. Efter en andra kontroll hittar vi 58 servrar.
20:18. Datacentertekniker blåser luft genom ett luftkonditionerat rum genom mobila kanaler som går genom korridorerna.
23:08. Den första administratören skickades hem. Någon måste sova på natten för att kunna fortsätta jobba imorgon. Därefter kommer vi att släppa några fler administratörer och utvecklare.
02:56. Vi lanserade allt som kunde lanseras. Vi kontrollerar mycket av alla tjänster med automatiska tester.
03:02. Luftkonditioneringen i den sista, sjunde hallen har återställts.
03:36. Vi förde fronterna i datacentret i rotation i DNS. Från det här ögonblicket börjar användartrafiken komma.
Vi skickar hem det mesta av det administrativa teamet. Men vi lämnar några personer bakom oss.
Liten FAQ:
F: Vad hände från 18:31 till 02:56?
S: Efter "Katastrofhandlingsplanen" lanserar vi alla tjänster, till att börja med de viktigaste. I det här fallet utfärdar koordinatorn i chatten tjänsten till en gratis administratör, som kontrollerar om operativsystemet och applikationen har startat, om det finns några fel och om indikatorerna är normala. Efter att lanseringen är klar rapporterar han till chatten att han är ledig och får en ny tjänst av samordnaren.
Processen bromsas ytterligare av felaktig hårdvara. Även om det gick korrekt att stoppa operativsystemet och stänga av servrarna, kommer vissa servrar inte tillbaka på grund av plötsligt fel på diskar, minne och chassi. När strömmen bryts ökar felfrekvensen.
F: Varför kan du inte bara köra allt på en gång och sedan fixa det som kommer upp i övervakningen?
S: Allt måste göras gradvis, eftersom det finns beroenden mellan tjänsterna. Och allt bör kontrolleras direkt, utan att vänta på övervakning - för det är bättre att ta itu med problem direkt, utan att vänta på att de ska förvärras.
7:40. Den sista admin (koordinator) gick och la sig. Första dagens arbete är avklarat.
8:09. De första utvecklarna, datacenteringenjörerna och administratörerna (inklusive den nya koordinatorn) påbörjade restaureringsarbetet.
09:37. Vi började höja hall nr 7 (den sista).
Samtidigt fortsätter vi att återställa det som inte var fixat i andra rum: byta ut diskar/minne/servrar, fixa allt som "bränns" i övervakning, byta roller tillbaka i master-standby-scheman och andra småsaker som det finns av ändå ganska mycket.
17:08. Vi tillåter allt regelbundet arbete med produktion.
21:45. Arbetet för den andra dagen är avslutat.
09:45. Idag är fredag. Det finns fortfarande en del små problem i övervakningen. Helgen ligger framför oss, alla vill koppla av. Vi fortsätter att massivt reparera allt vi kan. Regelbundna adminuppgifter som kunde ha skjutits upp sköts upp. Samordnaren är ny.
15:40. Plötsligt startade hälften av Core-nätverksutrustningsstacken i ETT ANNAT datacenter om. Fronter togs ur rotation för att minimera riskerna. Det finns ingen effekt för användarna. Det visade sig senare att det var ett trasigt chassi. Samordnaren arbetar med att reparera två olyckor samtidigt.
17:17. Nätverksdriften i ett annat datacenter har återställts, allt har kontrollerats. Datacentret sätts i rotation.
18:29. Tredjedagsarbetet och i allmänhet återställningen efter olyckan har slutförts.
efterordet
04.04.2013-XNUMX-XNUMX, , "Klasskamrater" — Under tre dagar var portalen helt eller delvis otillgänglig. Under hela denna tid har fler än 100 personer från olika städer, från olika företag (många tack igen!), på distans och direkt i datacenter, manuellt och automatiskt, reparerat tusentals servrar.
Vi har dragit slutsatser. För att detta inte ska hända igen har vi utfört och fortsätter att utföra ett omfattande arbete än i dag.
Vilka är de största skillnaderna mellan den aktuella olyckan och 404?
- Vi har en "Accident Action Plan". En gång i kvartalet genomför vi övningar - vi rollspelar en nödsituation, som en grupp administratörer (alla i sin tur) måste eliminera med hjälp av "Nödhandlingsplanen". Ledande systemadministratörer turas om att spela rollen som samordnare.
- Kvartalsvis, i testläge, isolerar vi datacenter (alla i tur och ordning) via LAN- och WAN-nätverk, vilket gör att vi snabbt kan identifiera flaskhalsar.
- Färre trasiga diskar, eftersom vi har skärpt standarderna: färre drifttimmar, strängare trösklar för SMART,
- Vi övergav helt BerkeleyDB, en gammal och instabil databas som krävde mycket tid att återhämta sig efter en omstart av servern.
- Vi minskade antalet servrar med MS SQL och minskade beroendet av de återstående.
- Vi har vår egen , där vi aktivt har migrerat alla tjänster i två år nu. Molnet förenklar avsevärt hela arbetscykeln med applikationen, och i händelse av en olycka ger det så unika verktyg som:
- korrekt stopp av alla applikationer med ett klick;
- enkel migrering av applikationer från misslyckade servrar;
- automatisk rankad (i tjänsternas prioritetsordning) lansering av ett helt datacenter.
Olyckan som beskrivs i denna artikel var den största sedan den 404:e dagen. Allt gick förstås inte smidigt. Till exempel, under avsaknaden av ett brandskadat datacenter i ett annat datacenter, misslyckades en disk på en av servrarna, det vill säga att endast en av de tre replikerna i Cassandra-klustret förblev tillgänglig, vilket är anledningen till att 4,2 % av mobilen programanvändare kunde inte logga in. Samtidigt fortsatte redan anslutna användare att arbeta. Totalt, som ett resultat av olyckan, identifierades mer än 30 problem – från banala buggar till brister i tjänstearkitekturen.
Men den viktigaste skillnaden mellan den aktuella olyckan och den 404:e är att medan vi eliminerade konsekvenserna av branden, skickade användarna fortfarande sms och ringde videosamtal till , spelade spel, lyssnade på musik, gav varandra presenter, tittade på videor, tv-serier och tv-kanaler i , och även strömmade in .
Hur går dina olyckor?
Källa: will.com