Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

Miltä sinusta tuntuisi, jos eräänä kauniina kesäpäivänä palvelinkeskus laitteineen näyttäisi tältä?

Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

Hei kaikki! Nimeni on Dmitry Samsonov, työskentelen johtavana järjestelmänvalvojana yrityksessä "Odnoklassniki" Kuvassa on yksi neljästä konesalista, joihin projektiamme palvelevat laitteet on asennettu. Näiden seinien takana on noin 4 tuhatta laitetta: palvelimet, tiedontallennusjärjestelmät, verkkolaitteet jne. - lähes kolmasosa kaikista laitteistamme.
Suurin osa palvelimista on Linux. Windowsissa (MS SQL) on myös useita kymmeniä palvelimia - perintöämme, josta olemme järjestelmällisesti luopuneet useiden vuosien ajan.
Joten 5. kesäkuuta 2019 klo 14 yhden palvelinkeskuksemme insinöörit ilmoittivat palohälytyksestä.

kieltäminen

14:45. Pienet savutapahtumat palvelinkeskuksissa ovat yleisempiä kuin uskotkaan. Hallien sisällä olevat indikaattorit olivat normaalit, joten ensimmäinen reaktiomme oli suhteellisen rauhallinen: ne kielsivät tuotannon kanssa työskentelyn, eli kaikki konfiguraatiomuutokset, uusien versioiden levittäminen jne., lukuun ottamatta jonkin korjaamiseen liittyviä töitä.

viha

Oletko koskaan yrittänyt selvittää palomiehiltä tarkalleen, missä katolla palo syttyi, tai päästä itse palavalle katolle arvioimaan tilannetta? Mikä on luottamus viiden ihmisen kautta saatuun tietoon?

14: 50. On saatu tietoa, että tuli on lähestymässä jäähdytysjärjestelmää. Mutta tuleeko se? Päivystävä järjestelmänvalvoja poistaa ulkoisen liikenteen tämän datakeskuksen edestä.

Tällä hetkellä kaikkien palveluidemme eturintamat on kopioitu kolmeen palvelinkeskukseen, tasapainotusta käytetään DNS-tasolla, jonka avulla voimme poistaa yhden datakeskuksen osoitteet DNS:stä ja näin suojata käyttäjiä mahdollisilta ongelmilta pääsyyn palveluihin. . Jos konesalissa on jo ilmennyt ongelmia, se poistuu automaattisesti kierrosta. Voit lukea lisää täältä: Kuormituksen tasapainotus ja vikasietoisuus Odnoklassnikissa.

Palo ei ole vielä vaikuttanut meihin millään tavalla - käyttäjiä tai laitteita ei ole vahingoitettu. Onko tämä onnettomuus? Asiakirjan ensimmäinen osa ”Onnettomuussuunnitelma” määrittelee käsitteen ”onnettomuus”, ja osio päättyy näin:
«Jos on epäilystäkään siitä, onko kyseessä onnettomuus vai ei, se on onnettomuus!»

14:53. Hätäkoordinaattori nimitetään.

Koordinaattori on henkilö, joka ohjaa kaikkien osallistujien välistä viestintää, arvioi onnettomuuden laajuuden, käyttää hätätilannesuunnitelmaa, houkuttelee tarvittavan henkilöstön, valvoo korjausten valmistumista ja mikä tärkeintä, delegoi kaikki tehtävät. Toisin sanoen tämä on henkilö, joka johtaa koko hätätilanneprosessia.

huutokauppa

