ZFS : Stavba a zkušenosti se ZFS storage

18.5.2020 12:56 | Přečteno: 8873× | linux | | poslední úprava: 3.3.2021 01:15

Trocha historie, jak funguje ZFS, na co si dát pozor, zkušenosti ze 4 let provozu low cost zfs storage atd.

• Co je to ZFS
• Jak je koncipován ZFS
• Big storage na zálohy s možností instant recovery
• Specifikace HW a složení pole
• FreeNAS aneb ZFS střední cestou
• FreeNAS a swap
• FreeNAS a šifrování
• ZIL a SLOG
• Proč 1x Intel Optane?
• SLOG na SSD : Jak moc je výkon znát?
• Jak je to s výkonem takového storage / IOPS?
• Vliv výkonu u fragmentace a zaplnění
• Výkon čtení - single thread / multi thread
• Životnost disků a chybování
• Chyby
• Počty reklamací
• Jak se mění disk
• Jak se chová pole s vadným diskem
• Kolik je potřeba paměti?
• Reálně využitá paměť
• Deduplikace
• Na co si dát pozor
• Bacha na dostatek ram
• Bacha na řadiče
• Bacha na použitý typ pole
• Pečlivý výběr HW
• Co bych použil aktuálně za železo?
• Diagnostika a statistiky
• Komerční řešení storage se ZFS
• Závěr

Co je to ZFS

ZFS (Zettabyte File System) je souborový systém vyvinutý firmou Sun Microsystems. Ze začátku probíhal vývoj uzavřeně v rámci Solarisu. ZFS byl vypuštěn na světlo v rámci projektu OpenSolaris v roce 2005 pod licencí CDDL, která není kompatibilní s GPL licencí. V roce 2007 zažaloval NetApp firmu Sun, protože údajně došlo k porušení patentů NetAppu, který vyvíjel WAFL filesystém (Write Anywhere File Layout). V této souvislosti na oplátku zažaloval Sun firmu NetApp. Soud byl ukončen v roce 2010 vyrovnáním, ohledně kterého nejsou známy žádné další podrobnosti.

V roce 2010 koupil Oracle firmu Sun. Mj. projekty Solaris a ZFS tedy přešly pod křídla Oracle. Oracle zrušil OpenSolaris a vývoj začal pomalu uzavírat.
V roce 2013 proto vznikl projekt OpenZFS, který si kladl a klade za cíl spojit vývoj ZFS pro Illumos(vychází z projektu OpenSolaris), FreeBSD, Linux, MAC OS a Windows. Nad tímto projektem je postaveno spousta komerčních řešení a sponzoruje jej nemálo firem. V současné době tedy nejsou na místě obavy z toho, že by podpora ZFS zanikla.

Výhody a vlastnosti ZFS jsou :

• podpora kontrolních součtů na úrovni dat i metadat, což zaručuje hodně pěknou úroveň konzistence dat
• podpora CoW (copy on write)
• podpora snapshotů
• obsahuje volume manager (kompletní správu blokových zařízení) včetně podpory vdev mirror (aka RAID1), RAIDZ (aka RAID5), RAIDZ2 (aka RAID6), RAIDZ3
• dokáže definovanou část exportovat jako blokové zařízení (hodí se třeba pro iSCSI)
• podporuje široké možnosti nastavení a nástrojů pro monitoring a kontrolu jako třeba scrub, zobrazovaní datových toků, iops apod.
• výkon jde vylepšovat přidáním ssd jako cache, a to buď pro zápis (ZIL/SLOG) nebo jako random read cache (L2ARC)
• umožňuje rychlý přístup k metadatům, protože si je přednačítá do ram (tato fce je součástí ARC) a stejně tak umí dopředné i zpětné cachování pomocí fce zfetch
• podporuje online kompresi
• podporuje šifrování (jen na některých OS)
• podpora replikace (přenos jen změněných dat včetně snapshotů na vzdálený ZFS storage)
• podpora deduplikace
• hodně slušné řízení IO
• pomocí ZFS lze postavit obrovské pole v řádu PiB při zachování rozumného výkonu a redundance disků

Aby to nevypadalo moc dokonale, má i nějaké nedostatky :

• když disk přidáme do pole, už ho neodebereme (=nejde zmenšit kapacita, člověk prostě musí přemýšlet nad návrhem, kterého se do budoucna musí držet). To je hlavně problém začátečníků. Ti, co už mají nějaký skill vědí co a jak. Relativně nedávno byla implementována obezlička, která umožňuje odstranit vdev ze zpoolu, ale není to úplně košér, viz : Odstranění vdev z ZFS poolu
• snapshoty jsou jen v read-only režimu a práce s nimi není tak komfortní jako u btrfs
• je vyžadováno hodně ram
• podpora v linuxu je dostatečná, i když pár věcí ještě chybí a na pár si je dát třeba pozor, ale odporuje GPL licenci, takže i když z technického hlediska problém není, je problém z hlediska morálního. Pokud Oracle neuvolní ZFS pod licencí kompatibilní s GPL, tak Linux bude mít smůlu.
• asi jedinou slabinou v kontrole integrity dat je to, že na data v ram se neaplikují checksummy, proto jsou nutné ECC paměti

Zajímavé shrnutí ZFS vs BTRFS je v tomto blogu : Btrfs vs ZFS – srovnání pro a proti

Pokud bych já osobně měl srovnávat btrfs se zfs, tak řeknu, že to je zatím nesrovnávatelné. Nepřijde mi, že by si tyto dva FS nějak konkurovaly, tedy zatím. ZFS je dělaný pro big storage, což btrfs nedává a dávat zfs na něco malýho také není nejrozumnější. Každopádně nechám zde prostor pro diskusi. Budu jen rád, když někdo v diskusi ukáže, jak podobný storage tomu, co popíšu, postavit na btrfs. Osobně si myslím, že to nejde udělat nějak rozumně.

Jak je koncipován ZFS

Máme samotné disky, ze kterých uděláme vdev. Vdev je něco jako RAID pole. Tzn., že můžeme použít mirror, raidz, raidz2, raidz3. A tyto vdevy se vkládají to poolu. Když máme vytvořen pool, tak v rámci něj vytváříme datasety. A do těchto datasetů pak už zapisujeme data (adresáře, soubory atd.). Dataset je tedy něco jako hlavní adresář, nad kterým si můžeme zapínat online kompresi, dělat snapshoty atd. Pokud jednou vytvoříme vdev z 5 disků a dáme do poolu, tak už ten vdev neodebereme. Stejně tak nelze ten vdev ponížit např. o jeden disk a nechat v něm jen 4 disky. Jak to ze začátku nastavíme, tak už s tím nehneme a musíme pokračovat v tom, co jsme započali.

ZFS si pak spoustu věcí cachuje do ram do ARC (Adaptive Replacement Cache).

Tady se můžete podívat na velmi základní schema, jak je ZFS koncipováno :

Big storage na zálohy s možností instant recovery

