Hoe zou u zich voelen als op een mooie zomerdag het datacenter met uw apparatuur er zo uit zou zien?
Dag Allemaal! Mijn naam is Dmitry Samsonov, ik werk als een toonaangevende systeembeheerder bij "" De foto toont een van de vier datacenters waar de apparatuur ten behoeve van ons project is geïnstalleerd. Achter deze muren bevinden zich ongeveer vierduizend apparaten: servers, gegevensopslagsystemen, netwerkapparatuur, enz. - bijna ⅓ van al ons materiaal.
De meeste servers zijn Linux. Er zijn ook enkele tientallen servers op Windows (MS SQL) - ons erfgoed, dat we al jaren systematisch in de steek laten.
Dus op 5 juni 2019 om 14 uur meldden ingenieurs in een van onze datacenters een brandalarm.
ontkenning
14:45. Kleine rookincidenten in datacenters komen vaker voor dan u denkt. De indicatoren in de hallen waren normaal, dus onze eerste reactie was relatief kalm: ze introduceerden een verbod op werken met productie, dat wil zeggen op eventuele configuratiewijzigingen, op het uitrollen van nieuwe versies, enz., Behalve op werk dat verband houdt met het repareren van iets.
toorn
Heeft u ooit geprobeerd om van de brandweer te achterhalen waar de brand precies heeft plaatsgevonden op het dak, of zelf op een brandend dak te komen om de situatie te beoordelen? Wat zal de mate van vertrouwen zijn in de informatie die via vijf personen wordt ontvangen?
14: 50. Er is informatie ontvangen dat de brand het koelsysteem nadert. Maar zal het komen? De dienstdoende systeembeheerder verwijdert het externe verkeer van de fronten van dit datacenter.
Op dit moment zijn de fronten van al onze diensten gedupliceerd in drie datacenters, er wordt balancering gebruikt op DNS-niveau, waardoor we de adressen van één datacenter uit de DNS kunnen verwijderen, waardoor gebruikers worden beschermd tegen mogelijke problemen met toegang tot services . Als er al problemen zijn opgetreden in het datacenter, verlaat het automatisch de rotatie. Je kunt hier meer lezen:
De brand heeft ons nog op geen enkele manier getroffen; gebruikers en apparatuur zijn niet beschadigd. Is dit een ongeluk? Het eerste deel van het document “Ongevallenactieplan” definieert het concept van “Ongeval”, en het deel eindigt als volgt:
«Als er enige twijfel bestaat of er sprake is van een ongeluk of niet, dan is het een ongeluk!»
14:53. Er wordt een noodcoördinator aangesteld.
De coördinator is de persoon die de communicatie tussen alle deelnemers regelt, de omvang van het ongeval beoordeelt, het noodactieplan gebruikt, het benodigde personeel aantrekt, toezicht houdt op de voltooiing van reparaties en, belangrijker nog, alle taken delegeert. Dit is met andere woorden de persoon die het gehele BHV-proces beheert.
veiling
15:01. We beginnen servers uit te schakelen die geen verband houden met de productie.
15:03. Wij schakelen alle gereserveerde diensten correct uit.
Dit omvat niet alleen fronten (waartoe gebruikers op dit moment geen toegang meer hebben) en hun ondersteunende diensten (bedrijfslogica, caches, enz.), maar ook verschillende databases met replicatiefactor 2 of meer (, , , enz.).
15: 06. Er is informatie ontvangen dat er brand dreigt in een van de datacenterhallen. We hebben geen apparatuur in deze ruimte, maar het feit dat de brand zich van het dak naar de hallen kan verspreiden, verandert het beeld van wat er gebeurt enorm.
(Later bleek dat er geen sprake was van fysieke bedreiging voor de hal, aangezien deze hermetisch afgesloten was van het dak. De bedreiging gold alleen voor het koelsysteem van deze hal.)
15:07. We staan uitvoering van opdrachten toe op servers in de versnelde modus zonder extra controles ().
15:08. De temperatuur in de hallen ligt binnen de normale grenzen.
15: 12. Er werd een stijging van de temperatuur in de hallen geregistreerd.
15:13. Ruim de helft van de servers in het datacenter staat uit. Laten we doorgaan.
15:16. Er werd besloten om alle apparatuur uit te schakelen.
15:21. We beginnen de stroom naar staatloze servers uit te schakelen zonder de applicatie en het besturingssysteem correct af te sluiten.
15:23. Er wordt een groep mensen toegewezen die verantwoordelijk is voor MS SQL (er zijn er maar weinig, de afhankelijkheid van diensten ervan is niet groot, maar de procedure voor het herstellen van de functionaliteit duurt langer en is ingewikkelder dan bijvoorbeeld Cassandra).
Депрессия
15: 25. Er is informatie ontvangen over het uitschakelen van de stroom in vier van de zestien hallen (nr. 16, 6, 7, 8). Ons materieel staat in hallen 7 en 8. Er is geen informatie over onze twee hallen (nr. 1 en 3).
Meestal wordt bij brand de stroomvoorziening onmiddellijk uitgeschakeld, maar in dit geval werd deze dankzij het gecoördineerde werk van brandweerlieden en technisch personeel van het datacenter niet overal en niet onmiddellijk uitgeschakeld, maar indien nodig.
(Later werd ontdekt dat de stroom in hallen 8 en 9 niet was uitgeschakeld.)
15:28. We beginnen MS SQL-databases te implementeren vanaf back-ups in andere datacentra.
Hoelang zal het duren? Is er voldoende netwerkcapaciteit voor het gehele traject?
15: 37. Er werd een uitschakeling van sommige delen van het netwerk geregistreerd.
Het management en het productienetwerk zijn fysiek van elkaar geïsoleerd. Als het productienetwerk beschikbaar is, kunt u naar de server gaan, de applicatie stoppen en het besturingssysteem uitschakelen. Als deze niet beschikbaar is, kunt u inloggen via IPMI, de applicatie stoppen en het besturingssysteem uitschakelen. Als er geen van de netwerken is, kun je niets doen. “Bedankt, Cap!”, zul je denken.
“En over het algemeen is er veel onrust”, denk je misschien ook.
Het punt is dat servers, zelfs zonder vuur, een enorme hoeveelheid warmte genereren. Om preciezer te zijn: als er koeling is, genereren ze warmte, en als er geen koeling is, creëren ze een helse inferno, die in het beste geval een deel van de apparatuur doet smelten en een ander onderdeel uitschakelt, en in het slechtste geval... brand in de hal, die vrijwel gegarandeerd alles vernietigt.
15:39. We lossen problemen met de conf-database op.
De conf-database is de backend voor de gelijknamige dienst, die door alle productieapplicaties wordt gebruikt om snel instellingen te wijzigen. Zonder deze basis kunnen we de werking van het portaal niet controleren, maar het portaal zelf kan wel werken.
15:41. Temperatuursensoren op kernnetwerkapparatuur registreren metingen die dicht bij het maximaal toelaatbare liggen. Dit is een box die een heel rack beslaat en zorgt voor de werking van alle netwerken binnen het datacenter.
15:42. Issuetracker en wiki zijn niet beschikbaar, schakel over naar stand-by.
Dit is geen productie, maar in het geval van een ongeval kan de beschikbaarheid van welke kennisbasis dan ook van cruciaal belang zijn.
15:50. Eén van de monitoringsystemen is uitgeschakeld.
Er zijn er meerdere, en zij zijn verantwoordelijk voor verschillende aspecten van de dienstverlening. Sommigen van hen zijn geconfigureerd om autonoom binnen elk datacenter te opereren (dat wil zeggen, ze monitoren alleen hun eigen datacenter), andere bestaan uit gedistribueerde componenten die op transparante wijze het verlies van welk datacenter dan ook overleven.
In dit geval stopte het met werken , die in de master-standby-modus werkt. Overgeschakeld naar stand-by.
Adoptie
15:51. Alle servers behalve MS SQL werden via IPMI uitgeschakeld zonder correct af te sluiten.
Bent u klaar voor grootschalig serverbeheer via IPMI indien nodig?
Precies op het moment dat de redding van apparatuur in het datacenter in deze fase is voltooid. Alles wat gedaan kon worden, is gedaan. Sommige collega's kunnen uitrusten.
16: 13. Er is informatie ontvangen dat freonleidingen van airconditioners op het dak barsten - dit zal de lancering van het datacenter vertragen nadat de brand is geëlimineerd.
16:19. Volgens gegevens van technisch personeel van het datacenter is de temperatuurstijging in de hallen gestopt.
17:10. De conf-database is hersteld. Nu kunnen we de applicatie-instellingen wijzigen.
Waarom is dit zo belangrijk als alles fouttolerant is en zelfs zonder één datacenter werkt?
Ten eerste is niet alles fouttolerant. Er zijn verschillende secundaire diensten die een datacenterstoring nog niet goed genoeg hebben overleefd, en er zijn databases in master-standby-modus. Dankzij de mogelijkheid om instellingen te beheren, kunt u al het nodige doen om de impact van de gevolgen van een ongeval op gebruikers te minimaliseren, zelfs in moeilijke omstandigheden.
Ten tweede werd duidelijk dat de werking van het datacenter de komende uren niet volledig zou worden hersteld, dus moesten er maatregelen worden genomen om ervoor te zorgen dat de langdurige onbeschikbaarheid van replica’s niet tot extra problemen zou leiden, zoals volle schijven in het datacenter. de overige datacenters.
17:29. Pizza tijd! Wij hebben mensen in dienst, geen robots.
Rehabilitatie
18:02. In hallen nr. 8 (bij ons), 9, 10 en 11 is de temperatuur gestabiliseerd. In een van de apparaten die offline blijft (nr. 7) staat onze apparatuur, en de temperatuur blijft daar stijgen.
18:31. Ze gaven groen licht voor het opstarten van de apparatuur in hallen nr. 1 en 3; deze hallen werden niet getroffen door de brand.
Momenteel worden servers gelanceerd in de hallen nr. 1, 3, 8, te beginnen met de meest kritische. De correcte werking van alle lopende services wordt gecontroleerd. Er zijn nog steeds problemen met hal nr. 7.
18:44. De technische staf van het datacentrum ontdekte dat in kamer nr. 7 (waar alleen onze apparatuur staat) veel servers niet uitgeschakeld zijn. Volgens onze gegevens blijven daar 26 servers online. Na een tweede controle vinden we 58 servers.
20:18. Technici van het datacenter blazen lucht door een ruimte zonder airconditioning via mobiele kanalen die door de gangen lopen.
23:08. De eerste beheerder werd naar huis gestuurd. Iemand moet 's nachts slapen om morgen verder te kunnen werken. Vervolgens zullen we nog enkele beheerders en ontwikkelaars vrijgeven.
02:56. We hebben alles gelanceerd wat gelanceerd kon worden. Wij controleren alle diensten veel met automatische tests.
03:02. De airconditioning in de laatste, 7e hal is hersteld.
03:36. We hebben de fronten in het datacenter in DNS in rotatie gebracht. Vanaf dit moment begint het gebruikersverkeer binnen te komen.
We sturen het grootste deel van het administratieve team naar huis. Maar we laten een paar mensen achter.
Kleine veelgestelde vragen:
Vraag: Wat gebeurde er van 18:31 tot 02:56?
A: In navolging van het “Rampactieplan” lanceren we alle diensten, te beginnen met de belangrijkste. In dit geval geeft de coördinator in de chat de service door aan een gratis beheerder, die controleert of het besturingssysteem en de applicatie zijn gestart, of er fouten zijn en of de indicatoren normaal zijn. Nadat de lancering is voltooid, meldt hij op de chat dat hij vrij is en een nieuwe dienst krijgt van de coördinator.
Het proces wordt verder vertraagd door defecte hardware. Zelfs als het stoppen van het besturingssysteem en het afsluiten van de servers correct zijn verlopen, keren sommige servers niet terug vanwege plotselinge uitval van schijven, geheugen en chassis. Wanneer de stroom uitvalt, neemt het uitvalpercentage toe.
Vraag: Waarom kun je niet gewoon alles in één keer uitvoeren en vervolgens oplossen wat er tijdens de monitoring naar voren komt?
A: Alles moet geleidelijk gebeuren, omdat er afhankelijkheden zijn tussen services. En alles moet meteen worden gecontroleerd, zonder te wachten op monitoring - omdat het beter is om problemen meteen aan te pakken, zonder te wachten tot ze verergeren.
7:40. De laatste admin (coördinator) ging naar bed. Het werk van de eerste dag zit erop.
8:09. De eerste ontwikkelaars, datacenteringenieurs en beheerders (inclusief de nieuwe coördinator) begonnen met de restauratiewerkzaamheden.
09:37. We begonnen hal nr. 7 (de laatste) te verhogen.
Tegelijkertijd gaan we door met het herstellen van wat in andere kamers niet was opgelost: het vervangen van schijven/geheugen/servers, het repareren van alles dat “brandt” bij het monitoren, het terugschakelen van rollen in master-standby-schema’s en andere kleine dingen, waarvan er toch best veel.
17:08. Wij staan alle reguliere werkzaamheden met productie toe.
21:45 uur. Het werk van de tweede dag zit erop.
09:45 uur. Vandaag is het vrijdag. Er zijn nog behoorlijk wat kleine problemen bij de monitoring. Het weekend staat voor de deur, iedereen wil ontspannen. We blijven massaal alles repareren wat we kunnen. Reguliere administratieve taken die uitgesteld hadden kunnen worden, zijn uitgesteld. De coördinator is nieuw.
15:40. Plotseling werd de helft van de kernnetwerkapparatuur in EEN ANDER datacenter opnieuw opgestart. Fronten werden uit de rotatie gehaald om de risico's te minimaliseren. Er is geen effect voor gebruikers. Later bleek dat het om een defect chassis ging. De coördinator is bezig met het repareren van twee ongelukken tegelijk.
17:17. De netwerkwerking in een ander datacenter is hersteld, alles is gecontroleerd. Het datacenter wordt in rotatie gebracht.
18:29. Het werk van de derde dag en in het algemeen de restauratie na het ongeval is voltooid.
nawoord
04.04.2013 , "Klasgenoten" —drie dagen lang was het portaal geheel of gedeeltelijk niet beschikbaar. Gedurende deze hele tijd hebben meer dan 100 mensen uit verschillende steden, van verschillende bedrijven (nogmaals hartelijk dank!), op afstand en rechtstreeks in datacentra, handmatig en automatisch, duizenden servers gerepareerd.
Wij hebben conclusies getrokken. Om te voorkomen dat dit nog eens gebeurt, hebben wij tot op de dag van vandaag omvangrijke werkzaamheden uitgevoerd en nog steeds uitgevoerd.
Wat zijn de belangrijkste verschillen tussen het huidige ongeval en 404?
- We hebben een ‘Ongevallenactieplan’. Eén keer per kwartaal houden we oefeningen - we spelen een noodsituatie na, die een groep beheerders (allemaal op hun beurt) moet elimineren met behulp van het 'Noodactieplan'. Leidinggevende systeembeheerders vervullen om de beurt de rol van coördinator.
- Ieder kwartaal isoleren we in testmodus datacenters (allemaal) via LAN- en WAN-netwerken, waardoor we knelpunten snel kunnen identificeren.
- Minder kapotte schijven, omdat we de normen hebben aangescherpt: minder draaiuren, strengere drempels voor SMART,
- We hebben BerkeleyDB volledig verlaten, een oude en onstabiele database die veel tijd nodig had om te herstellen na een herstart van de server.
- We hebben het aantal servers met MS SQL verminderd en de afhankelijkheid van de overige servers verminderd.
- Wij hebben de onze , waar we al twee jaar actief alle diensten migreren. De cloud vereenvoudigt de hele cyclus van het werken met de applicatie aanzienlijk en biedt in geval van een ongeval unieke tools zoals:
- correcte stop van alle applicaties in één klik;
- eenvoudige migratie van applicaties van defecte servers;
- automatische gerangschikte (in volgorde van prioriteit van diensten) lancering van een volledig datacenter.
Het in dit artikel beschreven ongeval was het grootste sinds de 404e dag. Uiteraard verliep niet alles vlekkeloos. Tijdens de onbeschikbaarheid van een door brand beschadigd datacenter in een ander datacenter viel bijvoorbeeld een schijf op een van de servers uit, dat wil zeggen dat slechts één van de drie replica's in het Cassandra-cluster toegankelijk bleef. Daarom bleef 4,2% van de mobiele datacenters toegankelijk. applicatiegebruikers konden niet inloggen. Tegelijkertijd bleven reeds verbonden gebruikers werken. In totaal werden als gevolg van het ongeval meer dan 30 problemen geïdentificeerd - van banale bugs tot tekortkomingen in de servicearchitectuur.
Maar het belangrijkste verschil tussen het huidige ongeval en het 404e ongeval is dat terwijl we de gevolgen van de brand elimineerden, gebruikers nog steeds sms'ten en videogesprekken voerden naar , spelletjes gespeeld, naar muziek geluisterd, elkaar cadeautjes gegeven, filmpjes, tv-series en tv-zenders bekeken , en ook gestreamd .
Hoe verlopen jouw ongelukken?
Bron: www.habr.com