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

jfila

Kombinování SSD a HDD úložiště
« kdy: 10. 08. 2024, 06:50:57 »
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. Ideálně aby to bylo možné provozovat na OpenWRT. Jistě už se něčím podobným musel někdo zabývat, NAS pro ukládání dat, pořídit velké SSD je moc drahé a než nastartují disky v raidu, tak to nějakou dobu trvá. Jedná se o server pro zálohování fotek a dalších souborů pro jednotky uživatelů. Tj. většinu času se nic neděje, ale když uživatelé něco potřebují, tak to musí být rychle, maximálně hledání staré fotky je akceptované krátké čekání. Uživatelé jsou zmlsaní Google Fotkami, ale nechce se jim platit předplatné. 😁


alex6bbc

  • *****
  • 1 689
    • Zobrazit profil
    • E-mail
Re:Kombinování SSD a HDD úložiště
« Odpověď #1 kdy: 10. 08. 2024, 09:38:18 »
bcache

alex6bbc

  • *****
  • 1 689
    • Zobrazit profil
    • E-mail

Re:Kombinování SSD a HDD úložiště
« Odpověď #3 kdy: 10. 08. 2024, 09:49:53 »
https://www.phoronix.com/news/MTM4ODA
Pro ty, co je, jako mě, zmate slovo news v URL. Je to 11 let starý článek. A třeba zmiňované EnhanceIO má poslední update před 9 lety.

Re:Kombinování SSD a HDD úložiště
« Odpověď #4 kdy: 10. 08. 2024, 09:52:25 »
Tohle dělával Seagate. Notebooková řada Medalist XT, na eshopech to bývalo značeno jako SSHD. První generace velmi rychle odcházela, a i pozdější generace hodně trpěly na selhání SSD části, po čemž jinak fungující disk nebyl schopen ani číst.
Kromě toho to moc nefungovalo, na SSD to drželo většinou úplně špatný soubory kam se sice často psalo nebo četlo, ale přitom u nich nezáleželo na latenci, zatímco soubory u kterých na latenci záleželo a chodilo se do nich míň, to dávalo na 5100rpm plotnu bez dalšího cachování. Takže počítač byl pomalej a navíc to brzy zdechlo.

U tohohle řešení je problém, jak tomu říct, který soubory / bloky fakt potřebuješ držet na rychlý části. Protože časový razítko a statistika přístupu pořád nepodchytí, jak moc u toho konkrétního souboru / bloku záleží na latenci. 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, přestože ti na jeho latenci záležet vůbec nebude, a byl bys na tom líp kdybys ho cachoval do RAM a jednou za čas vylil na pomalou plotnu velkej kus.
A tenhle problém tam budeš mít vždycky.

Jasně, pomůže to, a to tím víc, čím to SSD bude větší. Ale míň problematickej výsledek získáš, když se naučíš data ukládat sám na různý tiery úložiště podle jejich priority.

Jestli jsou užiatelé zmlsaní googlefotkama, nejlíp udělají když si zaplatí na googlu velkou kapacitu, tam si je nechají analyzovat, oindexovat, a rozházet do alb, a pak si ta hotová alba přetáhnou do Synology. BUdou s tím mít míň práce, než si ve fotkách dělat pořádek sami ručně. Protože jestli to dělat ještě nezačali, nezačnou s tím nikdy.
« Poslední změna: 10. 08. 2024, 09:55:30 od Marek Staněk »


Zopper

  • *****
  • 808
    • Zobrazit profil
Re:Kombinování SSD a HDD úložiště
« Odpověď #5 kdy: 10. 08. 2024, 09:58:53 »
True story, jedno SSHD jsem měl a reálně to na výkonu nebylo moc poznat, jen to stálo víc, než srovnatelný klasický HDD. Tenhle nápad (obzvlášť v consumer segmentu) umřel z dobrého důvodu.

jfila

Re:Kombinování SSD a HDD úložiště
« Odpověď #6 kdy: 10. 08. 2024, 10:48:59 »
Úložiště už mám, 5TB ve RAID a SSD 256 GB, kupovat SSHD se mi nechce a myslím si že by bylo lepší to realizovat už na úrovni systému, kde se ví o jaký soubor se jedná. Viz příklad s logy atd. Ideálně aby to bylo transparentní, aby aplikace nad tím nic nepoznaly, ale soubory byly na dvou discích /mnt/SSD a /mnt/HDD a čitelné třeba pro Sambu. Nad tím poběží něco stylu NextCloud, ten by byl nasměrován na /mnt/SSHD.

Zopper

  • *****
  • 808
    • Zobrazit profil
Re:Kombinování SSD a HDD úložiště
« Odpověď #7 kdy: 10. 08. 2024, 11:46:00 »
Pak my to možná šlo udělat přes overlayfs jako spojení těch HDD a SSD selektivně podle adresáře. Ale jestli to SSD je jen jedno, tak to nebude v RAIDu.

Wasper

  • ***
  • 124
    • Zobrazit profil
    • E-mail
