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

[Ruža Becelin]

> Dodavatel doporučoval, abychom koupili 8TB varianty, protože ty už v sobě mají Helium. Disky s ním mají nižší teploty a mnohem menší poruchovost.

Tady souhlasim, navic 8TB disky mivaji nejlepsi pomer cena/TB. Asi jak kde.

My budeme stavet AiO NAS s 48x WD Gold 18TB, tak uvidime. Kazdopadne diky za tipy ohledne podvozku, na EPYCu to planujeme taky, a vypada to, ze jsme vybrali rozumne

[Max]

Také ZFS? Pokud ano, použijete i nějaké SSD na SLOG a jak případně plánuješ skládat pool? Jen se ptám.
Díky
Zdar Max

[Ruža Becelin]

Dobra otazka, pujde na to GlusterFS,ktery normalne provozujeme s XFS, ale jak se divam, ZFS je podporovane, takze tomu dame sanci.

Deska na EPYC ma 1 port na NVMe, kam pujde OS, a 4x SATA + 2x PCIex 4.0, coz nabizi solidni moznosti pro cache.

Rozlozeni poolu (v pripade, ze bychom zvolili ZFS) jeste nemame rozmyslene.

[Pavel Křivánek]

Jak je to s životností takových disků? Helium je potvora a časem zákonitě vyprchá.

[xxxs]

uz su na trhu nejaky cas. zatial nie je problem. moralne zastara skor ako sa stihne prejavit fyzika.

[Max]

Přesně jak píše xxxs. Vypadá to, že mají nižší teploty, menší poruchovost a lepší životnost než normální disky. Ostatně, nedávali by na ně záruku 5 let, kdyby byl s životností nějaký problém.
Osobně bych se toho tedy nebál. Kdybych měl na výběr bez helia a s heliem, tak jdu do helia.
Další věcí je, co je v tom reálně za plyn / v jaké koncentraci. Představa, že je tam čisté helium nemusí být pravdivá (je to jen zamyšlení, nebádal jsem po tom).
Zdar Max

[Ruža Becelin]

Zivotnost je zatim OK, po dvou letech se hladina ani nehnula:

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   133   133   054    Pre-fail  Offline      -       93
  3 Spin_Up_Time            0x0007   158   158   024    Pre-fail  Always       -       417 (Average 416)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       13
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   128   128   020    Pre-fail  Offline      -       18
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       24132
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       13
 22 Helium_Level            0x0023   100   100   025    Pre-fail  Always       -       100
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       1009
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       1009
194 Temperature_Celsius     0x0002   153   153   000    Old_age   Always       -       39 (Min/Max 25/46)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

A jsou rozhodne chladnejsi, nez klasicke disky.

[j]

"...a mít tu komunikaci s diskama failoverovanou. "

Sak to stejne nemas, coz je presne ten rozdil v ty cene proti HP a spol. Mas tam SPOF v podobe MB, CPU, RAMky ... cokoli z toho pojde === pole lehne.

U tech "drahych" poli tam mas proste dve PCcka (vcetne vlastni ramky, cpu a radice) a kazdy jedno muzes vytrhnout a vymenit. Dal je to samo zapojeny do dvou swichu, takze ani tam neni SPOF. A typicky pak nekde za tim mas servery v clusteru, takze ani tam ti neva kdyz neco lehne.

"do pole lze osadit jen disky od WD"

Pokud sem neco neprehlid, tak "JBOD WD Ultrastar Data102" je jen tupa krabice na disky. A tudiz o tom jaky disky ano a jaky ne rozhoduje radic. Takze mozna je to spis "jen disky od WD v ramci supportu".

---

Dete s tim guuglem dopice!

[Max]

Nikdo ale nerozporuje, že pole od NetAppu, HPE aj. jsou failoverovaný ještě dál. To je snad jasný. Jsou to většinou dva plnohodnotné servery, mezi kterými je udělaný buď interní propoj, nebo externí (=kabelové propojení řadičů).
Já jsem jen zmínil rozdíl od předchozího modelu pole, který jsem popisoval v předchozím článku.

