{"id":84108,"date":"2020-06-05T07:42:44","date_gmt":"2020-06-05T05:42:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra"},"modified":"2020-06-05T07:42:44","modified_gmt":"2020-06-05T05:42:44","slug":"tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"Skal man \"slukke\" serverne, hvis der opst\u00e5r en \"brand\" ved smoke testen i datacenteret?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvad ville du f\u00f8le, hvis datacenteret med dit udstyr pludselig s\u00e5 s\u00e5dan her ud en dejlig sommerdag?<\/p>\n

\"Skal
\n
\nHej alle sammen! Mit navn er Dmitrij Samsonov, jeg arbejder som chef systemadministrator hos \u201cOdnoklassniki<\/a><\/noindex>\u201d. P\u00e5 billedet ses et af de fire datacentre, hvor udstyret til vores projekt er installeret. Bag disse v\u00e6gge findes der omkring 4000 enheder: servere, datalagringssystemer, netv\u00e6rksudstyr osv. \u2014 n\u00e6sten \u2153 af alt vores udstyr.
\nDe fleste servere k\u00f8rer p\u00e5 Linux. Der er ogs\u00e5 et par dusin servere p\u00e5 Windows (MS SQL) \u2014 vores arv, som vi har arbejdet p\u00e5 at udfase i mange \u00e5r.
\nDen 5. juni 2019 kl. 14:35 meldte ingeni\u00f8rerne fra et af vores datacentre om brandalarm.
\n<\/a><\/noindex><\/p>\n

Ben\u00e6gtelse<\/h4>\n

\n14:45. Sm\u00e5 h\u00e6ndelser med r\u00f8g i datacentrerne sker oftere, end man skulle tro. M\u00e5lene inde i hallen var normale, s\u00e5 vores f\u00f8rste reaktion var relativt rolig: vi indf\u00f8rte et forbud mod arbejde med produktionen, dvs. mod enhver \u00e6ndring af konfigurationer, udrulning af nye versioner osv., undtagen for arbejdet med at reparere noget.<\/p>\n

Vrede<\/h4>\n

\nHar du nogensinde fors\u00f8gt at finde ud af fra brandfolk, pr\u00e6cis hvor p\u00e5 taget branden var, eller selv komme op p\u00e5 det br\u00e6ndende tag for at vurdere situationen? Hvor meget tillid kan man have til informationen, der er kommet gennem fem personer?<\/p>\n

14:50. Der kom oplysninger om, at ilden n\u00e6rmer sig k\u00f8lesystemet<\/b>. Men n\u00e5r det kommer til stykket? Den vagthavende systemadministrator skifter det eksterne trafik fra fronten af dette datacenter.<\/p>\n

I \u00f8jeblikket er fronten for alle vores tjenester distribueret p\u00e5 tre datacentre, der anvendes DNS-balancering, hvilket g\u00f8r det muligt at fjerne adresserne fra et datacenter i DNS og dermed beskytte brugerne mod potentielle problemer med adgang til tjenesterne. I tilf\u00e6lde af at der allerede er opst\u00e5et problemer i datacentret, fjernes det automatisk fra rotationen. Du kan l\u00e6se mere her: Belastningsbalancering og fejltolerance i \u201cOdnoklassniki\u201d.<\/a><\/noindex><\/p><\/blockquote>\n

\nBranden har endnu ikke haft nogen indflydelse p\u00e5 os \u2014 hverken brugerne eller udstyret har lidt skade. Er det en n\u00f8dsituation? Den f\u00f8rste sektion i dokumentet \u201cN\u00f8dh\u00e5ndteringsplan\u201d definerer begrebet \u201cN\u00f8dsituation\u201d, og sektionen slutter med:
\n\u00abHvis der er tvivl om, hvorvidt det er en n\u00f8dsituation eller ej, s\u00e5 er det en n\u00f8dsituation!<\/u>\u00bb<\/b><\/p>\n

14:53. Udn\u00e6vnes katastrofekoordinator.<\/p>\n

Koordinatoren er den person, der kontrollerer kommunikationen mellem alle deltagere, vurderer omfanget af katastrofen, anvender 'Handlingsplanen for n\u00f8dsituationer', tilkalder n\u00f8dvendig personale, overv\u00e5ger afslutningen af reparationer, og, vigtigst af alt, delegerer enhver opgave. Med andre ord er det personen, der styrer hele processen for at afhj\u00e6lpe katastrofen.<\/p><\/blockquote>\n

<\/p>\n

Forhandling<\/h4>\n