15:01. Alamme poistaa käytöstä palvelimia, jotka eivät liity tuotantoon.
15:03. Sammutamme kaikki varatut palvelut oikein.
Tämä ei sisällä vain etuosia (joihin käyttäjät eivät tässä vaiheessa enää pääse) ja niiden apupalvelut (liiketoimintalogiikka, välimuistit jne.), vaan myös erilaiset tietokannat, joiden replikointikerroin 2 tai enemmän (Cassandra, binääritietojen tallennus, kylmävarasto, NewSQL jne.).
15: 06. On saatu tietoa, että tulipalo uhkaa yhtä palvelinkeskuksen hallista. Meillä ei ole laitteita tässä huoneessa, mutta se, että tuli voi levitä katolta halleihin, muuttaa suuresti kuvaa siitä, mitä tapahtuu.
(Myöhemmin kävi ilmi, että hallille ei ollut fyysistä uhkaa, koska se oli hermeettisesti suljettu katolta. Uhka kohdistui vain tämän hallin jäähdytysjärjestelmään.)
15:07. Sallimme komentojen suorittamisen palvelimilla kiihdytetyssä tilassa ilman lisätarkistuksia (ilman suosikkilaskintamme).
15:08. Hallien lämpötila on normaalirajoissa.
15: 12. Halleissa havaittiin lämpötilan nousua.
15:13. Yli puolet palvelinkeskuksen palvelimista on sammutettu. Jatketaan.
15:16. Kaikki laitteet päätettiin sammuttaa.
15:21. Alamme katkaista virran tilattomista palvelimista sammuttamatta sovellusta ja käyttöjärjestelmää oikein.
15:23. MS SQL:stä vastuussa oleva ryhmä on allokoitu (heitä on vähän, palveluiden riippuvuus heistä ei ole suuri, mutta toimivuuden palauttamisprosessi kestää kauemmin ja on monimutkaisempi kuin esimerkiksi Cassandra).

masennus

15: 25. Tietoa saatiin sähkön katkaisemisesta neljässä hallissa 16:sta (nro 6, 7, 8, 9). Laitteemme sijaitsevat halleissa 7 ja 8. Kahdesta hallistamme (nro 1 ja 3) ei ole tietoa.
Yleensä tulipalojen aikana virransyöttö sammutetaan välittömästi, mutta tässä tapauksessa palomiesten ja datakeskuksen teknisen henkilöstön koordinoidun työn ansiosta sitä ei sammutettu kaikkialla eikä heti, vaan tarpeen mukaan.
(Myöhemmin selvisi, että hallissa 8 ja 9 ei ollut katkaistu sähköä.)
15:28. Olemme alkaneet ottaa käyttöön MS SQL -tietokantoja muiden palvelinkeskusten varmuuskopioista.
Kauanko se kestää? Onko verkon kapasiteetti tarpeeksi koko reitille?
15: 37. Joidenkin verkon osien sammutus tallennettiin.
Johto ja tuotantoverkosto ovat fyysisesti eristettyjä toisistaan. Jos tuotantoverkko on käytettävissä, voit mennä palvelimelle, pysäyttää sovelluksen ja sammuttaa käyttöjärjestelmän. Jos se ei ole käytettävissä, voit kirjautua sisään IPMI:n kautta, pysäyttää sovelluksen ja sammuttaa käyttöjärjestelmän. Jos yhtään verkkoa ei ole, et voi tehdä mitään. "Kiitos, Cap!", ajattelet.
"Ja yleensäkin on paljon sekasortoa", saatat myös ajatella.
Asia on siinä, että palvelimet tuottavat valtavan määrän lämpöä jopa ilman tulta. Tarkemmin sanottuna, kun on jäähdytystä, ne tuottavat lämpöä, ja kun jäähdytystä ei ole, ne luovat helvetin helvetin, joka parhaimmillaan sulattaa osan laitteista ja sammuttaa toisen osan ja pahimmillaan... aiheuttaa tulipalon sisällä sali, joka melkein taatusti tuhoaa kaiken.

Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

15:39. Korjaamme conf-tietokannan ongelmat.

Conf-tietokanta on samannimisen palvelun taustaohjelma, jota kaikki tuotantosovellukset käyttävät asetusten nopeaan muuttamiseen. Ilman tätä perustaa emme voi hallita portaalin toimintaa, mutta itse portaali voi toimia.

15:41. Runkoverkon laitteiden lämpötila-anturit tallentavat lukemia lähellä suurinta sallittua. Tämä on laatikko, joka kattaa koko telineen ja varmistaa kaikkien verkkojen toiminnan datakeskuksen sisällä.

Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

