{"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\/no\/blog\/administrirovanie\/tushit-li-servera-esli-zagorelsya-smouk-test-dataczentra","title":{"rendered":"Skal man \"slukke\" serverne hvis \"smoketesten\" i datasenteret g\u00e5r av?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hva ville du f\u00f8lt hvis datasenteret med utstyret ditt en vakker sommerdag s\u00e5 slik ut?<\/p>\n

\"Skal
\n
\nHei alle sammen! Jeg heter Dmitrij Samsonov, og jeg jobber som ledende systemadministrator i \u00abMedarbeidere<\/a><\/noindex>\u00bb. P\u00e5 bildet ser vi et av de fire datasentrene hvor utstyret som st\u00f8tter prosjektet v\u00e5rt er installert. Bak disse veggene finnes det omtrent 4000 enheter: servere, lagringssystemer, nettverksutstyr osv. \u2014 nesten \u2153 av alt utstyret v\u00e5rt.
\nDe fleste serverne kj\u00f8rer Linux. Det er ogs\u00e5 noen titalls servere som kj\u00f8rer Windows (MS SQL) \u2014 v\u00e5rt arv som vi gradvis har kvittet oss med over mange \u00e5r.
\nS\u00e5, den 5. juni 2019 kl. 14:35 rapporterte ingeni\u00f8rer fra et av datasentrene v\u00e5re om brannalarm.
\n<\/a><\/noindex><\/p>\n

Benektelse<\/h4>\n

\n14:45. Sm\u00e5 hendelser med r\u00f8yk i datasentrene skjer oftere enn man skulle tro. M\u00e5lingene inne i hallene var normale, s\u00e5 v\u00e5r f\u00f8rste reaksjon var relativt avslappet: vi innf\u00f8rte forbud mot arbeid med produksjonen, det vil si noen endringer i konfigurasjoner, utrulling av nye versjoner, osv., unntatt arbeid relatert til reparasjoner.<\/p>\n

Raseri<\/h4>\n

\nHar du noen gang pr\u00f8vd \u00e5 sp\u00f8rre brannfolkene hvor p\u00e5 taket brannen oppsto, eller \u00e5 komme deg opp p\u00e5 det brennende taket selv for \u00e5 vurdere situasjonen? Hva vil v\u00e6re tilliten til informasjonen som er mottatt gjennom fem personer?<\/p>\n

14:50. Det har kommet informasjon om at flammene n\u00e6rmer seg kj\u00f8lesystemet<\/b>. Men vil det n\u00e5 frem? Den vaktsomme systemadministratoren rutet utg\u00e5ende trafikk fra frontene til dette datasenteret.<\/p>\n

Per n\u00e5 er frontene til alle tjenestene v\u00e5re duplisert i tre datasentre, med lastbalansering p\u00e5 DNS-niv\u00e5 som gj\u00f8r det mulig \u00e5 fjerne adressene til ett datasenter fra DNS, og dermed beskytte brukerne mot potensielle tilgangsproblemer til tjenestene. I tilfelle problemer i datasenteret allerede har oppst\u00e5tt, fjernes det automatisk fra rotasjonen. Du kan lese mer her: Lastbalansering og feilmotstand i \u00abMedarbeidere\u00bb.<\/a><\/noindex><\/p><\/blockquote>\n

\nBrannen har s\u00e5 langt ikke p\u00e5virket oss \u2014 verken brukerne eller utstyret har lidd. Er dette en n\u00f8dssituasjon? F\u00f8rste del av dokumentet \u00abHandlingsplan for n\u00f8dsituasjoner\u00bb gir en definisjon av begrepet \u00abN\u00f8dsituasjon\u00bb, og avsluttes med:
\n\u00abHvis det er tvil om det er en n\u00f8dssituasjon eller ikke, s\u00e5 er det en n\u00f8dssituasjon!<\/u>\u00bb<\/b><\/p>\n

14:53. Ein krisekoordinator blir tilsett.<\/p>\n

Koordinatoren er en person som kontrollerer kommunikasjonen mellom alle deltakere, vurderer omfanget av krisen, bruker \u00abHandlingsplan ved krise\u00bb, engasjerer n\u00f8dvendig personale, overv\u00e5ker fullf\u00f8ringen av reparasjoner, og viktigst av alt \u2014 delegerer oppgaver. Med andre ord, det er personen som leder hele prosessen med \u00e5 h\u00e5ndtere krisen.<\/p><\/blockquote>\n

<\/p>\n

Auksjon<\/h4>\n

\n15:01. Vi begynner \u00e5 sl\u00e5 av serverne som ikke er knyttet til produksjon.
\n15:03. Vi sl\u00e5r av alle reserverte tjenester p\u00e5 en korrekt m\u00e5te.
\nDette inkluderer ikke bare frontene (som brukerne allerede ikke f\u00e5r tilgang til p\u00e5 dette tidspunktet) og deres st\u00f8ttetjenester (forretningslogikk, cacher, osv.), men ogs\u00e5 ulike databaser med et replikasjonsfaktor p\u00e5 2 eller mer (Cassandra<\/a><\/noindex>, lagring av bin\u00e6re data<\/a><\/noindex>, kald lagring<\/a><\/noindex>, NewSQL<\/a><\/noindex> og s\u00e5 videre).
\n15:06. Det har kommet informasjon om at en brann truer et av rommene i datasenteret.<\/b> I dette rommet har vi ikke utstyr, men det at flammen kan spre seg fra taket til rommene endrer kraftig situasjonen.
\n(Senere viste det seg at det ikke var noen fysisk trussel mot rommet, siden det er hermetisk isolert fra taket. Trusselen var bare for kj\u00f8lesystemet i dette rommet.)
\n15:07. Vi tillater kommandoer p\u00e5 serverne \u00e5 bli utf\u00f8rt i akselerert modus uten ytterligere kontroller (uten v\u00e5r kj\u00e6re kalkulator<\/a><\/noindex>).
\n15:08. Temperaturen i rommene er innenfor normalen.
\n15:12. Det er registrert en temperatur\u00f8kning i rommene.<\/b>
\n15:13. Mer enn halvparten av serverne i datasenteret er sl\u00e5tt av. Vi fortsetter.
\n15:16. Det er tatt beslutning om \u00e5 sl\u00e5 av alt utstyr.
\n15:21. Vi begynner \u00e5 kutte str\u00f8mmen til stateless-serverne uten korrekt nedstenging av applikasjonen og operativsystemet.
\n15:23. Det blir utpekt en gruppe ansvarlige for MS SQL (det er f\u00e5, avhengigheten av tjenestene deres er ikke stor, men prosedyren for \u00e5 gjennopprette funksjonalitet tar lengre tid og er mer komplisert enn for eksempel Cassandra).<\/p>\n

Depresjon<\/h4>\n

\n15:25. Det har kommet informasjon om avstengning av str\u00f8m i fire rom av 16 (nr. 6, 7, 8, 9).<\/b> I rom 7 og 8 har vi v\u00e5rt utstyr. Det er ingen informasjon om de to andre rommene v\u00e5re (nr. 1 og 3).
\nVanligvis sl\u00e5r man av str\u00f8mmen umiddelbart ved branner, men i dette tilfellet, takket v\u00e6re koordinert arbeid fra brannmenn og teknisk personell i datasenteret, ble det ikke sl\u00e5tt av overalt og ikke med en gang, men etter behov.
\n(Senere viste det seg at str\u00f8mmen i salene 8 og 9 ikke ble sl\u00e5tt av.)
\n15:28. Vi begynner \u00e5 gjenopprette MS SQL-databaser fra sikkerhetskopier i andre datasentre.
\nHvor lang tid vil dette ta? Er b\u00e5ndbredden i nettverket tilstrekkelig gjennom hele ruten?
\n15:37. Det er registrert avbrudd i enkelte nettverkssegmenter.<\/b>
\nManagement- og produksjonsnettverket er fysisk isolert fra hverandre. Hvis produksjonsnettverket er tilgjengelig, kan du logge inn p\u00e5 serveren, stoppe applikasjonen og sl\u00e5 av operativsystemet. Hvis det ikke er tilgjengelig, kan du logge inn via IPMI, stoppe applikasjonen og sl\u00e5 av operativsystemet. Hvis ingen av nettverkene er tilgjengelige, kan du ikke gj\u00f8re noe. \"Takk, kaptein!\", vil du kanskje tenke.
\n\"Og generelt, det er litt mye styr,\" vil du kanskje ogs\u00e5 tenke.
\nSaken er at servere, selv uten brann, genererer enormt mye varme. Mer presist, n\u00e5r det er kj\u00f8ling, genererer de varme, og n\u00e5r det ikke er noe kj\u00f8ling, skaper de helvetes hete, som i beste fall smelter deler av utstyret og sl\u00e5r av andre deler, og i verste fall... for\u00e5rsaker brann inne i salen, som praktisk talt garantert vil \u00f8delegge alt.<\/p>\n

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

Conf-databasen er backend for den navngitte tjenesten som brukes av alle produksjonsapplikasjoner for \u00e5 justere innstillinger i sanntid. Uten denne databasen kan vi ikke styre portalen, men portalen kan fortsatt fungere.<\/p><\/blockquote>\n

\n15:41. Temperaturf\u00f8lerne p\u00e5 Core-nettverksutstyret registrerer verdier n\u00e6r de maksimalt tillatte niv\u00e5ene. Dette er en boks som tar opp en hel rack og s\u00f8rger for drift av alle nettverk inne i datasenteret.<\/p>\n

\"Skal
\n
\n15:42. Issue tracker og wiki er utilgjengelige, vi g\u00e5r over til standby.
\nDette er ikke produksjon, men ved en n\u00f8dsituasjon kan tilgjengeligheten av hvilken som helst kunnskapsbase v\u00e6re kritisk.
\n15:50. Ett av overv\u00e5kingssystemene har stoppet.
\nDet er flere av dem, og de er ansvarlige for forskjellige aspekter ved servicearbeid. Noen av dem er konfigurert for autonom drift inne i hvert datasenter (det vil si at de bare overv\u00e5ker sitt eget datasenter), mens andre best\u00e5r av distribuerte komponenter som greier \u00e5 h\u00e5ndtere tapet av et hvilket som helst datasenter.
\nI dette tilfellet har systemet for oppdagelse av anomalier i forretningslogikken<\/a><\/noindex>, som fungerer i master-standby-modus, stoppet. Vi har byttet til standby.<\/p>\n

Godkjenning<\/h4>\n

\n15:51. Via IPMI slukket vi alle serverne uten korrekt avslutning, unntatt MS SQL.
\nEr du klar for masseadministrasjon av servere via IPMI om n\u00f8dvendig?<\/p>\n

Det \u00f8yeblikket n\u00e5r redningen av utstyret i datasenteret er fullf\u00f8rt. Alt som kunne gj\u00f8res, er gjort. Noen kolleger kan ta en pause.<\/i>
\n16:13. Det har kommet informasjon om at kj\u00f8leanleggene p\u00e5 taket har f\u00e5tt lekkasje i kondensorr\u00f8rene \u2013 det vil forsinke oppstarten av datasenteret etter brannslukking.<\/b>
\n16:19. If\u00f8lge data fra det tekniske personalet i datasenteret har temperaturen i rommene sluttet \u00e5 stige.
\n17:10. Vi har gjenopprettet jobben til conf-databasen. N\u00e5 kan vi endre innstillingene til applikasjonene.
\nHvorfor er dette s\u00e5 viktig, hvis alt er redundante og fungerer selv uten ett datasenter?
\nFor det f\u00f8rste er ikke alt redundante. Det finnes forskjellige sekund\u00e6re tjenester som fortsatt ikke takler nedetid i datasenteret veldig godt, og det er databaser i master-standby-modus. Muligheten til \u00e5 administrere innstillingene gj\u00f8r at vi kan gjennomf\u00f8re de n\u00f8dvendige tiltakene for \u00e5 minimere virkningen av en n\u00f8dsituasjon p\u00e5 brukerne, selv under vanskelige forhold.
\nFor det andre ble det klart at i l\u00f8pet av de n\u00e6rmeste timene vil ikke driften av datasenteret bli gjenopprettet helt, derfor var det n\u00f8dvendig \u00e5 iverksette tiltak for \u00e5 unng\u00e5 langvarig utilgjengelighet av replikkene, som kan f\u00f8re til ytterligere problemer som diskfylling i de gjenv\u00e6rende datasentrene.
\n17:29. Tid for pizza! Vi har folk som jobber, ikke roboter.<\/p>\n

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

Rehabilitering<\/h4>\n

\n18:02. Temperaturen i rommene nr. 8 (v\u00e5rt), 9, 10 og 11 har stabilisert seg. I ett av rommene som fortsatt er avstengt (nr. 7) har vi v\u00e5rt utstyr, og temperaturen der fortsetter \u00e5 stige.
\n18:31. Vi har f\u00e5tt klarsignal for oppstart av utstyret i rom nr. 1 og 3 \u2013 disse rommene ble ikke ber\u00f8rt av brannen.<\/p>\n

For \u00f8yeblikket blir serverne i rom nr. 1, 3 og 8 startet opp, med fokus p\u00e5 de mest kritiske. Vi sjekker at alle igangsatte tjenester fungerer korrekt. Det er fortsatt problemer med rom nr. 7.<\/i><\/p>\n

18:44. Det tekniske personalet i datasenteret har funnet ut at mange servere i rom nr. 7 (hvor v\u00e5rt utstyr st\u00e5r) ikke ble sl\u00e5tt av. If\u00f8lge v\u00e5re data er 26 servere fortsatt p\u00e5. Ved ny sjekk finner vi 58 servere.
\n20:18. Det tekniske personalet i datasenteret bl\u00e5ser luft i rommet uten klimaanlegg gjennom mobile luftkanaler som er lagt gjennom gangene.
\n23:08. Den f\u00f8rste administratoren er sendt hjem. Noen m\u00e5 f\u00e5 sove om natten for \u00e5 kunne fortsette arbeidet i morgen. Vi slipper n\u00e5 ogs\u00e5 noen flere administratorer og utviklere.
\n02:56. Vi har startet alt som kan startes. Vi gj\u00f8r en grundig sjekk av alle tjenester med autotester.<\/p>\n

\"Skal
\n
\n03:02. Klimaanlegget i det siste, 7. rom, er gjenopprettet.
\n03:36. Vi har f\u00e5tt frontene i datasenteret inn i rotasjon i DNS. Fra dette tidspunktet begynner \u00e5 komme brukertrafikk.
\nVi slipper ned store deler av administratorteamet hjem. Men vi beholder noen personer.<\/p>\n

En liten FAQ:
\nQ: Hva skjedde mellom 18:31 og 02:56?
\nA: I henhold til \u00abHandlingsplan ved feil\u00bb starter vi alle tjenester, begynner med de viktigste. Samtidig gir koordinatoren i chatten en tjeneste til den ledige administratoren, som sjekker om OS og applikasjonen har startet, om det er noen feil, og om alt fungerer som det skal. Etter at oppstarten er fullf\u00f8rt, informerer han chatten om at han er ledig, og f\u00e5r en ny tjeneste fra koordinatoren.
\nProsessen blir ytterligere forsinket av sviktende maskinvare. Selv om nedstengingen av OS og avslutningen av serverne har g\u00e5tt korrekt, returnerer ikke en del servere p\u00e5 grunn av plutselige feil p\u00e5 disker, minne eller chassis. Ved str\u00f8mmangel \u00f8ker prosentandelen av brudd.
\nQ: Hvorfor kan vi ikke bare starte alt samtidig, og deretter fikse det som dukker opp i overv\u00e5kingen?
\nA: Alt m\u00e5 gj\u00f8res gradvis, fordi det er avhengigheter mellom tjenestene. Og vi m\u00e5 sjekke alt med en gang, uten \u00e5 vente p\u00e5 overv\u00e5kingen \u2014 fordi det er best \u00e5 h\u00e5ndtere problemer med en gang, uten \u00e5 vente p\u00e5 at de blir verre.<\/p><\/blockquote>\n

\n7:40. Den siste administratoren (koordinatoren) har g\u00e5tt til sengs. Arbeidet f\u00f8rste dag er avsluttet.
\n8:09. De f\u00f8rste utviklerne, ingeni\u00f8rene i datasentrene og administratorene (inkludert den nye koordinatoren) har begynt gjenopprettingsarbeidet.
\n09:37. Vi har begynt \u00e5 heve rom nr. 7 (det siste).
\nSamtidig fortsetter vi \u00e5 gjenopprette det vi ikke har f\u00e5tt gjort ferdig i de andre rommene: bytte disker\/minne\/servere, fikse alt som \u00abbrenner\u00bb i overv\u00e5kingen, reversere roller i master-standby skjemaene og andre sm\u00e5ting, som likevel er ganske mange.
\n17:08. Vi tillater alle ordin\u00e6re arbeider med produksjonen.
\n21:45. Arbeidet den andre dagen er avsluttet.
\n09:45. I dag er det fredag. Det er fortsatt en del sm\u00e5problemer i overv\u00e5kingen. Helgen n\u00e6rmer seg, og alle \u00f8nsker \u00e5 slappe av. Vi fortsetter \u00e5 fikse alt som kan fikses. Administrative oppgaver som kunne utsettes, blir utsatt. Den nye koordinatoren.
\n15:40. Plutselig restartet halvparten av Core-nettverksutstyret i EN ANNEN datasentral. Vi tok frontene ut av rotasjonen for \u00e5 minimere risikoene. Ingen effekt for brukerne. Senere ble det klart at det var en defekt chassis. Koordinatoren jobber med \u00e5 reparere to hendelser samtidig.
\n17:17. Nettverksarbeidet i den andre datasentralen er gjenopprettet, alt er sjekket. Datasentralen er tilbake i rotasjon.
\n18:29. Arbeidet med tredje dagen og generelt gjenopprettingen etter hendelsen er fullf\u00f8rt.<\/p>\n

Etterord<\/h4>\n

\n04.04.2013, p\u00e5 dagen for feilkode 404,<\/a><\/noindex>\u00abVKontakte\u00bb, overlevde den st\u00f8rste krasjen,<\/a><\/noindex> \u2014portalen var helt eller delvis utilgjengelig i l\u00f8pet av tre dager. I l\u00f8pet av denne tiden var over 100 personer fra ulike byer og selskaper (takk igjen!), som jobbet b\u00e5de eksternt og direkte i datasentrene, inne og ute, manuelt og automatisk, i gang med \u00e5 fikse tusenvis av servere.
\nVi har l\u00e6rt leksjonene. For \u00e5 unng\u00e5 slike hendelser igjen har vi utf\u00f8rt og fortsetter \u00e5 utf\u00f8re omfattende arbeider.<\/p>\n

Hva er de viktigste forskjellene fra den n\u00e5v\u00e6rende krasjen sammenlignet med 404?<\/p>\n