Ten JBOD není jen šasi, jak píši, má to OOBM, podporuje to konfiguraci zon a multizon, acl apod. Je pravda, že jsem do toho nezkoušel strčit jiný disk (ani nevím, zda tu jiný mít budu), ale možnosti, jak si to ten jbod může pohlídat, rozhodně má.
Zdar Max

[ET]

neplanujes pak nejaky perf grafiky z provozu, pac mi prijde, ze:

* ten EPYC2 na "par plotnacu" (a jednu vm) jako over-kill

* tem plotnacum uprostred ty "JBOD kastle" bude vedro (i kdyz bude v lednici 20C)

mozna se pletu, jen by me to zajimalo (a chapu, ze to neni investice na 1 rok a nevim, co na tom chces dalsiho v budoucnu provozovat)

jinak to mas pekny ;)

[Max]

Ten EPYC patří mezi nejlevnější CPU, není to žádný megaboost CPU. Jinak zapomínáš na online kompresy a šifrování přenášených dat + musí unést nějakou tu VM a zvládnout topku v podobě 15Gbit trafficu. Velikost záloh je cca podobná jako v předchozím zápisku. Tj. denně cca 2TB a jednou týdně dump 10TB databáze + pár věcí okolo. K tomu mám část vyhrazenou pro obnovu VM, takže částečně přes den to bude sloužít jako úložiště pro testovací VM (testování update/upgrade apod.). Třeba teď tam mám obnovený 6TB emailový systém a dalších 6 VM okolo, který to potřebuje k životu a budu na tom testovat upgrade na novější verze.

Pokud se podívám na aktuální stav těch dvou NVMe, tak už mají za tu chvilku pěkně naběháno:

Critical Warning:                   0x00
Temperature:                        41 Celsius
Available Spare:                    100%
Available Spare Threshold:          0%
Percentage Used:                    0%
Data Units Read:                    20,959 [10.7 GB]
Data Units Written:                 118,014,644 [60.4 TB]
Host Read Commands:                 386,604
Host Write Commands:                477,363,227
Controller Busy Time:               432
Power Cycles:                       11
Power On Hours:                     2,667
Unsafe Shutdowns:                   2
Media and Data Integrity Errors:    0
Error Information Log Entries:      0

Pokud bych se měl vyjádřit k tomu JBODu, tak uvidíme. Teď je tam 42ks disků, teplota nejstudenějšího disku je 28C, teplota nejteplejšího je 45C a větráky JBODu běží snad na nejnižší otáčky.

Zdar Max

[ET]

nice, thx

a mas tam rozjety nejaky monitoring? celkem by me zajimalo, kolik z toho CPU (orientacne) vyuzijes pri tyhle zatezi - tj. 15gbs + komprese (AES[NI] asi nebude cpu killer a je uz celkem bezny)

kolik mas beznou teplotu v lednici (serverovne)? 45C na plotnaci mi prijde uz trochu na hrane, ale kdyz to videj vetraky jinak, tak snad ok

[Max]

V místnosti 18C, zatížení CPU nula nula nic, ale 15Gbit tam ještě v plném proudu nešlo.
Zdar Max

[NUKE GAZA! 🎆]

ato jakoby zustane takle ležet nebo seto strčí do racku nebo pověsí nazeď?? :O :O v těch točicích discích sou mechanický součástky těm je jako jedno když se disky takle třeba natočej vo 90 strupňů?? :O :O

[Josef Kufner]

Není dobré s nima hýbat za provozu, ale jinak to je jedno.

[Max]

I samotné desktopové skříně jsou koncipovány různě. Některé mají uložení disků na ležato, jiné na stojáka. Rozdíl v životnosti by snad neměl být. Někdo by mohl říci, že na stojáka tam bude větší tlak na opotřebení ložisek, ale v reálu jsem neslyšel o tom, že by to měl být problém.
Zdar Max