15:42. Ongelmaseuranta ja wiki eivät ole käytettävissä, siirry valmiustilaan.
Tämä ei ole tuotantoa, mutta onnettomuuden sattuessa minkä tahansa tietokannan saatavuus voi olla kriittistä.
15:50. Yksi valvontajärjestelmistä on sammunut.
Niitä on useita, ja he vastaavat palvelujen eri puolista. Jotkut niistä on määritetty toimimaan itsenäisesti kussakin palvelinkeskuksessa (eli ne valvovat vain omaa palvelinkeskustaan), toiset koostuvat hajautetuista komponenteista, jotka selviävät läpinäkyvästi minkä tahansa datakeskuksen katoamisesta.
Tässä tapauksessa se lakkasi toimimasta liiketoimintalogiikan indikaattorit poikkeamien havaitsemisjärjestelmä, joka toimii master-valmiustilassa. Vaihdettu valmiustilaan.

Hyväksyminen

15:51. Kaikki palvelimet paitsi MS SQL sammutettiin IPMI:n kautta ilman, että ne sammuivat oikein.
Oletko valmis massiiviseen palvelinhallintaan tarvittaessa IPMI:n kautta?

Juuri se hetki, jolloin konesalin laitteiden pelastus valmistuu tässä vaiheessa. Kaikki mitä voitiin tehdä, on tehty. Jotkut kollegat voivat levätä.
16: 13. On saatu tietoa, että ilmastointilaitteiden freoniputket puhkesivat katolle - tämä viivästyttää palvelinkeskuksen käynnistämistä palon sammumisen jälkeen.
16:19. Palvelinkeskuksen tekniseltä henkilökunnalta saatujen tietojen mukaan lämpötilan nousu halleissa on pysähtynyt.
17:10. Conf-tietokanta on palautettu. Nyt voimme muuttaa sovellusasetuksia.
Miksi tämä on niin tärkeää, jos kaikki on vikasietoista ja toimii myös ilman yhtä datakeskusta?
Ensinnäkin kaikki ei ole vikasietoinen. On olemassa useita toissijaisia ​​palveluita, jotka eivät ole vielä selvinneet riittävän hyvin konesalin vioista, ja tietokantoja on master-standby-tilassa. Asetusten hallinta mahdollistaa kaiken tarvittavan minimoidaksesi onnettomuuden seurausten vaikutukset käyttäjiin vaikeissakin olosuhteissa.
Toiseksi kävi selväksi, että konesalin toimintaa ei palauteta täysin lähituntien aikana, joten oli tarpeen ryhtyä toimenpiteisiin sen varmistamiseksi, että jäljennösten pitkäaikainen poissaolo ei johda ylimääräisiin ongelmiin, kuten levyjen täyttymiseen. loput datakeskukset.
17:29. Pizzan aika! Työllistämme ihmisiä, emme robotteja.

Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

Kuntoutus

18:02. Halleissa nro 8 (meidän), 9, 10 ja 11 lämpötila on tasaantunut. Yhdessä offline-tilassa (nro 7) on laitteistomme, ja siellä lämpötila jatkaa nousuaan.
18:31. He antoivat luvan käynnistää laitteet halleissa nro 1 ja 3 – tuli ei vaikuttanut näihin halleihin.

Tällä hetkellä palvelimet lanseerataan halleissa nro 1, 3, 8 kriittisimmistä alkaen. Kaikkien käynnissä olevien palvelujen oikea toiminta tarkistetaan. Hallissa nro 7 on edelleen ongelmia.

18:44. Palvelinkeskuksen tekninen henkilökunta havaitsi, että huoneessa nro 7 (jossa vain laitteemme sijaitsevat) monia palvelimia ei ole kytketty pois päältä. Tietojemme mukaan siellä on edelleen verkossa 26 palvelinta. Toisen tarkistuksen jälkeen löydämme 58 palvelinta.
20:18. Palvelinkeskuksen teknikot puhaltavat ilmaa ilmastoimattoman huoneen läpi käytävien läpi kulkevien siirrettävien kanavien kautta.
23:08. Ensimmäinen ylläpitäjä lähetettiin kotiin. Jonkun täytyy nukkua yöllä jatkaakseen töitä huomenna. Seuraavaksi julkaisemme lisää järjestelmänvalvojia ja kehittäjiä.
02:56. Käynnistimme kaiken, mikä oli mahdollista. Tarkistamme kaikki palvelut paljon automaattisilla testeillä.

