Jak byste se cítili, kdyby jednoho krásného letního dne vypadalo datové centrum s vaším vybavením takto?
Ahoj všichni! Jmenuji se Dmitrij Samsonov a pracuji jako přední správce systému ve společnosti "" Na fotografii je jedno ze čtyř datových center, kde je instalováno zařízení sloužící našemu projektu. Za těmito zdmi se nachází asi 4 tisíce zařízení: servery, systémy pro ukládání dat, síťová zařízení atd. - téměř ⅓ veškerého našeho vybavení.
Většina serverů je Linux. Existuje také několik desítek serverů na Windows (MS SQL) - naše dědictví, od kterého se již řadu let systematicky upouštíme.
Takže 5. června 2019 ve 14:35 technici v jednom z našich datových center nahlásili požární poplach.
Odmítnutí
14:45. Drobné kouřové incidenty v datových centrech jsou častější, než si myslíte. Ukazatele uvnitř hal byly v normě, takže naše první reakce byla relativně klidná: zavedli zákaz práce s výrobou, tedy jakýchkoliv změn konfigurace, vyjíždění nových verzí atd., kromě prací souvisejících s něčím opravováním.
Hněv
Zkoušeli jste někdy od hasičů zjistit, kde přesně na střeše došlo k požáru, nebo se sami dostat na hořící střechu a posoudit situaci? Jaká bude míra důvěry v informace přijaté prostřednictvím pěti lidí?
14: 50. Byla přijata informace, že se požár blíží k chladicímu systému. Ale přijde to? Správce systému ve službě odstraňuje externí provoz z předních částí tohoto datového centra.
V tuto chvíli jsou fronty všech našich služeb duplikovány ve třech datových centrech, využívá se balancování na úrovni DNS, což nám umožňuje odstranit adresy jednoho datového centra z DNS, a tím chránit uživatele před případnými problémy s přístupem ke službám . Pokud již v datovém centru nastaly problémy, opustí rotaci automaticky. Více si můžete přečíst zde:
Požár nás zatím nijak nepostihl – nedošlo k poškození uživatelů ani zařízení. Je to nehoda? První část dokumentu „Accident Action Plan“ definuje pojem „nehoda“ a část končí takto:
«Pokud existují pochybnosti, zda došlo k nehodě nebo ne, pak je to nehoda!»
14:53. Je jmenován koordinátor pro mimořádné situace.
Koordinátor je ten, kdo řídí komunikaci mezi všemi účastníky, posuzuje rozsah nehody, využívá havarijní akční plán, přitahuje potřebný personál, hlídá dokončení oprav a hlavně deleguje případné úkoly. Jinými slovy, je to osoba, která řídí celý proces reakce na mimořádné události.
Obchodování
15:01. Začínáme deaktivovat servery, které nesouvisejí s výrobou.
15:03. Správně vypínáme všechny vyhrazené služby.
To zahrnuje nejen fronty (ke kterým již uživatelé nemají přístup) a jejich pomocné služby (obchodní logika, mezipaměti atd.), ale také různé databáze s replikačním faktorem 2 nebo více (, , , atd.).
15: 06. Byla přijata informace, že požár ohrožuje jednu z hal datového centra. V této místnosti nemáme vybavení, ale skutečnost, že se oheň může šířit ze střechy do hal, velmi mění obraz toho, co se děje.
(Později se ukázalo, že k žádnému fyzickému ohrožení haly nedošlo, protože byla ze střechy hermeticky uzavřena. Ohrožení bylo pouze pro chladicí systém této haly.)
15:07. Umožňujeme provádění příkazů na serverech ve zrychleném režimu bez dalších kontrol ().
15:08. Teplota v halách je v normálních mezích.
15: 12. Bylo zaznamenáno zvýšení teploty v halách.
15:13. Více než polovina serverů v datovém centru je vypnutá. Pokračujme.
15:16. Bylo rozhodnuto vypnout všechna zařízení.
15:21. Začneme vypínat napájení bezstavových serverů, aniž bychom správně ukončili aplikaci a operační systém.
15:23. Je vyčleněna skupina lidí odpovědných za MS SQL (je jich málo, závislost služeb na nich není velká, ale procedura obnovy funkčnosti trvá déle a je složitější než např. Cassandra).
Депрессия
15: 25. Byla přijata informace o odpojení proudu ve čtyřech sálech ze 16 (č. 6, 7, 8, 9). Naše zařízení se nachází v hale 7 a 8. O našich dvou halách (č. 1 a 3) nejsou žádné informace.
Obvykle se při požárech okamžitě vypne napájení, ale v tomto případě se díky koordinované práci hasičů a technického personálu datového centra nevypínalo všude a ne hned, ale podle potřeby.
(Později se zjistilo, že v halách 8 a 9 nebylo vypnuto napájení.)
15:28. Začínáme nasazovat MS SQL databáze ze záloh v jiných datových centrech.
Jak dlouho to trvá? Je dostatečná kapacita sítě pro celou trasu?
15: 37. Bylo zaznamenáno odstavení některých částí sítě.
Management a produkční síť jsou od sebe fyzicky izolované. Pokud je produkční síť k dispozici, můžete přejít na server, zastavit aplikaci a vypnout OS. Pokud není k dispozici, můžete se přihlásit přes IPMI, zastavit aplikaci a vypnout OS. Pokud neexistuje žádná ze sítí, nemůžete nic dělat. "Díky, Cape!", pomyslíte si.
"A obecně je tu spousta zmatků," můžete si také myslet.
Jde o to, že servery i bez požáru generují obrovské množství tepla. Přesněji řečeno, když dochází k chlazení, generují teplo, a když není chlazení, vytvářejí pekelné peklo, které v lepším případě roztaví část zařízení a vypne další část a v nejhorším... způsobí uvnitř požár halu, která téměř zaručeně vše zničí.
15:39. Opravujeme problémy s databází conf.
Databáze conf je backend pro stejnojmennou službu, kterou používají všechny produkční aplikace k rychlé změně nastavení. Bez této základny nemůžeme ovládat chod portálu, ale portál samotný fungovat může.
15:41. Snímače teploty na zařízení hlavní sítě zaznamenávají hodnoty blízké maximální povolené hodnotě. Jedná se o box, který zabírá celý rack a zajišťuje provoz všech sítí uvnitř datového centra.
15:42. Sledování problémů a wiki nejsou k dispozici, přepněte do pohotovostního režimu.
Nejedná se o výrobu, ale v případě nehody může být dostupnost jakékoli znalostní báze kritická.
15:50. Jeden z monitorovacích systémů se vypnul.
Je jich několik a jsou zodpovědní za různé aspekty služeb. Některé z nich jsou nakonfigurovány tak, aby fungovaly autonomně v rámci každého datového centra (to znamená, že monitorují pouze své vlastní datové centrum), jiné se skládají z distribuovaných komponent, které transparentně přežijí ztrátu jakéhokoli datového centra.
V tomto případě přestal fungovat , který pracuje v režimu master-standby. Přepnuto do pohotovostního režimu.
Přijetí
15:51. Všechny servery kromě MS SQL byly vypnuty přes IPMI bez správného vypnutí.
Jste připraveni na masivní správu serveru přes IPMI v případě potřeby?
Právě ten okamžik, kdy je v této fázi dokončena záchrana zařízení v datovém centru. Všechno, co se dalo udělat, bylo vykonáno. Někteří kolegové si mohou odpočinout.
16: 13. Byly obdrženy informace, že na střeše praskly freonové trubky z klimatizací – to zdrží spuštění datového centra po likvidaci požáru.
16:19. Podle údajů získaných od technických pracovníků datového centra se nárůst teploty v halách zastavil.
17:10. Databáze conf byla obnovena. Nyní můžeme změnit nastavení aplikace.
Proč je to tak důležité, když je vše odolné proti chybám a funguje i bez jednoho datového centra?
Za prvé, ne vše je odolné vůči chybám. Existují různé sekundární služby, které ještě dostatečně nepřežily selhání datového centra, a existují databáze v režimu master-standby. Schopnost spravovat nastavení vám umožňuje udělat vše potřebné pro minimalizaci dopadu následků nehody na uživatele i ve ztížených podmínkách.
Zadruhé se ukázalo, že provoz datového centra nebude v nejbližších hodinách plně obnoven, a proto bylo nutné přijmout opatření, aby dlouhodobá nedostupnost replik nevedla k dalším problémům, jako jsou plné disky v zbývající datová centra.
17:29. Čas na pizzu! Zaměstnáváme lidi, ne roboty.
Rehabilitace
18:02. V halách č. 8 (naše), 9, 10 a 11 se teplota ustálila. V jednom z těch, které zůstávají offline (č. 7), je umístěno naše zařízení a teplota tam stále stoupá.
18:31. Dali souhlas ke spuštění zařízení v halách č. 1 a 3 - tyto haly požárem zasaženy nebyly.
V současné době jsou servery spouštěny v halách č. 1, 3, 8, počínaje těmi nejkritičtějšími. Kontroluje se správný chod všech spuštěných služeb. S halou č. 7 jsou stále problémy.
18:44. Technický personál datového centra zjistil, že v místnosti č. 7 (kde se nachází pouze naše zařízení) není vypnuto mnoho serverů. Podle našich údajů tam zůstává online 26 serverů. Po druhé kontrole najdeme 58 serverů.
20:18. Technici datového centra foukají vzduch neklimatizovanou místností mobilními potrubími procházejícími chodbami.
23:08. První admin byl poslán domů. Někdo potřebuje v noci spát, aby mohl zítra pokračovat v práci. Dále uvolníme další administrátory a vývojáře.
02:56. Spustili jsme vše, co šlo spustit. Provádíme velkou kontrolu všech služeb pomocí automatických testů.
03:02. V poslední, 7. hale byla obnovena vzduchotechnika.
03:36. Uvedli jsme fronty v datovém centru do rotace v DNS. Od tohoto okamžiku začíná přicházet uživatelský provoz.
Většinu administrativního týmu posíláme domů. Ale pár lidí tu necháváme.
Malé časté dotazy:
Otázka: Co se stalo od 18:31 do 02:56?
Odpověď: Podle „Disaster Action Plan“ spouštíme všechny služby, počínaje těmi nejdůležitějšími. V tomto případě koordinátor v chatu vydá službu bezplatnému správci, který zkontroluje, zda se OS a aplikace spustily, zda nejsou nějaké chyby a zda jsou indikátory normální. Po dokončení spuštění nahlásí chatu, že je volný a dostává od koordinátora novou službu.
Proces dále zpomaluje vadný hardware. I když zastavení operačního systému a vypnutí serverů proběhlo správně, některé servery se nevrátí kvůli náhlému selhání disků, paměti a šasi. Při výpadku napájení se zvyšuje poruchovost.
Otázka: Proč nemůžete všechno spustit najednou a pak opravit to, co se objeví v monitorování?
A: Vše se musí dělat postupně, protože mezi službami jsou závislosti. A vše by se mělo zkontrolovat hned, bez čekání na sledování - protože je lepší řešit problémy hned, bez čekání na jejich zhoršení.
7:40. Poslední admin (koordinátor) šel spát. Práce prvního dne byla dokončena.
8:09. První vývojáři, inženýři a správci datových center (včetně nového koordinátora) zahájili restaurátorské práce.
09:37. Začali jsme zvedat halu č. 7 (poslední).
Zároveň pokračujeme v obnově toho, co nebylo opraveno v jiných místnostech: výměna disků/paměti/serverů, oprava všeho, co „hoří“ při monitorování, přepínání rolí zpět ve schématech master-standby a další drobnosti, kterých je přesto docela hodně.
17:08. Umožňujeme veškerou běžnou práci s výrobou.
21:45. Práce druhého dne je dokončena.
09:45. Dnes je pátek. V monitorování stále existuje několik malých problémů. Víkend je před námi, každý si chce odpočinout. Nadále masivně opravujeme vše, co se dá. Pravidelné úkoly správce, které mohly být odloženy, byly odloženy. Koordinátor je nový.
15:40. Najednou se polovina hlavního síťového zařízení v JINÉM datovém centru restartovala. Přední strany byly vyřazeny z rotace, aby se minimalizovala rizika. Pro uživatele to nemá žádný efekt. Později se ukázalo, že šlo o vadný podvozek. Koordinátor pracuje na opravě dvou nehod najednou.
17:17. Provoz sítě v jiném datovém centru byl obnoven, vše bylo zkontrolováno. Datové centrum je uvedeno do rotace.
18:29. Práce třetího dne a obecně restaurování po havárii je dokončeno.
Doslov
04.04.2013 , "Spolužáci" —po dobu tří dnů byl portál zcela nebo částečně nedostupný. Za celou tuto dobu více než 100 lidí z různých měst, z různých společností (ještě jednou velké díky!), na dálku a přímo v datových centrech, ručně i automaticky, opravilo tisíce serverů.
Vyvodili jsme závěry. Aby se to již neopakovalo, provedli jsme a provádíme rozsáhlé práce dodnes.
Jaké jsou hlavní rozdíly mezi současnou nehodou a 404?
- Máme „Akční plán pro nehody“. Jednou za čtvrt roku provádíme cvičení – hrajeme roli havarijní situace, kterou musí skupina administrátorů (všichni postupně) eliminovat pomocí „Krizového akčního plánu“. V roli koordinátora se střídají přední správci systému.
- Čtvrtletně v testovacím režimu izolujeme datová centra (všechna postupně) prostřednictvím sítí LAN a WAN, což nám umožňuje rychle identifikovat úzká hrdla.
- Méně rozbitých disků, protože jsme zpřísnili standardy: méně provozních hodin, přísnější prahové hodnoty pro SMART,
- Zcela jsme opustili BerkeleyDB, starou a nestabilní databázi, jejíž obnova po restartu serveru vyžadovala spoustu času.
- Snížili jsme počet serverů s MS SQL a snížili závislost na zbývajících.
- Máme vlastní , kam již dva roky aktivně migrujeme veškeré služby. Cloud výrazně zjednodušuje celý cyklus práce s aplikací a v případě nehody poskytuje tak unikátní nástroje jako:
- správné zastavení všech aplikací jedním kliknutím;
- snadná migrace aplikací z neúspěšných serverů;
- automatické seřazené (v pořadí podle priority služeb) spuštění celého datového centra.
Nehoda popsaná v tomto článku byla největší od 404. dne. Samozřejmě ne vše šlo hladce. Například během nedostupnosti požárem poškozeného datového centra v jiném datovém centru selhal disk na jednom ze serverů, to znamená, že pouze jedna ze tří replik v clusteru Cassandra zůstala přístupná, a proto 4,2 % mobilních uživatelé aplikace se nemohli přihlásit . Zároveň pokračovali v práci již připojení uživatelé. Celkem bylo v důsledku nehody identifikováno více než 30 problémů - od banálních chyb po nedostatky v architektuře služeb.
Ale nejdůležitější rozdíl mezi současnou nehodou a 404. je v tom, že zatímco jsme odstraňovali následky požáru, uživatelé stále posílali textové zprávy a uskutečňovali videohovory hráli hry, poslouchali hudbu, dávali si dárky, sledovali videa, televizní seriály a televizní kanály , a také streamoval .
Jak probíhají vaše nehody?
Zdroj: www.habr.com