Hoe soene jo fiele as op in moaie simmerdei it datasintrum mei jo apparatuer der sa útseach?
Hoi allegearre! Myn namme is Dmitry Samsonov, ik wurkje as in liedende systeembehearder by "" De foto lit ien fan 'e fjouwer datasintra sjen wêr't de apparatuer dy't ús projekt tsjinnet is ynstalleare. Efter dizze muorren binne d'r sa'n 4 tûzen stikken apparatuer: servers, data-opslachsystemen, netwurkapparatuer, ensfh. - hast ⅓ fan al ús apparatuer.
De measte servers binne Linux. D'r binne ek ferskate tsientallen servers op Windows (MS SQL) - ús erfgoed, dat wy in protte jierren systematysk hawwe ferlitten.
Dat, op 5 juny 2019 om 14:35, rapporteare yngenieurs by ien fan ús datasintra in brânalarm.
Negaasje
14:45. Lytse reekynsidinten yn datasintra binne faker dan jo tinke. De yndikatoaren yn 'e sealen wiene normaal, dus ús earste reaksje wie relatyf kalm: se yntrodusearre in ferbod op wurk mei produksje, dat is, op alle konfiguraasjewizigingen, op it útroljen fan nije ferzjes, ensfh., útsein wurk yn ferbân mei it reparearjen fan wat.
Wrath
Hawwe jo oait besocht by de brânwachtminsken út te finen wêr't de brân op it dak krekt ûntstie, of sels op in baarnend dak te kommen om de situaasje te beoardieljen? Wat sil de graad fan fertrouwen wêze yn ynformaasje ûntfongen troch fiif minsken?
14: 50. Der is ynformaasje binnenkaam dat de brân it koelsysteem nadert. Mar sil it komme? De systeembehearder yn tsjinst ferwideret ekstern ferkear fan 'e fronten fan dit datasintrum.
Op it stuit wurde de fronten fan al ús tsjinsten duplikearre yn trije datasintra, balânsjen wurdt brûkt op it DNS-nivo, wêrtroch wy de adressen fan ien datasintrum út 'e DNS kinne ferwiderje, en dêrmei brûkers beskermje fan potensjele problemen mei tagong ta tsjinsten . As der al problemen binne yn it datasintrum, ferlit it de rotaasje automatysk. Jo kinne hjir mear lêze:
It fjoer hat ús noch gjin ynfloed hân - noch brûkers noch apparatuer binne skansearre. Is dit in ûngelok? De earste seksje fan it dokumint "Accident Action Plan" definiearret it konsept fan "Accident", en de seksje einiget sa:
«As der twifel is oft der in ûngelok is of net, dan is it in ûngelok!»
14:53. Der wurdt in needkoördinator beneamd.
De koördinator is de persoan dy't de kommunikaasje tusken alle dielnimmers kontrolearret, de skaal fan it ûngelok beoardielet, it Emergency Action Plan brûkt, it nedige personiel lûkt, it foltôgjen fan reparaasjes kontrolearret, en it wichtichste, delegearret alle taken. Mei oare wurden, dit is de persoan dy't it hiele proses foar needreaksje beheart.
Bargain
15:01. Wy begjinne servers út te skeakeljen dy't net relatearre binne oan produksje.
15:03. Wy skeakelje alle reservearre tsjinsten korrekt út.
Dit omfettet net allinich fronten (dy't op dit stuit brûkers net mear tagong krije) en har helptsjinsten (bedriuwslogika, caches, ensfh.), Mar ek ferskate databases mei replikaasjefaktor 2 of mear (, , , ensfh.).
15: 06. Der is ynformaasje binnenkaam dat in brân ien fan de datacenterhallen bedriget. Wy hawwe gjin apparatuer yn dizze keamer, mar it feit dat it fjoer kin ferspriede fan it dak nei de sealen feroaret it byld fan wat der bart.
(Letter die bliken dat der gjin fysike bedriging wie foar de seal, om't dy hermetysk ôfsletten wie fan it dak. De bedriging wie allinnich foar it koelsysteem fan dizze seal.)
15:07. Wy tastean it útfieren fan kommando op servers yn versnelde modus sûnder ekstra kontrôles ().
15:08. De temperatuer yn de sealen leit binnen normale grinzen.
15: 12. In ferheging fan de temperatuer yn de sealen waard notearre.
15:13. Mear as de helte fan 'e servers yn it datasintrum is útskeakele. Lit ús trochgean.
15:16. Der is besletten om alle apparatuer út te setten.
15:21. Wy begjinne de macht út te skeakeljen nei steatleaze servers sûnder de applikaasje en it bestjoeringssysteem korrekt út te sluten.
15:23. In groep minsken ferantwurdlik foar MS SQL wurdt tawiisd (d'r binne in pear fan har, de ôfhinklikens fan tsjinsten op har is net grut, mar de proseduere foar it werstellen fan funksjonaliteit duorret langer en is yngewikkelder as bygelyks Cassandra).
Depresje
15: 25. Yn fjouwer sealen fan 16 (nr. 6, 7, 8, 9) waard ynformaasje ûntfongen oer de stroom útskeakele. Us apparatuer stiet yn sealen 7 en 8. Der is gjin ynformaasje oer ús twa sealen (nr. 1 en 3).
Meastentiids wurdt de stroomfoarsjenning fuortendaliks útskeakele yn 'e brân, mar yn dit gefal, troch it koördinearre wurk fan brânwachtminsken en technysk personiel fan it datasintrum, waard it net oeral útskeakele en net fuortendaliks, mar as nedich.
(It waard letter ûntdutsen dat de stroom net útskeakele wie yn sealen 8 en 9.)
15:28. Wy begjinne MS SQL-databases yn te setten fan backups yn oare datasintra.
Hoe lang sil it duorje? Is der genôch netwurkkapasiteit foar de hiele rûte?
15: 37. In shutdown fan guon dielen fan it netwurk waard opnommen.
Management en it produksjenetwurk binne fysyk isolearre fan elkoar. As it produksjenetwurk beskikber is, dan kinne jo nei de tsjinner gean, de applikaasje stopje en it OS útsette. As it net beskikber is, dan kinne jo ynlogge fia IPMI, stopje de applikaasje en útsette it OS. As d'r gjin fan 'e netwurken is, dan kinne jo neat dwaan. "Tankewol, Cap!", sille jo tinke.
"En yn 't algemien is der in soad ûnrêst," kinne jo ek tinke.
It ding is dat servers, sels sûnder fjoer, in enoarme hoemannichte waarmte generearje. Mear krekter, as der koeling is, generearje se waarmte, en as d'r gjin koeling is, meitsje se in helske inferno, dy't, op syn bêst, in diel fan 'e apparatuer sil smelte en in oar diel útsette, en yn' e slimste ... fjoer binnen de hal, dat is hast garandearre te fernielen alles.
15:39. Wy reparearje problemen mei de conf-database.
De conf-database is de efterkant foar de tsjinst mei deselde namme, dy't wurdt brûkt troch alle produksjeapplikaasjes om ynstellings fluch te feroarjen. Sûnder dizze basis kinne wy de wurking fan it portaal net kontrolearje, mar it portaal sels kin wurkje.
15:41. Temperatuersensors op Core-netwurkapparatuer registrearje lêzingen tichtby it maksimum tastien. Dit is in doaze dy't in hiele rek beslacht en soarget foar de wurking fan alle netwurken binnen it datasintrum.
15:42. Issue tracker en wiki binne net beskikber, skeakelje nei standby.
Dit is gjin produksje, mar yn it gefal fan in ûngelok kin de beskikberens fan elke kennisbasis kritysk wêze.
15:50. Ien fan de tafersjochsystemen is útskeakele.
Der binne ferskate fan harren, en se binne ferantwurdlik foar ferskate aspekten fan de tsjinsten. Guon fan harren binne konfigurearre om autonoom te operearjen binnen elk datasintrum (dat is, se kontrolearje allinich har eigen datasintrum), oaren besteane út ferdielde komponinten dy't transparant it ferlies fan elk datasintrum oerlibje.
Yn dit gefal stopte it mei wurkjen , dy't wurket yn master-standby-modus. Oerskeakele nei standby.
Adoption
15:51. Alle tsjinners útsein MS SQL waarden útskeakele fia IPMI sûnder goed ôf te sluten.
Binne jo ree foar massive serverbehear fia IPMI as it nedich is?
It krekte momint dat de rêding fan apparatuer yn it datasintrum yn dit stadium foltôge is. Alles wat dien wurde koe is dien. Guon kollega's kinne rêste.
16: 13. Der is ynformaasje ûntfongen dat freonpipen fan airconditioning op it dak barsten - dit sil de start fan it datasintrum fertrage nei't it fjoer útskeakele is.
16:19. Neffens gegevens ûntfongen fan technysk personiel fan it datasintrum is de ferheging fan temperatuer yn de sealen ophâlden.
17:10. De conf-database is weromset. No kinne wy applikaasje ynstellings feroarje.
Wêrom is dit sa wichtich as alles is fout-tolerant en wurket sels sûnder ien datacenter?
Foarste plak, net alles is fout-tolerant. D'r binne ferskate sekundêre tsjinsten dy't noch net goed genôch hawwe oerlibbe in flater yn it datasintrum, en d'r binne databases yn master-standby-modus. De mooglikheid om ynstellings te behearjen lit jo alles dwaan dat jo nedich binne om de ynfloed fan 'e gefolgen fan in ûngelok op brûkers sels yn drege omstannichheden te minimalisearjen.
Twads waard dúdlik dat de wurking fan it datasintrum yn 'e kommende oeren net folslein restaurearre wurde soe, dus it wie nedich om maatregels te nimmen om te soargjen dat de lange termyn net-beskikberens fan replika's net liede ta ekstra problemen lykas folsleine skiven yn de oerbleaune datasintra.
17:29. Pizza tiid! Wy wurkje minsken, gjin robots.
Rehabilitaasje
18:02. Yn sealen nr. 8 (ús), 9, 10 en 11 is de temperatuer stabilisearre. Ien fan dejinge dy't offline bliuwt (nr. 7) herberget ús apparatuer, en de temperatuer dêr bliuwt omheech.
18:31. Se joegen it startsein om de apparatuer yn sealen 1 en 3 op te starten - dizze sealen waarden net troffen troch de brân.
Op it stuit wurde servers lansearre yn sealen 1, 3, 8, begjinnend mei de meast krityske. De krekte wurking fan alle rinnende tsjinsten wurdt kontrolearre. Der binne noch problemen mei hal nr. 7.
18:44. It technyske personiel fan it datasintrum ûntduts dat yn keamer nr. 7 (dêr't allinnich ús apparatuer leit) in protte tsjinners net útskeakele binne. Neffens ús gegevens bliuwe dêr 26 servers online. Nei in twadde kontrôle fine wy 58 tsjinners.
20:18. Technici fan datacenters blaze lucht troch in keamer sûnder airconditioning troch mobile kanalen dy't troch de gongen rinne.
23:08. De earste admin waard nei hûs stjoerd. Immen moat nachts sliepe om moarn fierder te wurkjen. Folgjende sille wy wat mear admins en ûntwikkelders frijlitte.
02:56. Wy lansearre alles dat koe wurde lansearre. Wy dogge in protte kontrôle fan alle tsjinsten mei automatyske tests.
03:02. Airconditioning yn de lêste, 7e hal is restaurearre.
03:36. Wy brochten de fronten yn it datasintrum yn rotaasje yn DNS. Fan dit momint begjint brûkersferkear te kommen.
Wy stjoere it grutste part fan it bestjoerlik team nei hûs. Mar wy litte in pear minsken efter.
Lytse FAQ:
F: Wat barde fan 18:31 oant 02:56?
A: Nei it "Disaster Action Plan" lansearje wy alle tsjinsten, te begjinnen mei de wichtichste. Yn dit gefal jout de koördinator yn it petear de tsjinst út oan in fergese behearder, dy't kontrolearret oft it OS en de applikaasje binne begon, oft der flaters binne en oft de yndikatoaren normaal binne. Nei't de lansearring foltôge is, meldt hy oan it petear dat hy frij is en krijt in nije tsjinst fan 'e koördinator.
It proses wurdt fierder fertrage troch mislearre hardware. Sels as it stopjen fan it OS en it ôfsluten fan de servers goed gie, komme guon servers net werom fanwege hommelse mislearring fan skiven, ûnthâld en chassis. Wannear't macht wurdt ferlern, de flater rate nimt ta.
F: Wêrom kinne jo net gewoan alles tagelyk útfiere, en dan reparearje wat opkomt yn tafersjoch?
A: Alles moat stadichoan dien wurde, om't d'r ôfhinklikens binne tusken tsjinsten. En alles moat fuortdaliks kontrolearre wurde, sûnder te wachtsjen op tafersjoch - om't it better is om problemen direkt te behanneljen, sûnder te wachtsjen oant se minder wurde.
7:40. De lêste admin (koördinator) gie op bêd. It wurk fan de earste dei is klear.
8:09. De earste ûntwikkelders, datacenter-yngenieurs en behearders (ynklusyf de nije koördinator) begûnen restauraasjewurk.
09:37. Wy begûnen seal nr. 7 (de lêste) op te heffen.
Tagelyk geane wy troch mei it herstellen fan wat net fêst wie yn oare keamers: skiven/ûnthâld/servers ferfange, alles reparearje dat "baarnt" yn tafersjoch, rollen werom wikselje yn master-standby-skema's en oare lytse dingen, wêrfan d'r binne dochs aardich in soad.
17:08. Wy tastean alle reguliere wurk mei produksje.
21:45. It wurk fan de twadde dei is klear.
09:45. Hjoed is it freed. Der binne noch hiel wat lytse problemen by it tafersjoch. It wykein leit der foar, elkenien wol relax. Wy bliuwe massaal reparearje alles wat wy kinne. Reguliere admintaken dy't útsteld koenen, waarden útsteld. De koördinator is nij.
15:40. Ynienen is de helte fan 'e stapel fan Core-netwurkapparatuer yn ANAN datasintrum opnij starte. Fronten waarden út rotaasje helle om risiko's te minimalisearjen. D'r is gjin effekt foar brûkers. Letter die bliken dat it om in defekt chassis gie. De koördinator is dwaande mei it reparearjen fan twa ûngelokken tagelyk.
17:17. Netwurkoperaasje yn in oar datasintrum is hersteld, alles is kontrolearre. It datasintrum wurdt yn rotaasje set.
18:29. It wurk fan de tredde dei en yn it algemien de restauraasje nei it ûngelok is foltôge.
Nei wurd
04.04.2013 , "Klasgenoaten" - foar trije dagen wie it portaal folslein of foar in part net beskikber. Troch dizze hiele tiid hawwe mear as 100 minsken út ferskate stêden, fan ferskate bedriuwen (noch in protte tank!), Op ôfstân en direkt yn datasintra, manuell en automatysk, tûzenen servers reparearre.
Wy hawwe konklúzjes lutsen. Om foar te kommen dat dit wer bart, hawwe wy oant hjoed de dei wiidweidich wurk útfierd en fiere wy noch.
Wat binne de wichtichste ferskillen tusken it hjoeddeistige ûngelok en 404?
- Wy hawwe in "Accident Action Plan". Ien kear yn 't kertier fiere wy oefeningen - wy spylje in needsituaasje, dy't in groep bestjoerders (allegear op har beurt) moat eliminearje mei it "Emergency Action Plan". Leadende systeembehearders spylje om beurten de rol fan koördinator.
- Kwartaalliks, yn testmodus, isolearje wy datasintra (allegear op 'e beurt) fia LAN- en WAN-netwurken, wêrtroch't wy knelpunten prompt kinne identifisearje.
- Minder stikkene skiven, om't wy de noarmen oanskerpe hawwe: minder wurkoeren, strangere drompels foar SMART,
- Wy hawwe BerkeleyDB folslein ferlitten, in âlde en ynstabile databank dy't in protte tiid nedich hat om te herstellen nei in werstart fan 'e tsjinner.
- Wy fermindere it oantal tsjinners mei MS SQL en fermindere ôfhinklikens fan 'e oerbleaune.
- Wy hawwe ús eigen , wêr't wy no twa jier alle tsjinsten aktyf migrearje. De wolk ferienfâldiget de heule syklus fan wurkjen mei de applikaasje gâns, en yn it gefal fan in ûngelok leveret it sokke unike ark as:
- juste stop fan alle applikaasjes yn ien klik;
- maklike migraasje fan applikaasjes fan mislearre servers;
- automatyske ranglist (yn folchoarder fan prioriteit fan tsjinsten) lansearring fan in hiele datasintrum.
It ûngelok beskreaun yn dit artikel wie it grutste sûnt de 404e dei. Fansels gie net alles soepel. Bygelyks, tidens de net-beskikberens fan in troch brân skansearre datasintrum yn in oar datasintrum, mislearre in skiif op ien fan 'e tsjinners, dat is, mar ien fan' e trije replika's yn 'e Cassandra-kluster bleau tagonklik, dat is wêrom 4,2% fan mobyl applikaasje brûkers koenen net oanmelde. Tagelyk bleaunen al ferbûne brûkers wurkjen. Yn totaal waarden as gefolch fan it ûngelok mear as 30 problemen identifisearre - fan banale bugs oant tekoarten yn 'e tsjinstarsjitektuer.
Mar it wichtichste ferskil tusken it hjoeddeistige ûngelok en de 404e is dat wylst wy de gefolgen fan 'e brân elimineare, brûkers noch sms'en en fideoproppen makken nei , spile spultsjes, harken nei muzyk, joegen elkoar kado's, seagen fideo's, tv-searjes en tv-kanalen yn , en streamde ek yn .
Hoe geane jo ûngelokken?
Boarne: www.habr.com