Pitäisikö palvelimet sammuttaa, jos konesalin savutesti syttyy tuleen?

03:02. Viimeisen, 7. hallin ilmastointi on kunnostettu.
03:36. Otimme palvelinkeskuksen etuosat rotaatioon DNS:ssä. Tästä hetkestä lähtien käyttäjäliikenne alkaa saapua.
Lähetämme suurimman osan hallintotiimistä kotiin. Mutta jätämme muutaman ihmisen taakse.

Pienet UKK:
K: Mitä tapahtui klo 18-31?
V: "Katastrofitoimintasuunnitelman" mukaisesti käynnistämme kaikki palvelut tärkeimmistä alkaen. Tässä tapauksessa chatin koordinaattori antaa palvelun ilmaiselle ylläpitäjälle, joka tarkistaa, ovatko käyttöjärjestelmä ja sovellus käynnistyneet, onko virheitä ja ovatko ilmaisimet normaalit. Käynnistyksen päätyttyä hän ilmoittaa chatiin olevansa vapaa ja saa uuden palvelun koordinaattorilta.
Prosessia hidastaa edelleen viallinen laitteisto. Vaikka käyttöjärjestelmän pysäyttäminen ja palvelimien sammuttaminen sujuivat oikein, jotkin palvelimet eivät palaa levyjen, muistin ja kotelon äkillisen vian vuoksi. Kun virta katkeaa, vikaprosentti kasvaa.
K: Mikset voi vain ajaa kaikkea kerralla ja sitten korjata sitä, mitä seurannassa ilmenee?
V: Kaikki on tehtävä asteittain, koska palveluiden välillä on riippuvuuksia. Ja kaikki tulisi tarkistaa heti, odottamatta seurantaa - koska on parempi käsitellä ongelmia heti odottamatta niiden pahenemista.

7:40. Viimeinen admin (koordinaattori) meni nukkumaan. Ensimmäisen päivän työt on saatu päätökseen.
8:09. Ensimmäiset kehittäjät, palvelinkeskusten insinöörit ja ylläpitäjät (mukaan lukien uusi koordinaattori) aloittivat kunnostustyöt.
09:37. Aloimme nostaa salia nro 7 (viimeinen).
Samanaikaisesti jatkamme sen palauttamista, mitä muissa huoneissa ei ole korjattu: levyjen/muistin/palvelimien vaihtaminen, kaiken valvonnassa "polttavan" korjaaminen, roolien vaihtaminen takaisin master-standby-järjestelmissä ja muita pikkujuttuja, joita on olemassa. kuitenkin aika paljon.
17:08. Sallimme kaikki säännölliset työt tuotannon kanssa.
21:45. Toisen päivän työ on valmis.
09:45. Tänään on perjantai. Valvonnassa on edelleen pieniä ongelmia. Viikonloppu on edessä, kaikki haluavat rentoutua. Jatkamme massiivisesti kaiken mahdollisen korjaamista. Säännölliset järjestelmänvalvojan tehtävät, joita olisi voitu lykätä, siirrettiin. Koordinaattori on uusi.
15:40. Yhtäkkiä puolet ydinverkon laitepinosta TOISSA palvelinkeskuksessa käynnistyi uudelleen. Etuosat otettiin pois rotaatiosta riskien minimoimiseksi. Ei vaikutusta käyttäjiin. Myöhemmin kävi ilmi, että se oli viallinen alusta. Koordinaattori työskentelee kahden onnettomuuden korjaamiseksi kerralla.
17:17. Verkon toiminta toisessa palvelinkeskuksessa on palautettu, kaikki on tarkistettu. Palvelinkeskus laitetaan kiertoon.
18:29. Kolmannen päivän työ ja yleensä onnettomuuden jälkeinen kunnostus on saatu päätökseen.

