Cum te-ai simți dacă într-o zi frumoasă de vară centrul de date cu echipamentul tău ar arăta așa?
Salutare tuturor! Numele meu este Dmitry Samsonov, lucrez ca administrator de sistem principal la "" Fotografia arată unul dintre cele patru centre de date unde este instalat echipamentul care deservește proiectul nostru. În spatele acestor pereți se află aproximativ 4 mii de echipamente: servere, sisteme de stocare a datelor, echipamente de rețea etc. - aproape ⅓ din toate echipamentele noastre.
Majoritatea serverelor sunt Linux. Există, de asemenea, câteva zeci de servere pe Windows (MS SQL) - moștenirea noastră, pe care le abandonăm sistematic de mulți ani.
Deci, pe 5 iunie 2019, la ora 14:35, inginerii de la unul dintre centrele noastre de date au raportat o alarmă de incendiu.
Negare
14:45. Incidentele minore de fum în centrele de date sunt mai frecvente decât credeți. Indicatoarele din interiorul halelor erau normale, așa că prima noastră reacție a fost relativ calmă: au introdus interdicția de a lucra cu producția, adică de orice modificare a configurației, de lansare de noi versiuni etc., cu excepția lucrărilor legate de repararea a ceva.
mânie
Ați încercat vreodată să aflați de la pompieri exact unde s-a produs incendiul pe acoperiș sau să ajungeți singur pe un acoperiș care arde pentru a evalua situația? Care va fi gradul de încredere în informațiile primite prin intermediul a cinci persoane?
14: 50. S-au primit informații că incendiul se apropie de sistemul de răcire. Dar va veni? Administratorul de sistem de serviciu elimină traficul extern de pe fronturile acestui centru de date.
În prezent, fronturile tuturor serviciilor noastre sunt duplicate în trei centre de date, echilibrarea este utilizată la nivel de DNS, ceea ce ne permite să eliminăm adresele unui centru de date din DNS, protejând astfel utilizatorii de potențiale probleme de acces la servicii. . Dacă au apărut deja probleme în centrul de date, acesta părăsește automat rotația. Puteți citi mai multe aici:
Incendiul nu ne-a afectat încă în niciun fel - nici utilizatorii, nici echipamentele nu au fost avariate. Acesta este un accident? Prima secțiune a documentului „Plan de acțiune în caz de accident” definește conceptul de „Accident”, iar secțiunea se termină astfel:
«Dacă există vreo îndoială dacă există sau nu un accident, atunci este un accident!»
14:53. Este numit un coordonator de urgență.
Coordonatorul este persoana care controlează comunicarea între toți participanții, evaluează amploarea accidentului, utilizează Planul de acțiuni de urgență, atrage personalul necesar, monitorizează finalizarea reparațiilor și, cel mai important, deleagă orice sarcini. Cu alte cuvinte, aceasta este persoana care gestionează întregul proces de răspuns în caz de urgență.
Afacere
15:01. Începem să dezactivăm serverele care nu au legătură cu producția.
15:03. Oprim corect toate serviciile rezervate.
Aceasta include nu numai fronturi (pe care până acum utilizatorii nu le mai accesează) și serviciile lor auxiliare (logica de afaceri, cache-uri etc.), ci și diverse baze de date cu factor de replicare 2 sau mai mare (, , , etc.).
15: 06. S-au primit informații că un incendiu amenință una dintre sălile centrelor de date. Nu avem echipament în această cameră, dar faptul că focul se poate extinde de la acoperiș la holuri schimbă foarte mult imaginea a ceea ce se întâmplă.
(S-a dovedit mai târziu că nu a existat nicio amenințare fizică la adresa halei, deoarece era închisă ermetic de pe acoperiș. Amenințarea era doar pentru sistemul de răcire al acestei hale.)
15:07. Permitem executarea comenzilor pe servere în modul accelerat fără verificări suplimentare ().
15:08. Temperatura în holuri este în limite normale.
15: 12. S-a înregistrat o creștere a temperaturii în holuri.
15:13. Mai mult de jumătate dintre serverele din centrul de date sunt oprite. Hai sa continuăm.
15:16. S-a luat decizia de a opri toate echipamentele.
15:21. Începem să oprim alimentarea serverelor fără stat fără a închide corect aplicația și sistemul de operare.
15:23. Este alocat un grup de persoane responsabile de MS SQL (sunt puțini, dependența serviciilor de ele nu este mare, dar procedura de restabilire a funcționalității durează mai mult și este mai complicată decât, de exemplu, Cassandra).
depresiune
15: 25. S-au primit informații despre întreruperea curentului în patru săli din 16 (nr. 6, 7, 8, 9). Echipamentele noastre se află în halele 7 și 8. Nu există informații despre cele două săli ale noastre (nr. 1 și 3).
De obicei, în timpul incendiilor, alimentarea cu energie este oprită imediat, dar în acest caz, datorită muncii coordonate a pompierilor și a personalului tehnic al centrului de date, aceasta nu a fost oprită peste tot și nu imediat, ci la nevoie.
(S-a descoperit ulterior că curentul nu a fost oprit în halele 8 și 9.)
15:28. Începem să implementăm baze de date MS SQL din backup-uri din alte centre de date.
Cât timp va dura? Există suficientă capacitate de rețea pentru întregul traseu?
15: 37. A fost înregistrată o oprire a unor părți ale rețelei.
Managementul și rețeaua de producție sunt izolate fizic una de cealaltă. Dacă rețeaua de producție este disponibilă, atunci puteți accesa serverul, opriți aplicația și opriți sistemul de operare. Dacă nu este disponibil, atunci vă puteți conecta prin IPMI, opriți aplicația și opriți sistemul de operare. Dacă nu există niciuna dintre rețele, atunci nu poți face nimic. „Mulțumesc, Cap!”, vei crede.
„Și, în general, există o mulțime de frământări”, ați putea să vă gândiți.
Chestia este că serverele, chiar și fără incendiu, generează o cantitate uriașă de căldură. Mai exact, atunci când este răcire, generează căldură, iar când nu există răcire, creează un infern infernal, care, în cel mai bun caz, va topi o parte din echipament și va opri o altă parte și, în cel mai rău caz... foc în interiorul sălii, care este aproape garantat că va distruge totul.
15:39. Remediem problemele cu baza de date conf.
Baza de date conf este backend-ul pentru serviciul cu același nume, care este folosit de toate aplicațiile de producție pentru a schimba rapid setările. Fără această bază, nu putem controla funcționarea portalului, dar portalul în sine poate funcționa.
15:41. Senzorii de temperatură de pe echipamentul rețelei de bază înregistrează citiri aproape de maximul permis. Aceasta este o cutie care ocupă un întreg rack și asigură funcționarea tuturor rețelelor din interiorul centrului de date.
15:42. Instrumentul de urmărire a problemelor și wiki nu sunt disponibile, comutați în standby.
Aceasta nu este producție, dar în cazul unui accident, disponibilitatea oricărei baze de cunoștințe poate fi critică.
15:50. Unul dintre sistemele de monitorizare s-a oprit.
Există mai multe dintre ele și sunt responsabile pentru diferite aspecte ale serviciilor. Unele dintre ele sunt configurate să funcționeze autonom în cadrul fiecărui centru de date (adică își monitorizează doar propriul centru de date), altele constau în componente distribuite care supraviețuiesc în mod transparent pierderii oricărui centru de date.
In acest caz nu mai functioneaza , care funcționează în modul master-standby. A trecut în standby.
Adoptare
15:51. Toate serverele, cu excepția MS SQL, au fost oprite prin IPMI fără a se închide corect.
Sunteți pregătit pentru gestionarea masivă a serverelor prin IPMI, dacă este necesar?
Chiar momentul în care salvarea echipamentelor din centrul de date este finalizată în această etapă. S-a făcut tot ce se putea face. Unii colegi se pot odihni.
16: 13. S-au primit informații că țevile de freon de la aparatele de aer condiționat au izbucnit pe acoperiș - acest lucru va întârzia lansarea centrului de date după ce incendiul va fi eliminat.
16:19. Potrivit datelor primite de la personalul tehnic al centrului de date, creșterea temperaturii în hale a încetat.
17:10. Baza de date conf a fost restaurată. Acum putem schimba setările aplicației.
De ce este atât de important dacă totul este tolerant la erori și funcționează chiar și fără un singur centru de date?
În primul rând, nu totul este tolerant la greșeli. Există diverse servicii secundare care nu au supraviețuit încă suficient de bine unei eșecuri a centrului de date și există baze de date în modul master-standby. Capacitatea de a gestiona setările vă permite să faceți tot ce este necesar pentru a minimiza impactul consecințelor unui accident asupra utilizatorilor chiar și în condiții dificile.
În al doilea rând, a devenit clar că funcționarea centrului de date nu va fi complet restabilită în următoarele ore, așa că a fost necesar să se ia măsuri pentru a se asigura că indisponibilitatea pe termen lung a replicilor nu duce la probleme suplimentare, cum ar fi discuri pline în centrele de date rămase.
17:29. Ora pizza! Angajăm oameni, nu roboți.
reabilitare
18:02. În halele nr. 8 (a noastră), 9, 10 și 11 temperatura s-a stabilizat. Una dintre cele care rămâne offline (nr. 7) adăpostește echipamentele noastre, iar temperatura de acolo continuă să crească.
18:31. Aceștia au dat voie pentru punerea în funcțiune a utilajelor din halele nr. 1 și 3 - aceste hale nu au fost afectate de incendiu.
În prezent, serverele sunt lansate în halele nr. 1, 3, 8, începând cu cele mai critice. Este verificată funcționarea corectă a tuturor serviciilor care rulează. Mai sunt probleme cu sala nr.7.
18:44. Personalul tehnic al centrului de date a descoperit că în camera nr. 7 (unde se află doar echipamentele noastre) multe servere nu sunt oprite. Conform datelor noastre, acolo rămân online 26 de servere. După o a doua verificare, găsim 58 de servere.
20:18. Tehnicienii centrelor de date suflă aer printr-o cameră fără aer condiționat prin conducte mobile care trec prin holuri.
23:08. Primul administrator a fost trimis acasă. Cineva trebuie să doarmă noaptea pentru a continua munca mâine. În continuare, vom elibera mai mulți administratori și dezvoltatori.
02:56. Am lansat tot ce putea fi lansat. Facem multe verificări ale tuturor serviciilor folosind teste automate.
03:02. Aerul conditionat in ultima sala a 7-a a fost restaurata.
03:36. Am adus fronturile din centrul de date în rotație în DNS. Din acest moment începe să sosească traficul de utilizatori.
O trimitem acasă pe cea mai mare parte a echipei administrative. Dar lăsăm câțiva oameni în urmă.
Întrebări frecvente mici:
Î: Ce s-a întâmplat de la 18:31 la 02:56?
R: În urma „Planului de acțiune pentru dezastre”, lansăm toate serviciile, începând cu cele mai importante. În acest caz, coordonatorul din chat emite serviciul unui administrator gratuit, care verifică dacă sistemul de operare și aplicația au pornit, dacă există erori și indicatorii sunt normali. După ce lansarea este finalizată, el raportează la chat că este liber și primește un nou serviciu de la coordonator.
Procesul este încetinit și mai mult de hardware-ul eșuat. Chiar dacă oprirea sistemului de operare și închiderea serverelor au mers corect, unele servere nu revin din cauza defecțiunii bruște a discurilor, a memoriei și a șasiului. Când se pierde puterea, rata de defecțiuni crește.
Î: De ce nu puteți rula totul deodată și apoi remediați ceea ce apare în monitorizare?
R: Totul trebuie făcut treptat, pentru că există dependențe între servicii. Și totul ar trebui verificat imediat, fără a aștepta monitorizarea - pentru că este mai bine să faceți probleme imediat, fără să așteptați ca acestea să se agraveze.
7:40. Ultimul administrator (coordonator) s-a culcat. Lucrările din prima zi au fost finalizate.
8:09. Primii dezvoltatori, inginerii centrelor de date și administratorii (inclusiv noul coordonator) au început lucrările de restaurare.
09:37. Am început să ridicăm sala nr. 7 (ultima).
În același timp, continuăm să restaurăm ceea ce nu a fost remediat în alte camere: înlocuirea discurilor/memoriei/serverelor, reparăm tot ce „arde” în monitorizare, schimbarea rolurilor înapoi în schemele master-standby și alte lucruri mici, dintre care există totuși destul de mult.
17:08. Permitem toate lucrările regulate cu producția.
21:45. Lucrarea zilei a doua este încheiată.
09:45. Astăzi este vineri. Există încă câteva mici probleme în monitorizare. Weekend-ul vine, toată lumea vrea să se relaxeze. Continuăm să reparăm masiv tot ce putem. Sarcinile obișnuite de administrare care ar fi putut fi amânate au fost amânate. Coordonatorul este nou.
15:40. Dintr-o dată, jumătate din stiva de echipamente de rețea Core din ALLT centru de date a repornit. Fronturile au fost scoase din rotație pentru a minimiza riscurile. Nu există niciun efect pentru utilizatori. Ulterior s-a dovedit că era un șasiu defect. Coordonatorul lucrează la repararea a două accidente deodată.
17:17. Funcționarea rețelei într-un alt centru de date a fost restabilită, totul a fost verificat. Centrul de date este pus în rotație.
18:29. Lucrările din a treia zi și, în general, restaurarea după accident au fost finalizate.
postfață
04.04.2013 , "Colegi de clasa" — timp de trei zile portalul a fost complet sau parțial indisponibil. În tot acest timp, peste 100 de oameni din diferite orașe, din diferite companii (multe mulțumiri încă o dată!), de la distanță și direct în centre de date, manual și automat, au reparat mii de servere.
Am tras concluzii. Pentru a preveni ca acest lucru să se întâmple din nou, am desfășurat și continuăm să desfășurăm o muncă amplă până în prezent.
Care sunt principalele diferențe dintre accidentul actual și 404?
- Avem un „Plan de acțiune pentru accidente”. O dată pe trimestru, efectuăm exerciții - jucăm o situație de urgență, pe care un grup de administratori (toți la rândul lor) trebuie să o elimine folosind „Planul de acțiune de urgență”. Administratorii de sistem de top joacă pe rând rolul de coordonator.
- Trimestrial, în modul de testare, izolăm centrele de date (toate la rândul lor) prin rețele LAN și WAN, ceea ce ne permite să identificăm cu promptitudine blocajele.
- Mai puține discuri sparte, pentru că am înăsprit standardele: mai puține ore de funcționare, praguri mai stricte pentru SMART,
- Am abandonat complet BerkeleyDB, o bază de date veche și instabilă care a necesitat mult timp pentru a se recupera după repornirea unui server.
- Am redus numărul de servere cu MS SQL și am redus dependența de cele rămase.
- Noi le avem pe ale noastre , unde migrăm în mod activ toate serviciile de doi ani. Cloud-ul simplifică foarte mult întregul ciclu de lucru cu aplicația și, în cazul unui accident, oferă instrumente unice precum:
- oprirea corectă a tuturor aplicațiilor cu un singur clic;
- migrarea ușoară a aplicațiilor de pe servere eșuate;
- lansarea automată clasată (în ordinea priorității serviciilor) a unui întreg centru de date.
Accidentul descris în acest articol a fost cel mai mare din a 404-a zi. Desigur, nu totul a mers bine. De exemplu, în timpul indisponibilității unui centru de date deteriorat de incendiu dintr-un alt centru de date, un disc de pe unul dintre servere a eșuat, adică doar una dintre cele trei replici din clusterul Cassandra a rămas accesibilă, motiv pentru care 4,2% din mobil utilizatorii aplicației nu s-au putut autentifica. În același timp, utilizatorii deja conectați au continuat să lucreze. În total, în urma accidentului, au fost identificate peste 30 de probleme - de la bug-uri banale până la deficiențe în arhitectura serviciului.
Dar cea mai importantă diferență dintre accidentul actual și cel de-al 404-lea este că, în timp ce eliminăm consecințele incendiului, utilizatorii încă trimiteau mesaje și făceau apeluri video către , s-au jucat, s-au ascultat muzică, s-au făcut cadouri, au vizionat videoclipuri, seriale și canale TV în , și, de asemenea, transmis în flux .
Cum merg accidentele tale?
Sursa: www.habr.com