ZFS : Stavba zkušenosti se ZFS storage (diskuse)

[nevim dal]

mergerfs + snapraid

[trekker.dk]

i když z technického hlediska problém není, je problém z hlediska morálního

Stačí zastávat názor, že já mám nárok na všechno a respektovat přání autorů software tudíž nemusím, a morální problém je vyřešen.

asi jedinou slabinou v kontrole integrity dat je to, že na data v ram se neaplikují checksummy, proto jsou nutné ECC paměti

Aha, já jsem si říkal, kde se bere to, že pro ZFS MUSÍTE mít ECC.

online kompresy

Kompresy jsou obvazový materiál. Vy chcete zapnout kompresi. (x2)

[Max]

Překlep opraven, díky.
Zdar Max

[j]

"Dojde vám ram a server padne. "

"...3GB RAM na 1TB dat + režie OS / dalších služeb. "

Presne tohle je pro absolutni vetsinu vyuziti naprosty nogo. Nehorazna spotreba ramky a naprosto nemozny chovani kdyz dojde.

Jinak by me zajimalo, co si mam predstavit pod "... big storage, což btrfs nedává ...", protoze "...Zásadně nepoužívejte žádné řadiče s cache ..." samo o sobe rika, ze je to tak maximalne hracka, na dlouhy coronavirovy vecery, ale v realnym svete se to pouzivat neda.

---

Bezte stim guuglem dopice!

[Max]

3GB/1TB dat je v případě duduplikace, což se moc nepoužívá (není moc nasazení, kde to dává smysl).

Proč vznikly cache na řadičích? Protože to byla a je výkonnostní záplata pro hloupé systémy, které neumí cachovat a nepotřebují ani vědět, co pod nimi běží. Pokud mám systém, který si umí dělat vlastní cache, je rázem zbytečné používat hw fix.
Navíc cache na řadiči má omezenou životnost díky baterii. Člověk tedy musí preventivně měnit jednou za 4-5 let (bavíme se tedy o investici několik tisíc a nucené odstávce), jinak by se dočkal neplánovaného odstavení cache a výkonnostního propadu. Některé řadiče dovolují natvrdo cache znovu zapnout bez baterie, ale to není řešení pro produkční běh.
Poté existují náhrady za baterie v podobě plata kondíků, které by v sobě měly udržet potřebný počet energie, aby data v cache nechcíply. Nevím ale, jak moc se to používá.
Nicméně tím se řeší jen cache, neřeší se skládání pole jako takového, kde klasická RAID pole nenabízí redundanci jako zpool + raidz. Lze to řešit tak, že fci poolu nahradíme třeba pomocí LVM. Tzn. na řadiči si povytváříme několik RAID6 a v OS si to pomocí LVM spojíme. To by šlo, ale nemáme nikde rozumnou kontrolu konzistence dat.

Ad btrfs. Jak už jsem uvedl v zápisku, osobně 100TB považuji za větší pole, takže jak by se podobné pole dalo poskládat s btrfs, aby to mělo podobné parametry a diskovou redundanci?
Zdar Max

[trekker.dk]

Já pořád nechápu, proč na tohohle j-trotla, který si žije ve vlastním světě, ve kterém funguje jenom to, co nefunguje ostatním, ale zato nefunguje nic z toho, co ostatní běžně používají, ještě někdo reaguje.

Poté existují náhrady za baterie v podobě plata kondíků, které by v sobě měly udržet potřebný počet energie, aby data v cache nechcíply. Nevím ale, jak moc se to používá.

Superkondenzátorů - oproti normálním kondenzátorům je to trochu rozdíl. Používá se to třeba u LSI (dosaďte si vlastníka pro rok, kdy to čtete) 3108. Místo několika hodin nabíjení baterie, kdy řadič běží s degradovaným výkonem, se to nabije při bootu za asi deset sekund.

To by šlo, ale nemáme nikde rozumnou kontrolu konzistence dat.

dm-integrity? Teda pokud kontrolu konzistence dat nemá filesystém.

[Max]

Spíš jsem reagoval na ten hw řadič. Jinak dm-integrity + btrfs by mohlo být řešením (pokud bychom chtěli kontrolu integrity dat i snapshoty a věci okolo), ale obávám se, že by tam bylo pár zbytečných výkonnostních propadů :-/.
Zdar Max

