Kombinování SSD a HDD úložiště

[Vít Šesták (v6ak)]

No, jestli to SSHD zapisuje všechno prvně do nevelké flash paměti, tak bych fakt nečekal velkou životnost. Snad jediná výhoda oproti HDD může být rychlý zápis.
Ano, bude-li minimum zápisů, SSHD může přežít dlouho, ale zároveň ta výhoda rychlého zápisu ztratí na důležitosti…

[Reklama]

[Michal Šmucr]

SSHD byly vždycky strašná pomsta, když jsem pracoval na nějakém cizím notebooku, all-in-one stroji. Měli jsme jich pár starších ve firmě a sem tam to někdo donesl na opravu z domova. Bavíme se o 2,5" verzích, většinou 8GB flash a za tím 5400 disk.
Nechodilo to rychle téměř za žádných okolností, instalace a aktualizace byly vždycky na umření. To už byly lepší klasické CMR 7200 disky. Pokud to šlo, tak jsem to pak už rovnou měnil za nejlevnější Kingston SSD a šlo to do koše.

Navíc pro úložiště je to taky nesmysl, nejen že to nic nehodí, ale díky svým vlastnostem s tím nepredikovatelným remapováním se to nedá dát ani do RAIDu, který by se jen permanentně rozpadal.

[Franta Kučera]

Existuje například nějaký jaderný modul, který dokáže kombinovat dvě úložiště, typicky SSD a HDD a využívat výhody obou? Sledoval by které soubory se nejčastěji používají a ty by uložil na SSD a méně používané či hodně staré bylo uložil na HDD? Moje představa je něco mdadm. …

Taky jsem tohle řešil, psal jsem o tom tady: Hybridní diskové pole: RAID 1 s HDD a NVMe SSD. Různé moduly do jádra existují… ale problém je v tom, že to rozložení na SSD/HDD se těžko automatizuje. Frekvence přístupů k souborům totiž nesouvisí s požadavky na rychlost prakticky nijak. Když např. otevřu složku s pět let starými fotkami, ve které jsem několik let nebyl, tak chci, aby se mi ty náhledy načetly rychle. Naopak když budu mít nějaký oblíbený film, který si pouštím často, tak u něj mi na rychlosti nezáleží (stačí, aby se plynule přehrával, což zvládne i pomalý HDD). Takže než abych vymýšlel něco komplikovaného, nakonec jsem koupil NVMe stejně velký jako HDD a dal je do RAIDu 1 s tím, že jádro bude číst přednostně z NVMe, tudíž čtení bude rychlé a zápis na úrovni HDD.

Dá se vymyslet ledasco, původně jsem zvažoval jednak to automatické řešení (bcache, dm-cache, Flashcache, lvmcache…) a jednak ruční s tím, že bych ty soubory rozhazoval mezi NVMe a HDD RAIDem 1 a pak to spojil dohromady přes nějaký overlay, symlinky nebo mount + zálohoval snapshoty z NVMe na RAID… ale čím složitější to bude, tím je větší riziko, že se něco pokazí.

[jjrsk]

...Takže když budeš třeba zapisovat syslog a poteče ti do něj hodně dat, na základě statistiky ti vyjde jako absolutně prioritní, a sežere velkou část kapacity...

Az na to, ze takhle cache nikdy a zadna nefunguje.

Prevazne to funguje tak, ze ti vsechny zapisy miri primarne do cache, samozrejme az do pro ten ucel vyhrazene kapacity, a pak se to pomalu napozadi zapisuje na disk. Uplne stejne jako ram. A v cache se udrzuji data, ke kterym se casto pristupuje na cteni.

Funguje to tak desitky let na vsech urovnich a zadny problem s tim neni.

[Marek Staněk]

...Takže když budeš třeba zapisovat syslog a poteče ti do něj hodně dat, na základě statistiky ti vyjde jako absolutně prioritní, a sežere velkou část kapacity...

Az na to, ze takhle cache nikdy a zadna nefunguje.

Prevazne to funguje tak, ze ti vsechny zapisy miri primarne do cache, samozrejme az do pro ten ucel vyhrazene kapacity, a pak se to pomalu napozadi zapisuje na disk. Uplne stejne jako ram. A v cache se udrzuji data, ke kterym se casto pristupuje na cteni.

Funguje to tak desitky let na vsech urovnich a zadny problem s tim neni.

Až na to, že SSHD jinou, než tu flash cache, do který se posílají všechny zápisy a ze který se to pak lije na plotny, jednoduše nemá. Ještě jednou zopakuju: žádná DRAM cache tam není. Takže v tý flash má jen to, co se naposled zapisovalo, i když ve zpravidla větším objemu, než byla u non-flash-cached disku se stejnými plotnami DRAM (konkrétně 500GB Medalist XT měl 32MB flash cache, 500GB Medalist bez XT měl 8MB DRAM). V poslední generaci měl 1TB XT flashcache 8GB, a i když leták tvrdil, že analyzuje provoz a drží tam i soubory ze kterých se často čte (což by znamenalo její dělení na zápisovou a čtecí), na výsledcích se to vůbec nijak neprojevovalo.

