Kvůli chybě v softwaru od HPE přišla japonská univerzita o 77 TB dat výzkumu

24
Kyoto University Clock Tower
Kyoto University
-
Zdroj: Soraie8288 - CC BY-SA 4.0

Japonská univerzita přišla asi o 77 TB dat ze superpočítače Cray. Viníkem má být dodavatel počítače HP Enterprise. Výzkumníci ztratili 34 milionů souborů. HPE se omluvil.

Událost se stala na školním superpočítači Cray (firmu Cray odkoupil HPE v roce 2019 za 1,3 miliardy dolarů) kvůli skriptu. Ten měl pouze mazat starší logy, ale jeho nová verze po updatu dělala něco jiného. Smazala téměř všechny soubory starší deseti dnů, což počítači trvalo asi dva dny. Univerzita nezveřejnila příliš podrobností, ale ze zprávy je patrné, že smazaná data ovlivní 14 výzkumných skupin.

Za událost a špatný update se již omluvil dodavatel superpočítače, společnost HP Enterprise (HPE) a převzal plnou zodpovědnost. Společnost HPE uvedla: „Skript pro zálohování obsahuje příkaz find, který odstraňuje soubory protokolu starší než 10 dní. Kromě funkčního vylepšení skriptu byl pro zlepšení viditelnosti a čitelnosti změněn název proměnné předávané příkazu find pro smazání.“

„V postupu uvolnění tohoto upraveného skriptu však chyběla opatrnost. Nebyli jsme si vědomi vedlejších účinků tohoto chování a vydali jsme [aktualizovaný] skript, přičemž jsme přepsali [skript bash] v době, kdy ještě běžel. To mělo za následek opětovné načtení upraveného shellového skriptu uprostřed jeho provádění, což vedlo k nedefinovaným proměnným. V důsledku toho došlo k odstranění původních souborů protokolu v adresáři /LARGE0 [úložiště záložního disku] namísto původního procesu odstranění souborů uložených v adresáři protokolu.“

Superpočítač Cray na univerzitě v Kjótu
Superpočítač Cray na univerzitě v Kjótu

Kjótská univerzita je považována za jednu z nejvýznamnějších japonských výzkumných institucí a má druhé největší investice do vědeckého výzkumu z národních grantů. Nyní přišla o mnoho dokumentů z výzkumů, byť konkrétní ztráty neuvádí. Univerzita nyní hodlá vylepšit systém zálohování a udržovat také inkrementální zálohy. Ze 77 TB zřejmě půjde asi dvě třetiny dat obnovit a celá ztráta je jen malou částí celkového úložiště (24 PB) univerzity.

zdroj: thestack

Kvůli chybě v softwaru od HPE přišla japonská univerzita o 77 TB dat výzkumu
Ohodnoťte tento článek!
4.2 (84.44%) 9 hlasů