\n15:01. Vi begynder at slukke serverne, som ikke er knyttet til produktion.
\n15:03. Vi slukker alle reserverede tjenester korrekt.
\nDette inkluderer ikke kun front-end (som brugerne p\u00e5 dette tidspunkt ikke l\u00e6ngere tilg\u00e5r) og deres st\u00f8ttefunktioner (forretningslogik, caches osv.), men ogs\u00e5 forskellige databaser med en replikationsfaktor p\u00e5 2 eller mere (Cassandra<\/a><\/noindex>, opbevaring af bin\u00e6re data<\/a><\/noindex>, kold opbevaring<\/a><\/noindex>, NewSQL<\/a><\/noindex> og andre).
\n15:06. Der er kommet oplysninger om, at en brand truer et af datacenterets rum.<\/b> I dette rum har vi ikke noget udstyr, men at ilden kan sprede sig fra taget til rummene \u00e6ndrer drastisk situationen.
\n(Senere viste det sig, at der ikke var nogen fysisk trussel mod rummet, da det var hermetisk isoleret fra taget. Truslen var kun for k\u00f8lesystemet i dette rum.)
\n15:07. Vi tillader hurtig udf\u00f8relse af opgaver p\u00e5 serverne uden yderligere tjek (uden vores k\u00e6re lommeregner<\/a><\/noindex>).
\n15:08. Temperaturen i rummene er inden for normen.
\n15:12. Der er registreret en temperaturstigning i rummene.<\/b>
\n15:13. Mere end halvdelen af serverne i datacentret er slukket. Vi forts\u00e6tter.
\n15:16. Der er truffet beslutning om at slukke alt udstyr.
\n15:21. Vi begynder at slukke for str\u00f8mmen p\u00e5 stateless-servere uden korrekt at lukke applikationen og operativsystemet.
\n15:23. Der udpeges en gruppe ansvarlige for MS SQL (de er f\u00e5, afh\u00e6ngigheden af tjenesterne fra dem er ikke stor, men genopretning tager l\u00e6ngere tid og er mere kompleks end f.eks. for Cassandra).<\/p>\n

Depression<\/h4>\n

\n15:25. Der er kommet oplysninger om afbrydelse af str\u00f8mmen i fire rum ud af 16 (nr. 6, 7, 8, 9).<\/b> I rum 7 og 8 er vores udstyr. Vi har stadig ikke information om to af vores rum (nr. 1 og 3).
\nNormalt slukker man str\u00f8mmen straks ved brande, men i dette tilf\u00e6lde, takket v\u00e6re det koordinerede arbejde mellem brandm\u00e6nd og teknisk personale i datacentret, blev det ikke slukket overalt og ikke straks, men efter behov.
\n(Senere viste det sig, at str\u00f8mmen i sale 8 og 9 ikke var blevet afbrudt.)
\n15:28. Vi begynder at gendanne MS SQL-databaser fra backups i andre datacentre.
\nHvor lang tid vil det tage? Er der tilstr\u00e6kkelig b\u00e5ndbredde til netv\u00e6rket hele vejen?
\n15:37. Der er registreret et afbrudt netv\u00e6rk p\u00e5 nogle str\u00e6kninger.<\/b>
\nLedelsen og produktionsnetv\u00e6rket er fysisk adskilt fra hinanden. Hvis produktionsnetv\u00e6rket er tilg\u00e6ngeligt, kan du f\u00e5 adgang til serveren, stoppe applikationen og lukke OS. Hvis det ikke er tilg\u00e6ngeligt, kan du f\u00e5 adgang via IPMI, stoppe applikationen og lukke OS. Hvis ingen af netv\u00e6rkene er tilg\u00e6ngelige, kan du ikke g\u00f8re noget. \"Tak, kaptajn!\", vil du m\u00e5ske t\u00e6nke.
\n\"Og generelt, hvorfor er det s\u00e5 hektisk?\", vil du m\u00e5ske ogs\u00e5 t\u00e6nke.
\nDet hele skyldes, at serverne, selv uden brand, genererer en enorm m\u00e6ngde varme. Mere pr\u00e6cist, n\u00e5r der er k\u00f8ling, genererer de varme, men n\u00e5r der ikke er, skaber de et helvede, der i bedste fald smelter dele af udstyret og slukker andre dele, og i v\u00e6rste fald... for\u00e5rsager en brand inde i salen, som praktisk talt garanterer at \u00f8del\u00e6gge alt.<\/p>\n

\"Skal
\n
\n15:39. Vi registrerer problemer med conf-databasen.<\/p>\n

Conf-databasen er backend for den samme tjeneste, som bruges af alle produktionsapplikationer til hurtigt at \u00e6ndre indstillinger. Uden denne database kan vi ikke styre portalen, men selve portalen kan stadig fungere.<\/p><\/blockquote>\n