[Reklama]

[Vít Šesták (v6ak)]

Z druhé strany, jakkoli je tu validní kritika použití flash paměti jako writeback cache (rychlé opotřebení a špatné zacílení cacheovaných dat), neznamená to, że i jiné přístupy k cache na SSD jsou automaticky marné. Svého času tu byl Intel Optane. Dnes asi není moc relevantní, ale mám za to, že to bylo tak nějak funkční řešení, které si někteří chválili. Tím neříkám, že Optane je ta správná cesta (dnes nejspíš ne), ale že ten problém může být řešitelný i nějakou vhodnou automatikou. I když bych v tomto případě stále dal přednost rozumnému ručnímu rozdělení, protože bude predikovatelnější a protože mi přijde reálné něco rozumného vymyslet.

Hádám, že zápis tu není z hlediska výkonu nic kritického, fotky jsou relativně velké soubory a bottleneck bude spíš síť. (To z SSHD s writeback cache zde dělá nejspíš naprosto useless věc…) Bude spíš podstatné rychlé čtení. A ne nutně všeho (u fotek v plné velikosti bude nejspíš pomalost HDD relativně zakryta pomalostí sítě). Stále si myslím, že jde hlavně o databázi nebo její index. Možná ještě náhledy. Tím necháme tu nejobjemnější část (fotky v plné velikosti) na HDD a zároveň část náročnou na rychlost můžeme přesunout na SSD.

[Michal Šmucr]

I když bych v tomto případě stále dal přednost rozumnému ručnímu rozdělení, protože bude predikovatelnější a protože mi přijde reálné něco rozumného vymyslet.

Hádám, že zápis tu není z hlediska výkonu nic kritického, fotky jsou relativně velké soubory a bottleneck bude spíš síť. (To z SSHD s writeback cache zde dělá nejspíš naprosto useless věc…) Bude spíš podstatné rychlé čtení. A ne nutně všeho (u fotek v plné velikosti bude nejspíš pomalost HDD relativně zakryta pomalostí sítě). Stále si myslím, že jde hlavně o databázi nebo její index. Možná ještě náhledy. Tím necháme tu nejobjemnější část (fotky v plné velikosti) na HDD a zároveň část náročnou na rychlost můžeme přesunout na SSD.

Přesně tohle jsem myslel ve svém předchozím příspěvku.
Celá složka appdata v NC/OC, kde jsou uloženy i zmíněné náhledy, by se měla dát velice jednoduše přesunout na SSD. Stejně jako tam šoupnout datové soubory z MySQL. Oboje může tazatel jednoduše a relativně nedestruktivně vyzkoušet s rsyncem a pár symlinky. Stejně jako si následně hrát s laděním nastavení NC/OC podle toho, kolik má paměti.

Otázka je jak by to řešilo to probuzení HDD RAIDu ze standby (což může klidně trvat 20 sekund, než se to celé probere). U téhle varianty s rozdělením částí dat na SSD a HDD by záleželo, kdy i si na ten HDD sáhne. A jestli se náhodou nestane to, že pokud budou DB a náhledy na SSD, tak to překlene to dobu rozjíždění a nebude to pro uživatele subjektivně tak nepříjemné.

U ostatních navrhovaných možností, např. s tím SSD+HDD mirrorem a mostly write atributem (který je zajímavý) to podle mě moc řešení nemá, jakmile bude přistupovat k mirroru, musí obě zařízení být probuzené.
Takže pokud by se chtěl prodlevy úplně zbavit, asi nezbyde než ten standby vypnout a prostě se smířit s tím, že disky poběží 24/7. Což samozřejmě může stát něco navíc v provozu, i když to na malém serveru nebude nějaký zásadní majlant (třeba do 1 tis. ročně navíc) a bude to hučet, kde pak záleží na umístění.

[jjrsk]

Až na to, že SSHD...

Az na to, ze tu neni rec o rozbitych nefunkcnich kramech ktery sem tahate vi buh proc. Tazatel se ptal na kombinaci SSD+HDD a to je vec, ktera se naprosto bezne pouziva a naprosto bezproblemu to funguje. Nekolik multitier storage mam pod spravou osobne.

Provozovat SSD+HDD v zrcadle bych vrele nedoporucoval. Kazdou chvilu to lehne na tema disk neodpovida. Bude se to chovat velmi podobne jako sindele v raidu. Disky v raidu by mely mit vzdy +- stejne latence.

[Vít Šesták (v6ak)]

