Kas serverid tuleks "kustutada", kui andmekeskuse smook testi käigus "tuli" ilmnes?

Kuidas te tunneksite, kui ühel kaunil suvepäeval teie seadmete andmekeskus näeks välja just selline?

Tere kõigile! Minu nimi on Dmitri Samsonov, olen peamine süsteemiadministraator ettevõttes “Odnoklassniki”. Fotol on üks neljast andmekeskusest, kus asub meie projekti teenindamiseks vajalik varustus. Nende seinte taga on umbes 4000 seadmeühikut: serverid, andmesalvestussüsteem, võrguvarustus jne — peaaegu ⅓ meie kogu varustusest.
Enamus serveritest töötab Linuxil. On ka mitu tosinat Windowsi serverit (MS SQL) — meie pärand, millest me oleme aastate jooksul järk-järgult loobunud.
Nii, 5. juunil 2019 kell 14:35 teatas ühe meie andmekeskuse insener tulehäirest.

Eitamine

14:45. Andmekeskustes esinevad väiksemad suitsuõnnetused juhtuvad sagedamini, kui tundub. Siseõhus olevad näitajad olid normaalsed, seetõttu oli meie esialgne reaktsioon suhteliselt rahulik: keelasime kõik muutustööd, sealhulgas konfigureerimise muutused, uute versioonide juurutamise jne, välja arvatud need, mis on seotud millegi parandamisega.

Viha

Kas olete kunagi üritanud tuletõrjujatelt küsida, kus täpselt katusel tuli puhkes, või püüdsite ise sinna köetud katusesse pääseda, et olukorda hinnata? Kui palju usaldusväärsust on teabel, mis on saadud viiest inimesest?

14:50. Saime teavet, et tuli liigub jahutus­süsteemi poole.. Aga kas see jõuab sinna? Delegeeritud süsteemiadministraator suunab välise liikluse välja selle andmekeskuse frontidest.

Praegu on kõik meie teenuste esindused kolmes andmekeskuses dubleeritud, DNS-tasandil toimub koormuse tasakaalustamine, mis võimaldab eemaldada ühe andmekeskuse aadressid DNS-ist, kaitstes seega kasutajaid potentsiaalsete probleemide eest teenuste juurdepääsuga. Juhul, kui andmekeskuses on probleemid juba tekkinud, kõrvaldatakse see automaatselt rotatsioonist. Täiendavalt saab lugeda siit: Koormuse tasakaalustamine ja tõrketaluvus «Odnoklassnikutes».

Kuni nüüd pole tulekahju meid kuidagi mõjutanud — ei kasutajad ega seade ei ole kahjustatud. Kas see on avarii? Esimene osa dokumendist „Avariiplaneerimise plaan” annab definitsiooni mõistele „Avarii”, ja lõpeb peatükk nii:
«Kui on kahtlusi, kas see on avarii või mitte, siis see on avarii!»

14:53. Määratakse õnnetuste koordinaator.

Koordinaator on inimene, kes kontrollib kõigi osaliste vahelist suhtlust, hindab õnnetuse ulatust, rakendab „Õnnetusplaani“, kaasab vajalikud töötajad, kontrollib remondi lõpetamist ja kõige tähtsam — delegeerib kõik ülesanded. Teisisõnu on see inimene, kes juhib kogu õnnetuse likvideerimise protsessi.

Kaup

15:01. Alustame serverite väljalülitamist, mis ei ole produktsiooniga seotud.
15:03. Lülitame õigesti välja kõik reserveeritud teenused.
Siia kuuluvad mitte ainult esipinnad (kuhu kasutajad sel hetkel enam ei pääse) ja nende abiteenused (äri-logika, vahemädid jne), vaid ka erinevad andmebaasid koos replikaatide faktoriga 2 ja enam (Cassandra, binaarandmete salvestus, külmsalvestus, NewSQL ja muud).
15:06. Tulnud on teave, et tuleoht ähvardab ühte andmekeskuse saali. Selles saalis meil varustust ei ole, kuid asjaolu, et tuli võib katuselt üle kanduda saalidesse, muudab sündmuste pilti oluliselt.
(Hiljem selgus, et saali füüsilist ohtu ei olnud, kuna see oli tihedalt isoleeritud katuse eest. Oht oli ainult selle saali jahutusüsteemile.)
15:07. Lubame serverites anda käske kiirusrežiimis ilma lisakontrollideta (ilma meie lemmik kalkulaatorita).
15:08. Temperatuur saalides on normi piires.
15:12. Saalide temperatuur on tõusnud.
15:13. Üks rohkem kui pooled serveritest andmekeskuses on välja lülitatud. Jätkame.
15:16. Otsustatakse välja lülitada kogu varustus.
15:21. Alustame toite väljalülitamist stateless-serverites ilma rakenduse ja operatsioonisüsteemi õige väljalülitamiseta.
15:23. Määratakse vastutav grupp MS SQL-i jaoks (neid on vähe, teenuste sõltuvus neist ei ole suur, kuid töövõimetuks muutmise protseduur võtab kauem aega ja on keerulisem kui näiteks Cassandra puhul).

