ĂfarĂ« do tĂ« ndiheshit nĂ«se nĂ« njĂ« ditĂ« tĂ« bukur vere data-qendra me pajisjet tuaja do tĂ« dukej kĂ«shtu?
PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! UnĂ« quhem Dmitri Samsonov, dhe punoj si administrator kryesor i sistemeve nĂ« ââ. NĂ« fotografi Ă«shtĂ« njĂ« nga katĂ«r data-qendrat ku janĂ« vendosur pajisjet qĂ« mbĂ«shtesin projektin tonĂ«. Pas kĂ«tyre mureve ndodhen rreth 4,000 njĂ«si pajisjeje: serverĂ«, sistem depĂ«rtimi tĂ« tĂ« dhĂ«nave, pajisje rrjeti etj. - pothuajse â
e gjithë pajisjeve tona.
Shumica e serverëve janë me Linux. Ka gjithashtu disa dhjetëra serverë me Windows (MS SQL) - trashëgimia jonë, nga e cila po heqim dorë gradualisht për vite me radhë.
Kështu, më 5 Qershor 2019, në 14:35 inxhinierët e një prej data-qendrave tona raportuan një alarm zjarri.
Mohim
14:45. Incidentet e vogla të tymit në data-qendra ndodhin më shpesh se sa duket. Të dhënat brenda sallave ishin në normalitet, kështu që reagimi ynë i parë ishte relativisht i qetë: vendosëm një ndalim për punime në prodhim, domethënë për çdo ndryshim konfiguracioni, për nxjerrjen e versioneve të reja etj., përveç punëve që lidhen me rregullimin e ndonjë gjëje.
Ngashërim
A keni provuar ndonjëherë të pyesni zjarrfikësit se në cilin vend konkret në çati ndodhi zjarri, ose të shkoni vetë në çatin e zjarrit për të vlerësuar situatën? Sa do të ishte shkalla e besimit në informacionin e marrë përmes pesë personave?
14:50. Përfituam informacion se zjarri po shumëzohej me sistemin e ftohjes. Por, a do të arrijë? Administrator i sistemit në turn po heq trafikun e jashtëm nga frontet e kësaj data-qendre.
Në këtë moment, frontet e të gjithë shërbimeve tona janë të kopjuara në tri data-qendra, përdoret balancimi në nivel DNS, i cili lejon që të hiqen adresat e një data-qendre nga DNS, duke mbrojtur kështu përdoruesit nga probleme të mundshme me qasjen në shërbime. Në rast se ndodhin probleme në data-qendër, ajo del automatikisht nga rotacioni. Për më shumë informacion, mund të lexoni këtu:
Zjarri deri tani nuk na ka ndikuar - as përdoruesit, as pajisjet nuk janë dëmtuar. A është kjo një aksident? Seksioni i parë i dokumentit "Plani i veprimit në rast aksidentesh" jep përcaktimin e konceptit "Aksident", dhe seksioni përfundon kështu:
«Nëse ka dyshime, a është aksident apo jo, atëherë është aksident!»
14:53. Emërohet koordinatori i aksidentit.
Koordinatori është personi që kontrollon komunikimin midis të gjithë pjesëmarrësve, vlerëson shkallën e aksidentit, përdor "Planin e veprimit në rast aksidentesh", angazhon personelin e nevojshëm, kontrollon përfundimin e riparimeve, më e rëndësishmja - delegon çdo detyrë. Me fjalë të tjera, ky është personi që menaxhon të gjithë procesin e eliminimit të aksidentit.
Tregti
15:01. Fillojmë të fikim serverët që nuk janë të lidhur me prodhimin.
15:03. Korrektisht fikim të gjitha shërbimet rezervë.
Këtu përfshihen jo vetëm frontet (në të cilat në këtë moment përdoruesit nuk po hyjnë më) dhe shërbimet ndihmëse të tyre (logjika e biznesit, cache-et etj.), por edhe bazat e ndryshme të të dhënave me faktor replikimi 2 dhe më shumë (, , , etj.).
15:06. U njoftua se zjarri po kërcënon një nga sallat e data-qendrës. Në këtë sallë nuk kemi pajisje, por fakti që zjarri mund të kalojë nga çatia në sallat, ndryshon ndjeshëm situatën e ngjarjeve.
(Më vonë doli se nuk kishte kërcënim fizik për sallën sepse ajo ishte hermetikisht e izoluara nga çatia. Kërcënimi ishte vetëm për sistemin e ftohjes së kësaj salle.)
15:07. Lejojmë ekzekutimin e komandave në serverë në një ritëm të përshpejtuar pa kontrollime të mëtejshme ().
15:08. Temperatura në sallat është brenda normës.
15:12. Një rritje e temperaturës është fikur në sallat.
15:13. Më shumë se gjysma e serverëve në data-qendër janë fikur. Po vazhdojmë.
15:16. ĂshtĂ« marrĂ« vendim pĂ«r fikjen e gjithĂ« pajisjeve.
15:21. Fillojmë të fikim energjinë në serverët pa shtesë të saktë të aplikacionit dhe sistemit operativ.
15:23. Caktohet një grup përgjegjës për MS SQL (janë të pakët, varësia e shërbimeve nga ta nuk është e madhe, por procedura e rikthimit në funksionalitet merr më shumë kohë dhe është më e komplikuar se, për shembull, për Cassandra).
Depresion
15:25. U njoftua se energjia është fikur në katër sallat nga 16 (Nr. 6, 7, 8, 9). Në sallat 7 dhe 8 ndodhet pajisja jonë. Nuk kemi informacion për dy sallat tona (Nr. 1 dhe 3).
Zakonisht gjatë zjarreve energjia elektrik fiket menjëherë, por në këtë rast, falë punës të koordinuar të zjarrfikësve dhe personelit teknik të data-qendrës, ajo nuk u fik në të gjitha sallat menjëherë, por sipas nevojës.
(Më vonë doli se energjia në sallat 8 dhe 9 nuk u fik.)
15:28. Fillojmë bazat MS SQL nga kopjet rezervë në qendrat e tjera të të dhënave.
Sa kohë do të kërkohet për këtë? A do të mjaftojë kapaciteti i rrjetit gjatë tërë rrugës?
15:37. ĂshtĂ« regjistruar ndĂ«rprerja e disa segmenteve tĂ« rrjetit.
Menaxhimi dhe rrjeti i prodhimit janë fizikisht të ndara nga njëra-tjetra. Nëse rrjeti i prodhimit është i aksesueshëm, mund të hyni në server, të ndaloni aplikacionin dhe të fikni OS-në. Nëse nuk është i aksesueshëm, mund të hyni përmes IPMI, të ndaloni aplikacionin dhe të fikni OS-në. Nëse asnjë nga rrjetet nuk është e aksesueshme, nuk mund të bëni asgjë. "Faleminderit, kapiten!" do mendoni.
"Dhe gjithashtu, duket se ka shumë zhurmë", mund të mendoni gjithashtu.
E gjithë çështja është se edhe pa zjarr, serverët gjenerojnë një sasi të madhe marrëzit këtu. Më saktë, kur ka ftohje, ata gjenerojnë nxehtësi, dhe kur nuk ka, ata krijojnë një skënderb për të cilin, në rastin më të mirë, do të shkrijnë një pjesë të pajisjeve dhe do të fiknin një pjesë tjetër, e në rastin më të keq⊠do të shkaktojnë një zjarr brenda sallës, që garanton shkatërrimin e gjithçkaje.
15:39. Regjistrimi i problemeve me bazën conf.
Baza conf është backend për shërbimin e të njëjtit emër, i cili përdoret nga aplikacionet e prodhimit për të ndryshuar me shpejtësi konfigurimet. Pa këtë bazë nuk mund të menaxhojmë funksionimin e portalit, por portali mund të funksionojë gjithsesi.
15:41. Sensorët e temperaturës në pajisjet e rrjetit Core regjistrojnë lexime afër kufijve të lejuar. Kjo është një kut që zë një raft dhe siguron funksionimin e të gjitha rrjeteve brenda qendres së të dhënave.
15:42. Issue tracker dhe wiki të paarritshme, kalojmë në standby.
Kjo nuk është prodhim, por në rast emergjence, disponueshmëria e çdo baze njohurie mund të jetë kritike.
15:50. Një nga sistemet e monitorimit u fik.
Ka disa prej tyre, dhe ata përgjigjen për aspekte të ndryshme të funksionimit të shërbimeve. Disa prej tyre janë të konfigurara për të punuar autonomisht brenda çdo qendre të të dhënave (dmth., ato monitorojnë vetëm qendrën e tyre të të dhënave), të tjerat përbëhen nga komponentë të shpërndarë, të cilët e përballojnë humbjen e çdo qendre të të dhënave.
Në këtë rast, ka ndaluar funksionimi i , e cila funksionon në mënyrë master-standby. Kalojmë në standby.
Pranimi
15:51. Nëpërmjet IPMI, fikëm të gjithë serverët pa mbyllje të saktë, përveç MS SQL.
Jeni të gatshëm për menaxhimin masiv të serverëve përmes IPMI në rast nevoje?
Ky është momenti kur shpëtimi i pajisjeve në qendrën e të dhënave në këtë fazë është përfunduar. Gjithçka që mund të bëhej, është bërë. Disa kolegë mund të pushojnë.
16:13. Kemi marrĂ« informacion se tubat e freonit nĂ« çati plasaritĂ«n nga klimatikĂ«t â kjo do tĂ« vonojĂ« nisjen e qendrĂ«s sĂ« tĂ« dhĂ«nave pas eliminimit tĂ« zjarrit.
16:19. Sipas të dhënave të marra nga stafi teknik i qendrës së të dhënave, ka ndaluar rritja e temperaturës në sallat.
17:10. Rindërtuam funksionimin e bazës conf. Tani mund të ndryshojmë konfigurimet e aplikacioneve.
Pse është kaq e rëndësishme, nëse gjithçka është e qëndrueshme dhe funksionon edhe pa një qendër të dhënash?
Së pari, jo gjithçka është e qëndrueshme. Ka shërbime të ndryshme dytësore, të cilat për momentin nuk e përballojnë mjaftueshëm mungesën e një qendre të të dhënave, dhe ka baza në modalitetin master-standby. Mundësia për të menaxhuar konfigurimet lejon të bëhen të gjitha të nevojshmet për të minimizuar ndikimin e pasojave të emergjencës mbi përdoruesit, edhe në kushtet më të vështira.
Së dyti, bëhet e qartë se brenda disa orësh, funksionimi i qendrës së të dhënave nuk do të rifillojë plotësisht, prandaj ishte e nevojshme të merreshin masa për të parandaluar që mungesa e gjatë e replika të sillte ndërlikime të tjera si mbingarkesa e disqeve në qendrat e tjera të të dhënave.
17:29. Koha për picë! Ne kemi njerëz që punojnë, jo robotë.
Rehabilitimi
18:02. NĂ« sallat ââ8 (tona), 9, 10 dhe 11 temperatura u stabilizua. NĂ« njĂ«rĂ«n nga ato qĂ« mbeten tĂ« fikura (â7), ndodhet pajisja jonĂ« dhe temperatura aty vazhdon tĂ« rritet.
18:31. U dha miratimi pĂ«r fillimin e pajisjeve nĂ« sallat ââ1 dhe 3 â kĂ«to salla nuk u prekĂ«n nga zjarri.
PĂ«r momentin po fillohet nisja e serverĂ«ve nĂ« sallat ââ1, 3, 8, duke filluar nga ato mĂ« kritike. Po kontrollohet saktĂ«sia e funksionimit tĂ« tĂ« gjithĂ« shĂ«rbimeve tĂ« hapura. Ka ende probleme me sallĂ«n â7.
18:44. Stafi teknik i qendrĂ«s sĂ« tĂ« dhĂ«nave zbuloi se nĂ« sallĂ«n â7 (ku ndodhet vetĂ«m pajisja jonĂ«) shumĂ« servera nuk janĂ« fikur. Sipas tĂ« dhĂ«nave tona, aty mbeten tĂ« fikura 26 serverĂ«. Pas njĂ« kontrolli tĂ« dytĂ« gjejmĂ« 58 servera.
20:18. Stafi teknik i qendrës së të dhënave po ajros ajrin në sallën pa klimatikë përmes kanaleve mobile të ajrosjes, të cilat janë vendosur përmes korridoreve.
23:08. Ekipi ka lëshuar administratën e parë për në shtëpi. Disa prej nesh duhet të flenë natën për të vazhduar punën nesër. Për më tepër, lëshojmë edhe disa administratë dhe zhvillues.
02:56. Aktivizuam gjithçka që mund të aktivizohej. Po bëjmë një kontroll të gjerë të të gjitha shërbimeve me teste automatike.
03:02. Klimatizimi në sallën e fundit, sallën 7, është rikuperuar.
03:36. Aktivizuam frontet në qendrën e të dhënave në rotacionin e DNS. Nga ky moment, ka filluar të vijë trafiku i përdoruesve.
Po lëshojmë shumicën e ekipit të administratorëve për në shtëpi. Por disa njerëz mbeten.
Një pyetje e vogël:
P: ĂfarĂ« ndodhi nga ora 18:31 deri nĂ« 02:56?
P: Sipas "Planit të Veprimit në Rast të Fatkeqësive", ne aktivizojmë të gjitha shërbimet, duke filluar nga ato më të rëndësishmet. Në këtë kohë, koordinatori në chat jep shërbimin një administratori të lirë, i cili kontrollon nëse OS dhe aplikacioni janë aktivizuar, nëse ka ndonjë gabim, dhe nëse treguesit janë në normalitet. Pas përfundimit të aktivizimit, ai njofton në chat se është i lirë dhe merr nga koordinatori një shërbim të ri.
Procesi ngadalësohet gjithashtu nga hardueri i prishur. Edhe nëse ndalimi i OS dhe fikja e serverëve janë realizuar siç duhet, disa serverë nuk rikuperohen për shkak të disqeve, memories, ose shasisë që papritur kanë dështuar. Në rastin e humbjes së furnizimit me energji, përqindja e dështimeve rritet.
P: Pse nuk mund ta aktivizoni gjithçka njëherësh dhe pastaj të riparoni atë që del në monitorim?
P: NdĂ«rsa kĂ«rkesa Ă«shtĂ«: Gjithçka duhet bĂ«rĂ« gradualisht, sepse ka varĂ«si mes shĂ«rbimeve. PĂ«r mĂ« tepĂ«r, gjithçka duhet kontrolluar menjĂ«herĂ«, pa pritur monitorimin â sepse Ă«shtĂ« mĂ« mirĂ« tĂ« merren me problemet menjĂ«herĂ«, sesa tĂ« pritet pĂ«r tâu agravuar.
7:40. Administratori i fundit (koordinatori) ka shkuar për të fjetur. Punët e ditës së parë janë përfunduar.
8:09. Zhvilluesit e parë, inxhinierët në qendrat e të dhënave dhe administratorët (përfshirë koordinatori të ri) kanë filluar punën e rikuperimit.
09:37. Filluam të hapim sallën numër 7 (të fundit).
NĂ« tĂ« njĂ«jtĂ«n kohĂ«, vazhdojmĂ« tĂ« rikuperojmĂ« atĂ« qĂ« nuk e pĂ«rfunduam nĂ« sallat e tjera: zĂ«vendĂ«simi i disqeve/memories/serverĂ«ve, riparimi i gjithçkaje qĂ« âdigjetâ nĂ« monitorim, rikthimi i roleve nĂ« skemat master-standby dhe gjĂ«ra tĂ« tjera, tĂ« cilat megjithatĂ« janĂ« mjaft tĂ« shumta.
17:08. Lejojmë të gjitha punët standarde me prodhimin.
21:45. Punët e ditës së dytë janë përfunduar.
09:45. Sot është e premte. Në monitorim ende ka shumë probleme të vogla. Fundjavën po vjen, të gjithëve u pëlqen të pushojnë. Po vazhdojmë të riparojmë masivisht gjithçka që mundet. Detyrat standarde të administratorëve që mund të ishin shtyrë, janë shtyrë. Koordinatori është i ri.
15:40. Papritur, gjysma e stack-ut tĂ« pajisjeve rrjetike ka rikonfiguruar nĂ« qendrĂ«n e tĂ« dhĂ«nave TJETĂR. E hoqĂ«m nga rotacioni frontet pĂ«r tĂ« minimizuar rreziqet. Efekti pĂ«r pĂ«rdoruesit nuk ka qenĂ« prezent. MĂ« vonĂ« doli se kjo ishte njĂ« shasi e prishur. Koordinatori punon me riparimin e dy fatkeqĂ«sive njĂ«kohĂ«sisht.
17:17. Rrjeti nĂ« qendrĂ«n e tĂ« dhĂ«nave TJETĂR Ă«shtĂ« rikuperuar, gjithçka Ă«shtĂ« kontrolluar. Qendra e tĂ« dhĂ«nave Ă«shtĂ« kthyer nĂ« rotacion.
18:29. Punët e ditës së tretë dhe në përgjithësi rikuperimi pas fatkeqësisë janë përfunduar.
Pasthënie
04.04.2013, "Odnoklassniki" â gjatĂ« tre ditĂ«ve portali ishte plotĂ«sisht ose pjesĂ«risht i paaksesueshĂ«m. GjatĂ« gjithĂ« kĂ«tij kohĂ«, mĂ« shumĂ« se 100 njerĂ«z nga qytete tĂ« ndryshme, nga kompani tĂ« ndryshme (faleminderit edhe njĂ«herĂ« shumĂ«!), kanĂ« riparuar mijĂ«ra serverĂ« nĂ« distancĂ« dhe drejtpĂ«rdrejt nĂ« qendrat e tĂ« dhĂ«nave, manualisht dhe automatikisht.
Ne kemi nxjerrë përfundime. Për të mos lejuar që kjo të përsëritet, ne kemi zhvilluar dhe vazhdojmë të kryejmë punë të shumta.
Cilat janë dallimet kryesore të fatkeqësisë aktuale nga ajo 404?
- Ne kemi krijuar njĂ« "Plan Veprimi pĂ«r FatkeqĂ«sitĂ«". Ădo tremujor, organizojmĂ« stĂ«rvitje â simulojmĂ« njĂ« situatĂ« fatkeqĂ«sie qĂ« grupi i administratorĂ«ve (tĂ« gjithĂ« nĂ« radhĂ«) duhet ta zgjidhin, duke pĂ«rdorur "Planin e Veprimit nĂ« Rast tĂ« FatkeqĂ«sive". Administratoret kryesorĂ« tĂ« sistemeve praktikojnĂ« rolin e koordinatori nĂ« mĂ«nyrĂ« tĂ« alternuar.
- Ădo tremujor, izolojmĂ« qendrat e tĂ« dhĂ«nave (tĂ« gjitha nĂ« radhĂ«) nĂ« rrjetin LAN dhe WAN, duke na lejuar tĂ« zbulojmĂ« nĂ« kohĂ« vendet e ngushta.
- Më pak disqe të prishura, sepse ne kemi rritur normat: më pak orë pune, vlerat pragore për S.M.A.R.T. janë më të rrepta.
- Kemi hequr dorĂ« plotĂ«sisht nga BerkeleyDB â njĂ« bazĂ« tĂ« dhĂ«nash tĂ« vjetĂ«r dhe tĂ« paqĂ«ndrueshme, qĂ« kĂ«rkonte shumĂ« kohĂ« pĂ«r t'u rikuperuar pas rikonfigurimit tĂ« serverit.
- Kemi reduktuar numrin e serverëve me MS SQL dhe kemi ulur varësinë nga ata që kanë mbetur.
- Tani kemi një ku gjatë dy viteve të fundit po migrojmë aktivisht të gjitha shërbimet. Cloud-i e thjeshton ndjeshëm gjithë ciklin e punës me aplikacionin dhe në rast fatkeqësie ofron mjete unike të tillë si:
- ndalimi korrekt i të gjitha aplikacioneve me një klikim;
- migrojnë aplikacionet nga serverët e prishur;
- në mënyrë automatike të renditur (sipas prioritetit të shërbimeve) nisja e një qendër të të dhënave të tëra.
Aksidenti i përshkruar në këtë artikull ishte më i madhi që nga 404-a. Sigurisht, nuk shkoi gjithçka pa problem. Për shembull, gjatë papërshkueshmërisë së qendrës së të dhënave që kishte marrë flakë, një disk në një nga serverët në një tjetër qendër të të dhënave ra, duke lënë vetëm një nga tre replikat në klasterin Cassandra të aksesueshme, si pasojë e të cilës 4,2% e përdoruesve të aplikacioneve mobile nuk mund të logoheshin. Në të njëjtën kohë, përdoruesit që ishin tashmë të lidhur vazhduan të punonin. Në total, nga aksidenti u zbuluan më shumë se 30 probleme - nga bug-ët e zakonshëm deri te dobësitë në arkitekturën e shërbimeve.
Por dallimi më i madh i aksidentit aktual nga 404-a është se ndërsa po eliminojmë pasojat e zjarrit, përdoruesit vazhdonin të shkruanin mesazhe dhe të bënin videov calling në , luanin lojra, dëgjonin muzikë, ndanin dhurata, shikonin video, seriale dhe kanale televizive në , si dhe transmetonin në .
Si ndodhin aksidentet tuaja?
Burimi: habr.com