[trekker.dk]

obávám se, že by tam bylo pár zbytečných výkonnostních propadů

IMO je jedno, na které vrstvě se ten checksum udělá, takže spíš záleží na konkrétní implementaci

[Max]

Dělat checksum na úrovni FS je neúplné, když pod tím bude ještě další vrstva, která to dělat nebude (3rd raid řadič). Pokud použiješ mdadm s integrity, tak budeš dělat checksumm 2x, protože na btrfs tuto kontrolu vypínat nemůžeš.
Zdar Max

[trekker.dk]

Dělat checksum na úrovni FS je neúplné, když pod tím bude ještě další vrstva, která to dělat nebude

Neúplné v čem? Cílem je rozpoznat/opravit poškození dat a k tomu checksum na úrovni FS přece stačí, ne?

[Max]

Pokud je btrfs nad mdadm / jiným druhem pole, tak nemá k dispozici opravná data. Chybu tedy detekuje, ale už jí nemá podle čeho opravit.
Zdar Max

[trekker.dk]

Nerozumim - btrfs dělá checksumy jenom na detekci chyb, ale ne na opravu chyb?

Asi bych to vzal od začátku: btrfs je nad jiným druhem pole, konkrétně na jednom disku. Checksumy dat nefungují a aby začaly fungovat, musím mu dát druhý disk?

[Max]

Checksumy jsou jen nějaké kontrolní součty dat. A pokud ti checksum řekne, že na ty data nesedí, tak jak ty data opraví? Musí vzít někde jejich záložní kopii, na kterou ty checksumy sedí. To znamená, že by jsi měl v rámci btrfs provozovat jednu kopii dat i metadat (zlými zlořečníky nazývanou raid1). Tu ale nemáš, protože redundanci řešíš na úrovni pole (hw raid). A tuto nižší úroveň btrfs nevidí.
Zdar Max

[trekker.dk]

Jo takhle, já to bral tak, že to jsou checksumy typu, že umí menší chyby opravit a větší aspoň zjistit - tj. ekvivalent toho, co dělají HDD interně. Jestli je to jenom něco typu SHA256, tak to pak jo, v takovém případě skutečně není podle čeho opravovat. Nicméně btrfs nemusíme brát jako etalon správné implementace - na desktopové nasazení jsou takovéhle checksumy IMO dost k ničemu

[Max]

Používá crc32c a další info.
Zdar Max

[marbu]

I když se v brtfs používá crc32c, není možné vzhledem k velikosti bloku nic dopočítat. Ale i tak to je na desktopu s jedním diskem užitečné: v případě, že ti začne odcházet disk si toho včas všimneš (z vlastní zkušenosti), a jako bonus přesně víš která data ještě máš a která ne :), což se může hodit při obnovování zálohy na novém disku. Druhá věc je, že btrfs ukládá všechny metadata bloky dvakrát, takže i na jednom disku lze narazit na případ kdy btrfs podle výsledku scrubu něco opraví (jemně to zvyšuje odolnost naboření fs).

[trekker.dk]

Jak to říct... jsou tu tací, co tuhle funkci předkládají jako obrovskou výhodu btrfs, tak jsem čekal trochu víc.

[Max]

Obrovská výhoda je v tom, že víš, že je něco špatně a víš, co konkrétně je špatně. A pokud jedeš ještě jednu kopii dat, tak si to i opravíš. S ext3/4/reiserfs/ntfs apod. nic takového ani nezjistíš.
Mně to tedy přijde jako hodně velká výhoda.
Zdar Max

[trekker.dk]

S ext3/4/reiserfs/ntfs apod. nic takového ani nezjistíš.

Jednoho krásného dne se podívám na to dm-integrity a uvidí se, jak to nezjistím

[j]

Vazne nevim proc sem kreteni jako ty vubec lezou. ZFS prakticky vubec nikdo nikdo nepouziva.

Zato cache pouziva naprosto kazdy zarizeni ktery existuje, coz ovsem dement jako ty nemuze tusit.