Depressioon

15:25. Tulnud on teave, et toide lülitati välja neljas saalis 16-st (nr 6, 7, 8, 9). 7. ja 8. saalis on meie varustus. Kahest meie saalist (nr 1 ja 3) pole veel teavet.
Tavaliselt lülitatakse tulekahjude korral elektritoide kohe välja, kuid antud juhul, tänu hästi koordineeritud tööle päästetöötajate ja andmekeskuse tehnilise personali vahel, ei lülitatud seda igal pool ja kohe välja, vaid vajaduse järgi.
(Hiljem selgus, et toide saalides 8 ja 9 ei olnud katkestatud.)
15:28. Alustame MS SQL andmebaaside taastamist varukoopiatest teistes andmekeskustes.
Kui palju aega sellele kulub? Kas võrgu läbilaskevõime on kogu marsruudil piisav?
15:37. Mõned võrguosad on fikseeritud katkestada.
Juhtimine ja tootmisvõrk on füüsiliselt üksteisest eraldatud. Kui tootmisvõrk on kergesti kätte saadav, saate siseneda serverisse, peatada rakenduse ja välja lülitada operatsioonisüsteemi. Kui see ei ole kergesti kätte saadav, siis on võimalik siseneda IPMI kaudu, peatada rakenduse ja välja lülitada operatsioonisüsteemi. Kui ühtegi võrku pole, ei saa te midagi teha. 'Aitäh, kapten!,' võite te mõelda.
'Ja tõepoolest, on kuidagi palju sagimist,' võite samuti mõelda.
Probleem on selles, et serverid genereerivad isegi ilma tulekahjuta tohutult soojust. Täpsemalt öeldes, kui jahutus on olemas, genereerivad nad soojust, ja kui seda pole, siis tekitavad nad põrgulikku kuumust, mis parimas olukorras sulatab osa seadmetest ja lülitab välja teise osa, aga halvemal juhul… põhjustab tulekahju saalis, mis praktiliselt garanteerib kogu hävitamise.

15:39. Fikseerime probleeme conf andmebaasiga.

Conf andmebaas on backend vastava teenuse jaoks, mida kasutavad kõik tootmisrakendused seadete kiireks muutmiseks. Ilma selle andmebaasita ei saa me portaali tööd juhtida, kuid ise portaali töö võib jätkuda.

15:41. Temperatuurisensorid Core võrgu seadmetes näitavad lähedasi lubatavaid näitajaid. See on kappid, mis võtavad terve rack'i ja tagavad kõikide võrkude töö andmekeskuses.

15:42. Probleemide jälgimine ja wiki ei ole kergesti kätte saadavad, lülitame standby'le.
See ei ole tootmine, kuid õnnetuse korral võib igasugune teadmistebaasi kättesaadavus olla kriitilise tähtsusega.
15:50. Üks jälgimisse süsteemidest on välja lülitatud.
Nende on mitu ja nad vastutavad teenuste erinevate aspektide eest. Osa neist on seadistatud töötama iseseisvalt igas andmekeskuses (st nad jälgivad ainult oma andmekeskust), teised koosnevad jaotatud komponentidest, mis läbivad sujuvalt iga andmekeskuse kadumise.
Selles olukorras lakkas töötamast äri loogika anomaaliate tuvastamise süsteem, mis töötab master-standby režiimis. Lülitusime standby'le.

Võtmine

15:51. IPMI kaudu lülitasime välja kõik serverid, välja arvatud MS SQL, ilma korraliku sulgemiseta.
Kas olete valmis massiliseks serverihalduseks IPMI kaudu, kui vajadus tekib?