Když se bavíme o storage na zálohy, tak chceme hlavně velkou kapacitu, ale i nějaký rozumný výkon v IOPS kvůli paralelním operacím. Nechceme třeba vypínat zálohování, když potřebujeme něco rychle obnovit. Nebo když chceme udělat instant recovery nějaké VM (= spustit VM ze zálohy a pak live migrací přelít zpět na produkční storage).

Pro tento účel jsem vybral zlatou střední cestu. Tzn. storage založený na enterprise SATA diskách. Konkrétně jsem šel cestou 4TB WD RE4(později WD Gold, WD Ultrastar DC HC310, Toshiba MG04). Je to sice dražší, než desktop disky, ale lépe se chovají při chybách, mají 5 let záruku a jsou levnější jak SAS disky a výkon je přitom rozumný. Kdybych stavěl produkční storage pro ostré app, tak bych šel rozhodně do SAS disků, resp. dnes už čistě do SSD pole.

Specifikace HW a složení pole

Board : X10DRW-iT (2x CPU, Intel® X540 Dual port 10GBase-T, 10x SATA3, IPMI, SUB3) - u této WIO základní desky fungují s jedním CPU jen sloty 3 a 4 na levé straně

Case : SuperChassis 847BE1C-R1K28WB, 36x (24 front + 12 rear) 3.5" hot-swap, Redundant 1280W Platinum Level (1+1)

2x Intel Xeon E5-2620 v3 @ 2.40GHz (6 core, 12 threads)

4x 16GiB DDR4 2133MHz 2Rx4 (64GiB) - (Samsung M393A2G40DB0-CPB)

4x 32GiB DDR4 2133MHz 2Rx4 (128GiB) - (Samsung M393A4K40BB0-CPB)

1x Intel X520-DA2 (Cabling Type - SFP+ Direct Attached Twin Axial Cabling up to 10m)

1x LSI SAS 9300-8i SGL

Left riser card : [RSC-R2UW-4E8]

Right riser card: [RSC-R1UW-E8R]

Intel Optane 900p PCI-E 480GB

ZFS pool je poskládaný takto :
4x RAIDZ2, každý z 8xSATA 4TB + společný 1x spare
Víc, jak 8 SATA disků v jednom RAIDZ2 bych nepoužíval. Je to kombinace kapacity a rozumné redundance disků. Dále nechci dělat žádné divočiny, takže jakékoli rozšiřování pole chci dělat ve stejném duchu. Pokud tedy teď jedu RAIDZ2 z 8x SATA, tak při rozšiřování pole skákat opět po 8x SATA je celkem rozumné.

Výsledkem je tedy 128TB RAW pole, použitelných je 96TB, resp. je třeba i myslet na to, že by se nemělo jít nad 80% zaplnění, takže reálně máme k využití 77-80TB a větší zaplnění raději nepřekračovat.

FreeNAS/TrueNAS aneb ZFS střední cestou

Nejnativnější je ZFS na Solaris like systémech. Problém těchto OS je ale v přecijen o něco menší podpoře HW. ZFSonLinux má stále několik nedostatků a pak je tu ten licenční problém. Jako operační systém jsem tedy zvolil FreeNAS (tzn. FreeBSD). Důvodů bylo několik. Jednak pomohl ze začátku web ksicht pochopit celou filozofii ZFS a další věci, dále možnost správy mých neunixových kolegů (jako vždy se ukázalo, že to je zbytečné, protože nikdo jiný nemá potřebu ani vůli na to sahat), poté kvůli dobrému přehledu a statistikám a nakonec a hlavně kvůli tomu, že lidi od projektu FreeNAS mají ZFS vytuněné lépe, než to, co je v core FreeBSD. Když bych měl stavět další storage, nešel bych do čistého FreeBSD, ale opět do FreeNAS.

FreeNAS a swap

FreeNAS si každý disk rozdělí a na začátek si dá malý oddíl, který používá jako swap. Ve finále tedy máme třeba 30 disků a u každého první 2GB jsou použity jako swap. Osobně tuto filozofii nechápu, protože jakmile disk odejde do věčných lovišť, tak storage jde 100% do kolen (dokonce mám i osobní zkušenost). Doporučuji si dělat dobrý sizing, mít dost ram, neprovozovat na FreeNAS různé pluginy, co žerou ram atd. a hned po instalaci FreeNAS si v jeho nastavení vypnout vytváření swap oddílů a jet čistě bez swapu. Pokud už je pozdě a swap máte vytvořen, není nic jednoduššího, než příslušné partition ze swapu odebrat a tím i swap zrušit.

FreeNAS a šifrování

Pokud chcete šifrovat data, tak s tím musíte začít od začátku, tj. zvolit tuto možnost při vytváření poolu. Šifrování se totiž dělá nad blokovým zařízením (geli), protože FreeBSD nemá v ZFS podporu šifrování (zdroj). Zajímavé je, že ZFSonLinux tuto podporu již má. Pokud máte vytvořený pool a už máte produkční provoz, tak přejít na šifrování není jednoduché. Jeden z postupů je si vždy zašifrovat nový disk a pak ho prohodit za jiný v poolu. Ten, co byl prohozen pak zašifrovat a opět prohodit s jiným diskem v poolu a tak stále dokola, dokud nebudou všechny disky zašifrovány (jde to, ale dře to).

ZIL a SLOG

ZFS má ZIL (ZFS Intent Log). Ten se používá v případě sync zápisů. To jsou ty, u kterých se musí čekat, až pool odpoví, že je vše zapsáno na disky. To bývá někdy pomalé, obzvláště pokud máme pomalý pool. Proto se nejdříve zápis provede do ZIL, potvrdí se zápis a pak na pozadí se to zapíše do poolu. Dalo by se tedy říci, že to je něco jako journal u journalovacích FS (ext3/ext4/reiserfs/ntfs apod.)

ZFS ale umožňuje tento ZIL umístit bokem na jiné zařízení. Tomu se pak říká SLOG (Separate Intent Log). Je tedy vhodné pro SLOG mít vyčleněný nějaký rychlý SSD disk. A protože se jedná o data, která jsou již potvrzena a brána tak, že jsou zapsána, tak je nutné si SLOG dostatečně chránit. Není tedy moc vhodné jej mít jen na jednom SSD, ale vytvořit si vdev (mirror) dvou SSD. Toto opatření ale nestačí. Je také třeba volit vhodné SSD. Pokud pole stavíme pro kritické aplikace, tak je dobré zainvestovat do SSD, které mají Power Loss Protection (zaručují, že výpadkem proudu nepřijdete o jediný bit dat).

Proč 1x Intel Optane?

Do tohoto SSD jsem šel z několika důvodů. První je to, že současný řadič nepodporuje připojení SSD přes U.2 / NVMe. Druhým důvodem byla relativně hodně slušná životnost na přepisy i latence a parádní cena. Pokud bych chtěl něco takového ze světa MLC, musel bych si také nemálo zaplatit. Nicméně tento SSD používám v menším risku. První risk je v tom, že tento Optane nemá power loss protection. Druhý malý risk je v tom, že mám jen jeden Optane jako SLOG. Každopádně jedná se o backup storage pověšený na 2x 10kVA UPS, takže si to lajznu. U produkčního storage, kde by měly běžet ostré služby, bych to řešil určitě dvěma SSD pro SLOG (pokud bych pole neskládal z SSD, ale rotačních disků).