A uz vubec nemuze negramotnej dement tusi jak fungujou radice s baterkou ze? Jeste sem nepotkal takovej, kterej by jel v jakkoli degradovanym rezimu kvuli nabijeni baterky ... jednoduse proto, ze to by soudruhu ten stroj musel chcipnout, coz se muze stat leda kokotum jako ty ktery ho zapojej bez UPS. Nomalni lidi totiz maji UPS a ta ten stroj korektne vypne tudiz v cache nezustanene kupodivu NIC a baterka se vubec nepouzije.

---

Bezte s tim guuglem dopice!

[Max]

Prosím tě, vyjadřuj se slušně. To, že mluvíš sprostě a věci zobecňuješ tvým argumentům moc nepomáhá .
Tak aspoň napiš, co spravuješ ty, s čím máš zkušenosti.
Zdar Max

[trekker.dk]

Já bych tu snůšku blábolů teda neoznačoval jako argumenty... jenom ta googlí captcha mě vždycky potěší, že aspoň zjevně jednomu spammerovi zaškodí.

[alkoholik]

Dalsi j-blabol.
Ty jsi jenom poradne nemonitoroval HW, protoze battery learning/charging je pomerne bezny stav.

[j]

"Proč vznikly cache na řadičích? Protože to byla a je výkonnostní záplata pro hloupé systém ..."

Skoda ze to neni zaplata na hloupy lidi ...

FS sam o sobe nemusi vubec tusit jak funguje zarizeni, se kterym pracuje. Radic ma ulozisti mnohem bliz, proto je kupodivu cache na jeho urovni pro spoustu uziti mnohem efektivnejsi.

A zase kupodivu ... zazrak prirody, pouziva se i cache na urovni jednotlivych disku. Protoze zase plati, ze ani radic nemusi nic vedet o skutecnym usporadani uloziste, ktery je k nemu pripojeny.

A opet, protoze jak vidno nekteri vcetne tebe vubec netusi ...

Baterka je tam POUZE a VYHRADNE proto, kdyz ten stroj bez dalsiho chcipne (na discich samotnych je to reseny nejakym kondikem, kterej staci na to aby se cache vyklopila na disk). Jinak se VUBEC nepouziva. ... ale jo urcite je MNOHEM vyhodnejsi, kdyz ten stroj (bez ty hnusny HW cache) chcipne, vsechno v ramce ZMIZI, a tudiz jsou v PICI i vsechna data (coz je mimochodem PRESNE to, co se na ZFS realne deje, presne proto jsou vsude upozorneni, ze tam musi byt UPS a ze se nesmi dopustit aby to chciplo, obdobne to pak samo plati i pro btrfs, jen to vypada, ze jeho tvurci s takovou situaci precijen pocitaji o dost vic).

Protoze milej zlatej, cache ktera nepotvrzuje zapis je cache k hovnu, ze? Protoze pak musis cekat, az ti zapis potvrdi ten pomalej disk ze?.

Naprosto vtom pripade ale nechapu, proc tu pises o vecech, o kterych zhola nic nevis?

Ad btrfs, to jako ze btrfs nezvladne 32 disku? Nebo jak to mam chapat? Kdyz teda pominu, ze kapacitne se to da poskladat z mnohem mensiho poctu.

BTW: Sem zvedav, jak dlouho se korektne ukoncuje filesystem, kterej zabira stovky GB ram. Rek bych, ze se to do tech +- 15 minut coz je tak limit jak dlouho bezne drzej upsky, nemuze vejit.

BTW2: Ty tvoje hracky asi budou nejaky samodomo bastly, ze? Na svych hrackach umim vymenit vlastne cokoli ... za chodu. Nejen baterky ... ale klidne radic. Vlastne dokonce i na tech hrackach, ktery nejsou primarne ulozisti ... muzu klidne celej stroj proste vypnout ... a zadna odstavka se nedeje. Neco delas spatne. Specielne kdyz mluvis o "produkcnim nasazeni". Ostatne, zrovna vcera sem normalne za chodu postupne restartnul 10 stroju ... a nikdo si ani nevsim.

BTW3: Po 5 letech se vyhazuje (kupodivu preventivne) celej HW, takze nejaka chcipla baterka me fakt dojme ...