See on see hetk, kui seadmete päästmise protsess andmekeskuses on sel etapil lõpule viidud. Kõik, mis võimalik, on tehtud. Mõned kolleegid saavad puhata.
16:13. On tulnud teavet, et katusele on purunenud külmutustorud konditsioneeridest — see lükkab andmekeskuse avamise tulekahju likvideerimise järel edasi.
16:19. Andmete kohaselt, mis on saadud andmekeskuse tehniliselt personalilt, on saalides temperatuuri tõus peatunud.
17:10. Taastasime conf. andmebaasi töö. Nüüd saame muuta rakenduste seadeid.
Miks see nii oluline on, kui kõik on rikkepreventiivne ja töötab isegi ilma ühe andmekeskuseta?
Esiteks, mitte kõik ei ole rikkepreventiivne. On erinevaid teisejärgulisi teenuseid, mis ei talu andmekeskuse rikke piisavalt hästi, ja on andmebaasid režiimis master-standby. Võimalus seadistusi juhtida võimaldab teha kõik vajaliku, et isegi keerulistes tingimustes minimeerida avarii tagajärgede mõju kasutajatele.
Teiseks, on selge, et järgmise paari tunni jooksul andmekeskuse töö täielikult ei taastu, seetõttu tuli võtta meetmeid, et pikaajaline replikate puudumine ei tooks kaasa täiendavaid ebameeldivusi, nagu näiteks diskide ülevool jäänud andmekeskustes.
17:29. Pitsa aeg! Meie juures töötavad inimesed, mitte robotid.

Rehabiliteerimine

18:02. Saalides nr 8 (meie), 9, 10 ja 11 stabiliseerus temperatuur. Ühes neist, mis jäävad välja lülitatuks (nr 7), asub meie seadmed, ja seal temperatuur jätkab tõusmist.
18:31. Antud luba seadmete käivitamiseks saalides nr 1 ja 3 — need saalid ei ole tulekahju puudutanud.

Praegu käivitame servereid saalides nr 1, 3, 8, alustades kõige kriitilisematest. Kontrollime käivitatud teenuste korrektset toimimist. Saalis nr 7 on endiselt probleeme.

18:44. Andmekeskuse tehniline personal avastas, et saalis nr 7 (kus asub ainult meie seadmed) ei ole paljusid servereid välja lülitatud. Meie andmete kohaselt on seal 26 serverit sisse lülitatud. Pärast korduvkontrolli selgub, et neid on 58.
20:18. Andmekeskuse tehniline personal puhub õhku saalis, kus ei ole konditsioneere, mobiilsete õhukanalite kaudu, mis on paigaldatud läbi koridoride.
23:08. Esimene admin saadeti koju. Keegi peab öösel magama, et homme tööd jätkata. Edasi saadame veel osa adminne ja arendajaid.
02:56. Käivitasime kõik, mis oli võimalik käivitada. Teeme põhjaliku kontrolli kõigist teenustest automaatsete testidega.

03:02. Kliimaseade viimases, seitsmendas saalis on taastatud.
03:36. Suuname andmekeskuse serverite frontid DNS-i rullimisele. Sellest hetkest hakkab saabuma kasutajate liiklus.
Saadame suure osa adminnide meeskonnast koju. Kuid mõned inimesed jäävad.

Väike FAQ:
K: Mis juhtus ajavahemikus 18:31 kuni 02:56?
V: Järgides „Hädaolukorra tegevuskava”, käivitame kõik teenused, alustades kõige olulisematest. Sellega samal ajal annab koordinaator vestluses teenuse vabale adminile, kes kontrollib, kas operatsioonisüsteem ja rakendus käivitusid ning kas vigu pole ning kas näidud on normis. Pärast käivitamise lõpetamist teatab ta vestluses, et on vaba, ja saab koordinaatorilt uue teenuse.
Protsessi aeglustavad täiendavad rikke tõttu probleemid. Isegi kui opsüsteemi peatamine ja serverite väljalülitamine toimusid õigesti, ei taastu osa serveritest äkiliste rikete tõttu ketastes, mälus või šassiis. Elektri kadumise korral suureneb rikkeprotsent.
K: Miks ei saa lihtsalt kõike korraga käivitada ja pärast parandada seda, mis monitorimisest välja tuleb?
V: Kõike tuleb teha järk-järgult, kuna teenuste vahel on sõltuvused. Ja kõike tuleks kontrollida kohe, mitte oodata monitorimist — sest probleemide lahendamiseks on parem minna otse, mitte oodata, et need süvenevad.

