Fórum Root.cz
Hlavní témata => Server => Téma založeno: jfila 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é. 😁
-
bcache
-
https://www.phoronix.com/news/MTM4ODA
-
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.
-
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.
-
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.
-
Ú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.
-
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.
-
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ů)
-
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.
-
Pokud jde o akceleraci čtení, prostě použijte ZFS a SSD dejte jako L2ARC cache..
-
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.
-
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í.
-
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 :)
-
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.
-
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…
-
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.
-
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 (https://blog.frantovo.cz/c/393/). 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í.
-
...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.
-
...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.
-
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.
-
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í.
-
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.
-
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…
-
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 :)
-
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…
-
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 (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 (https://www.redhat.com/en/blog/improving-read-performance-dm-cache)