Re:Kombinování SSD a HDD úložiště
« Odpověď #8 kdy: 10. 08. 2024, 23:33:40 »
Doma pouzivam uz delsi doby kombinaci SSD a HDD v klasickem mdraidu (mirror), placka je v modu Write-Mostly, a chova se to velmi uspokojive.

Sice jsem zkoumal bcache přes dm, ale nikdy jsem nenašel odvahu to zkusit (na rozdíl od flash cache v ESXi6.x, kde se to chovalo poměrně dobře to alespoň podle RTFM nepřežije pád toho SSD, což mě odradilo od experimentů)

Wasper

  • ***
  • 124
    • Zobrazit profil
    • E-mail
Re:Kombinování SSD a HDD úložiště
« Odpověď #9 kdy: 10. 08. 2024, 23:37:46 »
Tohle dělával Seagate. Notebooková řada Medalist XT, na eshopech to bývalo značeno jako SSHD. První generace velmi rychle odcházela, a i pozdější generace hodně trpěly na selhání SSD části, po čemž jinak fungující disk nebyl schopen ani číst.
Jo, přesně. Měl jsem Firecudu, představoval jsem si od toho zrychlení přístupu a pořádně nepročetl dokumentaci. Jaké bylo moje překvapení, když jsem zjistil, že jde o velmi pomalý SMR kam přidali docela málo (už si to nepamatuju, nižší desítky giga?) flashe čistě proto, aby to nebylo tak tragické už na první pohled. Ale třeba jen instalace ne úplně AAA hry ze Steamu pak klidně trvala několik hodin.

Re:Kombinování SSD a HDD úložiště
« Odpověď #10 kdy: 11. 08. 2024, 00:02:10 »
Pokud jde o akceleraci čtení, prostě použijte ZFS a SSD dejte jako L2ARC cache..

Re:Kombinování SSD a HDD úložiště
« Odpověď #11 kdy: 11. 08. 2024, 14:32:13 »
Jde hlavně o rychlost čtení, rychlost zápisu je vedlejší?

Od toho se bude totiž odvíjet architektura:

a. Na HDD je vždy všechno podstatné, SSD slouží jen jako cache. (Možná by stačilo na SSD hodit nějaké indexy, ne samotné fotky.) Když odejde SSD, nepřijdete o žádná data. Na druhou stranu, když zapisujeme, je nutné počkat, až se to zapíše na HDD.
b. Na HDD nemusí být všechno podstatné, nebo až se zpožděním. To přinese vyšší rychlost zápisu, ale zároveň vyšší křehkost – jakmile odejde SSD, na HDD nemusí být všechna data, ne nebo nemusí být vždy konzistentní.

Tady mimochodem může být ukrytý i ten důvod, proč to SSHD od Seagate po poruše té SSD části nedovolí ani číst z HDD.

Re:Kombinování SSD a HDD úložiště
« Odpověď #12 kdy: 11. 08. 2024, 16:20:18 »
Tady asi těžko říct bez nějakého zkoušení na konkrétní aplikaci a hardware.
Jsou nějaké nástroje, co se dají na určitou funkcionalitu použít v systému např. blokové cache: bcache, dm-cache či mergerfs s specifickým nastavením. Nebo jak už tu zaznělo ZFS s persistentní L2ARC.

Otázkou zůstává, co to reálně přinese a jaká jsou i případně rizika.
Obecně vzato ty požadavky jdou přesně proti sobě, na jednu stranu levný hardware, energeticky nenáročný (standby na discích), nějaká mini distribuce a proti tomu za okamžitá dostupnost dat, ukládání s redundancí. To je vždycky trochu oříšek, který se nemusí povést rozlousknout.

Ty blokové cache můžou na určité workloady fajn, ale není to rozhodně všelék a někdy to může přinés víc problémů, než to má řešit. V principu to běží na vrstvě pod FS, do struktur FS a už. dat nad tím to nemá přístup. Navíc i provozně obě zmíněné implementace můžou být eufemisticky řečeno - temperamentní. Zvlášť v situacích, kdy nastane třeba byť dočasný problém s blokovým zařízením, kde je cache.

ZFS je samozřejmě další možnost, můžete použít SSD na L2ARC cache, ale opět strašně záleží na workloadu, jestli vám to výrazně pomůže. Je to vymyšleno primárně na cachování krátkých bloků dat a metadat souborového systému. Pokud tyto  nejsou v ARC (cache v RAM), pak se použije L2ARC, a když to tam není, pak to teprve jde do disků. U sekv. čtení typicky dřív zafunguje readahead, který data načítá dopředu z disků do ARC a L2ARC (SSD) se nepoužije. Tohle se dá do jisté míry ladit, ale stejně to základní určení a princip zůstává. Není to řešení na to, abyste si tím nahradil plnohodnotný tiering, který ZFS nemá.
Samozřejmě ZFS může přinést nějaké další výhody, kdy to nahradí mdraid, má to vestavěnou kontrolu integrity dat, snapshoty, možnost nastavení různých parametrů datasetů podle potřeby atp. Ale i nevýhody, rozhodně to není v každé Linux distribuci, vyvíjí se to jako out-of-tree modul odděleně od jádra. OpenWRT to standardně nemá, nejbližší minimalistická distribuce se ZFS ve svých standardních repozitářích je asi Alpine. Navíc aby to slušně chodilo, tak je záhodné mít dost RAM, právě na tu ARC, aby tam byly nějaké benefity. Což pokud máte nějakou danou konfiguraci otevírá otázku, jestli je výhodnější tu paměť v systému nechat použít aplikace (Něco..cloud, PHP, databázi se svým interním bufferem), nebo to nechat filesystému.