SLOG na SSD : Jak moc je výkon znát?

Celkem hodně. A kdo nemá SSD na otestování, může si trochu zariskovat a v rámci testování si může vytvořit SLOG z ramdisku a porovnat výkon BEZ a S. Jak na to viz :

# vytvořit ramdisk :
mdconfig -a -t swap -s 32g -u 1

# přidat do zpoolu jako SLOG :
zpool add datastore1 log md1

-------

# odebrání ze zpoolu :
zpool remove datastore1 md1

# zrušení ramdisku :
mdconfig -d -u 1

Jak je to s výkonem takového storage / IOPS?

Je třeba si uvědomit, že vdev (ať mirror, nebo RAIDZ) má výkon IOPS v zápisu na úrovni 1xHDD. Je to dáno tím, že při zápisu se čeká vždy na všechny disky ve vdevu, až dokončí operaci. Výše mám tedy poskládaný pool z 4x RAIDZ2, takže v IOPS mám výkon 4x 80-150IOPS. Reálně díky cache a pár věcem kolem není problém dlouhodobě vykrývat přes 5k IOPS. Storage mám stále pod zátěží, aktuálně na něm nouzově běží jedna celkem diskově náročná VM (šmejďárna, co se snaží permanentně žrát 300-500IOPS), takže tento test je třeba brát jen jako malou indicii :

root@storage:# fio --randrepeat=1 --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=40G --readwrite=randrw --rwmixread=75
test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=64
fio-3.5
Starting 1 process
test: Laying out IO file (1 file / 40960MiB)
Jobs: 1 (f=1): [m(1)][99.4%][r=149MiB/s,w=50.6MiB/s][r=38.2k,w=12.9k IOPS][eta 00m:03s]
test: (groupid=0, jobs=1): err= 0: pid=25346: Fri Apr 24 21:22:45 2020
   read: IOPS=16.6k, BW=64.7MiB/s (67.9MB/s)(29.0GiB/474686msec)
   bw (  KiB/s): min=29780, max=329121, per=99.49%, avg=65927.84, stdev=23640.12, samples=949
   iops        : min= 7445, max=82280, avg=16481.60, stdev=5910.01, samples=949
  write: IOPS=5522, BW=21.6MiB/s (22.6MB/s)(10.0GiB/474686msec)
   bw (  KiB/s): min=10451, max=109844, per=99.49%, avg=21977.88, stdev=7939.04, samples=949
   iops        : min= 2612, max=27461, avg=5494.12, stdev=1984.76, samples=949
  cpu          : usr=2.80%, sys=88.62%, ctx=655585, majf=0, minf=0
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=7864104,2621656,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=64.7MiB/s (67.9MB/s), 64.7MiB/s-64.7MiB/s (67.9MB/s-67.9MB/s), io=29.0GiB (32.2GB), run=474686-474686msec
  WRITE: bw=21.6MiB/s (22.6MB/s), 21.6MiB/s-21.6MiB/s (22.6MB/s-22.6MB/s), io=10.0GiB (10.7GB), run=474686-474686msec

Vliv výkonu u fragmentace a zaplnění

ZFS si fragmentaci dat řeší samo online. Stav fragmentace lze zjistit takto :

root@storage~ # zpool list datastore1
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
datastore1   116T  91.7T  24.3T        -         -    27%    79%  1.00x  ONLINE  /mnt

# nebo
root@storage:~ # zpool get capacity,size,health,fragmentation datastore1
NAME          PROPERTY       VALUE   SOURCE
datastore1    capacity       79%     -
datastore1    size           116T    -
datastore1    health         ONLINE  -
datastore1    fragmentation  27%     -

Pokud jde o zaplnění diskového prostoru, udává se, že se nesmí přešvihnout 80% zaplnění. Poté jde výkon dolu a začne stoupat fragmentace. Nicméně pozor, těch 80% se netýká všech možných nasazení. Lze se třeba dočíst, že v případě provozu VM, kde bude jako storage backend ZFS, je nejlepší používat vdev mirror a nepřesáhnout zaplnění 50%. Důvod je ten, že takové nasazení je náchylnější na fragmentace a degradaci výkonu. Toto samozřejmě platí, pokud budeme mít pole poskládané z magnetických disků, u kterých je fragmentace problém. Osobně jsem ale toto nikdy neřešil, takže nemohu potvrdit, jak moc reálný dopad to má.

Zajímavá diskuse na toto téma je zde :
Some differences between RAIDZ and mirrors, and why we use mirrors for block storage

Výkon čtení - single thread / multi thread a vdev mirror vs raidz

Zde odkážu jen na tento zajímavý thread :
ZFS read performance of mirrored VDEVs

Životnost disků a chybování

Životnost kontroluji přes SMART. Dělám jednou týdně long SMART testy, ale přemýšlím o jejich zbytečnosti (jak z podstaty, tak z hlediska zbytečného performance impactu). Ten storage je celkem vytížený (denně se zapíše cca 2TiB dat a jednou týdně backup menší 7TiB databáze navrch), takže se kontroluje neustále to, co se stejně už děje věčným čtením a zápisy. Přemýšlím, že ty long testy stopnu a nebudu je už dělat a nechal bych jen shorty. Uvidíme, zatím je to jen ve stádiu úvah.

Pokud jde o scrub (kontrolu konzistence dat celého poolu), tak tu dělám jednou měsíčně. Pokud vypnu SMART long testy, tak to zkrátím na 14 dní.
Poslední scrub praví toto (trval jeden den, takže kromě toho, že na tom běží jedna VM, se tam zapsal ještě i denní backup) :

root@storage:~ # zpool status datastore1
  pool: datastore1
 state: ONLINE
  scan: scrub repaired 2.45M in 1 days 08:08:57 with 0 errors on Mon Apr 20 08:09:06 2020
config:

        NAME                                            STATE     READ WRITE CKSUM
        datastore1                                      ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/2a663563-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/2e3c3fd6-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/313dc33b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/33f0312b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/3595c593-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/36530c30-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/b3cfb3ce-4997-11e9-9147-0cc47a34a53a  ONLINE       0     0     0
            gptid/3bd6c7cc-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-1                                      ONLINE       0     0     0
            gptid/72a6e04c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/75edbf3c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/77f2aba2-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7a9a7a58-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7e27cce7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7ff754a7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/80a703cb-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/8153ec3f-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-2                                      ONLINE       0     0     0
            gptid/aa1f9e5a-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b19b82c6-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b6cf9f02-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/be2876dc-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c3568f08-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c92abbc7-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d0774cf2-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d630b1bb-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
          raidz2-3                                      ONLINE       0     0     0
            gptid/baed7380-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bbadca4c-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bc618666-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bd17e6d3-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bdd28194-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/be8e40c6-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bf443662-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/917fe6ed-d60b-11e9-9c34-0cc47a34a53a  ONLINE       0     0     0
        logs
          gptid/94428971-570e-11ea-af91-0cc47a34a53a    ONLINE       0     0     0

errors: No known data errors