\n15:41. Temperaturf\u00f8lere p\u00e5 Core netv\u00e6rksudstyr registrerer m\u00e5linger, der ligger t\u00e6t p\u00e5 de maksimalt tilladte v\u00e6rdier. Det er en boks, der fylder en hel rack og sikrer driften af alle netv\u00e6rk inde i datacentret.<\/p>\n

\"Skal
\n
\n15:42. Issue tracker og wiki er utilg\u00e6ngelige, vi skifter til standby.
\nDette er ikke produktion, men ved en n\u00f8dsituation kan tilg\u00e6ngeligheden af enhver knowledge base v\u00e6re kritisk.
\n15:50. Et af overv\u00e5gningssystemerne er faldet ud.
\nDer er flere af dem, og de d\u00e6kker forskellige aspekter af serviceydelser. Nogle af dem er indstillet til autonom drift inden for hvert datacenter (de monitorerer kun deres eget datacenter), mens andre best\u00e5r af distribuerede komponenter, der problemfrit h\u00e5ndterer tabet af ethvert datacenter.
\nI dette tilf\u00e6lde er systemet til opdagelse af anomalier i forretningslogik<\/a><\/noindex>, som arbejder i master-standby-tilstand, stoppet. Vi har skiftet til standby.<\/p>\n

Accept<\/h4>\n

\n15:51. Via IPMI har vi slukket alle servere uden korrekt nedlukning, undtagen MS SQL.
\nEr I klar til massestyring af servere via IPMI, hvis det bliver n\u00f8dvendigt?<\/p>\n

Det \u00f8jeblik, hvor redningen af udstyret i datacenteret p\u00e5 dette stadium er afsluttet. Alt, hvad der kunne g\u00f8res, er gjort. Nogle kolleger kan tage en pause.<\/i>
\n16:13. Der er kommet information om, at der er sprunget k\u00f8lestoffer\u00f8r fra klimaanl\u00e6gget p\u00e5 taget - dette vil forsinke \u00e5bningen af datacenteret efter branden.<\/b>
\n16:19. If\u00f8lge de oplysninger, der er modtaget fra datacenterets tekniske personale, er temperaturstigningen i rummene stoppet.
\n17:10. Driften af conf-databasen er blevet genoprettet. Vi kan nu \u00e6ndre appindstillinger.
\nHvorfor er det s\u00e5 vigtigt, hvis alt er redundant og fungerer selv uden et datacenter?
\nFor det f\u00f8rste er ikke alt redundant. Der er forskellige sekund\u00e6re tjenester, som endnu ikke klarer nedbruddet af datacentret godt nok, og der er databaser i master-standby tilstand. Muligheden for at styre indstillingerne giver mulighed for at g\u00f8re alt n\u00f8dvendigt for at minimere konsekvenserne af ulykken for brugerne, selv under vanskelige forhold.
\nFor det andet er det blevet klart, at datacenterets drift ikke vil blive fuldst\u00e6ndig genoprettet i de kommende timer, s\u00e5 der var behov for at tr\u00e6ffe foranstaltninger for at undg\u00e5, at langvarig utilg\u00e6ngelighed af replikerne f\u00f8rte til yderligere problemer som overfyldte diske i de resterende dataceter.
\n17:29. Tid til pizza! Vi har folk, der arbejder, ikke robotter.<\/p>\n

\"Skal
\n<\/p>\n

Rehabilitering<\/h4>\n

\n18:02. Temperaturen er stabiliseret i rum 8 (vores), 9, 10 og 11. I et af de rum, der er blevet sl\u00e5et fra (nr. 7), st\u00e5r vores udstyr, og temperaturen forts\u00e6tter med at stige.
\n18:31. Godkendelse til at starte udstyret i rum 1 og 3 er givet - disse rum blev ikke p\u00e5virket af branden.<\/p>\n

Vi er i \u00f8jeblikket ved at starte serverne i rum 1, 3 og 8, startende med de mest kritiske. Der kontrolleres for korrekt drift af alle k\u00f8rende tjenester. Der er stadig problemer med rum 7.<\/i><\/p>\n

18:44. Datacenterets tekniske personale har opdaget, at mange servere i rum 7 (hvor kun vores udstyr st\u00e5r) ikke er slukket. If\u00f8lge vores oplysninger er 26 servere stadig t\u00e6ndte. Efter en ny kontrol opdager vi 58 servere.
\n20:18. Datacenterets tekniske personale bl\u00e6ser luft i rummet uden klimaanl\u00e6g via mobile luftkanaler, der er lagt gennem gangene.
\n23:08. Den f\u00f8rste administrator blev sendt hjem. Nogen skal sove i nat, s\u00e5 vi kan forts\u00e6tte arbejdet i morgen. Derefter sender vi flere administratorer og udviklere hjem.
\n02:56. Vi har startet alt, hvad der kunne startes. Vi laver en grundl\u00e6ggende kontrol af alle tjenester med automatiserede tests.<\/p>\n

