CVT FI

RSS

Novinky, zajímavosti a změny v provozu počítačů, počítačové sítě, prezentační a další techniky na FI MU. Další informace jsou dostupné v Technických informacích na webu fakulty.

Pro hlášení problémů prosím kontaktujte příslušnou sekci CVT FI.

Informace o aktuálních problémech naleznete na stránce o výpadcích.

Vlastníci blogu: FI:unix@fi, FI:CVT FI
Starší příspěvky
Kategorie
Vlastníci blogu: FI:unix@fi, FI:CVT FI
Právo číst: kdokoliv v Internetu
Právo komentovat: kdokoliv přihlášený v ISu
30. 4.
2019

Výpadek chlazení datacentra 26. dubna

  • RSS
Zajímavé | 39 | 39
RNDr. Jan Kasprzak, Ph.D. (CVT FI MU), učo 1885
infrastruktura
V noci ze čtvrtka na pátek 26. 4. cca v 0:50 došlo k poruše systému chlazení datacentra FI. Řídicí systém nahlásil v jeden okamžik poruchu asi patnácti různých součástí - od vysokých teplot všude možně přes poruchy servopohonů ventilů až po chybějící signál od detekce úniku chladiva. Zřejmě v důsledku tohoto stavu pak odstavil kompletně strojovnu chlazení. Datacentrum se začalo přehřívat.

Zprávu z monitoringu jsme dostali ve stejnou minutu a začali jsme podnikat kroky k analýze problému. Vzhledem k noční době byli na místě pouze recepční. Instruovali jsme je, aby zkusili resetovat kontroler chlazení. Pro tuto situaci máme ve strojovně chlazení připravené podrobné grafické instrukce, aby fyzický reset kontroleru byl schopen rychle udělat kdokoli, koho tím pověříme.

Bohužel i po resetu kontroleru byly vidět nesmyslné údaje na vstupech od teploměrů a dalších čidel. Teplota v datacentru dále rostla. Protože se nepodařilo problém nijak řešit vzdáleně a hrozilo poškození serverů v datacentru vysokou teplotou, přikročili jsme ke krizovému opatření - vypnutí přívodu napájení do datacentra. (cca v 01:50, teplota na rozhraní teplé a studené uličky již dosahovala téměř 50 °C).

Pracovníci CVT FI pak na místě pracovali na manuálním nastavení strojovny pomocí otevírání a zavírání jednotlivých ventilů a ruční manipulací s dalšími prvky tak, aby strojovna i bez kontroleru fungovala aspoň v režimu freecooling. Toto bylo naštěstí vzhledem k nevelkým venkovním teplotám funkční a datacentrum se posupně začalo ochlazovat.

Ve 4:10 bylo opět zapnuto napájení do obou sálů datacentra a začalo řešení problémů - počínaje koncovými jističi které vybavily proudovým nárazem při zapnutí přes problémy s bootováním různých serverů až po zprovozňování koncových služeb. Okolo 6:30 už byla podle Nagiosu většina služeb opět funkční.

Protože venkovní teplota stoupala, bylo třeba co nejdříve opět chladicí systém zprovoznit tak, aby mohl fungovat i v režimu strojního chlazení pomocí kompresorových chladicích jednotek. To se bohužel nepodařilo. Nakonec jsme použili nouzové řešení, které máme pro nejkritičtější případy připravené - vyměnili jsme celý kontroler chlazení za náhradní kus. Předávání řízení tomuto kontroleru se neobešlo bez dalších problémů - kontroler chtěl přepínat strojovnu na strojní chlazení dřív, než se podařilo zrušit ruční ovládání některých prvků. Navíc nový kontroler odmítal pracovat se servopohonem jednoho z nejdůležitějších ventilů. Toto se nakonec ukázalo být způsobeno vadným kontaktem ovládacího relé.

Okolo 12:30 už byla strojovna řízena náhradním kontrolerem, z bezpečnostních důvodů zafixovaným v režimu strojního chlazení. V neděli večer jsme pak přepnuli strojovnu do automatického výběru chladicího režimu.

Předběžný průzkum vadného kontroleru ukázal poškození některých dat na vnitřním úložišti kontroleru. Jestli to byla příčina nebo důsledek výpadku zatím nevíme. Problém řešíme s dodavatelem chladicího systému a ten s výrobcem samotného kontroleru.

Výpadek chlazení datacentra ukázal, že bohužel žádný systém není stoprocentně spolehlivý, a také že každá další porucha se může významně lišit od těch předchozích. Na pozitivní straně je to, že hned v několika situacích pomohla krizová dokumentace, kterou pro tyto případy připravujeme, samozřejmě aniž bychom dopředu tušili, jak přesně může konkrétní výpadek vypadat, a co přesně postihne.

Jako nesouvisející zajímavost dodáváme, že v noci z 25. na 26. dubna bylo 33. výročí havárie jaderného reaktoru v Černobylské elektrárně. Všem uživatelům systémů postižených pátečním výpadkem se omlouváme.

Dosud nečteno4 komentářepermalink
« Pípajúci orchester Fakulty informatiky (8. 4. 2019 18:49) | Kterak pácháme DoS útoky » (17. 6. 2019 15:53)

Osobní stránka Mgr. Jan Dvorský, Ph.D.
Re: Výpadek chlazení datacentra 26. dubna
  • RSS
Dobry den,