[j]

"větší tlak na opotřebení ložisek"

Nebude, je to jedno, sak maj stejne vsechny ty loziska fluidni, takze by ke kontaktu vubec dochazet nemelo. A nevadi jim ani to ze bys snima hejbal, pokud nepresahnes mezni Gcka. Pak to odnesou plotny a hlavicky.

Pri tomhle usporadani bych videl problem spis prave v tom, ze ty disky uvnitr budou dostavat naprdel teplotne. Rozdil skorem 20 stupnu mezi vnejsima a vnitrnima je dost a to pocitam ze nic moc nedelaj. Nemyslism si ze by libovolny vetraky byly schopny v tomhle usporadani vyrobit nejakej pruvan.

---

Dete s tim guuglem dopice!

[Josef Kufner]

Mezní G jsou uvedena pro vypnutý stav, kdy se netočí a hlavičky jsou zaparkované. Gyroskopický efekt je ošklivá věc a plotnám se to nebude líbit. Ty hlavičky létají velmi nízko a opravdu nechceš, aby se dotkly povrchu. Není to o tom, že by se disk rozbil jen s ním trochu šoupneš, ale některé notebooky třeba mají akcelerometry a zaparkují hlavičky, když detekují pád. (V dobách SSD už to ale není moc relevantní.)

[johnyK]

my jsme po letech abstinence zase koupili LSI RAID Controler. A vlastne jsem ani nebyl prekvapen, kdyz jsem na chladici zmeril 90 °C. (pro 22 °C okolo - jak to asi bude vypadat v lete?) Na netu jsou miliony stiznosti, ze se vlastne prehrivaji vsechny radice (HP, Dell ...)

Mate take takove zkusenosti? Autor rika, ze LSI zadny problem? Jak je to s teplotami? Me to prijde, ze je to moc, i kdyz v technickych listech jsou teploty kolem 100 °C jeste jako povolene.

[Max]

LSI je dost dobrý HBA, je podporovaný, a co tak slýchám, tak bezproblémový. Osobně ho vídám všude, i integrovaný na supermicro deskách. Pokud jde o ty LSI HBA zmíněné v zápisku, tak teplota je úplně ok:

storcli /c0 show all |grep -i temperature
ROC temperature(Degree Celcius) = 53

storcli /c1 show all |grep -i temperature
ROC temperature(Degree Celcius) = 54

V místnosti chladíme na 18C. volně ložený temp sensor v racku ukazuje 21C.

Problémy s teplotou při běžném provozu jsme snad nikdy nezaznamenali. Jednou se podělali klimatizace a v serverovně bylo asi hodinu kolem 40C, teplota komponent v serverech šla k 80C při plných otáčkách větráčků, a i tak nebyl problém. Jaké byly teploty na řadičích (většinou HPE SmartArray P420i apod.) ale nevím.

Jinak musím říci, že mi máme HBA, ty mluvíš o Raidu, takže tam to bude trochu jiné. Naposledy jsme brali LSI MegaRAID SAS9341-8i, tam jsou teploty kolem 56C (teplota v racku 19,5C).
Zdar Max

[trekker.dk]

a co tak slýchám, tak bezproblémový.

Za mě si udělejte čárku k "problémový" LSI3008 a LSI3108 (provozovaný jako HBA). Musel jsem na discích vypnout zápisovou cache (cache_type = "write through") a NCQ (queue_depth = 1), jinak ten řadič tuhl. Sice ne trvale, ale dost dlouho na to, aby třeba vypadl disk z RAIDu

[Max]

A co to bylo za disky?
Zdar Max

[trekker.dk]

SSD Samsung (SM863 a podobné) - a rotační nějaké Toshiba (podle toho, kdo ještě rotační disky v dané době vyráběl.) U těch SSD se to dělo častěji, co jsem vypátral (byly to teda většinou debaty typu "za úplňku obětujte černou slepici" z různých diskuzí), tak jako největší podezřelý se jevil příkaz k synchronizaci cache disku. Což by odpovídalo, protože na těch SSD leží databáze, takže tenhle příkaz bude častější než u těch rotačních.