\"Skal
\n
\n03:02. Ventilationen i den sidste, 7. sal, er genoprettet.
\n03:36. Vi har inkluderet fronten i datacenteret i DNS-rotation. Fra dette tidspunkt begynder brugertrafikken at komme.
\nVi sender hovedparten af teamet af administratorer hjem. Men vi beholder et par personer.<\/p>\n

Lille FAQ:
\nQ: Hvad skete der fra 18:31 til 02:56?
\nA: I henhold til 'Handlingsplanen ved n\u00f8dsituationer' starter vi alle tjenester, begyndende med de mest kritiske. Koordinatoren i chatten tildeler tjenester til en ledig administrator, som kontrollerer, om OS og applikationen er startet korrekt, om der er fejl, og om indikatorerne er normale. Efter afslutning af opstarten meddeler han i chatten, at han er ledig, og modtager en ny tjeneste fra koordinatoren.
\nProcessen forsinkes yderligere af defekt hardware. Selvom nedlukningen af OS og slukningen af serverne gik korrekt, vender nogle servere ikke tilbage p\u00e5 grund af pludselige hardwarefejl i diske, hukommelse eller chassiser. Ved str\u00f8msvigt stiger fejlraten.
\nQ: Hvorfor kan vi ikke bare starte alt p\u00e5 \u00e9n gang og s\u00e5 reparere det, der viser sig i overv\u00e5gningen?
\nA: Alt skal g\u00f8res gradvist, fordi der er afh\u00e6ngigheder mellem tjenesterne. Og vi skal kontrollere alt med det samme, i stedet for at vente p\u00e5 overv\u00e5gningen \u2014 for med problemer er det bedre at f\u00e5 dem l\u00f8st med det samme, i stedet for at vente p\u00e5, at de bliver v\u00e6rre.<\/p><\/blockquote>\n

\n7:40. Den sidste administrator (koordinatoren) gik i seng. Arbejdet den f\u00f8rste dag er afsluttet.
\n8:09. De f\u00f8rste udviklere, ingeni\u00f8rer i datacenteret og administratorer (inklusive den nye koordinator) er begyndt med genoprettelsesarbejdet.
\n09:37. Vi er begyndt at h\u00e6ve sal \u21167 (den sidste).
\nSamtidig forts\u00e6tter vi med at genoprette det, vi ikke fik f\u00e6rdiggjort i de andre sale: udskiftning af diske\/hukommelse\/servere, reparation af alt, der 'br\u00e6nder' i overv\u00e5gningen, tilbagevenden af roller i master-standby ordninger og andre sm\u00e5ting, som dog stadig er mange.
\n17:08. Vi tillader alle planlagte arbejder med produktionen.
\n21:45. Arbejdet den anden dag er afsluttet.
\n09:45. I dag er det fredag. Der er stadig ret mange sm\u00e5 problemer i overv\u00e5gningen. Weekenden n\u00e6rmer sig, og alle vil have lidt fri. Vi forts\u00e6tter med massivt at reparere alt, hvad vi kan. De administrative opgaver, der kunne uds\u00e6ttes, er blevet udsat. Den nye koordinator.
\n15:40. Pludselig blev halvdelen af Core-netv\u00e6rksudstyrets stak genstartet i EN ANDEN datacenter. Vi tog frontene ud af rotation for at minimere risiciene. Ingen effekt for brugerne. Senere viste det sig, at det var en defekt chassis. Koordinatoren arbejder p\u00e5 at reparere to fejl samtidig.
\n17:17. Netv\u00e6rksarbejdet i det andet datacenter er genoprettet, alt er tjekket. Datacenteret er blevet taget tilbage i rotation.
\n18:29. Arbejdet fra den tredje dag og generelt genopretning efter uheldet er afsluttet.<\/p>\n

Efterord<\/h4>\n

\n04.04.2013, p\u00e5 dagen for 404-fejlen,<\/a><\/noindex>, \"Odnoklassniki\" oplevede den st\u00f8rste nedbrud,<\/a><\/noindex> \u2014 i l\u00f8bet af tre dage var portalen helt eller delvist utilg\u00e6ngelig. I hele denne periode reparerede over 100 mennesker fra forskellige byer og virksomheder (igen mange tak!), b\u00e5de fjernbetjent og direkte i datacenterne, tusinder af servere manuelt og automatisk.
\nVi har draget konklusioner. For at undg\u00e5 lignende situationer har vi gennemf\u00f8rt og forts\u00e6tter med at gennemf\u00f8re omfattende arbejder.<\/p>\n

Hvad er hovedforskellene mellem det nuv\u00e6rende nedbrud og 404?<\/p>\n