---

Bezte s tim guuglem dopice!

[Max]

1) Zatím jsem se setkal jen s řadiči, které cache na diskách vypínaly. Prostě koupíš disky s cache, dáš je do řadiče a ten jim tu cache deaktivuje, aby si to mohl celé řídit sám pomocí svý vlastní cache zálohovanou baterií. Takže tvé zmínce o výhodnosti cache na diskách moc nerozumím. HBA řadič pak samozřejmě nic takového nedělá.

2) Pokud jde o kešování, tak OS/FS ví nejlíp, co kešovat, může dělat i dopředné kešování. 3rd shit na úrovni blokového zařízení toto neumožňuje, nemá o tom ani páru. Stejně tak lze držet v cache celistvá data, to řadič nepozná, co je třeba celý soubor a co ne, protože zná jen bloky. Já jsem tedy příklad pro výhody cachování v rámci OS/FS uvedl, mohl by jsi zmínit nějaký příklad ty, ve kterém má cache na řadiči navrh? Píšeš "spoustu uziti mnohem efektivnejsi.", takže asi těch příkladů máš hodně, můžeš tedy nějaký napsat?

3) Pokud jde o výpadek proudu u ZFS, tak nesouhlasím, výpadek proudu nevadí a nevím, proč by vadit měl? Sync zápisy se zapisují přímo, nebo přes SLOG (tedy rychlé ssd), kterému ale výpadek proudu neuškodí a zálohovaný baterií být samozřejmě nemusí.
Pokud jde o zápisy v ram, tak když se neprovedou, tak nejsou provedený a nejsou ani potvrzený, no problemo. V čem ty konkrétně ten problém vidíš?
A k problému by nemělo dojít ani u jiných rozumných FS. Nastuduj si, co jsou to bariery a pak pochopíš, jak to reálně funguje.

4) Funkci baterie u řadičů tu myslím všichni chápeme. Každopádně na jedné straně argumentuješ tím, že výpadek nemůže nastat, protože vše je zálohováno velkou baterií, poté ale napíšeš, že běžně to na bateriích vydrží 15min. My máme baterie, na kterých servery dokážou běžet v řádu hodin a když štěstěna přeje, dostaneme se do dvoumístných čísel počtu hodin. Každopádně zpět k problému, server ti může crashnout v pohodě i bez napájení. Setkal jsem se s tím u HP i IBM. buď za to mohli pitomosti jako vadný panel s diodama, nebo pak i chyby ve firmware řadiče, tj. hw problémy.

5) btrfs zvládne 32 disků, ale zvládne 32 disků při zachování podobné diskové redundance?

6) storage server se naposledy vypnul asi do 5min

7) Mít virtualizační cluster a otáčet si hw podle potřeby není nic světoborného, to máme samozřejmě také. Pokud provozuješ nějaký clustorový FS, tak otáčení jednotlivých node patří mezi samozřejmé fce, to snad nikoho nepřekvapí. My clusterový fs neprovozujeme, ale postupně k tomu směřujeme. Storage zatím jedeme v HA active/pasive. V rámci risk managementu nám to zatím vychází ok.
Pokud máš nějaký hw pole od nějakého vendora, tak se většinou jedná o dva servery v jednom šasi nastavené jako cluster. Vyndáním "řadiče" se vlastně vytrhne jeden node toho clusteru dvou serverů. Rychlost převzetí kontroly nad polem druhým serverem je otázkou toho, jak je to pole vytížené.

Zdar Max

[hefo]

3GB/1TB dat je v případě duduplikace, což se moc nepoužívá (není moc nasazení, kde to dává smysl).

Nič proti, ale pokiaľ sa to správa tak mizerne, ako si uviedol v článku, tak to nielen že nedáva zmysel, ale tá deduplikácia by sa ani nemala uvádzať medzi vlastnosťami toho FS, nanajvýš niekde v TODO.

[Max]

Je to jasně zdokumentovaný a jsou případy, kdy to smysl dává a vyplatí se to. Nevidím důvod tu fci nějak skrývat, jak naznačuješ.
Když něco nasazuji, tak si jednak pročtu dokumentaci, dále si to před ostrým nasazením otestuji.
Zdar Max