[Bebín]

Hezké, ale zastaralé. Měl by ses podívat na CEPH a neřešit věci jako multipath, neflexibilní ZFS nebo úzké hrdlo 10 GBit per stroj.

[Max]

Poskládat podobně výkonné pole na CEPH vyjde o dost dráž a ve finále to pro tento účel nepřinese nic navíc.
Zdar Max

[trekker.dk]

Odstraníte nějaký ten SPOF, ale jinak jo, bylo by to dost drahé.

Nemůžu to teď vyzkoušet - zjistil jsem, že nemám celý testovací cluster zkonvertovaný na bluestore - ale krom ceny bych si tipnul, že by si to ani moc nerozumělo s výkonem. RBD má výchozí velikost bloku 4M a cokoliv menšího AFAIK znamená přepis celého bloku, protože ochranné součty. A dokopat klienty k tomu, aby posílaly 4MB velké bloky, je nereálné, v Linuxu je napevno nastaveno, že disky mají bloky o velikosti 4kB nebo 512B. (Což částečně může pořešit slučování operací, ale jen částečně.)

Plus se zpravidla nepočítá s tím, že "disk" je celý cluster a že se tam mají hrnout požadavky po desítkách.

[Max]

Jinak ještě doplním, že pro menší nasazení ti stačí dva servery jako storage, děláš sync active-pasive, případně active-active (pokud to to řešení umožňuje). Když padne jeden server, nebo jedna lokalita, jsi v pohodě. Aby jsi tento druh failoveru pokryl Cephem, tak v každé lokalitě musíš mít aspoň 3 servery, spíše 4. Je jasné, že Ceph nabízí jiné možnosti, ale je to názorná ukázka toho, jak ta cena/režie nejsou zanedbatelné (8 serverů vs 2, tj. více zabraného místa v racku, více žraní proudu, více žraní/dimenzování klimy na uchlazení místnosti atd.). V případě Cephu může podvádět a mít více nodů na jednom fyzickém železe, ale jaký to pak má reálně smysl, případně budou tam mnohem větší režie na provoz / ten výkon z toho nepůjde vyždímat takový jako u toho ZFS.
Zdar Max

[trekker.dk]

aspoň 3 servery, spíše 4

Ten čtvrtý je IMO navíc, pokud ho nepotřebujete kvůli kapacitě.

Jinak pár let zpátky jsem byl na nějaké konferenci o úložištích - o Cephu tam mluvili nejvíc - a někdo z přednášejících měl spočítáno, že pokud z Cephu stavíte úložiště za účelem, který vám pokryje blackbox za půl milionu, tak se ten Ceph finančně nevyplatí. Zlom byl někde okolo 750 tisíc a nad to už Ceph vyšel cenově lépe. (Snad si ta čísla pamatuju dobře.)

výkon z toho nepůjde vyždímat takový jako u toho ZFS

AFAIK Ceph nemá nic jako SLOG. (Teď jsem našel, že je to ve vývoji.) Má tiering, ale v dokumentaci je u toho hromada varování, že to s ním bude spíš horší, pokud zátěž není přesně taková, na jaké to bude fungovat

[Max]

Ten zlom 750k podle mě neodpovídá, bude mnohem vyšší, tedy pokud budeme chtít být k těm jiným řešením féroví. Pokud stavím něco od nějakého vendora, tak věř, že sundat z pricelistu 70% i více nemusí být problém.
Zdar Max

[trekker.dk]

Jak jsem koupil, tak prodávám - teda jak říkám, pokud si ta čísla pamatuju dobře, ale určitě to bylo pod 1M. A nemyslím si, že to bylo porovnáváno s ceníkovou cenou těch blackboxů.