Je tedy vidět, že našel a opravil 2,45MiB nekonzistencí. Smysl to tedy má značný. Konzistenci databázových dumpů (600GiB) ověřuji většinou 1x za 14 dní, kdy dělám full db restore do testovacích databází a nikdy žádný problém. Restore záloh VM taktéž dělám (jakékoli větší updaty nebo změny si nejdříve otestuji v testovacím prostředí)

Pokud jde o replace vadného disku za nějaký jiný, tak u poslední výměny mám poznamenáno (storage byl vytíženější a snad jsem ani v té době neměl SLOG) :

resilvered 2.62T in 0 days 15:03:27 with 0 errors

Chyby

Disky většinou nechávám skoro dožít, nějaký občasný realokace mně nechávají klidným. Aktuálně mám špatný toto a zatím mně to nijak extrémně netrápí :

1) Tři disky občas mají tento problém (příklad z da9):

(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 cc 6c 7c a8 00 00 01 00 00 00 
        (da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 28 ed 2c 90 00 00 00 20 00 00 length 16384 SMID 213 terminated ioc 804b l(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
oginfo 31080000 scsi 0 state 0 xfer 0
        (da9:mpr0:0:17:0): WRITE(16). CDB: 8a 00 00 00 00 01 d1 c0 ba 90 00 00 00 10 00 00 length 8192 SMID 722 terminated ioc 804b l(da9:oginfo 31080000 scsi 0 state 0 xfer 0
mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 cc 6c 7d a8 00 00 01 00 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 cc 6c 7e a8 00 00 00 e8 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): WRITE(6). CDB: 0a 00 02 90 10 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 cc 6c 80 90 00 00 00 80 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(10). CDB: 28 00 be 3d 0b 58 00 01 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(10). CDB: 28 00 be 3d 0c 58 00 00 c0 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): READ(16). CDB: 88 00 00 00 00 01 28 ed 2c 90 00 00 00 20 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command
(da9:mpr0:0:17:0): WRITE(16). CDB: 8a 00 00 00 00 01 d1 c0 ba 90 00 00 00 10 00 00 
(da9:mpr0:0:17:0): CAM status: CCB request completed with an error
(da9:mpr0:0:17:0): Retrying command

2) U dvou paměťových modulů se občas objeví chybka (až bude time odstávky, zkusím je prohodit, pokud nepomůže, půjdou na reklamaci):

MCA: Bank 7, Status 0x8c00004000010090
MCA: Global Cap 0x0000000007000c16, Status 0x0000000000000000
MCA: Vendor "GenuineIntel", ID 0x306f2, APIC ID 16
MCA: CPU 12 COR (1) RD channel 0 memory error
MCA: Address 0x2bf837e100

3) SMART pár disků ukazuje, že je možná čas řešit reklamaci (zbytek je ok, tzn. 0 realokací a žádné chyby ve SMART error logu) :

da13
Reallocated_Sector_Ct : 107
Reallocated_Event_Count : 4

da14
Reallocated_Sector_Ct : 41
Reallocated_Event_Count : 1

da20
Reallocated_Sector_Ct : 64
Reallocated_Event_Count : 45

Zatím pošlu da20, protože začíná dost často vyhazovat v logu "CCB request completed with an error" a těch realokovaných eventů už má fakt dost. První dva jsou zatím ok, resp. nejsou, ale je to zatím v klidu (= neohrožují provoz). Nicméně vzhledem k tomu, že se blíží konec záruky, je otočím také.

4) Takto to vypadá, když už i ZFS si všimne vadného disku :

root@storage:~ # zpool status datastore1
  pool: datastore1
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: http://illumos.org/msg/ZFS-8000-9P
  scan: resilvered 10.3M in 0 days 00:00:25 with 0 errors on Sun May 2 04:47:59 2019
config:

        NAME                                            STATE     READ WRITE CKSUM
        datastore1                                      ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/2a663563-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/2e3c3fd6-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/313dc33b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/33f0312b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/3595c593-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/36530c30-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/b3cfb3ce-4997-11e9-9147-0cc47a34a53a  ONLINE       0     0     0
            gptid/3bd6c7cc-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-1                                      ONLINE       0     0     0
            gptid/72a6e04c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/75edbf3c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/77f2aba2-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7a9a7a58-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7e27cce7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7ff754a7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/80a703cb-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/8153ec3f-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-2                                      ONLINE       0     0     0
            gptid/aa1f9e5a-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b19b82c6-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b6cf9f02-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/be2876dc-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c3568f08-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c92abbc7-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d0774cf2-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d630b1bb-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
          raidz2-3                                      ONLINE       0     0     0
            gptid/baed7380-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bbadca4c-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bc618666-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bd17e6d3-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bdd28194-497b-11e9-b585-0cc47a34a53a  ONLINE       0    41     0
            gptid/be8e40c6-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bf443662-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/917fe6ed-d60b-11e9-9c34-0cc47a34a53a  ONLINE       0     0     0
        logs
          gptid/94428971-570e-11ea-af91-0cc47a34a53a    ONLINE       0     0     0

errors: No known data errors

SMART pak u takového disku vypadá takto :

  1 Raw_Read_Error_Rate     0x002f   199   162   051    Pre-fail  Always       -       8
  3 Spin_Up_Time            0x0027   151   151   021    Pre-fail  Always       -       11441
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       25
  5 Reallocated_Sector_Ct   0x0033   195   195   140    Pre-fail  Always       -       180
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   053   053   000    Old_age   Always       -       34549
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       25
 16 Total_LBAs_Read         0x0022   011   189   000    Old_age   Always       -       635193355198
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       23
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       1
194 Temperature_Celsius     0x0022   109   103   000    Old_age   Always       -       43
196 Reallocated_Event_Count 0x0032   190   190   000    Old_age   Always       -       10
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       20

Počty reklamací

Jak vidíte výše, zas tak moc si z malého zaškobrtnutí nelámu hlavu (hlavně proto, že používám ZFS, jinak bych si to nelajz). Dřív stačilo 50 realokovaných sektorů a už disk šel. Jo, kdyby to nebyl backup storage, tak bych tam ani jeden z těch tří disků už neměl. Za 4 roky provozu jsem reklamoval celkem 6 disků a ty tři výše půjdou teď. Zde je ale třeba si uvědomit jednu věc. Nemám od začátku takové rozložení disků ani to SSD jako SLOG. Ty disky jsem někdy dost silně zatěžoval a měl pod 100% zatížením celkem dlouho. Kdybych měl od začátku rozložení jako teď + ten Optane, tak si myslím, že by jich doteď odešly(=vykazovaly chyby) třeba jen dva a né 9.

Jak se mění disk

Uděláme replace (nedělá se fullscrub, překopírují se jen data toho disku na nový / náš spare disk). Následně si rozsvítím červenou diodu na šasi u disku, který chci vyměnit pomocí příkazu :

# zapnout led na kleci
sas3ircu 0 locate 2:8 ON

Až disk vyměním za nový (do budoucna bude dělat spare, jelikož jsme replace udělali s náhradním diskem), tak červenou led vypnu :

# vypnout led na kleci (když dáme nový disk)
sas3ircu 0 locate 2:8 OFF