dekuji za dalsi zajimavy clanek a moznost nahlednout "za oponu" nebot se tento
vypadek dotkl i nasich sluzeb. Jelikoz pro nas nedopadl moc dobre (doslo k
fatalnimu poskozeni dat na cephu pro nekolik nasich virtualu), chtel jsem se
prosim dotazat, zdali nahodou neplanujete pripravit/nastavit nejaky krizovy plan
postupneho odstavovani serveru (predevsim ulozist) "graceful" zpusobem misto
tvrdeho vypnuti elektriky pro cele datacentrum? Osobne bych jednoznacne
preferoval delsi vypadek pred poskozenim dat.

Dekuji za odpoved,
Jan Stourac.
30. 4. 2019 22:10, Mgr. Jan Dvorský, Ph.D. (abs FI MU, PřF MU), učo 113869
Osobní stránka RNDr. Jan Kasprzak, Ph.D.
Re: Výpadek chlazení datacentra 26. dubna
  • RSS
Dobrý den,

děkujeme za podnět.

Nejprve - podle mého názoru by vypnutí všeho nemělo vést k poškození dat na
Cephovém úložišti. Je taky možné, že na fyzickém železe mohlo být chybně zapnuto
cachování tam, kde být zapnuto nemělo, nebo vznikla nějaká podobná chyba. U
našeho Cephu jsme poškození nezaznamenali (ale to samozřejmě nic moc neznamená,
třeba jsme jen měli menší provoz nebo větší štěstí :-).

Možnost "měkkého" vypnutí datacentra v případě výpadku chlazení zvažujeme. Teď
nevím, v jakém vztahu jsou vaše servery k nám - možná mezi námi leží ještě jedna
nebo více "mezivrstev" - zprostředkovatelů. Asi by bylo dobré v tomto se obrátit
na nejbližší nižší mezivrstvu (CERIT-SC?).

Každopádně takové softwarové vypnutí má další úskalí - nemělo by zkomplikovat
život tomu člověku, který bude příště řešit výpadek (je to další věc na kterou
by měl myslet, a dalších 5 minut, které mu sebereme), bylo by třeba řešit
bezpečnost a spolehlivost (jak to testovat?), bylo by třeba řešit co se stane,
když se po těch 5 minutách nakonec nerozhodneme datacentrum vypnout, atd.

Ozvali bychom se Vám i dalším přes mail, až budeme mít nějakou představu, jak to
příště řešit. Tento blog přecejen není vhodná platforma pro diskusi tohoto
problému.

Děkuji za pochopení a ještě jednou se omlouvám za výpadek.
2. 5. 2019 15:01, RNDr. Jan Kasprzak, Ph.D. (CVT FI MU), učo 1885
Osobní stránka RNDr. Petr Velan, Ph.D.
Re: Výpadek chlazení datacentra 26. dubna
  • RSS
Dobrý den,

také se přimluvím za prozkoumání možnosti měkkého vypnutí strojů. V rámci
OpenStacku ÚVT máme zničeny nebo poškozeny skoro všechny disky virtuálních
strojů, které v tu dobu běžely. Už nás to stálo, a ještě bude stát, docela dost
času při obnově těchto dat.

V praxi bych si představoval rozeslání signálu pro vypnutí strojům a nějaký
timeout (dle situace a urgentnosti vypnutí), po kterém by teprve byly stroje
vypnuty tvrdě. Předpokládám, že do virtuálního prostředí tento signál předá
hypervizor, nicméně to už je asi věc na dořešení s cloudovým týmem.
6. 5. 2019 16:31, RNDr. Petr Velan, Ph.D. (INFRA ITPV ÚVT MU), učo 255519
Osobní stránka RNDr. Jan Kasprzak, Ph.D.
Re: Výpadek chlazení datacentra 26. dubna
  • RSS
Zdravím,

tohle by stálo za prozkoumání - předpokládám že disky virtuálních strojů máte na
Ceph RBD, a Ceph by v případě výpadku OSD neměl takovéto poškození dovolit.
Aspoň co jsem si povrchně četl o tom, jak ta komunikace funguje, tak dokud
nepotvrdí nadpoloviční většina OSD, tak se data nezapíšou. Mám informace jen z
doslechu, ale nedošlo tam k tomu, že by se pustila VM znovu v domnění, že ta
původní neběží, ale přitom ta původní ještě běžela, a pak si přepisovaly data
navzájem? Fakt mi přijde divné, že pouhým vypnutím serverů by mělo dojít k takto
masivnímu poškození dat na Cephu. Skoro bych si myslel, že primární důvod
poškození dat by bylo třeba hledat někde jinde než v samotném vypnutí.

Ohledně notifikace:
Já bych si naopak představoval něco, kde by se o plánovaném vypnutí mohl dovědět
kdokoli i napřímo bez mezičlánků. Představoval bych si, že by se v případě
úmyslu vypnout datacentrum vygenerovala nějaká GPG podepsaná zpráva s údaji
typu:

testovací/ostrá zpráva
čas a datum plánovaného vypnutí
kontaktní telefon?

a ta by se nějakým mechanismem (HTTPS pull nebo push) poslala zájemcům.
Předpokládám, že čas by byl tak nejvíc 5 minut do budoucnosti. O větším čase
nemá cenu uvažovat. Předpokládám, že periodicky (třeba každou první středu v
měsíci ve 12:00 :-) bychom posílali testovací zprávu, aby si zájemci mohli
ověřit funkčnost.
9. 5. 2019 11:11, RNDr. Jan Kasprzak, Ph.D. (CVT FI MU), učo 1885