Každopádně v obou případech (bloková cache, ZFS) byste logicky musel zazálohovat všechna data, přeformátovat všechny disky a pak laborovat.
Taky bych si od žádného z těch řešení nesliboval, že vám to vyřeší tu úvodní prodlevu, když se uspí disky. Stačí, že ta aplikace udělá jedinou blocking I/O operaci z těch disků a stejně čekáte, klidně i desítky vteřin.
U těch blokových cachí bych si taky spíš tipnul, že budete čekat, než se proberou všechna zařízení.




Re:Kombinování SSD a HDD úložiště
« Odpověď #13 kdy: 11. 08. 2024, 16:21:00 »
Osobně bych se za daných podmínek spíš mrknul přímo na ten OwnCloud/NexCloud, nebo co tam máte. Přiznám se, že jsem to viděl hodně z rychlíku a před pár lety. Nicméně si dovedu představit, že když se selektivně rozdělí umístění některých částí mezi SSD a pomalejší RAID, případně se to zkusí ještě optimalizovat, tak by to mohlo s odezvou pomoct.
Co mě z hlavy napadá, tak ta aplikace ve výchozím nastavení používá sqlite, ale dá se to změnit a zmigrovat na MySQL. Ta může mít soubory uložené rovnou na SSD. Nejen, že jen tohle by mělo být rychlejší, při víceuživatelském přístupu (který je v MySQL nativně), ale dá se dál docela poladit bufferování tak, aby databáze primárně obsluhované z paměti, pokud se tam vejde. Tím, že tam jsou všechna metadata, mělo by se to projevit. Případně ještě vyzkoušet co třeba udělá s aplikací přidání a zapnutí APCu v PHP.

Další věc z hlediska fotek je umístění složky, kam se generují náhledy, ta by také mohla být na SSD.
Podobně i nějaké "staging" adresáře, kam třeba putují větší uploady, než se přeskládají do finálního umístění.
Teoreticky by to mělo jít někde nastavit, případně rsyncnout data (např. s náhledy) na SSD, a udělat symlinky a ozkoušet jak se to bude chovat.

Pokud by pak podobné optimalizace případně pomohly, zamyslel bych se nad tím, zda ještě nezainvestovat do druhého stejně velkého SSD, abych měl mirror, jestliže by na něm byla databáze.

Teď koukám, že podobné myšlenky má i v6ak výše :)

Re:Kombinování SSD a HDD úložiště
« Odpověď #14 kdy: 11. 08. 2024, 20:08:14 »
K těm příhodám se Seagate SSHD: Mám tu relativně málo jetý 2,5" 1TB SSHD Seagate FireCuda (ST100LX015). A povím vám hned, proč je to taková shitka a na v podstatě žádné výhody té flash části nenarazíte: Je to totiž šindelka.

Pokud SMR disky znáte, tak víte, že je v nich velká část typu SMR, ale taky poněkud menší část typu CMR o kapacitě několik GB, která se používá pro dočasný zápis dat, která aktuálně nelze zapsat do SMR zón, protože by je to rozbilo. Zápis na různá náhodná místa na šindelový disk připomíná zápis na SSD, protože data jdou na disk bez zdržení mezi přesuny hlav na ta náhodná místa - prostě se to zapíše dočasně všechno za sebou a když má disk čas, tak si to z těch CMR zón rozháže, kam to patří, a při tom si dává pozor, aby opravil všechno v těch SMR zónách, co se tím poničí.

No, a v těchdle SSHD discích je tam místo těch CMR zón prostě ta flashová část, to je celá věda. Nehraje se tam na žádné „sesypávání nejčastěji používaných souborů na flash část“, to kolikrát bývá jen shoda náhod z důvodu principu práce se šindelovým diskem.

Jiným slovy: s takovýmto SSHD úložištěm budete typicky zapisovat na flash část a číst z ploten. Žádný rychlý přístup k datům, „protože tam je kousek SSD“, se nekoná.

Tyhle maličký SSHD šindelky nepoužívají flash část, aby urychlovaly přístup k datům, to je marketingový krasožvást. Používají to proto, aby kompenzovaly nevýhody šindelových disků. Na klasických šindelových discích se musí data přehazovat mezi CMR a SMR zónami, na těchdle SSHD šindelkách to jde mezi SMR a flash. O něco rychlejší než šindelka bez flash části, ale pořád je to zapráskaná šindelka, na kterou OS nepatří. Tyhle disky nebrat.