Jak se chová pole s vadným diskem

Existují případy, kdy disk vykazuje drobné chyby a nebo úplně vypadne a odmlčí se. To jsou ty lepší případy. Pak je zde případ, kdy disk je silně poškozen, ale ještě se drží a funguje s velkou chybovostí. Poté si toho všimne ZFS :

root@storage:~ # zpool status datastore1
  pool: datastore1
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu May 7 10:17:45 2019
        26.6T scanned at 3.63G/s, 19.6T issued at 1.56G/s, 102T total
        0 resilvered, 19.29% done, 0 days 15:00:13 to go
config:

        NAME                                              STATE     READ WRITE CKSUM
        datastore1                                        ONLINE       0     0     0
          raidz2-0                                        ONLINE       0     0     0
            gptid/2a663563-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/2e3c3fd6-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/313dc33b-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/33f0312b-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/3595c593-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/36530c30-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/b3cfb3ce-4997-11e9-9147-0cc47a34a53a    ONLINE       0     0     0
            gptid/3bd6c7cc-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
          raidz2-1                                        ONLINE       0     0     0
            gptid/72a6e04c-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/75edbf3c-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/77f2aba2-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/7a9a7a58-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/7e27cce7-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/7ff754a7-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/80a703cb-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/8153ec3f-3a91-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
          raidz2-2                                        ONLINE       0     0     0
            gptid/aa1f9e5a-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/b19b82c6-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/b6cf9f02-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/be2876dc-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/c3568f08-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/c92abbc7-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/d0774cf2-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
            gptid/d630b1bb-5aa1-11e9-81fa-0cc47a34a53a    ONLINE       0     0     0
          raidz2-3                                        ONLINE       0     0     0
            gptid/baed7380-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/bbadca4c-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/bc618666-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/bd17e6d3-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            replacing-4                                   ONLINE       0     0 6.08K
              gptid/bdd28194-497b-11e9-b585-0cc47a34a53a  ONLINE     259   711     0
              gptid/8bb2c39b-95ad-11ea-af91-0cc47a34a53a  ONLINE       0     0     0
            gptid/be8e40c6-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/bf443662-497b-11e9-b585-0cc47a34a53a    ONLINE       0     0     0
            gptid/917fe6ed-d60b-11e9-9c34-0cc47a34a53a    ONLINE       0     0     0
        logs
          gptid/94428971-570e-11ea-af91-0cc47a34a53a      ONLINE       0     0     0

Ve výpisu vidíte pokus udělat replace. Ten ale nikdy nedojde a zpomalý pool. Je tam vidět, že chybovost při čtení i zápisu je opravdu velká. Řešením v takovém případě je vykašlat se na probíhající replace, vyndat vadný disk, detachnout nový

zpool detach datastore1 /dev/gptid/8bb2c39b-95ad-11ea-af91-0cc47a34a53a

který jsme pro replace použili a provést replace s tímto diskem znovu s tím, že už tam nebude původní vadný disk a replace tak bude za chybějící disk. Výsledný replace pak bude o dost rychlejší :

root@storage:~ # zpool status datastore1
  pool: datastore1
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon May 10 09:50:11 2019
        57.9T scanned at 2.91G/s, 48.3T issued at 1.75G/s, 104T total
        425G resilvered, 46.30% done, 0 days 09:04:23 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        datastore1                                      ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/2a663563-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/2e3c3fd6-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/313dc33b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/33f0312b-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/3595c593-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/36530c30-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/b3cfb3ce-4997-11e9-9147-0cc47a34a53a  ONLINE       0     0     0
            gptid/3bd6c7cc-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-1                                      ONLINE       0     0     0
            gptid/72a6e04c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/75edbf3c-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/77f2aba2-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7a9a7a58-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7e27cce7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/7ff754a7-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/80a703cb-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/8153ec3f-3a91-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
          raidz2-2                                      ONLINE       0     0     0
            gptid/aa1f9e5a-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b19b82c6-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/b6cf9f02-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/be2876dc-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c3568f08-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/c92abbc7-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d0774cf2-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
            gptid/d630b1bb-5aa1-11e9-81fa-0cc47a34a53a  ONLINE       0     0     0
          raidz2-3                                      ONLINE       0     0     0
            gptid/baed7380-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bbadca4c-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bc618666-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bd17e6d3-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/e93ab71e-98db-11ea-af91-0cc47a34a53a  ONLINE       0     0     0
            gptid/be8e40c6-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/bf443662-497b-11e9-b585-0cc47a34a53a  ONLINE       0     0     0
            gptid/917fe6ed-d60b-11e9-9c34-0cc47a34a53a  ONLINE       0     0     0
        logs
          gptid/94428971-570e-11ea-af91-0cc47a34a53a    ONLINE       0     0     0

errors: No known data errors

Dobré je tedy to, že pole i takto ošklivý disk ustojí. Pokud bychom na něco podobného narazili u jiného řešení (třeba mdadm), tak se bude čekat na hodně velké timeouty, které budou mít za následek znefunkčnění pole a služeb nad tím běžících. V našem případě všechny služby fungovaly, VM nad storage běžela, ale některé backup úlohy se hodně protáhly.

Kolik je potřeba paměti?

Papírově se udává minimálně 1GB ram na 1TB RAW. V případě zapnuté deduplikace je doporučováno 5GB ram na 1TB RAW. Toto nejsou minimální možné hodnoty, ale hodnoty doporučované, u kterých máte jistotu, že se vám to nesesype. Já mám té paměti opravdu hodně, protože jsem jednak musel přidat CPU kvůli dalším kartám, dále jsem počítal s rezervou na rozšiřování (to mně teď čeká, do začátku o 8x SATA) a jeden čas jsem na tom serveru provozoval i nějaké VM, které dělaly bridge pro jiné druhy záloh.

Reálně využitá paměť

Reálné využití paměti se odvíjí od reálných dat. Tzn. záleží na tom, co máte na storage uloženo. Když bych měl já uvést maximální alokaci paměti u mých dat, tak je to tato :

root@storage:~ # arcstat.py -a
    time  hits  miss  read  hit%  miss%  dhit  dmis  dh%  dm%  phit  pmis  ph%  pm%  mhit  mmis  mread  mh%  mm%  arcsz     c   mfu   mru  mfug  mrug  eskip  mtxmis  dread  pread
19:40:42   56G  1.9G   58G    96      3   56G  621M   98    1  279M  1.3G   17   82   53G  183M   53G   99    0   149G  149G   52G  3.8G  7.1M   12M    93K    2.1M    57G   1.6G

Pár bodů k vysvětlení :

• mhit (metadata hits) : metadata, která jsou v ram
• mmis (metadata misses) : metadata, která nejsou v ram a přečetly se z L2ARC (pokud se používá) nebo přímo z poolu (disků)
• dhit (data hits) : data, která jsou v cache / ram
• dmis (data misses) : data, která nejsou v ram a přečetly se z L2ARC (pokud se používá) nebo přímo z poolu (disků)

