Fórum Root.cz
Hlavní témata => Server => Téma založeno: CPU 02. 12. 2023, 10:19:53
-
Ahoj,
pro jednoho spořivějšího kamaráda potřebuji poměrně dost rychlé úložiště.
O co se jedná:
- cca 15 málo náročných Widlo Serverů
- cca 50 málo náročných Debianích serverů
Virtualizace je na VMware 7, aktuální storage je připojená přes iSCSI a asi bych u ní rád zůstal.
Aktuálně to má na QNAPu, prostý RAID5, který to tak nějak zvládá, pokud se nepustí hodně věcí naráz (třeba aktualizace na všech strojích naráz a podobně).
Z důvodu cenové úspory jsem přemýšlel o nahrazení QNAPu serverem se ZFS:
- 2x10core CPU jednak kvůli L3 a jednak kvůli možnosti osazení paměťových modulů
- 384 GB RAM (hodně kvůli ARC cache)
- 2x SSD 400 GB pro L2ARC (prý není nutný RAID, selhání prý není zásadní problém)
- 3x mirrorovaný SLOG
- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)
Já osobně bych to hodil na Debian, ale slyšel jsem názory, že TrueNAS se ZFS si povede lépe a bude to mít pohodlnou administraci. Pak mi to poplival i kamarád, že mám použít CEPH, protože se ZFS bude bolest zaručit HA (byť teď taky není). Pak mi to poplival další kámoš, že místo RAID5 mám použít 3+3 disky na dva Datasety, že jeden by byl pomalejší než RAID5, ale po rozdělení to bude čistší.
Budu rád za vaše poznámky, pokud povedou správným směrem...
-
Muzete pouzit TrueNAS Scale, coz je nova generace TrueNASu postavena nad Debianem.
Co jsem se tak dival, kolegove davaji prednost raid10 pred raid5 prave kvuli rychlosti.
-
Ted do me kamos huci, at to nedelam nad RAID. Že se otevřou dveře pekla, pozřou všechna moje data a já skončím v sekci pekla pro patlaly a PHPkáře... ::)
Já si uvědomuji, že to pak nebude škálovat, ale to nevadí. Naopak mi vyhovuje údržba na úrovni řadiče.
-
SCALE ne, maji na to hrani, vyhazeji spoustu standardnich funkci jako "too old for us" a pak to tam musi clovek lamat nazpet nebo cekat, az si to rozmysli. Je tam velky bonus u kontejnarizace, ale ten use case nediskutujeme.
ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"
Pocet core nebo L3 nema moc vliv. Hodne stare CPU - OK, typicky bazarovy Xeon 55x0 porad na 100% a zastropoval rychlost, a to nebylo sifrovani zapnuto.
Uzitecnost mega velke pameti bych neprecenoval, pokud to clovek nepouziva s deduplikaci. A zda se, deduplikaci dnes skoro kazdy vzdal. V kazdem pripade pri tehle velikosti RAM uz L2ARC toho moc neprinese.
FYI, co se tyka zapisu, ZFS kesuje do RAM neco jako "5 sekund transakci co prosly NIC". Prvnich 5 sekund zapis jede, co LAN da a RAM pojme, potom to spadne na rychlost zapisu tech koncovych disku.
Cele tohle nema smysl diskutovat a optimalizovat, pokud nemluvime NVME.
p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.
-
ve smyslu ze ten raid bude "transparentne" delat ten HW RAID radic? A TrueNas bude celou dobu videt "jediny vysledny disk"?
V tom pripade tahle diskuse nema dalsi smysl.
Ted do me kamos huci, at to nedelam nad RAID. Že se otevřou dveře pekla, pozřou všechna moje data a já skončím v sekci pekla pro patlaly a PHPkáře... ::)
Já si uvědomuji, že to pak nebude škálovat, ale to nevadí. Naopak mi vyhovuje údržba na úrovni řadiče.
-
Pokud chceš "HW" krabici tak o ZFS nebo Cephu nemá smysl uvažovat. Rychlostně slušné a levné bedny jsou od Huaweii (OceanStor).
Btw. ZFS bych stejně nikomu nepodoručoval, na malé věci je to celkem nevhodné a na ty větší zase neškálovatelné.
-
ve smyslu ze ten raid bude "transparentne" delat ten HW RAID
Ano a podle všeho to tak provozuje poměrně dost lidí a v podstatě ze stejných důvodů, které pro to mám já.
I run ZFS on top of HP ProLiant Smart Array RAID configurations fairly often.
Why?
https://serverfault.com/questions/545252/zfs-best-practices-with-hardware-raid
Moje důvody:
- vizuálni notifikace pri selháni disku, server začne blikat
- interní diagnostika začne hlásit problém
- jednotnà propagace závady
- okamžité nahrazeni disku pomocí volného SPARE + dostatečné zálohy
- RAID s 8GB cache zálhovaný baterkou a vylepšeným time-improved-NCQ
Všechno, co se použitím RAID5 pod ZFS stane nerelevantní, mi bud nevadí nebo je nahrazeno výhodou ve formě výkonu. A skutečně jsem nenašel nic kromě "použití RAIDu pod ZFS je jako chodit po ulici jen v tričku, bez kalhot a trenek...". No ano, přiznam se, že netuším, proc by to mělo být takové zlo.
AD L2ARC - tedy myslíš, že je při 284 GB zbytečná?
Deduplikace je IMHO k prdu, žere RAM a výsledky jsou "pochybné/neprůkazné".
-
Btw. ZFS bych stejně nikomu nepodoručoval, na malé věci je to celkem nevhodné a na ty větší zase neškálovatelné.
Huawei lidi děsí...a ředitelé nakupy nepodepisují. Jinak okolo mě lidé používají jak CEPH, tak i ZFS. Bohatší firmy samozřejmě věci jako Netapp nebo řešeni od Dellu (PowerVaulty s pod).
CEPH dnes tlači i IBM ve formě IBM CEPH STORAGE a ZFS dělá každý, kdo chce používat snapshooty.
Ale budu rád, pokud to rozvedete , právě ten ten CEPH jsem se chtěl do budoucna naučit, že je v něm budoucnost...
-
Místo konfigurace by jsi měl spíše upřesnit jaký potřebuješ datový tok po síti.
Množství virtuálních serverů znáš, kolik jich je fyzických jsi nenapsal.
Ani jsi nenapsal jaký provoz tím budeš zajišťovat, to je nějaký hosting, nebo firma se specifickými požadavky?
A cenový rozpočet?!
Velikost cache je nesmyslně velká, běžné RAID řadiče mají 4GB a zvládají to bez problémů, nicméně to pouze můj názor.
Toto se většinou staví na 40Gbit sítích apod.
A většinou se to staví na vysoké dostupnosti.
Ale jestli se jedná pouze o hračku, tak na to odpovědi nemám, tam jsi limitován pouze svými finančními možnostmi.
-
citujes snad jediny souhlasny nazor z veledlouhe diskuse, tohle root vlakno jen postupne zopakuje vsechny ty nesouhlasne komentare. jen konstatuji...
-blikani zavad, interni diagnostika... - jasne, uz jen to blikani vadneho disku je bolest, kdyz si to stavis doma. Ale to taky znamena, ze te jakekoli kontrolni mechanismy ZFS nezajimaji potoze nebudou blikat a navic stejne budou obchazeny).Ale co teda z toho ZFS zbude, co je teda pridana hodnota ZFS, ktery je proste silene pomaly kvuli vsem tem kontrolnim mechanismum, Snapshoty?
ve smyslu ze ten raid bude "transparentne" delat ten HW RAID
Ano a podle všeho to tak provozuje poměrně dost lidí a v podstatě ze stejných důvodů, které pro to mám já.
I run ZFS on top of HP ProLiant Smart Array RAID configurations fairly often.
Why?
https://serverfault.com/questions/545252/zfs-best-practices-with-hardware-raid
Moje důvody:
- vizuálni notifikace pri selháni disku, server začne blikat
- interní diagnostika začne hlásit problém
- jednotnà propagace závady
- okamžité nahrazeni disku pomocí volného SPARE + dostatečné zálohy
- RAID s 8GB cache zálhovaný baterkou a vylepšeným time-improved-NCQ
Všechno, co se použitím RAID5 pod ZFS stane nerelevantní, mi bud nevadí nebo je nahrazeno výhodou ve formě výkonu. A skutečně jsem nenašel nic kromě "použití RAIDu pod ZFS je jako chodit po ulici jen v tričku, bez kalhot a trenek...". No ano, přiznam se, že netuším, proc by to mělo být takové zlo.
AD L2ARC - tedy myslíš, že je při 284 GB zbytečná?
Deduplikace je IMHO k prdu, žere RAM a výsledky jsou "pochybné/neprůkazné".
-
Nikde nevidim kapacitu a pozadovane IOPS. Vystupem bude co? iSCSCI nebo NFS / SAMBA? A co hw/sitova topologie - na kolika hostech jsou ty VM?, je to vse v 10GbE klientech nebo ma storage 40GbE a mas pak agregaci na switchi ?
-
Ale co teda z toho ZFS zbude, co je teda pridana hodnota ZFS, ktery je proste silene pomaly kvuli vsem tem kontrolnim mechanismum, Snapshoty?
- Cena
- Snapshoty
- Replikace (až najdou nějaké prašule, chtěl jsem rozjet online replikace)
- Cache, především jsem chtěl velmi silný a robustní mechanismus Cache, který odbaví požadavky dřív, než probublají k poli (LARC, L2ARC atd.)
- nároky na IT obsluhu, protože i ňouma zvládne najít a vyreklamovat blikající disk
- chci využít poměrně výkonný řadič zálohovaný baterkou s velkou cachce
Naopak nepotřebuji:
- flexibilní a snadno rozšiřitelné pole
- selhání více disků se nijak extra nebojím
- používat podivné disky s určitou mírou chybovosti (všechno to jsou DC disky)
Možná zkusím výkon ZFS v režimu HBA a s CACHE...jde mi primárně o výkon.
-
Nikde nevidim kapacitu a pozadovane IOPS. Vystupem bude co? iSCSCI nebo NFS / SAMBA? A co hw/sitova topologie - na kolika hostech jsou ty VM?, je to vse v 10GbE klientech nebo ma storage 40GbE a mas pak agregaci na switchi ?
Na začátku jsou dva VMware hosty s ručním přepínáním VM, pokud se na některém hostu dělá údržba.
Stroje jsou připojené přes iSCSI, každý má svůj 10Gbps adaptér vyhrazený pro data, aplikační vrstva má svojí lan. Počet IOPS jsem nepočítal, ale odhadem si myslím, že by se 90% mělo odbavit z cache.
-
citujes snad jediny souhlasny nazor z veledlouhe diskuse
Martin Cracauer napsal:
ZFS will work just fine on the single block devices provided by the RAID controller.
As others have said, the important thing is how you notify yourself of disk breakages and how you manage disk replacements. If you are already comfortable with the support software for your controller that would be fine. Otherwise I would let FreeBSD do the mirrors.
https://forums.freebsd.org/threads/zfs-on-hardware-raid.84861/
Martin Cracauer se jako vývojář dost angažuje v ZFS:
https://www.cons.org/cracauer/
https://github.com/openzfs/zfs/issues/8396
https://medium.com/@MartinCracauer/stupid-zfs-tricks-expanding-zraid-79e716d41fad
Ale těch lidí je daleko víc, kteří tvrdí v podstatě to samé.
Tedy že na jedné straně se odřízneš od některých vychytávek, ale na straně druhé to je v podstatě v pohodě, pokud zajistíš výměnu selhávajícího HW a monitoring jinak. ::)
-
Nikde nevidim kapacitu a pozadovane IOPS. Vystupem bude co? iSCSCI nebo NFS / SAMBA? A co hw/sitova topologie - na kolika hostech jsou ty VM?, je to vse v 10GbE klientech nebo ma storage 40GbE a mas pak agregaci na switchi ?
Na začátku jsou dva VMware hosty s ručním přepínáním VM, pokud se na některém hostu dělá údržba.
Stroje jsou připojené přes iSCSI, každý má svůj 10Gbps adaptér vyhrazený pro data, aplikační vrstva má svojí lan. Počet IOPS jsem nepočítal, ale odhadem si myslím, že by se 90% mělo odbavit z cache.
Mno kdyz je to iSCSI, tak to je blockdev, to muzes rovnou vysdilet procachovany hw raid (treba pres DM) a nemusis resit FS na strane toho uloziste jakoze vubec. A v jednotlivych hostech muzes mit ext4 / ntfs a papa.
Kapacitne se to nevejde do SSD cele to pole? pokud jde o vykon, tak to ma rozhodne lepsi pomer cena/vykon nez adekvatni hdd reseni.
-
Mno kdyz je to iSCSI, tak to je blockdev, to muzes rovnou vysdilet procachovany hw raid (treba pres DM) a nemusis resit FS na strane toho uloziste jakoze vubec.
Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé. :o
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky :o (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
Plus mi šlo o replikace a maximalizaci cache.
Pak tu jsou ty možnosti snapshootů a replikace na pozadí.
-
Mno kdyz je to iSCSI, tak to je blockdev, to muzes rovnou vysdilet procachovany hw raid (treba pres DM) a nemusis resit FS na strane toho uloziste jakoze vubec.
Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé. :o
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky :o (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
Plus mi šlo o replikace a maximalizaci cache.
Pak tu jsou ty možnosti snapshootů a replikace na pozadí.
Ano, proto jsem navrhoval tam vlozit jeste cache pres device mapper - jsou dva druhy, jedna umi cachovat jen cteni, druha i zapisy.
Snapshoty a replikace ci resizing jsou v dm/lvm ok, co je tusim vetsi nedoresenost je thin-provisioning, a prave ty qnap/synology tohle resi nejspise skrze FS ktery poskytuje sparse file support (pochybuji ze by to delali pres qcow2 format).
-
Nojo, ale jestli to není snazší přes to ZFS.
Všechno, co píšeš, dává smysl, ale aby to ve výsledku nebyla jen tako samodomo kopie ZFS.
ZFS umí slušně nakládat s RAM, podporuje L2ARC, solidní cache a obecně, pokud bych se rozhodl přejít na HBA, cirkus nad tím zůstane. Mám standardní způsob replikací a prý by měly fungovat ZFS->QNAP replikace.
-
trochu mi prijde, ze si budes vlastni Google bubble, vyhledavas podporu pro vlastni zamer. PLus zrejme chces mermomoci pouzit radic, co uz mas tak jako tak.
Porovnej rychlost te onboard 6 GB cache s tim planovanym 400GB L2ARC.., ocividne se to jen muze zpomalit? Pokud neni nedostatek RAM, jedina vyhoda L2ARC proti ARC je, ze to nezacina z nuly po restartu (a to jenom od nejake verze OpenZFS a nejsem si jist, zda je to zapnuto by default).
Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.
A udelej si ten A-B benchmark "za tim iSCSI"
citujes snad jediny souhlasny nazor z veledlouhe diskuse
Martin Cracauer napsal:
ZFS will work just fine on the single block devices provided by the RAID controller.
As others have said, the important thing is how you notify yourself of disk breakages and how you manage disk replacements. If you are already comfortable with the support software for your controller that would be fine. Otherwise I would let FreeBSD do the mirrors.
https://forums.freebsd.org/threads/zfs-on-hardware-raid.84861/
Martin Cracauer se jako vývojář dost angažuje v ZFS:
https://www.cons.org/cracauer/
https://github.com/openzfs/zfs/issues/8396
https://medium.com/@MartinCracauer/stupid-zfs-tricks-expanding-zraid-79e716d41fad
Ale těch lidí je daleko víc, kteří tvrdí v podstatě to samé.
Tedy že na jedné straně se odřízneš od některých vychytávek, ale na straně druhé to je v podstatě v pohodě, pokud zajistíš výměnu selhávajícího HW a monitoring jinak. ::)
-
Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS
To je zajímavá teze, takhle jsem na to nenahlížel. A nedokážu to v podstatě odmítnout.
ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...
-
V kazdem pripade pri tehle velikosti RAM uz L2ARC toho moc neprinese.
Pročetl jsem si dokumentaci k L2ARC.
Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.
Nově načtený blok se umístí na vrchol cache a poslední z ní vypadne. (Všechny se tam nevejdou že...)
Část těchto bloků je před zahozením vybrána, aby se jimi naplnila L2ARC. U L2ARC se očekává poměrně nízký poměr úspěšnosti, cokoliv na 25% je považováno za dobré. Doporučení pak jsou použít max. 512 GB NVMe a jeho kapacitu snížit na 460 GB, protože se určitě dřív nebo později zaplní a pak by mohl nastat poměrně intenzivní negativní dopad. (Úplně plná SSD se často chovají velmi divně.)
Nicméně doporučení ohledně L2ARC cache jsou taková, že její použití dává smysl jen když je opravdu hodně operační paměti a poměr úspěšnosti ARC je dost pod 90%. Jeden z důvodů je ten, že L2ARC stojí operační paměť (snižuje ARC) a L2ARC by se měla nacházet na rychlém NVMe disku.
Vyčetl jsem, že řada lidí L2ARC s dostatečně velkou RAM L2ARC skutečně vůbec nepoužívá, přesně jak říkal pruzkumbojem.
This isn't an exact parallel, but I have 256G of RAM in my E5-2637 V4 system and there are just short of 20 VM's (on separate ESXi server) on this NFS pool and this is what my ARC stats look like. I have an Optane SLOG and I debated using some of that for L2ARC, but I can't see a reason to do it. (ARC =>99)
(https://www.truenas.com/community/attachments/1650744090069-png.54954/)
Naopak disky Intel Optane jsou považovány za vhodné na SLOG.
-
Zajímavé pak jsou rychlosti ZFS vs EXT.
Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.
https://gist.github.com/saurabhnanda/6720c13fe02c4ffd950c80f41091e199
A nejsou to ojedinělé výkřiky do tmy...takových postů je dost. Tak velký rozdíl ve výkonu jsem skutečně nečekal.
U nějaké mini databáze to je asi fuk, ale nějaké hlavní databáze je potřeba přenastavit s ohledem na ZFS.
Důvod bude asi podobný jako u MySQL:
http://download.nust.na/pub6/mysql/tech-resources/articles/mysql-zfs.html
A je na to řešení (resp. dá se to vyřešit - změnit chování DB):
https://bun.uptrace.dev/postgres/tuning-zfs-aws-ebs.html#logbias
https://people.freebsd.org/~seanc/postgresql/scale15x-2017-postgresql_zfs_best_practices.pdf
https://vadosware.io/post/everything-ive-seen-on-optimizing-postgres-on-zfs-on-linux/
Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4. :o
-
Pár poznámek k této diskuzi:
3x mirrorovaný SLOG
Zde bych upozornil na málo známý fakt že SLOG stačí jen o velikosti jednotek GB. Praktické maximum jsou 4GB. A SLOG sníži jen latenci, nezlepší propustnost a funguje jen u synchronních zápisů.
- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)
Hlavní problém je že přijdete o ochranu před bitflipem na disku. Pokud dojde k bitflipu tak HW raid to neumí detekovat a předá vadná data ZFS. A ZFS sice detekuje že jsou data poškozená ale když vidí jen hw raid tak nemůže ty data opravit.
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z (https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z)
ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"
S tím většinou nemám problém. Ve většině případů se mi podaří vyladit ZFS že je rychlejší než ext4. Někdy i výrazně. Ale ano, je to alchymie s parametry modulu, parametry datasetu a případně způsobem vytvoření poolu a výsledek není jistý
p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.
Jo, special device to umí hodně zrychlit. Ale určitě bych se ho nebál. Trojitý mirror nemá smysl. V tomto případě když se řeší RAID5 odolný proti výpadku jednoho disku tak nemá smysl míd metadata odolná proti výpadku 2 disků. Provozuji i RAIDZ2 (odolný proti výpadku 2 disků) s metadaty v mirroru. Protože zfs umí od verze 2.0 sekvenční rebuild. Takže pokud by mi odešel jeden z SSD disků s metadaty tak se rebuild toho mirroru provede sekvenčně a tedy rychlostí SSD (450-500MB). Takže redundanci mám obnovenou za čtvrt hodiny. A většinou vím podle smartu včas že SSD odchází tak udělám dočasně mirror ze 3 disků a pak ten opotřebený odeberu.
Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.
L2ARC se hodí pokud víme velikost working setu se kterým se často pracuje. Pak můžeme dát tak velkou L2 cache aby se to do ní vešlo. Ale zase je to docela alchymie. L2ARC má své hlavičky v ARC. Takže když se dá neadekvátně velká L2 cache tak se významně sníží použitelná ARC cache a to může mít naopak negativní dopad na výkon.
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.
ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...
To je pravda, režie tam je a není úplně malá. Zase na druhou stranu zfs má integrovanou kompresi a například u DB se běžně dostávám na kompresní poměr větší než 2. To výrazně pomáhá. Zapíše se méně dat a kvůli tomu že data v ARC jsou komprimovaná tak se do ARC cache vejde víc logických dat což pomáhá při čtení.
Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.
Na tak úplně. ARC opět není jen ZFS cool název pro LRU. ARC cache algoritmus byl vyvinutý nezávisle na ZFS a ZFS ho jen jako jediné využilo. Hlavní rozdíl je že ARC je složeno z MRU (most recently used) a MFU (most frequently used) cache a interně vyvažuje poměr mezi těmito cachemi podle toho jaký mají hitrate. Tím že bere úvahu i frekvenci použití tak dosahuje výrazně vyššího hitrate než cache v kernelu. Navíc kvůli tomu je scan resistent, ted jednorázové čtení nějakých jindy nevyužitých dat nezaplní ram zbytečnými daty a nesníží hitrate.
Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.
Například Lets Encrypt si svoji novou DB postavil na ZFS s 24xNVMe, 2TB RAM a 2x64c EPYC. a hodně si to tam chválí. A je tam i proklik do gitu kde mají tunning pro zfs i mysql který používají.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html (https://letsencrypt.org/2021/01/21/next-gen-database-servers.html)
Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4.
Tohle je například tím že zfs má defaultní record_size 128kB a mysql má v inndob pagesize 8kB. Takže pokud vezmu defaultní nastavení zfs a rozjedu nad tím mysql tak bude amplifikace zápisu 16x. S něčím sice pomůže komprese ale i tak ten výkon bude tragický. Pokud ale snížím recordsize například na 16kB (sweet spot mezi malým recordsize které snižuje write amplification a velkým recordsize které zlepšuje kompresi) tak se při zapnuté kompresi dostanu na rychlosti jako má ext4 nebo lepší (samozřejmě existují patologické případy kdy je zfs pomalejší). Druhá věc je že například zfs umí atomicky modifikovat data až do velikosti record_size. Takže je bezpečné vypnout doublewrite v mysql protože se oproti ext4 nikdy nestane že by se z 8kB InnoDB stránky zapsala jen první polovina a druhá zůstala stará (například kvůli pádu serveru uprostřed zápisu).
-
Váš příspěvek lze označit jako maximálně přínosný!
-
Jak jsem presel na 64-128 GB RAM, tak L2ARC uz nepozoruju zadny prinos.
RAIDZx jsem prestal pouzivat, straslive pomaly resilvering (a vubec zapisovy vykon).
kdyz udelam RAID10 nebo RAID20 (2x10), tak budu mit plus minus redundancy 2 a 4disky (jasne, se to muze strefit do paru). Mit v tomhle okamziku Metadata Special Device jen RAID1 mi prijde opravdu vyrazne slabe misto v porovnani s tim zbytkem. Bych si tipnul, ze spousta lidi to bude mit jako dve male NVME na jedne PCIe karte pres bifurging {protoze to nema smysl natlacit na SATA zarizeni, ktere je extra pomale u malych dat a soucasne ty PCIe sbernice nerostou na stromech) a to je opravdu Single point of failure.
Otazka je, zda to Metadata Special Device ma smysl v okamziku, kdy cely pool je ciste NVME, coz je jednoznacne budoucnost.
a nejvetsi prinos pro zapis je koupit bazarovy Mellanox se SFP28, vysledkem je write cache pro 5 sec x25Gb/s = nejakych 15GB nacpanych do pameti, co rychlost site dovoli. S incrementalnimi backupy desktopu s NVME to dela zazraky.
Priorita ZFS vzdy bylo zajisteni dat, do OpenZFS 2.0+ se cpe hodne cool vykonostnich vylepseni (pro specialni scenare) a dle udalosti poslednihch dvou tydnu mne to zacina desit.
Pár poznámek k této diskuzi:
3x mirrorovaný SLOG
Zde bych upozornil na málo známý fakt že SLOG stačí jen o velikosti jednotek GB. Praktické maximum jsou 4GB. A SLOG sníži jen latenci, nezlepší propustnost a funguje jen u synchronních zápisů.
- ZFS nad RAID5 (to mě sice obere o část výhod ZFS, ale výhodou je rychlost RAID5)
Hlavní problém je že přijdete o ochranu před bitflipem na disku. Pokud dojde k bitflipu tak HW raid to neumí detekovat a předá vadná data ZFS. A ZFS sice detekuje že jsou data poškozená ale když vidí jen hw raid tak nemůže ty data opravit.
O tom že bude HW RAID rychlejší než zfs si také nejsem jistý. Ta cache tam není jako nějaká zázračné zrychlení ale spíš na odstranění problémů které má HW RAID a RAIDZ ne (RAIDZ má vlastní problémy). Zde je zajímavý článek od jednoho z autorů zfs o RAIDZ. RAIDZ totiž není jen cool název pro RAID5/6 ale interně je to úplně jiný raid.
https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z (https://web.archive.org/web/20111214214904/http://blogs.oracle.com/bonwick/entry/raid_z)
ZFS a "dost rychle uloziste" se vetsinou nevyskytuje v jedne vete (podotykam, ze ja mam ZFS vsude, nejsem antifan). A tyhle diskuse se vzdy zmeni v alchymistickou diskusi "tajnych kombinaci parametru"
S tím většinou nemám problém. Ve většině případů se mi podaří vyladit ZFS že je rychlejší než ext4. Někdy i výrazně. Ale ano, je to alchymie s parametry modulu, parametry datasetu a případně způsobem vytvoření poolu a výsledek není jistý
p.S. zazracne pomoci by mohlo ZFS Metadata Special Device. Ja se toho bojim a bez trojiteho miroru bych se k tomu ani nepriblizil.
Jo, special device to umí hodně zrychlit. Ale určitě bych se ho nebál. Trojitý mirror nemá smysl. V tomto případě když se řeší RAID5 odolný proti výpadku jednoho disku tak nemá smysl míd metadata odolná proti výpadku 2 disků. Provozuji i RAIDZ2 (odolný proti výpadku 2 disků) s metadaty v mirroru. Protože zfs umí od verze 2.0 sekvenční rebuild. Takže pokud by mi odešel jeden z SSD disků s metadaty tak se rebuild toho mirroru provede sekvenčně a tedy rychlostí SSD (450-500MB). Takže redundanci mám obnovenou za čtvrt hodiny. A většinou vím podle smartu včas že SSD odchází tak udělám dočasně mirror ze 3 disků a pak ten opotřebený odeberu.
Takze muzes vyvodit z rozhodovaciho Matrixu L2ARC, je to jen cool slovo. Vsechny ty "solidni ZFS Cache" tam jsou, aby kompenzovaly straslivy dopad ZFS na vykon, nejsou primarni benefit ZFS.
L2ARC se hodí pokud víme velikost working setu se kterým se často pracuje. Pak můžeme dát tak velkou L2 cache aby se to do ní vešlo. Ale zase je to docela alchymie. L2ARC má své hlavičky v ARC. Takže když se dá neadekvátně velká L2 cache tak se významně sníží použitelná ARC cache a to může mít naopak negativní dopad na výkon.
Občas se to hodí jako rychlý hotfix výkonu například u HDD NAS kdy se větší část čtení odbaví z SSD.
ZFS se umí vypořádat s vadnými sektory, dopočítává kontrolní součty, řeší CRC v průběhu celé životnosti dat...proto je logické, že to má nějakou významnou režii. Jen nemám představu jak moc...
To je pravda, režie tam je a není úplně malá. Zase na druhou stranu zfs má integrovanou kompresi a například u DB se běžně dostávám na kompresní poměr větší než 2. To výrazně pomáhá. Zapíše se méně dat a kvůli tomu že data v ARC jsou komprimovaná tak se do ARC cache vejde víc logických dat což pomáhá při čtení.
Každý čtený blok jde do ARC, což je v podstatě na úrovni Least Recently Used cache.
Na tak úplně. ARC opět není jen ZFS cool název pro LRU. ARC cache algoritmus byl vyvinutý nezávisle na ZFS a ZFS ho jen jako jediné využilo. Hlavní rozdíl je že ARC je složeno z MRU (most recently used) a MFU (most frequently used) cache a interně vyvažuje poměr mezi těmito cachemi podle toho jaký mají hitrate. Tím že bere úvahu i frekvenci použití tak dosahuje výrazně vyššího hitrate než cache v kernelu. Navíc kvůli tomu je scan resistent, ted jednorázové čtení nějakých jindy nevyužitých dat nezaplní ram zbytečnými daty a nesníží hitrate.
Nejspíš - někdy - lze ve výchozích nastaveních dospět ke stavu, kdy je databáze 2-3x pomalejší než na EXT4.
Například Lets Encrypt si svoji novou DB postavil na ZFS s 24xNVMe, 2TB RAM a 2x64c EPYC. a hodně si to tam chválí. A je tam i proklik do gitu kde mají tunning pro zfs i mysql který používají.
https://letsencrypt.org/2021/01/21/next-gen-database-servers.html (https://letsencrypt.org/2021/01/21/next-gen-database-servers.html)
Zajímavé je, že těch lidí ohledně výkonu ZFS brblá poměrně dost. A pak jiní lidé pouští podobné testy a jejich výkony jsou naopak lepší nebo stejné jako u EXT4.
Tohle je například tím že zfs má defaultní record_size 128kB a mysql má v inndob pagesize 8kB. Takže pokud vezmu defaultní nastavení zfs a rozjedu nad tím mysql tak bude amplifikace zápisu 16x. S něčím sice pomůže komprese ale i tak ten výkon bude tragický. Pokud ale snížím recordsize například na 16kB (sweet spot mezi malým recordsize které snižuje write amplification a velkým recordsize které zlepšuje kompresi) tak se při zapnuté kompresi dostanu na rychlosti jako má ext4 nebo lepší (samozřejmě existují patologické případy kdy je zfs pomalejší). Druhá věc je že například zfs umí atomicky modifikovat data až do velikosti record_size. Takže je bezpečné vypnout doublewrite v mysql protože se oproti ext4 nikdy nestane že by se z 8kB InnoDB stránky zapsala jen první polovina a druhá zůstala stará (například kvůli pádu serveru uprostřed zápisu).
-
PMR/CMR "desktop grade" disk se 7200 ot/min dá nějakých 75 random IOps, a moc neškáluje při seřazení požadavků.
Enterprise disky (blahé paměti Seagate Cheetah, WD Raptor a další SCSI/SAS 10-15k RPM) uměly nativně tuším něco jako 150 random IOps, a při seřazení požadavků ještě trochu škálovaly (někam ke 300 IOps per spindle? už nevím).
Šindelové disky jsou zřejmě docela svinstvo - ale pravda je, že "enterprise šindelové" jsem v ruce nedržel, možná jsou trochu poladěné.
Pokud pod "chytrý" FS typu ZFS vložíte blokový HW RAID, oberete ZFS o část příležitostí k optimalizaci IOps, pokud Vám o toto jde. RAID5 je rychlý při čtení a sekvenčním zápisu, naopak při random zápisu umí být hnusně pomalý.
Před poměrně mnoha lety jsme prodávali nějaké DAS RAIDy, řekněme do 16 nebo 24 disků. (Mou oblíbenou značkou řadičů je dodnes Areca.) Bylo to v dobách, kdy se rozjela určitá skupina internetových služeb, kde hejno drobných sosačů v divokém internetu cucají každý svůj soubor, a cucají ho sice sekvenčně, ale relativně pomalu. V té době nebylo snadné najít/poskládat webový server, který by zařídil smysluplný read-ahead per soubor = aby se soubory (před)načítaly po blocích dostatečně velkých na to, aby se průchodnost v MBps blížila sekvenčnímu stropu jednotlivých disků i při worst-case IOps (zmíněných cca 75 pro levné nešindelové točivé disky). Zavelet to kernelu paušálně nešlo. Je na to odjakživa nějaké ioctl() na otevřený soubor, ale webservery si o to neuměly říct. Nevím, zda se situace v dnešní době někam pohnula. Každopádně mi tehdy tvrdil jeden odcházející zákazník, že jim tenhle problém vyřešilo právě ZFS.
Odbočím maličko od původního dotazu:
Nedávno jsem pro nenáročnou interní potřebu a vlastní potěchu/vzdělání řešil, jak navrstvit QEMU VM na hostitele (HV), ve kterém chci snapshoty, aspoň trochu komfortní SW RAID0, možnost expanze kapacity v HV a nějaké trochu úsporné ukládání QCOW images. Po relativně dlouhém bádání jsem to navrstvil takto:
Ve virtuálu Linux, virtio blokové zařízení mountuji s podporou discard
VM images podávám QEMU, se zapnutým mapováním discard na sparse file (QCOW image)
BTRFS subvolume pro každý virtuál, v něm jeden či více VM images, které k danému virtuálu patří
BTRFS s potlačeným COW (aby VM image přepisoval in-place, jenom při uloupnutí snapshotu na omezenou dobu jede COW)
MD RAID 1 (při expanzi kapacity bych musel přidat další MD RAID) - je to nakonec menší opruz, než BTRFS RAID
holé disky (JBOD) - nemám bohužel failure LEDky
Při kopírování VM images je potřeba dát pozor, aby se zachoval sparse charakter souborů. Jsou na to zaklínadla pro cp a dd. Toto najde využití při testování variantních změn konfigurace uvnitř VM, při hledání odkdy se vleče skryté poškození čehosi apod. Backup a restore sparse souborů umí například Borg. Snapshot se dělá nikoli z jednotlivého souboru "QCOW image", ale z BTRFS subvolume (jako prostý adresář, ale s touhle čarovnou schopností navíc). Je to způsob, jak zálohovat debilní VM, jehož obsah nedává smysl zálohovat nějak interně/nativně.
Má to vespod jenom dva disky na data (další dva v mirroru slouží čistě pro boot HV).
Když startuje jediný virtuál, je to pěkně svižné - ale kdyby jich startovalo deset simultánně (nikoli ze sdíleného systémového image), byla by to asi smutná podívaná. Padesát VM? Děsivá představa. Virtuály možná nejlíp startovat a típat naschvál sekvenčně. A to se bavím jenom o startu a vypnutí. Pokud virtuály potřebují nějaké nenulové nekešovatelné IOps ke svému životu, je to na točivých discích asi smuténka. Samozřejmě důsledně všechny oddíly mountuju s opšnou noatime.
Počítám, že to co jsem uplácal holýma rukama, by takový Proxmox mohl umět komfortně a bez namáčení.
A tohle vše nejspíš už zhruba 20 let jde postavit na DM volume manageru, jak už někdo zmínil přede mnou. Err... nevím jak passthrough pro "-o discard => sparse image" skrz QEMU, to je tuším relativní novinka.
Veliká cache (jedno na jaké vrstvě) má šanci pomoct pro čtená data, pokud se do ní vejdou. Pro write-back je přínos v podstatě maličký, protože v mixu zápisových operací se vyskytuje poměrně velké množství bariérových operací (seřazení) a dokonce tvrdých synců. Tuším na některých vrstvách lze zakázat bariérové operace (FS mount option? block device?), což Vám dá možnost naplnit celou RAMku write-back bufferem, ale přijdete tím o důležitou záruku konzistence dat na disku (pro případ pádu stroje) a nakonec pokud těch zápisových IOps je i tak v průměru prostě moc, tak po zaplnění cache začnou VM guesti drhnout i tak, bariéry nebariéry. Protože prostým seřazením operací velkého škálování nedosáhnete (otestováno) pokud zápisy přesně nenavazují.
Ten pokrok je stejně svinstvo. Za starých časů si študáci na hraní stavěli servery pro přístup přes telnet a IRC, kde vesele chatovalo třeba 200 lidí. Každý měl spotřebu pár desítek kB RAM. Dneska má člověk na hraní 50 virtuálů :-)
-
... Každopádně mi tehdy tvrdil jeden odcházející zákazník, že jim tenhle problém vyřešilo právě ZFS.
Pardon... už si nejsem jistej, jestli pomohlo ZFS, nebo spíš Solaris.
-
Mám zkušenost, že přímo vysdílená partice jako iSCSI blokové zařízení je pomalé. :o
Údajně je problém v tom, že Linux cachuje pouze soubory a nikoliv bloky :o (nevím, nezkoumal jsem dál, jen mi to někdo řekl).
...
Je na místě otázka, kterou implementaci iSCSI targetu jste na storage serveru použil. Vím zhruba o čtyřech. Asi nejstarší byl iSCSI Enterprise Target, modernější jsou STGT, SCST a LIO.
https://scst.sourceforge.net/scstvsstgt.html
Osobně jsem kdysi, v dobách svého obcování s RAIDem, testoval tuším SCST = to je ta věc, co žije v kernelu (bohužel navždycky mimo mainline). Hrotil jsem maximální průchodnost. Mírně se lišily varianty konfigurace "skrz blokovou cache" vs. "direct" (tuším nastojato předává SCSI příkazy z iSCSI skrz HBA připojenému SCSI target zařízení). Tušímže ve variantě "skrz blokovou cache" jsem dokázal vystropovat 10Gb Ethernet při přenosu do cache - ale jak se muselo sahat na fyzické zařízení, nevystropoval jsem ani sekvenční rychlost připojeného SAS RAIDu (tuším to dalo asi 3 Gbps max). A při variantě "direct" jsem vystropoval připojený SAS RAID (6 Gbps), ale zase jsem pochopitelně neměl k dispozici blokovou cache iSCSI serveru. Toto vše se zapnutými jumbo frejmy na přímém propoji 10Gb Eth client-server, síťové karty Myricom. Jak dlouho to může být... před 15 lety?
Pokud vím, ostatní implementace iSCSI žijí v user space.
Pokud otevřete v user space blokové zařízení jako soubor, máte možnost použít nebo nepoužít flag tuším O_DIRECT. Ten ovládá, zda se jede skrz blokovou cache nebo bez cache. Která varianta je rychlejší, to záleží na charakteru zátěže, typu a konfiguraci IO scheduleru, na výkonu CPU...
Ne že bych chtěl iSCSI nějak propagovat, nebo snad že bych s ním měl rozsáhlejší zkušenosti.
-
:
Pokud vím, ostatní implementace iSCSI žijí v user space.
:
LIO (LinuxIO) is the in-kernel iSCSI target (since Linux 2.6.38).
https://wiki.archlinux.org/title/ISCSI/LIO
-
Matně si vybavuju, že když LIO integrovali, tak mělo zhruba nejrozsáhlejší doprovodnou podporu / nejlepší dokumentaci managementu, integraci v ekosystému. Snadný start. Bolkhovitin s jeho SCST je bohužel mimo kernel, asi nepomáhalo že je Rus, a sice byl docela silný "pod kapotou" (výkon/features), ale management v user space neměl mnoho plyšáků.
-
Intel Optane je na SLOG úžasný, ale už se nevyrábí. Myslím že Kioxia má i model tomu podobný, ale hodně drahý.
-
Intel Optane je na SLOG úžasný
Zatím jich jsou plné bazary a vím, že někteří jich mají třeba padesát v šuplíku...
-
Zatím jich jsou plné bazary a vím, že někteří jich mají třeba padesát v šuplíku...
To nevím, nehledal jsem to. Je potřeba zmínit, že mluvíme o 900p/905p a 4800X, ty M.2 nejsou pravé Optane.
-
Tyhle věci dnes už stavím jen nad ceph, teda pokud nejsou peníze (a potřeba) na nějaký enterprise level storage. Ač ceph vyžaduje nějaké znalosti v počátku, poskytuje spousty výhod, dobře se škáluje a řeší data placement, poskytuje checksum a pousty vychytávek. Kontrolky disků lze u velké části serverů ovládat z venku, takže když se SW detekuje špatný disk, můžeš ho rozvítit, což je tak nebo tak lepší než když ti technik vytáhne špatný disk. Důvodů proč se mění disk je v praxi daleko více, než které detekují řadiče.
K tomu jestli raid1 (mirroring) stačí, tak zpravidla to je dobré tak na domácí hraní, při výpadku primárního disku je ten druhý poměrně dlouho plně zatížen replikací a podstatně spadne jeho provoz, zejména pokud se bavíme o plotnách. Raid1 je tak akorát dobrý na to, abych mohl za provozu vyměnit OS disk a ne, abych to měl jako jediné uložiště pro data.
Ono se to blbě navrhuje, když ty výpadky jsou tak nějak hodně vyjímečné a pokaždé lehce jiné. Teď nám třeba díky malému požáru v jednom DC se spustil požární systém v sále, ten vysál kyslík, udělal se tam podtlak a 1/3 plotnových dísků bez helia odešla, spousta serverů s 15k OS enterprise disky v raid1 přišla o oba, zlatá datová helia, která přežila všechna. Jindy nám zase náhlý výpadek napájení v celém sále odrovna ssd/nvme disky (poškozený fs, hlavičky), odpadly jak hrušky.
Ceph umožňuje dynamicky řídit repliky a reagovat na situaci na síti. Dá se začít pár malými servery a postupně přidávat silnější jak budou peníze a to celé je možné průběžně správně balancovat, tak aby se ideálně saturovaly disky/síť. Dají se z toho vytáhnout veškerá provozní data a udělat velice podrobný reporting, svázat konkrétní datasety s jejich disky a reportobat to vertiálně (běžně získám z řadiče data z SNMP, ale už je nejsem schopný svázat s konkrétní operací a daty, které jsou na daném disku).