loppusanat

04.04.2013 g., 404-virheen päivänä, "luokkatoverit" selvisi suurimmasta onnettomuudesta -portaali oli kokonaan tai osittain poissa kolme päivää. Koko tämän ajan yli 100 ihmistä eri kaupungeista, eri yrityksistä (suuret kiitokset jälleen!), etänä ja suoraan palvelinkeskuksissa, manuaalisesti ja automaattisesti, korjasi tuhansia palvelimia.
Olemme tehneet johtopäätökset. Jotta tämä ei toistuisi, olemme tehneet ja jatkamme laajaa työtä tähän päivään asti.

Mitkä ovat tärkeimmät erot nykyisen onnettomuuden ja 404:n välillä?

  • Meillä on "onnettomuuksien toimintasuunnitelma". Kerran vuosineljänneksessä toteutamme harjoituksia - näyttelemme hätätilannetta, joka ryhmän ylläpitäjiä (kaikki vuorotellen) on poistettava "Emergency Action Plan" -ohjelman avulla. Johtavat järjestelmänvalvojat toimivat vuorotellen koordinaattorina.
  • Neljännesvuosittain testitilassa eristämme datakeskukset (kaikki vuorotellen) LAN- ja WAN-verkkojen kautta, mikä mahdollistaa pullonkaulojen nopean tunnistamisen.
  • Vähemmän rikkinäisiä levyjä, koska olemme tiukentaneet standardeja: vähemmän käyttötunteja, tiukemmat SMART-kynnykset,
  • Hylkäsimme kokonaan BerkeleyDB:n, vanhan ja epävakaan tietokannan, jonka palautuminen palvelimen uudelleenkäynnistyksen jälkeen vaati paljon aikaa.
  • Vähensimme MS SQL -palvelimien määrää ja vähensimme riippuvuutta jäljellä olevista palvelimista.
  • Meillä on omamme pilvi - yksipilvi, jossa olemme siirtäneet kaikkia palveluita aktiivisesti jo kahden vuoden ajan. Pilvi yksinkertaistaa huomattavasti koko sovelluksen kanssa työskentelysykliä, ja onnettomuuden sattuessa se tarjoaa ainutlaatuisia työkaluja, kuten:
    • kaikkien sovellusten oikea pysäytys yhdellä napsautuksella;
    • sovellusten helppo siirto epäonnistuneilta palvelimilta;
    • kokonaisen datakeskuksen automaattinen paremmuusjärjestys (palvelujen tärkeysjärjestyksessä).

Tässä artikkelissa kuvattu onnettomuus oli suurin sitten 404. päivän. Kaikki ei tietenkään mennyt putkeen. Esimerkiksi toisen palvelinkeskuksen palovaurioituneen palvelinkeskuksen ollessa poissa käytöstä toisessa palvelimessa oleva levy epäonnistui, eli vain yksi Cassandra-klusterin kolmesta kopiosta oli käytettävissä, minkä vuoksi 4,2 % mobiililaitteista sovelluksen käyttäjät eivät voineet kirjautua sisään. Samaan aikaan jo yhteydessä olevat käyttäjät jatkoivat työtä. Yhteensä onnettomuuden seurauksena tunnistettiin yli 30 ongelmaa - banaaleista virheistä palveluarkkitehtuurin puutteisiin.

Mutta tärkein ero nykyisen onnettomuuden ja onnettomuuden 404 välillä on se, että kun olimme poistamassa tulipalon seurauksia, käyttäjät lähettivät edelleen tekstiviestejä ja soittivat videopuheluita. tomtom, pelasi pelejä, kuunteli musiikkia, antoi toisilleen lahjoja, katseli videoita, TV-sarjoja ja tv-kanavia ОКja myös suoratoistettu OK Livenä.

Miten onnettomuutesi menevät?

Lähde: will.com

Lisää kommentti