Jinými slovy, aktuální storage využívá v produkci 56GB RAM, což je 438MiB na 1TB RAW kapacity, nebo také 584MiB na 1TB dat. To je tedy úplně oholená kost. Pokud bychom chtěli fungovat, tak dává smysl minimálně 750MB ram na 1TB dat + režie OS / dalších služeb.

Deduplikace

Pokud chcete vědět, zda má deduplikace na vašem poolu smysl a kolik minimálně potřebujete ram, abyste dedup uživili, tak si spusťte analýzu poolu (How to Determine Memory Requirements for ZFS Deduplication):

# u FreeNAS není zpool.cache ve standardní cestě, proto musíme jeho umístění specifikovat
root@storage:~ # time zdb -S -U /data/zfs/zpool.cache datastore1
Simulated DDT histogram:

bucket              allocated                       referenced
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1     539M   67.3T   52.2T   52.8T     539M   67.3T   52.2T   52.8T
     2    32.9M   4.11T   2.75T   2.80T    75.0M   9.37T   6.30T   6.41T
     4    2.78M    355G    154G    161G    13.8M   1.72T    770G    806G
     8    1.81M    232G    146G    149G    19.5M   2.44T   1.46T   1.50T
    16     444K   55.4G   28.1G   28.8G    9.03M   1.13T    585G    600G
    32    60.8K   7.60G   3.75G   3.87G    2.08M    266G    131G    135G
    64      393   47.7M   7.43M   8.95M    33.4K   4.06G    615M    748M
   128      175   21.4M   1.14M   1.89M    31.3K   3.84G    200M    337M
   256       62   7.27M    336K    640K    19.6K   2.30G    103M    201M
   512       15   1.63M    178K    247K    10.2K   1.12G    134M    180M
    1K        4    512K     16K   34.1K    5.55K    710M   22.2M   47.3M
    2K        4    512K    264K    273K    10.3K   1.29G    622M    647M
    4K       12   1.50M   1.26M   1.27M    74.6K   9.33G   7.84G   7.90G
    8K        2    256K    256K    256K    17.7K   2.21G   2.21G   2.21G
   32K        2    256K      2K   17.1K    92.2K   11.5G   92.2M    786M
   64K        1    128K      4K   8.53K     122K   15.2G    486M   1.01G
  128K        1    128K      4K   8.53K     180K   22.5G    719M   1.50G
  256K        1    128K      4K   8.53K     368K   46.1G   1.44G   3.07G
 Total     577M   72.1T   55.3T   55.9T     659M   82.3T   61.4T   62.2T

dedup = 1.11, compress = 1.34, copies = 1.01, dedup * compress / copies = 1.47

3278.945u 5009.703s 1:20:44.54 171.0%   141+2615k 8132798+0io 7pf+0w

Jak je vidět, tak analýza poolu trvala 1h 20min. Předpokládaný dedup ratio je 1.11, takže bychom zapnutím moc místa neušetřili.

Jeden DDT (deduplikační tabulka) zápis má v průměru 320 byte. v případě mých dat by bylo tedy potřeba minimáně : 577M * 320 = 184 640MB RAM. Jinými slovy 185GB RAM jen pro DDT tabulky (a to přesně, je potřeba připočítat ještě rezervu pro další záznamy). Poté je ještě potřeba ram pro běžné režie (výše zmíněných 750MB ram na 1TB dat). Můj příklad tedy vychází, že se zapnutou deduplikací bych potřeboval minimálně 1,45GB ram na 1TB RAW, nebo 1,93GB ram na 1TB dat. Reálně však ale 1,8 + 0,75 = 2,55GB na 1TB RAW, nebo 2,3 + 0,75 = 3GB RAM na 1TB dat + režie OS / dalších služeb.

Jak je tedy vidět, tak v obou případech nejsou tabulkové doporučení od těch skutečných tak daleko, pokud tedy započítáme, že data mohou být hodně rozdílná a v určitých případech může být využití ram ještě o něco vyšší.

Na co si dát pozor

Několik základních tipů :

Bacha na dostatek ram

Pokud si chcete hrát a zapnete si bez uvážení deduplikaci a nebudete mít dostatek ram, tak máte velký problém. Dojde vám ram a server padne. Po restartu se vám pool, potažmo datasety, nenaimportují, protože při jejich importu opět dojde ram. Východisko z této situace může být jediné, doplnit fyzickou paměť do serveru. Tj. celkem nepříjemná věc, která většinou nejde hned vyřešit.

Bacha na řadiče

Zásadně nepoužívejte žádné řadiče s cache apod. Vždy jen čistě HBA řadiče, aby ZFS vidělo na fyzické disky. V opačném případě si zaděláváte na problém. Já to vyhrál úplně, protože jsem kdysi pořídil Areca řadič, který sám o sobě nebyl stable. V případě 100% vytížení disků se odmlčel. Celkem náhoda jednou za x měsíců. A to jsem měl disky v passthrough. Další problém s Arecou byl, že k omezeným SMART informacím se dalo dostat jen přes tool od Arecy. Tzn. i když byly disky v passthrough, smartmontools měl problém. Občas i Areca disky odpojovala (vnitřní timeout, když disk byl delší dobu ve 100% zatížení, jí asi donutil). Pokud tedy nepoužijete hloupý HBA řadič, tak se vystavujete potenciálním problémům i co se diagnostiky životnosti disků týče. Myslím si, že výše uvedené LSI je parádní. Dnes už bych sáhl po novějším ks v podobě Tri-Mode řady, která právě podporuje připojení kromě SATA/SAS i NVMe disků.

Bacha na použitý typ pole

Pokud si postavíte pool z jednoho RAIDZ, tak si uvědomte, že výkon v IOPS bude tragický, obzvláště bez SLOG. Takový případ nelze pomalu použít ani na zálohy, protože stačí spustit zálohu i obnovu najednou a storage se může lehce ubít.

Pečlivý výběr HW

Sestavit si server, kde není něco úplně 100% funkční ve FreeBSD/ Solaris like OS je dost zásadní chyba. Je tedy třeba vybírat rozumné řadiče i síťové karty. Lidi ze světa Linuxu na to už moc zvyklý nejsou, ale ostatní OS nemají tak rozšířenou podporu HW jako Linux.

Co bych použil aktuálně za železo?

Se Supermicro nemám problém. Jejich skříně jsou parádní, člověk si může poskládat, co jen chce. Zálohovací storage bych dnes poskládat úplně stejně, jen s tím rozdílem, že bych jako CPU použil jeden Epyc Rome 7232P a LSI tri mode řadič (podpora ve FreeBSD už je), abych do něj mohl jako SLOG dát Optane 905p 480GB U.2. Pokud jde o disky, tak sice mně trochu nahlodává lepší cenová rentabilita 6TB SATA disků, ale asi bych přecijen zůstal u 4TB variant.

Pokud bych měl stavět storage např. pro produkční běh VM, tak bych postupoval podobně, jen bych použil dva řadiče a SAS disky (kvůli lepší životnosti a podpoře DP - DualPort). Jako SLOG bych pak použil dva SSD v mirroru.
Resp. bych asi rovnou použil SSD SAS nebo NVMe disky s podporou DP a vůbec neřešil SLOG a rotační disky.