Jo, probuzení může být hlavní problém, pokud to nebude v nižších jednotkách sekund. Nicméně počítání nákladů mě vede k jiné otázce – opravdu pak vyjde ve výsledku HDD levněji?

Dejme tomu, že by i nějaké levné SSD udělalo dobrou službu. Záleží samozřejmě na kapacitě, vytížení apod. Mrkl jsem se na Alze na ~2TB+. SSD (nová) začínají někde na cca 2800 CZK, HDD kousek nad 1500 CZK. To je 1 300 CZK rozdíl. Pokud budeme disk udržovat stále v pohotovosti, asi bude mít cca konstantní spotřebu, nehledě na zatížení. Při velkém vytížení ten rozdíl může vyjít i ve prospěch HDD, při malém vytížení ale SSD bude mít většinu času spotřebu blízkou nule, zatímco HDD bude žrát v jednom kuse…

[Michal Šmucr]

Jo, probuzení může být hlavní problém, pokud to nebude v nižších jednotkách sekund. Nicméně počítání nákladů mě vede k jiné otázce – opravdu pak vyjde ve výsledku HDD levněji?

Dejme tomu, že by i nějaké levné SSD udělalo dobrou službu. Záleží samozřejmě na kapacitě, vytížení apod. Mrkl jsem se na Alze na ~2TB+. SSD (nová) začínají někde na cca 2800 CZK, HDD kousek nad 1500 CZK. To je 1 300 CZK rozdíl. Pokud budeme disk udržovat stále v pohotovosti, asi bude mít cca konstantní spotřebu, nehledě na zatížení. Při velkém vytížení ten rozdíl může vyjít i ve prospěch HDD, při malém vytížení ale SSD bude mít většinu času spotřebu blízkou nule, zatímco HDD bude žrát v jednom kuse…

Bral jsem to tak, že jemu asi primárně šlo o pořizovací cenu. Tazatel psal, že má teď 5TB RAID s HDD a 256 GB SSD, z čehož usuzuji, že by asi nechtěl jít do 2TB SSD, to už je vcelku výrazný rozdíl kapacity. Když si to vztáhnu na používání, co vidím okolo sebe, tak 2TB je prd. Foťáky v mobilu dělají velké jpegy, lidi točí videa, telefon má bez problémů 256GB úložiště - pokud tohle někam odlívá 5-6 lidí, už to chce nějakou kapacitu.
Řekněme, že pokud by ještě skousl snížení na 4 TB, tak je to pořád v mirroru 12-15 tisíc, podle toho jaké koupí SSD. Samozřejmě bylo by to rychlé a relativně úsporné.

Když mu bude stačit zmíněná optimalizace OC/NC a případně si přidá další 256 GB SSD, aby měl mirrorovaná všechna data, tak tam bude třeba za 800 korun.
Točivé disky nemají konstantní spotřebu, mají asi 4-5 W v idle a do 10 W v seeku podle modelu. SSD má v idle klidně i pod Watt. Takže když bych to vzal všechno dohromady (jedno SSD navíc a případné vypnout usínání), tak by rozdíl oproti stávajícímu setupu mohl být třeba okolo 10 W. Nevím přesně, ale odhadoval bych to tak na 500-700 korun ročně navíc.. podle tarifu.
Navíc pokud to nastaví tak, že budou v pohodě s odezvou a vejdou se na SSD s metadaty a náhledy, může pak vcelku jednoduše dál kapacitně rozšiřovat třeba na dvoj-trojnásobek jenom tím, že bude měnit ty točivé disky, což by v setupu jen s SSD vyšlo pořád na docela dost.

Ale nic, přemýšlím už asi trochu za roh

[Vít Šesták (v6ak)]

Jo, neviděl jsem tu požadovanou kapacitu. I když, od oka si říkám, že by to mohlo na celkových nákladech vyjít zhruba šul nul. Záleží samozřejmě na hromadě parametrů, některé bude znát tazatel (vytížení) a některé nikdo (vývoj ceny elektřiny).

Idle – predpokladám, že je tím myšlena situace, kdy se HDD točí, ale nemá nic na práci. Kdyby se netočil, čekal bych typickou spotřebu < 1W. OK, překvapil mě takový vliv seeku, na druhou stranu, rotace jede z velké části ze setrvačnosti, což snižuje potřebnou energii. Seek ze setrvačnosti moc těžit nemůže…

[Ondřej Vaniš]

Používám SSD jako cache pro software raid-5 se 4mi rotačními disky a na výkonu to znát určitě je.
Takže za vyzkoušení to stojí.
Je to modul pro LVM (dm-cache)
Myslím že jsem postupoval podle tohoto:
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_logical_volumes/enabling-caching-to-improve-logical-volume-performance_configuring-and-managing-logical-volumes

Zajímavé čtení včetně performance grafů:
https://www.redhat.com/en/blog/improving-read-performance-dm-cache