24 KOMENTÁŘE

  1. oni maju za „cely zivot minus 10 dni“ toho superPC len 77TB dat? Ked to pritiahnem za vlasy, tak na zalohu staci 4diskove synology za 400€ (+ 4x20tb HDD), tak ale snad tam maju 1 blbu paskovu mechaniku a laduju zalohy na pasku, nie?

    • Ono to nebude tak jednoduché. Z popisu mně není jasné, jestli to sejmulo soubory starší, než mělo nebo „jen“ jiných složkách. 77TB za 10 dnů – ok, ale je to tak vždy? Třeba to je jen nějaké slabší období nebo naopak silnější, kdo ví? Předpokládám, že nějaké zálohování tam mají, ale prostě nepočítalo s právě touto eventualitou.
      Jo a těm NAS: mrkněte na konfiguraci té bestie. Fakt myslíte, že by zálohování toho drobečka daly NASky za 400€? A druhý pohled, ta mašina má makat, ne zálohovat, proč „plýtvat“ cenným výkonem na zálohy?
      Další věc, čas: páska má 30TB, rychlost 750MB/s, to je asi 12 hodin jedna páska, potřebujete víc než dvě. Opět, nedělal byste skoro nic jiného, než zálohoval. U těch NASek, kterými jste se úspěšně ztrapnil, je to ještě horší, ty mají mnohem menší přenosovku.

      • „Smazala téměř všechny soubory starší deseti dnů“ = vsetky subory, v celom pocitaci okrem poslednych 10 dni. A nemyslim, ze by bolo vhodne zalohovat to na 400€ NAS, ale principialne by to islo, ked mam 77 TB dat a 4x20TB disk)

        • Jenže ona ta záloha většinou jedna nestačí, zálohy musíš rotovat, takže tohle asi fakt neklapne. Navíc je tu další problém, který už nastínil Libb – rychlost. Přenést taková kvanta dat je problém, tady už narážíš nejen na rychlost síťových rozhraní, ale typicky i rychlost diskových rozhraní.

  2. To budou nejspíše data pouze pro ten Cray, tzn. budou tam probíhat nějaké složité a časově náročné výpočty.
    A data skutečná budou na ostatních serverech a ty nejspíše budou v pohodě.
    Ale ty výpočty se budou muset udělat znova.

  3. Koukám že mazání souborů není na těchto systémech zrovna moc efektivní když trvalo dva dny. viz „Smazala téměř všechny soubory starší deseti dnů, což počítači trvalo asi dva dny. “ Za dva dny si nikdo nevšiml, že mu chybí soubory. Asi moc důležité nebyly. 😀

    Možná tohle byla jenom taková bouře ve sklenici vody. Ale i tak tohle je dosti na pováženou „To mělo za následek opětovné načtení upraveného shellového skriptu uprostřed jeho provádění, což vedlo k nedefinovaným proměnným.“

    • Pokud procházíš megakrutopřísnohustě velké úložiště (velmi pravěpodobně tierované) se ziliony souborů a promazáváš selektivně podle stáří, tak ano, to bude trvat dlouho.

      Dát si do souvislosti chybnou implementaci skriptu a postupně mizející soubory v multiuživatelském systému taky není úplně triviální.

      Hovada jsou v tomto případě jednoznačně HPE, protože zvrzali implementaci, zřejmě neměli vůbec change management (nebo byl jen na papíře) a hlavně práci skriptu nelogovali a nikdo to nemonitoroval, což je při takovém nasazení naprosto klíčové.

      • Tohle jednoznačné vidění nemám.
        Jako hovado číslo jedna bych spíše viděl tvůrce systému který umožnuje za chodu podvrhnout jiný změněný skript a vůbec mu to nevadí. O to více to ale může vadit uživatelům. Ty kluky z HPE bych spíše viděl jako hovada až ve druhé řadě že tohle nevědí a s takovou variantou nepočítají.

          • No ale tohle je o programování a ne o tom co může nebo nemůže dělat root a o tom co umí a neumí programátor skriptu.

            Tím jste mne přivedl k tomu, že svůj díl stupidity na tom má i architekt který zvolil skript jako nástroj pro tvorbu tohoto řešení namísto programování v programovacím jazyku který by si tohle ohlídal.

            • ehm… Bash je integrální součást moderních unixů, ostatně až donedávna v něm byla napsána dobrá půlka každé distribuce a root každého systému by bash měl zvládat a ovládat, alespoň na základní úrovni.
              A vysvětluj to třeba Microsoftu, který před pár lety pochopil sílu skriptování a příkazové řádky a uvedl powershell, což je taková neumělá kopie bashe pracující s binárními daty a API (dědictví Windows). 😉 Síla unixu je mj. právě v široké míře customizovatelnosti, do které patří právě i ty skripty (nejen v bashi, ale třeba i pythonu nebo perlu). To s binárkami nikdy nedosáhneš, takové míry flexibility a svobody.

            • Jo Microsoft. Byl jsme zvyklý na RSX nebo VM/CMS a proto když přišel Microsoft s příkazovým řádkem tak to bylo jako rána mezi oči. Naštěstí se pak MS inspiroval a pracoval ne jen na GUI ale i na příkazovém řádku což jsme my sytémáci či admini ocenili.

              Tohle skriptování je prostě hlavně na ušetření práce správců. Na komplikovanější a systémové náročné aplikace denní operativy je prostě klasický kód z kompilátoru a ne skript což si Hoši od HPE neuvědomili. Klasický kód je náročné vytvořit ale běží rychleji a zajištuje právě tuhle integritu. Ta svoboda u klasického kompilátoru je taky ale je vykoupena psaním hodně velkého množství kódu a množstvím znalostí. Něco za něco.

  4. A technická: ta vyjádření HP mi nedávají smysl. Kromě takové nepodstatnosti, že to nebyl „software“ ale „skript“ (naprasený za vlastního běhu (!)), jsem nepochopil to mazání „logů.“ Schválně jsem se kouknul i na zdroj, tam je to napsané úplně stejně blbě. Nedává smysl, aby výmaz aktivních logů „zrušil“ samotnou zálohu. Takže to pravděpodobně bylo asi vše trochu jinak, respektive došlo k výmazu možná metadat, potřebných k práci s daty, případně ony „logy“ byly defacto vlastními výstupy výpočtů a tedy daty onoho superpočítače, nebo zde došlo k efektu tiché pošty a výsledné mediální vyjádření je zcela zavádějící a skript jednoduše promazal běžná data místo adresáře s logy.

    • V podstatě to je narušení integrity mezi skripty „To mělo za následek opětovné načtení upraveného shellového skriptu uprostřed jeho provádění, což vedlo k nedefinovaným proměnným. “

      Tohle je pak vlastně i neotestovatelné. Pochybuji totiž jestli je vůbec možné napříč celým systém zjistit jestli někdo někde nemá spuštěný nějaký skript z uvedeného zdrojového souboru.

      • Tohle není vůbec žádný problém. Kdo kdy něco napsal v bashi, tak tyhle zákonitosti zná – subshelly, globální, lokální proměnné. Já třeba podobným způsobem měním konfiguraci jednoho svého „mediálního“ skriptu aka démona, který tak není nutno přerušovat a díky tomu vše neustále běží bez přerušování a viditelné rekonfigurace.

        Problém vidím ve vyjádření HPE, protože nedává smysl.

        • Pokud změnili nějakou dynamicky načítanou část skriptu, pak by právě vyjádření „Kromě funkčního vylepšení skriptu byl pro zlepšení viditelnosti a čitelnosti změněn název proměnné předávané příkazu find pro smazání“ dávalo smysl – předali nový parametr subskriptu, kterýžto ale ne[o|u]pravili a onen subskript očekával parametr se starým názvem a spustil find s cestou „/LARGE0/“, namísto třeba „/LARGE0/log/“, kde právě část cesty „log/“ mohlo být předáváno v inkriminovaném parametru („/LARGE0/$SUBPATH“)…

          • to chápu, nicméně pokud jsou logy v /LARGE0/log, jak je možné, že došlo dle textu ke smazání logů v /LARGE0, když jsou přece jinde? Navíc logfile je čistě utilitární věc, ne něco, z čeho se budeš střílet, když o to přijdeš.

            • Skript měl mazat původně v /LARGE0/log rekurzvině, ale začal, též rekurzivně, mazat v /LARGE0, kde byly další podadresáře, třeba ./SCIENCE_DATA atp…

        • No jak se v tomhle případě ukazuje tak to problém je. Právě proto že ne všichni si tohle uvědomují. Jen tak mimochodem já bych dopadl stejně jako hoši od HPE. Byl jsem zvyklý, že skript mi tohle za běhu neudělal. Nemohl jsem ho změnit. Bash a Linux je pro mne terra icognita a proto mne tahle informace, že je to v tomhle světě normální hodně zaskočila.

          Mám pocit, že v HPE použili na šroubky kladívko a takhle se jim to vymstilo. 🙂

  5. Možná by stálo za to článek doplnit o pár informací, například že se ztratila pouze data z úkolů řešených na onom jednom superpočítači od 3. do 16. prosince, že ze čtrnácti výzkumných okruhů jich deset lze obnovit z jiných záloh (takže jen čtyři se ztratily definitivně) a že celkový objem záloh na Todai je asi 25 PB, takže tamní admini nejsou žádní pitomci 😉