Diagnostika a statistiky

Kromě různých možností tunění je síla ZFS i ve velmi podrobných diagnostických nástrojích. Analýzu ARC v podobě "arcstat.py" jsme si již částečně ukázali. Zobrazit stav fragmentace, deduplikace a zaplnění lze pomocí příkazu :

root@storage:~ # zpool list datastore1
NAME         SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
datastore1   116T   102T  14.2T        -         -    34%    87%  1.00x  ONLINE  /mnt

Zobrazit kompresní poměr lze třeba takto :

root@storage1:~ # zfs get compressratio
NAME                                                         PROPERTY       VALUE  SOURCE
datastore1                                                   compressratio  1.32x  -
datastore1/ISO                                               compressratio  1.08x  -
datastore1/datastore-test                                    compressratio  1.49x  -
datastore1/dms-backup                                        compressratio  1.21x  -
datastore1/helios-backup                                     compressratio  1.99x  -
datastore1/oracle-backup                                     compressratio  1.71x  -
...

Pomocí "zfs get" lze získat spoustu dalších informací, viz :

root@storage:~ # zfs get all datastore1/oracle-backup
NAME                      PROPERTY                 VALUE                          SOURCE
datastore1/oracle-backup  type                     filesystem                     -
datastore1/oracle-backup  creation                 Fri Mar 15 12:50 2019          -
datastore1/oracle-backup  used                     12.0T                          -
datastore1/oracle-backup  available                7.52T                          -
datastore1/oracle-backup  referenced               12.0T                          -
datastore1/oracle-backup  compressratio            1.71x                          -
datastore1/oracle-backup  mounted                  yes                            -
datastore1/oracle-backup  quota                    none                           default
datastore1/oracle-backup  reservation              none                           default
datastore1/oracle-backup  recordsize               128K                           default
datastore1/oracle-backup  mountpoint               /mnt/datastore1/oracle-backup  default
datastore1/oracle-backup  sharenfs                 off                            default
datastore1/oracle-backup  checksum                 on                             default
datastore1/oracle-backup  compression              lz4                            inherited from datastore1
datastore1/oracle-backup  atime                    on                             default
datastore1/oracle-backup  devices                  on                             default
datastore1/oracle-backup  exec                     on                             default
datastore1/oracle-backup  setuid                   on                             default
datastore1/oracle-backup  readonly                 off                            default
datastore1/oracle-backup  jailed                   off                            default
datastore1/oracle-backup  snapdir                  hidden                         default
datastore1/oracle-backup  aclmode                  passthrough                    inherited from datastore1
datastore1/oracle-backup  aclinherit               passthrough                    inherited from datastore1
datastore1/oracle-backup  canmount                 on                             default
datastore1/oracle-backup  xattr                    off                            temporary
datastore1/oracle-backup  copies                   1                              default
datastore1/oracle-backup  version                  5                              -
datastore1/oracle-backup  utf8only                 off                            -
datastore1/oracle-backup  normalization            none                           -
datastore1/oracle-backup  casesensitivity          sensitive                      -
datastore1/oracle-backup  vscan                    off                            default
datastore1/oracle-backup  nbmand                   off                            default
datastore1/oracle-backup  sharesmb                 off                            default
datastore1/oracle-backup  refquota                 none                           default
datastore1/oracle-backup  refreservation           none                           default
datastore1/oracle-backup  primarycache             all                            default
datastore1/oracle-backup  secondarycache           all                            default
datastore1/oracle-backup  usedbysnapshots          0                              -
datastore1/oracle-backup  usedbydataset            12.0T                          -
datastore1/oracle-backup  usedbychildren           0                              -
datastore1/oracle-backup  usedbyrefreservation     0                              -
datastore1/oracle-backup  logbias                  latency                        default
datastore1/oracle-backup  dedup                    off                            default
datastore1/oracle-backup  mlslabel                                                -
datastore1/oracle-backup  sync                     standard                       default
datastore1/oracle-backup  refcompressratio         1.71x                          -
datastore1/oracle-backup  written                  12.0T                          -
datastore1/oracle-backup  logicalused              19.9T                          -
datastore1/oracle-backup  logicalreferenced        19.9T                          -
datastore1/oracle-backup  volmode                  default                        default
datastore1/oracle-backup  filesystem_limit         none                           default
datastore1/oracle-backup  snapshot_limit           none                           default
datastore1/oracle-backup  filesystem_count         none                           default
datastore1/oracle-backup  snapshot_count           none                           default
datastore1/oracle-backup  redundant_metadata       all                            default
datastore1/oracle-backup  org.freenas:description                                 local
datastore1/oracle-backup  org.freebsd.ioc:active   yes                            inherited from datastore1

Dalším dobrým nástrojem je gstat :

root@storage:~ # gstat
dT: 1.062s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0     67      0      0    0.0     67    667    0.0    0.2| nvd0
    0      0      0      0    0.0      0      0    0.0    0.0| da0
    0      0      0      0    0.0      0      0    0.0    0.0| da1
    0      7      7    139    0.2      0      0    0.0    0.1| da2
    0      8      8    136    1.5      0      0    0.0    1.1| da3
    0      8      8    128    1.6      0      0    0.0    1.2| da4
    0      8      8    147    0.2      0      0    0.0    0.2| da5
    0      9      9    151    1.5      0      0    0.0    1.4| da6
    0      6      6    105    0.4      0      0    0.0    0.2| da7
    0      1      1      4    0.1      0      0    0.0    0.0| da8
    0      6      6    117    0.2      0      0    0.0    0.1| da9
    1      8      8    147    6.3      0      0    0.0    4.7| da10
    1      9      9    177    1.1      0      0    0.0    1.0| da11
    1      8      8    162    0.4      0      0    0.0    0.4| da12
    0      9      9    169    3.9      0      0    0.0    2.4| da13
    0     10     10    185    1.7      0      0    0.0    1.7| da14
    0      0      0      0    0.0      0      0    0.0    0.0| da15
    0      0      0      0    0.0      0      0    0.0    0.0| da16
    0      0      0      0    0.0      0      0    0.0    0.0| da17
    0      0      0      0    0.0      0      0    0.0    0.0| da18
    0      0      0      0    0.0      0      0    0.0    0.0| da19
    0      0      0      0    0.0      0      0    0.0    0.0| da20
    0      0      0      0    0.0      0      0    0.0    0.0| da21
    0      0      0      0    0.0      0      0    0.0    0.0| da22
    0      5      5     87    0.2      0      0    0.0    0.1| da23
    0      1      1      4   14.7      0      0    0.0    1.4| da24
    0      1      1      4   10.8      0      0    0.0    1.0| da25
    0      1      1      4   15.4      0      0    0.0    1.5| da26
    0      6      6    105    0.3      0      0    0.0    0.2| da27
    1      7      7    113    0.3      0      0    0.0    0.2| da28
    1      9      9    169    0.7      0      0    0.0    0.7| da29
    0      0      0      0    0.0      0      0    0.0    0.0| da30
    0      1      1      4    0.1      0      0    0.0    0.0| da31
    0      0      0      0    0.0      0      0    0.0    0.0| da32
    0      0      1      4   13.4      0      0    0.0    1.3| da33