7:40. Viimane admin (koordinaator) läks magama. Esimese päeva tööd on lõpetatud.
8:09. Esimesed arendajad, insenerid andmekeskustes ja adminnid (sealhulgas uus koordinaator) alustasid taastamistöid.
09:37. Alustame saali nr 7 (viimane) ülesse tõstmist.
Samas jätkame taastamisega, mida pole lõpetatud teistes saalides: ketaste/mälu/serverite vahetamine, kõik, mis „põleb” monitorimises, rollide tagasireklaamifunktsioonide vahetamine ja teised pisiasjad, mida siiski on piisavalt palju.
17:08. Lubame kõik tavalised tööd produktsiooniga.
21:45. Teise päeva tööd on lõpetatud.
09:45. Täna on reede. Jälgimisel on endiselt palju pisiprobleeme. Ees on nädalavahetus, kõik tahavad puhata. Jätkame aktiivset kõigi parandamist, mis võimalik. Administraatorite tavapärased ülesanded, mida sai edasi lükata, on edasi lükatud. Uus koordinaator.
15:40. Ühtäkki taastus pool kogu võrguseadmestiku Core teises andmekeskuses. Edastasime riski vähendamiseks frontid. Kasutajatele ei olnud negatiivset mõju. Hiljem selgus, et tegemist oli riketega šassiiga. Koordinaator tegeleb kahe eriolukorra korrigeerimisega.
17:17. Teise andmekeskuse võrgu töö on taastatud, kõik on kontrollitud. Andmekeskus on taaskäivitamisel.
18:29. Kolmanda päeva tööd ja hädaolukorra taastamine on lõppenud.

Eessõna

04.04.2013, 444. vea päeval,«Odnoklassniki», koges suurimat avariid. — kolme päeva jooksul oli portaal täielikult või osaliselt kättesaamatu. Kogu selle aja jooksul parandasid rohkem kui 100 inimest erinevatest linnadest, erinevatest ettevõtetest (veel kord suur aitäh!), kaugtöötades ja mitte ainult andmekeskustes, manuaalselt ja automaatiliselt, tuhandeid servereid.
Oleme teinud järeldused. Selleks, et sellist asja ei juhtuks, oleme läbi viinud ja jätkame seniajani ulatuslikke töid.

Mis on praeguse avarii peamised erinevused 404st?

• Meil on ilmnenud «Hädaolukorra tegevuskava». Kord kvartalis korraldame harjutusi — simuleerime hädaolukorda, mille grupi administraatorid (kõik kordamööda) peavad likvideerima, kasutades «Hädaolukorra tegevuskava». Peamised süsteemiadministraatorid harjutavad koordinaatori rolli kordamööda.
• Iga kvartali järel isolatsiooni testrežiimis andmekeskused (kõik kordamööda) LAN ja WAN võrgus, mis aitab õigel ajal tuvastada kitsaskohti.
• Vähem rikutud kettaid, sest oleme karmistanud norme: vähem töötunde, rangemad läviväärtused S.M.A.R.T. jaoks.
• Oleme täielikult loobunud BerkeleyDB-st — vanast ja ebastabiilsest andmebaasist, mille taastamine serveri taaskäivitamise järel võttis palju aega.
• Oleme vähendanud MS SQL serverite arvu ja vähendanud sõltuvust ülejäänutest.
• Meil on oma pilv — one-cloud,kuhu oleme juba kahe aasta jooksul aktiivselt migranud kõik teenused. Pilv lihtsustab kogu rakenduse töötsüklit ja hädaolukorra korral annab unikaalsed tööriistad, nagu:
  • korrektne rakenduste peatamine ühe klõpsuga;
  • lihtne rakenduste migratsioon ebaõnnestunud serveritelt;
  • automaatne järjestikune (prioriteedi järgi) kogu andmekeskuse käivitamine.

Antud artiklis kirjeldatud avarii oli suurim alates 404. aastast. Loomulikult ei läinud kõik sujuvalt. Näiteks said ebaõnnestunud andmekeskuse ajal teises andmekeskuses ühel serveril ketas rikki, mistõttu jäi kätte ainult üks kolmest replikast Cassandra klastris, mille tõttu 4,2% mobiilirakenduste kasutajatest ei saanud sisse logida. Sellegipoolest saavad juba ühendatud kasutajad endiselt töötada. Kokku tuvastati avarii tulemusena üle 30 probleemi – alates lihtsatest vigadest kuni teenuste arhitektuuri puudusteni.

Ent kõige olulisem erinevus praeguse avarii ja 404. aasta vahel on see, et seni, kuni me kustutasime tulekahju tagajärgi, suutsid kasutajad endiselt kirjutada ja teha videokõnesid Tamtam, mängisid mänge, kuulasid muusikat, kinkisid üksteisele kingitusi, vaatasid videosid, sarju ja telekanaleid OK, samuti voogesitasid OK Live.

Aga kuidas teie avariid kulgevad?

Allikas: habr.com