Ako sme už informovali v prehľade výpadkov, celkom podrobne na výveske, cez MOTD Aisy/Anxura/Aury, a tiež mailmi pre jednotlivých dotknutých používateľov, hneď na úvod októbra sme riešili problémy s úložiskom „data“ a strate časti v ňom uložených dát (keďže úložisko je priznane koncipované ako nezálohované).
Predohra: Pády Anxura, degradovaný RAID a niečo o „data“
Ešte v septembri došlo v dôsledku pádov Anxura k rozpadu diskových polí RAID 10 na serveri, čo vyvolalo ich plnú resynchronizáciu. U RAIDu 10 to znamená kontrolu zhody dát na zrkadlách, ktorá sa deje sériovo a nejakú dobu pri väčšom úložisku trvá. Navyše musí úložisko stále obsluhovať bežné operácie, takže býva žiadúce limitovať rýchlosť kontroly.
U jedného z RAIDov, na ktorom bolo umiestnené väčšie a pomalšie nezálohované úložisko „data“/K:, došlo chvíľu na to k výpadku jedného z diskov. Tento RAID je postavený na rotačných diskoch s kapacitou 12 TB a aktuálne využitá (logická) kapacita úložiska „data“ bola 5.6 TB. Stav v tento moment nebol skvelý, ale navonok nebol viditeľný, takže to stále nebol zásadný problém.
Dejstvo prvé: Chyby čítania disku a záchrana dát
Ten prišiel až 30. 9. po 18:00, kedy sa vyskytli chyby pri čítaní z druhej dvojičky vypadnutého disku, čo viedlo následne k chybám XFS. Bezprostredne na to sme sa začali snažiť o vykopírovanie dát z tohto úložiska (s prioritizovaním zamestnaneckých dát). Tým, že úložisko nebolo zálohované, na čo sme sa vždy snažili upozorňovať napríklad i cez $HOME/data/README.txt či v technickej dokumentácii, nám lepšia možnosť obnovy/záchrany dát nezostávala.
V tejto situácii hrozilo, že ak by úplne umrela i táto disková dvojička, aj vzhľadom na striping by to v podstate znamenalo stratu dát z celého úložiska „data“. Z viacerých možností záchrany dát – ddrescue, xfsdump a rsync – sme sa s cieľom maximalizácie množstva obnovených dát rozhodli pre poslednú (aby sa udialo čo najmenej prístupov k disku). Väčšiu časť dát sa nám takto podarilo vykopírovať, hoci s nejakými chybami kvôli chybným sektorom, ale inak prebiehalo kopírovanie v rámci možností úspešne.
Dejstvo druhé: Viditeľný výpadok „data“
Ako sme však i trocha očakávali, eventuálne, 2. 10. po jednej ráno došlo k vypnutiu XFS a zväzok „data“ prestal byť dostupný. Došlo k tomu cca v polovici kopírovania (z hľadiska využitého diskového miesta).
Toto spôsobilo zaseknutie procesov na iných serveroch, ktoré mali toto úložisko pripojené (typicky cez NFS), v stave D. Skorým ranným zásahom sme export tohto úložiska na iné stroje zrušili, stav dotknutých strojov sa zotavil sám alebo s našou pomocou – a to všetko ešte pred začiatkom rannej výuky.
V zápätí na to sme zverejnili udalosť o výpadku diskového poľa (zamestnanci boli informovaní mailom), vrátane MOTD, a večer i správu na výveske pre študujúcich. V rámci toho sme tiež kvôli žravým a syslivým nástrojom zrušili ručne vyrobené symlinky v domovských adresároch (napr. VS Code), na ktoré nabádame pri prekročení kvóty, a tiež systémové symlinky (moduly IDEA a PyCharm), pretože sme zistili, že IDE by v takomto stave neboli funkčné, a zvýšili sme kvóty. Úložisko „data“ sme teda v túto chvíľu pre bežné používanie úplne zneprístupnili a pokračovali sme v záchrane dát pomocou rsync.
Dejstvo tretie: Obnova a sprístupnenie dát
3. 10. po jednej poobede sa nám podarilo v rámci možností dokončiť obnovu dát. Následne, večer po ôsmej, sme opäť sprístupnili úložisko „data“, i s obnovenými dátami. a 4. 10. doobeda sme o tomto informovali mailom zamestnancov/dohodárov/doktorandov a tiež separátnym mailom tých, u ktorých sa časť dát obnoviť nepodarilo, vrátane zoznamu poškodených súborov.
V priebehu mesiaca sme potom vrátili nazad symlinky v moduloch IDEA a PyCharm (tie ručne vyrábané v domovských adresároch sme už neobnovovali).
Epilóg: Poučenia a vylepšenia
Urgentná práca bola hotová. Čo ďalej? Pokúšali sme sa ešte zachrániť dodatočné dáta z chybného disku cez ddrescue, ale pre veľké množstvo chýb bez úspechu.
Prehodnotili sme konfiguráciu našich RAIDov (používame len softvérový): zapli sme write-intent bitmaps (zatiaľ mimo RAIDu s „data“, kde ešte plánujeme reštrukturalizáciu), čo umožňuje evidovať bloky, do ktorých sa zapisovalo, a následne sa pri resynchronizácii pracuje len s týmito, namiesto celého disku. Toto býva implicitne zapnuté, ale my sme ho pri výrobe zväzkov RAIDu vypínali, keďže vie mať (závisí na type RAIDu a chunksize) nemalú výkonovú réžiu, a doteraz bola plná resynchronizácii zväzku potrebná iba pri jeho výrobe, kde bola i tak nutná.
Ďalej plánujeme (po určitej príprave) robiť pravidelné kontroly konzistencie dát na zrkadlách (tzv. scrubs), ktoré odhalia chyby vzniknuvšie napríklad v dôsledku chybných sektorov na jednom z diskov. Vďaka tomu bude možné buď tieto chybné dáta (ktoré nie sú fatálne, ale ak sú dlho neodhalené a v medzičase dôjde k problému s diskovou dvojičkou ako sa nám stalo tu, môže situácia skončiť dosť nepríjemne) včas prepísať podľa obsahu zdravého disku (chyby čítania sektorov je často možné opraviť ich prepisom) alebo celý disk označiť za poškodený a nahradiť ho. Tým sa riziko takéhoto incidentu síce neodstráni, ale jeho pravdepodobnosť sa zníži. U scrubs ide ale opäť o operáciu, ktorú by bolo vhodné robiť pravidelne, no má nejakú réžiu, ktorá spomaľuje bežné prístupy k disku, a je potom nutné ju obmedzovať (/sys/block/$DEV/md/sync_speed_max) a voliť vhodný balans medzi spomaľovaním bežnej prevádzky a dĺžkou trvania scrubs (napríklad pri našich 12 TB diskoch a limite rýchlosti 10 MBps by takáto operácia trvala 14 dní).
Dodajme ešte, že tento typ zlyhania úložiska RAID 10 sme u nás minimálne v poslednej dekáde doteraz nezaznamenali. A vďaka nášmu intenzívnemu úsiliu sa oproti najhoršiemu scenáru, kedy mohlo dôjsť i ku kompletnej strate dát z celého úložiska „data“, podarilo v tejto situácii vyviaznuť oproti najpesimistickejšiemu scenáru ešte celkom únosne, a hlavne dosť rýchlo.