Zobrazení iostat a průtoku dat jinak (aktuální hodnoty se po 1s vypisují pod sebou):

root@storage:~ # zpool iostat datastore1 1
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
datastore1   102T  14.2T    494    826  48.4M  47.5M
datastore1   102T  14.2T     37  1.70K  1.11M   108M
datastore1   102T  14.2T     36     46  1.76M   663K
datastore1   102T  14.2T     38     41  1.47M   691K
datastore1   102T  14.2T     34  1.17K  2.48M  14.4M
datastore1   102T  14.2T     37     89  2.40M  1.02M
...

Komerční řešení storage se ZFS

Máme tu několik asi nejvýraznějších řešení se ZFS:

• TrueNAS
  FreeNAS se supportem se jmenuje TrueNAS Enterprise. Aktuální stav je, že FreeNAS byl přejmenován na TrueNAS CORE. Došlo tedy ke sjednocení názvů, aby to do budoucna nebylo matoucí (blog).
• Nexenta
  Nexenta staví na Solaris základu a řeší HA a další věci okolo se ZFS. Kolovaly fámy, že používá Linux, ale to není pravda. Z Linuxu kdysi používali jen userspace a říkali tomu Nexenta OS (zdroj). To je ale minulost, aktuální řešení se jmenuje NexentaStor. Dále mají SDS řešení, kterému říkají QuantaStor.
• Qnap
  Jedná se o řešení NAS systému. Synology používá Linux a BTRFS a Qnap používá jako os QES (založený na FreeBSD) a samozřejmě ZFS. Dále Qnap používá ještě QTS, což je os založený na Linuxu, kde používá ext4 (proč né btrfs). A aby toho nebylo málo, tak nově prodává QuTS hero, což je QTS se ZFS. Jedná se tedy asi o Linux a v něm asi ZFSonLinux?
• Oracle ZFS
  I Oracle dodává ZFS storage řešení. Ještě aby ne, když má v rukách ZFS i Solaris.
• napp-it
  Jedná se o web ksicht pro OmniOS / OpenIndiana (Solaris Like), který lze použít zdarma, nebo s placeným supportem. Když se člověk dívá, jak to vypadá, tak z toho má smíšené pocity.
• RSF-1 ZFS
  Jedná se o rozšíření ZFS, který přidává HA fce. Zajímavé je, že podporují i Linux.

Závěr

V zápisku není zmíněno vše, je to jen ukázka toho, jak věci mohou fungovat / nefungovat. Dokumentační projekt k ZFS v tom tedy nehledejte. Zajímavé ale je, jakým tempem jde implementace ZFS na Linuxu kupředu (jak z hlediska funkčnosti, tak z hlediska zájmu firem).

Zdar Max

PS: Snajpo, ZFS zdar!

Zdroje: (nezmíněné v textu)
ZFS na Linuxu: proč ho určitě chcete - Pavel Šnajdr
ZFS na Linuxu: co je nového - Pavel Šnajdr
OpenZFS bude pokračovat ve vývoji souborového systému ZFS
       

Anketa

Komentáře

[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

[PetebLazar]

Nikde jsem v úvodním příspěvku a diskusi pod ním nenarazil na slovo "update". V jakém režimu (pokud) se u takovéhoto řešení aplikují update (rozuměj aktualizace OS zahrnující implementaci FS) s ohledem na případný negativní dopad na kompatibilitu/konzistenci_dat/funkčnost/výkon?

[Max]

Je to uděláno naprosto parádně. Aktualizace oznamuje web ksicht a přes něj je můžeš nainstalovat + si můžeš nastavit, zda chceš být ve stable větvi, nebo beta větvi. Taktéž není problém je stáhnout a nainstalovat ručně z cmd.

Každý update vygeneruje snapshot OS a pokud se ti něco nelíbí, není problém na pár kliků myší přejít na předchozí verzi OS (je to tedy otázka jednoho rebootu).
Pokud jde o ZFS, tak ten se neaktualizuje automaticky. Web ksicht tě jen upozorní, že nový OS podporuje nové fce ZFS a zda chceš udělat aktualizaci poolu (ZFS). Dále tě upozorňuje, že se jedná o nevratnou věc a aby jsi to pečlivě zvážil.

Reálně tedy postupuji tak, že aktualizuji OS a pokud po několika týdnech nenarazím na problém, provedu i update ZFS poolu (pokud je k dispozici).

Dále je možné udělat backup nastavení (export do jednoho file). FreeNAS pak umožňuje takový export znovu importovat. Pokud ti tedy z nějakého důvodu padne HW (všechny disky), na kterých máš OS, tak obnova je celkem easy, prostě nainstaluješ freenas a importneš nastavení a hotovo.

Zdar Max

[Max]

Jinak za celou dobu, co FreeNAS používám, jsem nenarazil na problém, resp. jsem narazil na jediný : FreeNAS Corral končí, všichni downgradujte.

Tato slepá větev byla unstable (samba dělala problémy) a vrácení se zpět na původní starou větev nebyl pro mně problém.
Pokud jde o styl aktualizování, tak když vyjde nová major, nedělám hned update a čekám vždy na nějaký fix realase U1/U2 apod.
Zdar Max

[PetebLazar]

Díky za objasnění a doplnění.

V návrhu Vašeho nového pole je mezi komponentami navržen jako CPU EPYC Rome (7302P). Jak je na tom dnes FreeNAS(potažmo spíše FreeBSD) z hlediska podpory vlastností/výhod/omezení této chipletově-orientované architektury? Existuje nějaké výkonostní srovnání pro ZFS s běžnými XEON-based řešeními?

[Max]

Neřešil jsem benchmarky. Na AMD přecházím, protože je na tom lépe poměr cena/výkon a nejsou pro něj aktuálně známy tak fatální (z hlediska ztráty výkonu) bezpečnostní chyby jako u intelu. To jest důvod, proč na téměř všech polích po nějakých 20 letech přecházíme na AMD.
Ještě se ve vzduchu vznáší přechod z HP na Supermicro. Důvodů je více, možná se o tom někdy rozepíši.
Zdar Max

[PetebLazar]

Snad SuperMicro doprodá H11DSi-NT-B rev.2.0 a dočkáme se tak obnovení nabídky E-ATX Dual SP3 (s PCIe 4.0).

[Max]

Mluvil jsem s jedním z dodavatelů a první desky by měly přijít asi za dva měsíce.
Ale na to nechci čekat, protože včera už bylo pozdě.
Zdar Max

[PetebLazar]

Další dva měsíce? To už se z "Čekání na Godota"(PCIe4.0/DDR4_3200MHz) může už klidně stát čekání na Milana(Zen 3). Skoro 3/4 roku od uvedení CPU se stále čeká na širší dostupnost MB s podporou jeho nativních schopností. No co, ceny komponent jsou teď takové, že asi není kam se hnát (pokud to tedy není jako ve zmíněném případě nezbytně nutné).

[Max]

Já mám nasazení, kde to nevyužiji, takže mně to zatím netrápí.
Zdar Max