[bigBRAMBOR]

Abychom mu ale jen nespílali, má i nějaké menší nedostatky

víš co znamená spílat?

[Max]

Díky, opraveno.
Zdar Max

[deda.jabko]

jeste bych se primlouval za tu fylozofii

[Max]

Vy mi dáváte, ale to mám za to, že jsem se k tomu choval laxně a sepisoval to delší dobu.
Zdar Max

[michal]

>proto jsou nutné ECC paměti

Já bych to tak kategoricky nepsal. Kdysi jsem byl také zastáncem ECC ale teď mám dostatek statistických dat z praxe. Takže bych ten požadavek přirovnal k požadavku na to mít server v bunkru 30 metrů pod zemi. Protože co kdyby meteorit?

[Max]

No, stačí se podívat na ten error log zmíněný v blogu, co mi to občas u pamětí háže. Možná jsou vadné, možná ne, ale jedno je jistý, chyby občas detekují.
Zdar Max

[michal]

Ta pamet by zrejme memtestem neprosla... No ale je to otazka priorit. Ty s tim mirrorovanym SLOGem take riskujes a usetreny peniz za druhy optane ma vetsi hodnotu, nez pocit nohou v suchu.

[michal]

*nemirrorovanym

[Max]

Problém s memtestama je ten, že když jsem nějaké naposledy zkoušel, tak se chovaly nekonzistentně. Jeden hlásil chybu, druhý, že je vše ok, třetí chybu, pátý, že je vše ok, pak se člověk dočte, že u některých memtestů není úplně ok implementace ECC atd.
Ve finále na to tedy kašlu, když chybuje, tak půjde na výměnu.
Jinak u nového backup storage už poptávám 2x Optane, takže posun tu je.
Zdar Max

[alkoholik]

Nejlepsi zkusenosti mam s userspace memtester. O ECC sice nic nevi a pamet obsazenou kernelem nezkontroluje, ale nasel chyby, ktere memtest86+ unikly.

[Aleš Kapica]

To je zajímavé. Dík za tip.

[Michal]

Díky za zajímavý post. Koukám, že musím aktualizovat ty zfs tooly. Můj arcstat nezná -a a bez něho vrací jen

    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
13:18:57    44     4      9     4    9     0    0     4    9   179G  180G

Moje zkušenost s DEDUP - až na velmi specifické usecase nebrat. Nestojí to za hlavobol. A to mám 256GB RAM na 24TB RAW kapacity.

Můj pool přežil už vadný diskový řadič, vadný napájecí káblik, který v náhodných intervalech způsoboval reset 2 disků v poli, 2 migrace mezi počítači, při upgradech, výměnu vadného disku a celkově značně hrubé zacházení typu přehození disku za chodu do jiného šuplíku kvůli výměně ventilátoru. Nesmrtelna věc

[Max]

Mno, právě jsem se dozvěděl, že mi rozšiřování pole neprošlo :-/ ... prej mám koupit nový :). Takže asi půjdu podobnou cestou jako nyní, aktuálně koukám po tomto :

• Amd EPYC2 Rome (SPA3 LGA) 7302P - 3GHz, 16core/32thread,
• H12SSW-iN S-SP3(225W), WIO, 2GbE, 8DDR4-3200, 16sATA, 2M.2, IPMI
• 8x 32GB 3200MHz DDR4 ECC Registered 2R×4, LP(31mm), Samsung (M393A4K40DB3-CWE)
• LSI TriMode 9400-8i8e(3416) SAS3/NVMe HBA(JBOD) 2×8643,2×8644,exp:1024HD/24NVMe,PCI-E8 g3,MD2,SGL
• 2x Intel Optane SSD 905P Series 480GB
• SC847BE1C-R1K28W 4U WIO 24+12 sATA/SAS3 (SAS3 exp.),2SFF, rPS 1280W (80+ PLATINUM)
• 3r NBD on-site
• 34x 6TB WDC Ultrastar 7K600/HC310 - 7200rpm, SAS3, 512e, 256MB, (SE), P3, 3,5" SAS

Takže navýším kapacitu pole z 96TB na 144TB, SLOG budu mít v mirroru a přejdu na SAS disky.