Jinak jsem udělal výkonový pokus - rsync adresáře, ve kterém mám zdrojáky, tj. spousta malých souborů a git archivy, z pracovního stroje na zálohu - filesystém připojený na RBD. Změny asi za 3/4 roku:

sent 91,362,212 bytes received 385,674 bytes 423,777.76 bytes/sec

Oproti tomu ten samý rsync z jednoho adresáře pracovního stroje do jiného:

sent 91,362,533 bytes received 385,716 bytes 425,745.94 bytes/sec

Docela dobrá náhoda, že to vychází skoro stejně, ale je potřeba vzít do úvahy, že v tom druhém případě se na tom pracovním stroji zároveň zapisuje i čte, takže výkon RBD cca poloviční

[plostenka]

RBD je urcene na zviditelneni pole pres sit, takze pochopitelne na localhostu bude mit mizerny vykon v porovnani s lokalnim RAIDem.

[trekker.dk]

To samozřejmě ano, nicméně i když se síť vyloučí, tak ten výkon je furt horší než lokální disky. A je to z principu, zaokrouhlení zápisů na 4MB nahoru se prostě někde poznat musí.

[trekker.dk]

Používám tedy nativní šifrování a online kompresy.

Vizte poslední odstavec v https://www.abclinuxu.cz/blog/Max_Devaine/2019/9/zfs-stavba-zkusenosti-se-zfs-storage#2

[Max]

No tvl, zásah do černého. Je vidět, že v případě jazyků nebudu nikdy patřit mezi nejostřejší pastelky v penále :-/
Zdar Max

[cbrpnk]

Chcel som pôvodne písať blogový zápisok o nasadení TrueNAS Core na zálohovaci server pre malú firmu (HP Microserver Gen 8 i3 s 8BG RAM + 256GB NVME cache + 3 x 8TB HDD (14TB space) v RAIDZ1) ale nejako ma to prešlo

[Ruža Becelin]

Proc? Kazda zkusenost dobra

[loco]

No, mě by to i zajímalo, nejsem v tom moc kovanej. Mám Microserver Gen8, tu zeleninu 1610T jsem vyměnil za Xeon E3 1220L V2, a mám tam 8GB RAM. Dřív jsem jel RedHat 7.x, pak jsem přešel na FreeNAS (ZFS), a teď jedu už nějakou dobu debian. Mám tem jenom nextcloud plus nějaký nfs a smb share. Stačila by ta RAM pro to ZFS? Mě to s tím vycházelo celkem na hraně dle doporučení, a to jsem tam měl pouze 2xTB disky, ale zase žádnej velkej nápor uživatelů nehrozil. FreeNAS jsem opustil proto, že se mi v té době nepodařilo rozjet nextcloud v té virtualizaci s certifikátem ..., a taky jsem si myslel že mám potřebu běhu dalších virtualizovaných kontejnerů v dockeru, a na linuxu mi to přišlo jednodušší.

[Max]

Jak reálně s pamětí máš myslím přehledně popsáno v minulém zápisku: Kolik je potřeba paměti?.
Pokud jde o ZFS, tak to si můžeš provozovat i na tom Debianu.
Zdar Max

[loco]

Díky, to jsem přehlédl.

Mrkl jsem na to a to doporučení v tom předchozím zápisku, odpovídá tomu co doporučoval Freenas, pro 8TB ~ 8GB za předpokladu nízké režie os. Co mě spíš děsí, že když dojde RAM tak se to sesype... Když bych to osadil 4x4TB, tak jsem na tom co to zhruba alokovalo dle zápisku. K tomu tam byl tenkrát ten Celeron... S problémy s ext4fs si umím poradit ale zfs moc ošahané nemám. Teď mám problém, že na Big Sur mi přestal jet time machine na nfs share a lidi co to rozchodili, měli úspěch jenom na zfs a možná btrfs. Proto o něm zase uvažuji, ale přidávat paměť na to domácí nasováni se mi moc nechce, už jenom nové disky budou pěkných pár tisíc.

Žďár, jdu na to mrknout hlouběji.