Jinak aktuální stav toho PCI-E Optane je:

root@storage:~ # nvmecontrol logpage -p 2 nvme0
SMART/Health Information Log
============================
Critical Warning State:         0x00
 Available spare:               0
 Temperature:                   0
 Device reliability:            0
 Read only:                     0
 Volatile memory backup:        0
Temperature:                    318 K, 44.85 C, 112.73 F
Available spare:                100
Available spare threshold:      0
Percentage used:                0
Data units (512,000 byte) read: 29
Data units written:             198421208
Host read commands:             494
Host write commands:            1095760618
Controller busy time (minutes): 878
Power cycles:                   4
Power on hours:                 2059
Unsafe shutdowns:               0
Media errors:                   0
No. error info log entries:     0
Warning Temp Composite Time:    0
Error Temp Composite Time:      0

Takže Optane by už za sebou mělo mít : 96,6TB zápisu, pěkný.
Zdar Max

[MarV]

Ahoj, zaujala mě nízká hodnota "Data units read". Znamená to, že se 96TB zapsalo a pouze 14MB přečetlo?

[Michal]

To nemusí být daleko od pravdy, za normálních okolností se do SLOGu pouze zapisuje. Čte se z něho pouze ve dvou případech 1) počítač padl dříve, než se stihla data zapsat na datové disky 2) přišel najednou tak velký burst zápisových IOPS, že přeplnil ARC cache dříve, než se odtamtud stihla zapsat na datové disky.

[MarV]

OK dík za info

[Max]

Je to tak, jak píše Michal. Jinak když ten zápis převedu na DWPD (Drive Writes Per Day), tak jsme na nějaké hodnotě :

97TB
85dní
= 1,2TB/den
DWPD: 2,5

Optane 900P/905P 480GB má max DWPD 10, takže v průměru se do toho dá vejít naprosto v klidu. Pokud jde o top v nějaký den, tak bohužel statistiku nemám. Zkusím si před big zálohou přečíst hodnoty a po big záloze také a uvidíme. Pokud nezapomenu, tak provedu a hodím to sem.
Nicméně je z toho patrné, že běžné serverové SSD s DWPD 5 by na toto oficiálně asi nestačily (protože občas nějaký peak v zálohování).
Zdar Max

[alkoholik]

Beznym serverovym SSD se bohuzel o DWPD 5 ani nezda. Horsi mivaji kolem 1, lepsi 3.

[Max]

Tak jsem to našel, viděl jsem to u Micronu 5200 MAX (5200_series_product_brief.pdf) a jsou to poněkud levná TLC SSD.
Jinak máš pravdu, většinou mají 1-3DWPD.
Jak moc je ten Micron seriozní nevím :-/, třeba ta fce "Flex capacity" tomu DWPD moc důvěryhodnosti nepřidává :).
Zdar Max

[trekker.dk]

Hm, to mají i jiní výrobci a občas o tom ani neví - tak jsme ten 960GB SSD, co o sobě najednou začal tvrdit, že má kapacitu 960MB, vyreklamovali.

[Max]

Smutný je, že takové věci většinou odchází na pozadí bez toho, aniž by ten SSD něco hodil do SMARTu, jeden den ok, druhý den 2MB kapacita disku (ale to s těmi 2M byla chyba v Intel firmware) :-/
Zdar Max

[trekker.dk]

No jo, ono to s programátory firmwaru disků bude podobné jako s programátory biosů: funguje to? šup s tím do výroby. Na věci, co by bylo dobré, aby ten firmware taky uměl, není čas.

[.]

Skončil jsem u poznámky o swapu. Nikdy nikde nevypínat. Bez diskuze.

[Max]

Já důvod pro jeho deaktivaci u toho konkrétního nasazení uvedl (všude jinde ho mám, i tam, kde není nutný, tak ho mám aspoň se swappiness 10). Pokud chceš nějak konstruktivně diskutovat, tak uveď důvod, proč bych u FreeNASu neměl swap deaktivovat? Je to storage, žádné další nasazení, takže tolik ram, kolik je potřeba a žádný swap. V čem vidíš problém?
Zdar Max