ZFS vagy SoftRAID egy HP N36L Microserver-en

Linux-haladó

Sziasztok, egy kis tapasztalati segítséget szeretnék kérni, van egy HP N36L Microserver 16GB memóriával, és 2x1TB ill. 2x2Tb diszkkel, Proxmox-ot szeretnék használni és pár applikációs szervert futtatni rajta, és érdekelne hogy teljesítményben melyik a jobb megoldás ZFS-re mindent vagy SoftRAID+LVM-el megoldani. Nagyon fontos tényező a teljesítmény, a Proxmox-ban alapvetően LXC konténereket használnék. A ZFS azért gondolkodtatott el kicsit mert azért elég nagy a memória igénye, és ebbe a szerverbe többet nem lehet beletenni, ez a max.
Előre is köszönöm a hozászolásokat.

( gyuri23 | 2019. 08. 22., cs – 11:57 )

A Proxmox nem támogatja az MD+LVM-et rendszer lemeznek. Vagy hardver raid vagy ZFS raid. Rá tudod hackelni de én nem tenném. A ZFS memória használatát lehet limitálni 4 GB-al már elég jól elvan.

Hát a ZFS nincs "ingyen". Hogy mit vesztesz az meg attól függ, hogy mit fognak csinálni a guest gépek. Ha nem lesz nagy IO load akkor nem vészes a különbség, viszont ha megállás nélkül reszelik a disk-et akkor lesz CPU terhelés is a memória mellé. Pont ma csináltam egy 100GB-os gép visszaállítást egy ilyen desktop gépen 4 x Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
Nem állítottam be limit-et a restore-nak és nem futott semmi más a gépen. A CPU terhelés 20% felett volt, a load megy 40 körül. Ez kb. a max amit tud ez a gép.

Az én tapasztalatom az, hogy semmivel. Gyorsabb lesz az írás, de a fizikai memória és a CPU igény nem csökken. Ráadásul csak az enterprise ssd-k bírják, akkora terhelést kapnak. Ez 3 db samsung evo-ba került nekem, kettő fél év alatt a rekorder meg 3/4 év alatt döglött meg. Az ssd cache legalább +100.000 ft költség.

Csak a sync írásokra gyorsít, az aszinkron írásra nincs hatással, azon nincs mit gyorsítani. ZIL/SLOG-nak ajánlatosabb a "vállalati" PLP-s ssd. A power lost protection miatt a RAM cache-ük sebességével működhetnek, elöbb tudják visszaigazolni az írást, mint ahogy az ténylegesen megtörtént a PLP miatt. De ha elfogy a cache, ezek sem bírják a tempót.
https://images.anandtech.com/doci/8104/consistency_575px.png

Sajnos nem írtam fel, már kidobtam őket :( Arra emlékszem, hogy a leggagyibb Samsung 840 EVO Basic 120GB diskek voltak. A hiba meg úgy jelentkezett, hogy a rendszer (ZFS) iszonyat belassult. Hibát nem láttam sehol, de a smart teszt jelezte, hogy gond van. Kikapcsoltam a ARC és ZIL-t, mindkettő ugyan azon az SSD-n volt és egyből "megjavult" a rendszer. Adatvesztés nem volt érdekes, hogy a ZFS nem hisztizett, a RAID lemezekre nálam nagyon hamar bejelez, elég egy hiba és egyből DEGRADED-be rakja. Szerintem az SSD szoftvere még meg tudta oldani, hibát nem csinált, de teszt 30% taksálta a lemez állapotát.

Itt van előttem egy 120 GB-os Samsung 840 (DXT0AB0Q) 63.7 TB írással :)
Samsung Magician szerint:
Drive Condition: Good

HD Sentinel szerint:
Power on time: 1518 days, 16 hours
Estimated remaining life: 44 days (!)
Lifetime writes: 63.73 GB
Health: 38 %
Uncorrectable Error count: 186 (de nem növekszik).

Rohadt melegben egy hajón volt DVR-ben és 0-24-ben rögzített, most netezős gépben van.
Szóval azért annyira nem rosszak ezek.

AnandTech teszt szerint, akkor most érte el kb. élete felét.

Igen és ráadásul egy SSD-n volt a ZIL és az L2ARC cache is. Tudom, hogy ez nem igazán nagykönyv szerinti konfig, a ZIL-t különrakni és még tükrözni is kéne, de a proxmox fórumon többen ajánlották. Ezért raktam szinkronra az írást. Valóban javított a teljesítményen, de nagyon gyorsan kinyírta a gagyi SSD-t. Vagy nem volt szerencsém és hibás sorozatot fogtam ki...
Azóta teljesítményt a sok kis lemez technikával növelem. Sikerült egy olcsó DeLock 10 csatornás sata kontroller-el és 10 db teljesen vegyes sima lemezzel (nem ssd), amiben még 5200-es is van 320 MB/s írási sebességet elérni.

Hát igen, a többi fórumon irnak mindenfélét, kivéve a HUP. :-)
Nem jó egy lemezre tenni az SLOG-ot és az L2ARC-ot.
Ha emiatt kiadtad a syncron=always-t egy pool-ra , netán az összesre,
akkor az aszinkron írásokat is szinkron írássá kényszerítetted, az átment ezen a ZIL/SLOG ssd-n. Vagyis a pool összes forgalma naplózódott, ha csak másoltál egy nagy fájlt jobbról balra, az is. A legterheltebb lemez a rendszerben emiatt ez az ssd volt, 10 lemezes raid-ben sokszorosa, mint egy HDD-nek, persze hogy kinyiffant. Ha csak nincs valami speciális ok, jobb azt defaulton hagyni. Szerintem jó a default, az alkalmazás döntse el, ha szinkron írást akar, akkor már csak ezek az írások "fogyasztják" az SLOG ssd-t, pl csak a mysql, postgres.

Most már én is tudom. Annyi haszna volt, hogy megismertem egy újabb módszert ahogy nem érdemes csinálni :D Meg kénytelen voltam utánaolvasni a ZIL meg cache működésnek :) Mindenesetre a ZFS rajongásom nem csökkent, annak ellenére hogy jóval háklisabb a "mezei" fájlrendszereknél.

2,8 naponta lett teleírva.
Ha te óránként teleírod az SSD-t, akkor neked nagyon speciális igényeid vannak. A legtöbb enterprise SSD sem alkalmas erre, nemhogy consumerek.

Talán ezek:
https://www.intel.com/content/www/us/en/architecture-and-technology/opt…
https://www.intel.com/content/www/us/en/products/memory-storage/solid-s…
(a legolcsóbb is elmegy 6 évet óránkénti teleírással)

Szia,

Samsung nem való ssd-nek Semmilyen szerverbe, az Evo meg főleg nem.

A 2 magos 36l proci nem túl fényes, de fileszervernek használható.

Freenashoz itt jó sok hw info, ami hasznos:

Ez amúgy a kedvenc site-om, iszonyú naprakészek szerver hardverügyileg és tele vannak tesztekkel.

https://www.servethehome.com/buyers-guides/top-hardware-components-free…

SSD: Nekem S3700 van eltéve 800 GB-os, az lesz a cache majd, meg van 2 db 500-as Enterprise még.

Nekem N54L 4 db WD red 5 TB diszk,egyik 2 db tükörben, másik 2 tükörben, 10GBE IBM X540 beletéve és 3Gbitet tudtam kipréselni belőle. Egyébként az SSD-vel nem értek túl sokat 10GBE nélkül, mert Sata 2.0 az N36L is, azaz 300MB/sec a sávonkénti átvitel, és ezt az enterprise SSD-k röhögve tudják.

6 db diszknél többet meg nem lehet beletuszkolni 3.5-ösből többre meg nincs hely a 10GBE miatt a PCI-E 1x meg nem sokat ér.

Amúgy most akarok otthon szervert építeni, mert kelleni fog és alaposan a servethehome-os tippek alapján fogom összerakni.

A mellékelt fenti oldalt azért javasolom, mert rengeteg jó tipp van fent és a Fórumban a great deals között is van pár jó cucc, amire érdemes ráugrani.

Hát igen, ez már gyors lehet:
https://www.servethehome.com/wp-content/uploads/2017/11/Intel-Optane-900p-U.2-in-server-hot-swap-696x461.jpg

Intel S3700 jó ötlet, ebay-en tényleg annyiért lehet megvenni mint most egy új "asztali ssd"-t. (Remélem nincs benne semmi trükk). És ZIL/SLOG nak igazából Power Lost Protection-os ssd való. A samsung evo próblkozás a "szegény ember ssd"-jével. [:)]

Ha szervert építesz, használtan 1GB ECC Ram kb. 1000 Ft, ez jobb mint bármilyen ssd és nem kell L2ARC ssd. NAS-ba fölösleges a ZIL/SLOG, az csak a szinkron íráshoz kell. Ettöl még van ZIL, csak az a HDD-n lesz. Vagyis ha van ZFS-ed, van ZIL -ed. (Nem tévesztendő össze a régi orosz teherautóval)

HBA-nak Dell H200 is biztosan jó, használtam, szintén IT módban (LSI9211-8i) 8 db 6GB sata, dell H310 is megy IT módban, ilyenem nem volt.
Igen jobb a P sorozat, kérdés hog megér-e 1 millió ft többletet az adott célra + félmillió egy darab Optane DC Persistent Memory Module-ért (ha lehet kapni egyáltalán) , vagy veszel inkább 3 darab használt 400 GB-os S 37xx sorozatot 70 ezerért.
Az NVMe már "komolyabb" io igényhez jó, ha az optane nvme , az állandó ram és hasonlók terjednek, a mostani vállalati sata ssd-t úgy dobják majd utánad. De ez még odébb van, a nagytömegű tároló egyenlőre a HDD.

Szóval ZIL-nek Power Lost Protection-os SSD a célszerű, ilyen meg kerti ssd-ben nincs. Erre a célra a PLP nélküli ssd olyasmi, mint az aksi nélküli raid kártya. Jobb, mivel a ZIL csak a szinkron írást érinti, a fájlrendszer nem fog sérülni így sem, de például egy sql szerver már sérülhet, vagy inkonzisztens lehet, mert azt hiszi hogy az elküldött adatai lemezen vannak.
Persze az ext4/md-raid -ben sincs ilyen védelem, meg van egy rakat BBU nélküli raid vezérlő és vígan mennek.

Sebességben meg egy HDD-hez elég egy 500 uSec latencys sata ssd. SSD -hez viszont csak egy 100 uSec-es NVMe-nek van értelme, 100 uSec-es NVMe-hez meg már csak ezek a 3-10 uSec-es ( pl.Optane DC Persistent Memory Module) mostanában megjelenő SLOG eszköznek van értelme.
Kicsi vagy nagy SOHO nas-ba meg egyik sem kell, elég a HDD.

Előkotortam egy 120 GB-os Samsungot:

Samsung SSD 840 EVO 120GB # Disk descr.
S1D5NEADC02151V # Disk ident.

Hat db. 3 TB-os TOSHIBA DT01ACA3 HDD RaidZ2 + a samsung ssd SLOG

dd eredmények, tömörítés kikapcsolva:
---------------------------------------------------------------------

set sync=always , nincs ZIL/SLOG

# dd if=/dev/zero of=testfile_2 bs=16k count=50000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 507.671247 secs (1 613 643 bytes/sec)

---------------------------------------------------------------------

set sync=always és Samsung 120 GB SLOG

dd if=/dev/zero of=testfile_2 bs=16k count=50000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 134.517935 secs (6 089 894 bytes/sec )

Kipróbáltam még két sata ssd-t zil/slog-nak (freenas, 8GB Ram 6x3TB HDD) :

Samsung 860 EVO : 17 MB
Intel DC S3700 : 77 MB

zfs set sync=always T6ZFSR2
root@nas:/mnt/T6ZFSR2/mentes # dd if=/dev/zero of=testfile_3 bs=16k count=50 000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 46.166388 secs (17 744 511 bytes/sec)

root@nas:/mnt/T6ZFSR2/mentes # zfs set sync=always T6ZFSR2
root@nas:/mnt/T6ZFSR2/mentes # dd if=/dev/zero of=testfile_2 bs=16k count=50 000
50000+0 records in
50000+0 records out
819200000 bytes transferred in 10.576980 secs (77 451 218 bytes/sec)

Nekem ez működni szokott:

Ez az aktuális állapot:

cat /sys/module/zfs/parameters/zfs_arc_max

Ha 0 akkor 50%

Így állítsd be:

/etc/modprobe.d/zfs.conf

options zfs zfs_arc_min=536870912 (amit akarsz)
options zfs zfs_arc_max=2147483648 (amit akarsz)

update-initramfs -u (hogy reboot után is úgy maradjon)

ZFS-hez kell a memória, elég lehet a 4GB ram, ha maradsz a 128 K-s recordsize-nál,
ajánlás szerint ARC a dateset méretének 0.1 % -a, vagyis 3T hdd 3 GB ram.
Ha például sql-t is használsz, még HDD-n is túl nagy a 128K , 16 k nál viszont már 0.8 % kell az ARC-nak.
250 GB 16K-s dataset-nél az 250*0.008=2GB Ram, vagyis már kevés lesz a 4GB a "metaadatoknak".

Ha kevés a RAM olvasáson segíteni tud ssd L2ARC, ide jó 128 GB "consumer" ssd is :
https://www.percona.com/blog/2018/05/15/about-zfs-performance/

Íráson meg nem, a ZIL/SLOG SSD csak naplóz, nem cache, lényegében a szinkron írás tényleges elvégzése nélkül biztosítja az írások végrehajtását, az ugyanúgy a ram-ból iródik a lemezre mint az aszinkronnál, csak közbe ékelődik a ZIL írása, illteve áramszünet után ebből írja vissza a "hiányzó" adatokat.

( dorsy v | 2019. 08. 23., p – 08:42 )

A mikrokocka sem RAM-ban sem CPU-ban nem tul acelos, ZFS kb. felejtos rajta.
Telepits egy alap debiant a gepre softraiddel, izles szerint particionalva, arra meg siman felteszed a proxmoxos csomagokat, erre a dokumentaciojukban van leiras.

Ha nem s.o.s a dolog próbáld ki, a telepítés kb. 10 perc. Ha megy ZFS el megfelelően akkor az sokkal jobb választás. Nekem egy egy i5-2500 3.30GH 16GB ram-os gépen, ami finoman szólva sem egy mai és acélos cpu, 4 gép megy amiből az egyik windows 10. Minden gond nélkül teszi a dolgát. A HP kocka procija tényleg elég kevéske, de a tesztből nem lesz baj. Aztán persze számolj be róla :)

Az a baj hogy nagyon SOS a dolog, igazából nem a telepítés a hosszú, hanem a további működés során fellépő problémák amik lehet 1 hét múlva jelentkeznek amikor a guestek használják, azért is kérdeztem mert a biztosabb megoldást akartam választani. Ez a szerver egy Samba Fileszervert-t, Windows kliens-t, 2 kisebb LXC konténert és egy Firebird adatbázis szolgálna ki. Eddig egy Cloudmin volt rajta, jól működött és ezt akarom lecserélni.

Az soft-raid/lvm/ext4 régóta beton stabil, robusztus hármas. Ha minden finomhangolást beállítasz, akkor még gyors is. Én nem erőltetném a zfs-t. 32 GiB alatt nekem mindig lassú volt.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

( uid_21239 | 2019. 09. 02., h – 21:03 )

Kollegam ma meselte, hogy a "haziszerveren" zfs-t hasznalt, 3 hdd-vel raid-z1-be, de a hetvegen az egyik hdd behalt. Tett be egy masikat, de vegtelen resilvering-scrubbing-resilvering-scrubbing ciklusba kerult a cucc. Egy napig szenvedett vele, aztan inkabb hagyta a francba az egeszet es visszaallitotta backup-bol.

Szoftverfejleszto a srac, nem sysadmin, ennek megfelelo linux ismeretekkel. Ez annyit tesz, hogy lehet, hogy csak nem ert hozza, de en azert kinezem belole, hogy egy degraded tombot rendbe rak.
Tobb infom nincs, talalgatni nem akarok. Eljen az mdadm meg a HW raid! :-P

( vasla_ | 2019. 09. 03., k – 16:15 )

Mindenképpen jó lenne, mert a /dev/zero-s teszteket a bekapcsolt compression (akár a defaulton hagyott lz4 is) érdemben tudja befolyásolni.

Kikapcsolt compression minden lemezen. (6 db HDD 2.7 GB TOSHIBA DT01ACA3 HDD RaidZ2, freenas, 8G ram, lsi 8211-8i )

fio teszt :

# fio --name=test --filename=testfile--size=100M --direct=1 --bs=(1M vagy 16k vagy 4k) --iodepth=16 --rw=randwrite --randrepeat=1
----------------------------------------------------------------------------------------------------------------------------------------------------------

Nincs SLOG, sync=always, --bs=4k WRITE : bw=368KiB/s (377kB/s), 368KiB/s-368KiB/s (377kB/s-377kB/s), io=100MiB (105MB), run=278395-278395msec

INTEL S3700 sync=always, --bs=4K WRITE..: bw=20.5MiB/s (21.5MB/s), 20.5MiB/s-20.5MiB/s (21.5MB/s-21.5MB/s), io=100MiB (105MB), run=4871-4871msec
INTEL S3700 sync=always, --bs=16K WRITE.: bw=67.0MiB/s (71.3MB/s), 67.0MiB/s-67.0MiB/s (71.3MB/s-71.3MB/s), io=100MiB (105MB), run=1471-1471msec
INTEL S3700 sync=always, --bs=1M WRITE..: bw=215MiB/s (225MB/s), 215MiB/s-215MiB/s (225MB/s-225MB/s), io=9.77GiB (10.5GB), run=46520-46520msec

860 EVO 500G sync=always, --bs=4K WRITE..: bw=5193KiB/s (5318kB/s), 5193KiB/s-5193KiB/s (5318kB/s-5318kB/s), io=100MiB (105MB), run=19719-19719msec
860 EVO 500G sync=always, --bs=16K WRITE: bw=19.1MiB/s (20.0MB/s), 19.1MiB/s-19.1MiB/s (20.0MB/s-20.0MB/s), io=100MiB (105MB), run=5239-5239msec
860 EVO 500G sync=always, --bs=1M WRITE.: bw=164MiB/s (172MB/s), 164MiB/s-164MiB/s (172MB/s-172MB/s), io=9.77GiB (10.5GB), run=61036-61036msec

bonnie++ túl lassú volt ennyi teszthez, ezért fio. Jobb az intel, de 860 evo szódával elmegy.

Belejöttem :-)
Meg örököltem már néhány "használaton kívüli" sata ssd-t, nem ez a mainstream.
A főcsapás az NVMe, a Szent Grál az OPTANE, meg a néhány µSecundum-os persistent memory-k.

Ezek a tesztek kicsit mesterségesek. Ha a fio-t 100M heleyett 5 GB-os állományokkal csinálom, sokkal rosszabbak az értékek, elfogy a DC ssd-kben is előbb-utóbb a cache, és a drágább és az olcsóbb típusok kezdenek hasonlítani, legalábbis
sebességben.
Az megint más kérdés, hogy egy szerver hol kap folymatos 5-10 Gigabájtos, 4kB-s blokkokban szinkron terhelést.

Windows 10-es desktop gépbe tettem bele, más nincs, sajnos, nincsen PCI-E 3.0 a közelben, egy delock vezérlővel.

Lefogja a PCI-E 2.0 (Amiben nagy a veszteség egyébként)

Critsldiskmark MB/sec

seq q32t1 Read 1475 Write 1355
4KiBq8t8 955 869
4KiBq32t1 209 200
4KiBq1t1 134 127

A PCI-e 2.0 elvesz az elméleti 2000MB-ből elég sokat.

Még annyi, hogy 1835GB írás volt rajta összesen, 5.11PB az elméleti írás rá., amit kibír

fio-val nincs kedved megnézni ?
fio bináris windowshoz:
https://bsdio.com/fio/

windosws alattat az sssd -n legyen a pormpt mert oda teszi a tesztfájlt.
fio --name=ssdtest --filename=testfile1 --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1

Van itt már több fio teszt.

Ennek a 6 disk + ssd cache setupnak nem kene jelentosen jobb teljesitmenyt hoznia? probabol megneztem az elerheto leg gyengebb konfigon: rpi4, buster, ext4, usb-n egy desktop disk(ST4000DM004)

fio --name=test --filename=testfile --size=100M --direct=1 --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 |grep WRITE
WRITE: bw=5098KiB/s (5221kB/s), 5098KiB/s-5098KiB/s (5221kB/s-5221kB/s), io=100MiB (105MB), run=20085-20085msec
fio --name=test --filename=testfile --size=100M --direct=1 --bs=16k --iodepth=16 --rw=randwrite --randrepeat=1 |grep WRITE
WRITE: bw=21.3MiB/s (22.3MB/s), 21.3MiB/s-21.3MiB/s (22.3MB/s-22.3MB/s), io=100MiB (105MB), run=4705-4705msec
fio --name=test --filename=testfile --size=100M --direct=1 --bs=1M --iodepth=16 --rw=randwrite --randrepeat=1 |grep WRITE
WRITE: bw=220MiB/s (230MB/s), 220MiB/s-220MiB/s (230MB/s-230MB/s), io=100MiB (105MB), run=455-455msec

Ennek a 6 disk + ssd cache setupnak nem kene jelentosen jobb teljesitmenyt hoznia? probabol megneztem az elerheto leg gyengebb konfigon: rpi4, buster, ext4, usb-n egy desktop disk(ST4000DM004)

A tesztek sync=always beállítás mellett mentek, vagyi a szinkron írást néztük,az SLOG miatt.
próbáld ki ezzele a kiegészítéssel :--sync=1 --fsync=1 és ezzel hasonlitsd vagyis:
fio --name=test4k --filename=test4kdx --size=10M --direct=1 --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1

AZ aszinkron irás azért "kicsit" jobb, kb két nagyságrenddel jobb mint rpi4:
zfs set sync=standard T6ZFSR2

root@nas:/mnt/T6ZFSR2# fio --name=test4k --filename=test4kdx --size=100M --bs=4k --iodepth=16 --rw=randwrite --randrepeat=1 | grep WRITE:
WRITE: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=100MiB (105MB), run=193-193msec

( ggallo | 2019. 09. 23., h – 11:10 )

Nekem az a véleményem, hogy a ZFS verzió Proxmox esetében könnyebben telepíthető és kezelhető, mert GUI szintig támogatott. A másikat kézzel kell csinálni és felügyelni. Azt nem gondolom, hogy rosszabb lenne stabilitásban, mert egy sima Debian 9 az alap, szóval miért lenne bármi baj az MD+LVM-mel.
A teljesítmény max. mérve térhet el kicsit, de használat közben szerintem nincs érdemi különbség, lévén mindkét rendszer szoftveresen dolgozik (azonos CPU-n), és mindkettővel két tükröt tudsz kialakítani ilyen hardverre, ami nem jár semmiféle paritás számítással, így extra CPU igénnyel sem.

Tény, hogy kb. 4 GB memóriáról le kell mondani, mert annyit érdemes (sőt, muszáj) fenntartani a ZFS-nek (a gyári konfig az össze memória 50%-a, szóval telepítés után ezen mindenképp állítani kell, sokkal több memóriával rendelkező gépen is). Cserébe az LXC konténerek spórolnak egy csomó erőforrást ahhoz képest, mintha ugyan annyi VM-et futtatnál.

Egy ilyen rendszeren SSD-vel leginkább úgy tudsz gyorsítani, ha 2 db-ból építesz egy tükröt valamelyik HDD pár helyett, és azon lesz az OS meg a VM-ek (és a másik, HDD-s tükrön az adatok). Egyetlen HDD 100-200 IOPS-nél többet nem tud (sima 2 lemezes tükörnél pedig az egy HDD-s IOPS számít), így az lesz a szűk keresztmetszet, nem az írási vagy olvasási sebességek.
Ezen felül ZFS esetében ne is gondolkozz sem SLOG sem L2ARC beüzemelésén, mert mindkettő csak speciális esetekben és csak bizonyos dolgokat segít meg, nem általános cache varázsszerek (persze elmondom bővebben, ha érdekel/fontos lenne).

Engem is érdekelne a tapasztalatod. Most hétvégén volt időm egy DL360G9+P440ar gépet nyüstölni egy kicsit.
Az async írást a tesztjeim szerint semennyire sem befolyásolta az SLOG. A sync írást viszont brutálisan.

Azt tudja valaki, hogy mivel lehet mérni, hogy mennyi sync írás van egy rendszerben?

Az eredményeim:

recordsize 128K, sync always, 3 db 4 TB Sagate SAS + SSD

slog SSD teszt:
micron = Micron M510DC
dell = PX02SMF020

fio --name=test --filename=testfile --size=100M --bs=[$bs] --iodepth=16 --rw=randwrite

bs=4K
no log write: IOPS=100, BW=402KiB/s (412kB/s) (100MiB/254508msec)
log, micron write: IOPS=2463, BW=9853KiB/s (10.1MB/s)(100MiB/10393msec)
log, dell write: IOPS=2972, BW=11.6MiB/s (12.2MB/s)(100MiB/8613msec)

bs=64K
no log write: IOPS=57, BW=3710KiB/s (3799kB/s)(100MiB/27602msec)
log, micron write: IOPS=1369, BW=85.6MiB/s (89.8MB/s)(100MiB/1168msec)
log, dell write: IOPS=1582, BW=98.9MiB/s (104MB/s) (100MiB/1011msec)

bs=128K
no log write: IOPS=58, BW=7491KiB/s (7671kB/s)(100MiB/13670msec)
log, micron write: IOPS=1244, BW=156MiB/s (163MB/s) (100MiB/643msec)
log, dell write: IOPS=1626, BW=203MiB/s (213MB/s) (100MiB/492msec)

"ZFS esetében ne is gondolkozz sem SLOG sem L2ARC beüzemelésén"
Ez engem is foglalkoztat(na). Én build rendszerhez üzemelnék be ZFS-t a forráskódnak. Tömörítés és a dedup miatt, de nagyon kevés memória felhasználás mellet. Ezekhez ha jól olvastam nem kellenek "ezek" a szolgáltatások. Hogy lehet szinte teljesen lecsupaszítani a ZFS-t?
Amúgy én tökre zavaros irodalmakat találok a ZFS-ről. Olyan, mintha akik fejlesztik se tudnák már, hogy mi mire való.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Hát a dedup memóriaigénye a legnagyobb az összes ZFS "móka" között. Nagyjából így kell számolni: 4-5GB Ram / 1 TB disk (adat), pontosabban blocks * 320 bytes. Csak éppen a blokkszámot előre elég nehéz kiszámolni :)
A ZFS-el egy baj van, az hogy nem "fire and forget" jól el lehet vele bíbelődni. Viszont én minél jobban megismerem, annál jobban megszeretem :)

Kösz a tippet. Mondjuk ha már találnék egy általános képletkupacot a hókuszpókuszokhoz szükséges memória kiszámolására, már az is sokat segítene. És erre céloztam, hogy ezt a fejlesztők se tudják már követni (szerintem).

Marad a kísérletezgetés virtuálisgépben.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

A mondás általában az, hogy dedup nélkül 4GB elég 8GB-al meg már jó a teljesítmény. A memória számoláshoz két képlet elég, a sima ARC memória:

Recordsize of 128KB => 0.1% of the uncompressed dataset size
Recordsize of 64KB => 0.2% of the uncompressed dataset size
Recordsize of 32KB => 0.4% of the uncompressed dataset size
Recordsize of 16KB => 0.8% of the uncompressed dataset size

+ dedup blocks * 320 bytes

Ennyi elég. Persze elég érdekes a read (ARC) memória, mert a ZFS mindent belerak amit olvas. Idő is kell neki a feltöltődéshez. Így minél több annál jobb logika is működik :) Ez viszont csak az olvasásra igaz. Az írás más tészta, ott a minél több disk a nyerő.

Ezt a közelítő leírást én is megtaláltam. De pl ez alapján nekem elég conf fájlban 512MiB-et beállítanom. (256GiB data(64KB recordsize)*0.2%)
De nem tudom mit kell érteni a dedup block-on?
Vagy, hogy a recordsize-t mi alapján kell megválasztani?

Nade nem offolom tovább ezt a szálat. Lehet nyitok rá egy másik forumszálat. (bocsi a tulajnak)

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Neked így elvileg elég ARC-nak az 512, gyakorlatilag minimum 4G-t ajánlanak mindenhol, viszont kíváncsi lettem én is :) elkezdek tesztelni minimum konfigot.
A ZFS blokkra számol cheksum-ot és azt nézi a dedup-nál, viszont nincs fix blokkméret mert az dinamikus, ellenben nagyjából az összes többi fájlrendszerrel. A recordsize az a méret ahol az annál nagyobb blokkokat "szétszedi". A default recordsize 128K, ez alapból megfelelő. Csökkenteni akkor érdemes, ha pl. az sql alkalmazásod 16K-s blokkméretet használ az adatbázisban. Növelni nem igazán érdemes, mert elkezd nőni a checksum számítási idő. A recordsize minden dataset-nél külön állítható. A dedup block számolással nem igazán kell foglalkozni, a 4GB ram/1 TB disk elég. A dedup block az a block amiből van másik ugyan olyan a rendszerben és élég egyszer tárolni, így nyersz helyet. A ram-ot viszont a teljes blokk darabra kell számolni, gondolom a block checksum-okat tárolja memóriában a ZFS. A block számolgatáshoz használhatod a "zdb" utasítást, az mindent megszámol neked.

A zavart erősíti, hogy van különbség a különböző megvalósítások között.
Például honnan tudjam, hogy a BSD parancsai hogyan (vagy egyáltalán) működnek(-e) OpenZFS-en, vagy Fuse-on?

Azért kösz az ajánlást.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Működnek, olyan nincs, hogy valamire más utasítás kell. A különbség az max annyi, hogy nincs minden implementálva a linux-on, akkor értelemszerűen hiányzik valami, de ez viszonylag kevés dolog és nem az alap utasítások. Én a linuxon a legtöbbet az oracle sun doksijaiból tanultam.

Válaszolok mindenkinek egyszerre, ha szabad, legjobb tudásom szerint (pontosítást, helyesbítést, javítást szívesen fogadok)! :-) Bocsi, hosszú!

Ha nincs elég erőforrás a ZFS-hez, akkor más után kell nézni (pl. MD+LVM+ext4 :-). A ZFS fájlrendszer, kötetkezelő és redundancia szolgáltató egyben. Ennek erőforrás igénye van. El kell fogadni, hogy ha nincs ilyesmire szánható, megfelelő mennyiségű CPU és RAM, akkor el kell engedni a ZFS-t. Olyan nem nagyon van, hogy lecsupaszítani. Olyan van, hogy korlátozod a memória felhasználást, és az kiad valami teljesítményt (ZFS szinten), ami vagy megfelel a felhasználásnak vagy kevés.

A ZoL elműködik 4 GB memóriával (mármint, hogy 4 GB jut a ZoL-nak, nem teljes rendszer memória!), a FreeBSD-s ZFS inkább 8 GB-ot szeret minimumként magáénak tudni (FreeNAS pl.). De persze ne erre építse senki a rendszertervét, ezek a minimumok, amik ahhoz kellenek, hogy irtó lassulás ne legyen. Én Linux-on 8GB-t (általános rendszer, nem storage célú), FreeBSD alapon 16 GB-ot javaslok minimumnak (persze ha FreeNAS storage, akkor inkább 32+ GB legyen). Ezek a számok csak több 10 TB pool méret felett lesznek csak kevesek. A ZFS belépési küszöbe eléggé magas RAM terén. Manapság eléggé olcsó a RAM és a legtöbb gépbe tehető is belőle jó sok, így nem kell ez gondot okozzon. Ha a gép erre nem képes, az azt jelenti, hogy nem való ZFS alá, nem a ZFS a hibás.
Itt még megjegyzendő, hogy sokáig riogattak mindenkit, hogy ha nem ECC RAM van a gépben, akkor egy esetleges RAM hiba esetén az egész pool oda lesz, mert a rossz RAM-mal újraszámolt checksum mind rossz lesz, ami tönkreteszi a pool-on lévő adatokat. Ez butaság, rossz RAM modul esetén ZFS-nél sem lesz több adat hiba a pool-on, mint bármi más rendszerrel lenne. Az a különbség, hogy a ZFS majd a scrub során legalább ezt észreveszi (míg egy ext4 esetén sose derül ki). Más oldalról ZFS alá a szerver hardverek ideálisak, amik általában ECC képesek, így én éles környezetbe mindenkit bátorítok az ECC RAM használatára ZFS esetén (is). Játszós teszt rendszeren mindegy.

A felhasznált memória jelentős része az ARC (Adaptive Replacement Cache), ami egy olvasási gyorsítótár annyi különbséggel, hogy erre a rendszernek van szüksége inkább. Ebből minél több van, annál jobb a rendszer általános teljesítménye (nem csak user adat van benne - sőt -, hanem rengeteg metaadat a ZFS működéséhez). Ehhez kell igazából a "sok" memória. Az L2ARC a nevéből is gondolhatóan a másodszintű ARC (lenne). Ez a régi idők maradéka, amikor a CPU-k memória címzése korlátos volt, és nagyon drága volt a RAM. Ilyenkor tettek be L2ARC-nak a pool-nál gyorsabb tárolót. Ez a RAM-ban lévő ARC és a pool közötti olvasási réteget ad(na ha használnánk). Manapság mindenki azt mondja (jogosan), hogy ki kell maxolni a RAM-ot a gépben mielőtt L2ARC kerülne a pool-ba. Ha így sem elég, akkor kell egy több RAM-ot kezelő gép, nem L2ARC. :-) Persze lehet kísérletezni (sok fórumon olyan szintig értik félre a működést és az értelmet, hogy egyazon kommersz SSD-t osztanak szét SLOG és L2ARC számára partíciókra - ez nagyon rossz ötlet). Vannak olyan speciális esetek, amikor jól jön az L2ARC mégis (nagyon nagy, jellemzően csak olvasott, de gyakran olvasott adathalmazok, amik mellett van más kisebb, de még gyakrabb olvasott adat is). Azt tudni kell, hogy az L2ARC is igényel RAM (ARC) területet, mert a ZFS az ARC-ban tárolja az L2ARC-ban elérhető adatok indexét. Szóval kevés RAM esetén pláne nem kell L2ARC, mert a sokkal hasznosabb ARC-ból rabol el helyet a működése.

A ZIL (ZFS Intent Log) az írási napló. Ez az írások lényege (mert a ZFS ugye Copy on Write). Alapból a memóriába kerül az írási log, majd onnan (az alapértelmezetten) a pool-on lévő ZIL-be, ahonnan (alapértelmezetten) 5 mp-ként a pool-on lévő végleges helyére a tartalma (ez nem a ZIL-ből, hanem szintén a memóriából, a ZIL-ből nem olvas vissza a rendszer, hogy kiírja a helyére). A ZIL-t a rendszer csak írja, folyamatosan. Egy esetben kerül csak olvasásra, ha egy összeomlás után helyre akar állni a ZFS, és a pool-on lévő adatokra rá akarja vezetni a ZIL tartalmát (az összeomlás előtti utolsó 5 mp-et). Tehát a ZIL nem gyorsítja az írás sebességét, azt a pool fogadási képessége határozza csak meg.
Az SLOG (Separate Intent Log) egy külső eszköz, de a pool része, ahol a ZIL helyet kap, a pool helyett. Régen a ZIL elvesztése pool elvesztéssel járt, ezért javasolták a tükrözését, de a mostani ZFS verzióknál erre nincs szükség (sőt, adott esetben lassabb lehet, mint egyetlen SLOG meghajtóval). Ha a ZFS rendszer SLOG hibát észlel, akkor simán visszavált a pool ZIL-re, és megy tovább hiba nélkül (mert ugye csak ír a ZIL-be, így nem okoz kárt, ha e közben hibát talál - persze ha ad abszurdum pont ilyenkor omlik össze a rendszer, akkor adatveszés lesz, max. 5 mp-nyi).
As SLOG célszerűen a pool-nál (jóval) gyorsabb írásra képes, magas IOPS értékű eszköz. A ZIL léte csak szinkron írásnál "tűnik fel". A ZFS a szinkron írásokat akkor jelzi vissza sikeresnek a kliens felé, ha a write log tartalma nem-felejtő tárolóba került nyugtázottan. Pl. VMware csak szinkron módon használ NFS-t datastore-nak. Namost ha egy nagy IOPS-es SSD kerül be SLOG-nak a pool-ba, akkor annyival lesz gyorsabb a szinkron írás IOPS (nem a throughput), amennyivel magasabb az SLOG IOPS-3 a pool-énál. Ezt leginkább erősen párhuzamos szinkron írásnál venni észre (pl. VM-ek futnak NFS-en keresztül a ZFS pool-on).

Az L2ARC hasznossága utáni másik félreértés itt szokott lenni, hogy bármilyen SSD jó ZIL-nek, mert mind gyors és magas az IOPS. Ez egy oldalról igaz, más oldalról saját magunk becsapása. Mert tényleg gyorsabbak, mint a pool jellemzően pörgő lemezei, de a legtöbb kommersz SSD DRAM-ot használ gyorsításra, onnan általában SLC NAND-ba ír (vagy közvetlen az MLC-be), majd onnan vezeti át később az MLC (TLC, QLC) NAND-ba az adatot a végleges helyére. A szinkron írást vagy a DRAM-ba, vagy az SLC-be írás után nyugtázza (a DRAM-os esetben áramkimaradás esetén adatvesztés lesz a ZIL-ben!), ráadásul nagyon lelassul, mikor a DRAM/SLC megtelik (pl. burst random írás a pool-ba).
Ellenben a vállalati PLP (Power Loss Protection - általában supercap-pel) képes SSD-k a fogadás után azonnal nyugtázzák a szinkron írást, mert a védelem miatt biztosan ki tudják írni nem felejtő tárba az adatot, bármilyen gyorsítást is használnak. Ezek általában nem is lassulnak le folyamatos terhelés alatt. Ilyen kedvelt PLP SSD az Intel Optane 4800-as sorozata (a 800-as, 900-as gyors, de nincs PLP!), vagy a Samsung SM-xx3-ra végződő vállalati SSD-inek jó része (a PMxx3 nem PLP-s). Fontos, hogy magas legyen az SLOG SSD írási tűrőképessége (TBW értéke), mert csak ír rá a rendszer, sokat.
A másik fontos dolog az SLOG-gal kapcsolatban a mérete. A minél nagyobb annál jobb itt nem igaz, sőt. Csak árt a nagy SLOG. Az SLOG méretének annyinak kell lennie, amennyi adatot a gép a ZIL kiírások közötti idő alatt (gyárilag 5 mp) fogadni képes írás céljából. Ez 1x1 GbE kapcsolat esetén 125 MB * 5 mp = 625 MB (!) összesen. Ha 1x10 GbE kapcsolat van, akkor lesz 6.25 GB az igény (!) összesen. Emiatt az SLOG-nak szánt meghajtókat leméretezik (overprovision) a gyári méret alá jóval (8 vagy 16 GB jellemzően), és így a "felszabadult" helyet az SSD kontrollere még a cellaterhelés kiegyenlítésére is el tudja használni (ez sokkal jobb módszer, mint a kicsi partíció létrehozása). Sajnos a gyárilag ilyen méretű meghajtók SSD-s léptékkel lassúak (minél nagyobb, annál több csip, annál gyorsabb párhuzamos írás), és általában nincs PLP (Pl. Intel Optane M10 sorozat ilyen, ami ideális lenne, de mégsem az).

Deduplikáció: az OpenZFS készítői, és az egyes megvalósítások készítői is arra biztatnak mindenkit, hogy _ne_ használjon deduplikációt. Ez is a régi idők maradéka, amikor a drága és kicsit HDD-k mellett a tárolható adatok mennyisége fontosabb volt a teljesítménynél. Az ajánlás most az, hogy 1 TB deduplikálandó adathoz tartozzon (dedikáltan erre szánt) 5 GB memória. Ezen felül jelentős a plusz CPU igénye a deduplikációnak, ha a teljesítmény csökkenését el akarjuk kerülni. Több veszik a vámon, mint jön a réven.
Manapság a tárkapacitás még olcsóbb, mint a memória, így én (is) mindenkinek azt javaslom, hogy több kapacitást tegyen a gépbe deduplikáció helyett, meg több RAM-ot az ARC növelésre, és úgy lesz a legjobb a teljesítménye és a költséghatékonysága. Jól átgondolt pool tervezéssel általában simán "meg lehet takarítani" a deduplikálással megtakarítani remélt tárterületet, a hibatűrés romlása nélkül.

Összefoglalásként annyit javaslok nem túl nagy ZFS rendszert építőknek, hogy minél több RAM legyen, és L2ARC meg SLOG nélkül használják azt. Ha valamire a HDD pool-nál nagyobb sebességű pool kell (átvitel és/vagy IOPS), akkor legyen csak SSD pool ilyen célra a rendszerben (és az legyen mirror vagy stipe+mirror, ne RaidZx). Ezen felül a megfelelő pool tervezéssel érhető el a kívánt cél (nagy throughput és/vagy magas IOPS) leginkább, szóval a tervezésnél kell körültekintőnek lenni (mennyi meghajtó lesz egy VDEV, mennyi és milyen VDEV kerül egy pool-ba, stb.). A pool tervezés alapok legalább ennyi betű lenne még, mint ez az írás...
Meg fontos még az ashift értéke a teljesítmény terén, ami az adott VDEV/pool-ban használt meghajtók szektorméretétől függ (512 byte esetén 9, 4096 byte esetén pedig 11 a helyes értéke). Egy pool-ban lehetőleg ne legyen több különböző szektor méretű eszköz. Ez fontos.

Ezen felül érdemes a recordsize-t a tárolt adathoz igazítani, ezzel sokat lehet a helykihasználáson (ZFS space overhead) és a teljesítményen is javítani. Ha nagy állományok kerülnek rá (pl. média tartalom), akkor nyugodtan lehet 1 MB a recordsize, ha pedig kis rekordokkal dolgozó rendszer (adatbázis), akkor akár xx kB-ig is le lehet menni (a ZFS a 4 kB-os egységekkel már nem igazán bánik gyorsan, így érdemes DB esetén lehetőség szerint inkább 8-16-32-64 kB rekordméretre állni). A recordsize dataset szintű paraméter, szóval nem kell az egész pool-nak kicsi vagy nagy rekord méretűnek lennie. Ezen felül tetszőlegesen változtatható futásidőben, annyi megkötéssel, hogy a már tárolt adatok rekord mérete nem változik, csak az újonnan az adott dataset-re írt adatok lesznek az új rekord mérettel tárolva.

Remélem ezzel a sok szövegeléssel sikerül valakinek segítenem kicsit.

Köszi szépen a sok munkát. Még esetleg ha van tapasztalat a raidz lemez darabszám és sebesség dologról írhatnál. Mindenütt olvasom és tapasztalom is, hogy adott méret mellett a több lemez sokall jobb. Most teszteltetem pl.

HP DL360G9+P440 4xSAS disk
size=10G -> write: IOPS=2513, BW=314MiB/s (330MB/s) (10.0GiB/32586msec)
Desktop (saját otthoni nas) DeLock 10 csatornás SATA 7xkevert öreg gagyi diskek, többnyire 5200-es és nincs két ugyanolyan
size=10G -> write: IOPS=3963, BW=495MiB/s (520MB/s)(10.0GiB/20667msec)

A DeLock simán verte a HP P440-et a 7 kontra 4 disk-el :)

Azt is olvastam, hogy 2n+paritás disk szám a tuti. Pl raidz2-nél mondjuk 8+2. Ezt viszont nem tudtam kimérni, hogy jobb lenne.

Még egy kérdés, ha nem titok, honnan van ennyi tapasztalatod a ZFS-el?

Nincs semmi titok ebben, minden fent van a neten. Ezek az infók rengeteg olvasáson és tanuláson keresztül szerezhetők meg. A tanulás utáni kísérletezés csak alátámaszt jó esetben. Ezeket használva (számomra) sikeresen működtetek ilyen (nem túl nagy) rendszereket, fennakadások nélkül.
Az a lényeg, hogy ki kell tudni szűrni a sok elérhető infóból a hozzá nem értők által félreértelmezett/rosszul használt részeket. A ZFS pedig elég bonyolult ahhoz, hogy könnyű legyen félreérteni és/vagy rosszul magyarázni. Azt figyeltem meg, hogy amit a legtöbben irkálnak (fórumokban, szakmai oldalakon, blogokban), azt veszi mindenki hitelesnek független az írás valódi "jóságától" (a nagy számú megjelenés miatt, emberi tulajdonság), pedig sokszor csak egy adott butaságot ismételget mindenki más, alapos utána nézés vagy értelmezés nélkül.

A P440 4xSAS diszket nem értem, mert a P440 nem HBA (és nem is flesselhető azzá tudtommal), hanem HW RAID vezérlő. Legjobb esetben is egy lemezes stripe virtuális köteteket mutathat az OS felé. ZFS-hez pedig fizikai diszk hozzáférés kell sok okból, ez sokkal fontosabb, mint az ECC vagy nem ECC RAM kérdése. A HW RAID vezérlő mindig gyorstárazik, amire sem ráhatása, sem infója nincs a ZFS-nek, így sok védelmi mechanizmus megbénul. Ráadásul a pre-fail diszket simán kidobja, elveszi az OS alól, és ez elég gond, ha az nem redundáns kötet része a RAIO vezérlőn, hanem egy szóló diszk virtuális egységként kiajánlva.
Vagy a P440-en natív HW RAID kötet van (miféle?), és azt mérted?
Ezért SAS HDD-kkel csak HBA jöhet szóba ZFS alá, HW RAID semmiképp.
Egyébként a 4 vs 7 HDD tiszta sor, ha mind a két verzió 1-1, azonos típusú VDEV-ben van (mondjuk RaidZ1-2). Mivel a 7 HDD-s VDEV-nél 7 felé oszlik a terhelés, a másiknál pedig csak ennek bő felére. Nyilván a több felé osztott ad magasabb teljesítményt összesen (olvasáskor, mert az írás mindkét esetben kb. 1 HDD sebességével egyezik, és az IOPS is azonos).

Az egy VDEV-ben lévő meghajtóknál valóban a 2^n+p az iránymutató, de az ettől való eltérés nem a teljesítményt, hanem a ZFS recordsize alapján eltérő overhead (elvesztegetett tárhely) változik. Meg az elméleti rendelkezésre állás. Ha nem e "szabály" szerinti a diszkek száma, és kicsi a recordsize, akkor több hely vész kárba (a dummi block-ok miatt), ha nagyobb, akkor kevesebb a veszteség. A szabály szerinti elrendezésnél a veszteség recordsize függetlenül nulla. De itt mindig max. néhány % körüli veszteségekre kell gondolni még extrém darabszám/rekordméret mellett is. Ezt még tovább árnyalja, hogy a ZFS dinamukus blokkméretű, és a blokk méretét befolyásolja ha tömörített a dataset. Szóval a 2^n+p képlet jó, de semmiképp sem kell nagyon ragaszkodni hozzá.

Itt egy jó kis számológép, ami pár adatból kiszámolja a ZFS overhead-et, a használható kapacitást, a várható meghibásodás idejét, várható resilver időt, stb.
Ez egy irózat jó részletes leírás erről a témakörről.

Általános és bevált, hogy egy VDEV-ben ne legyen 11-13 meghajtónál több. Akkor a legjobb a teljesítmény és a hibatűrés. Az az igazi, ha egyforma méretűek a HDD-k (később hiba javításnál ez sokat segít), és jellemzően egy vezérlő nem enged keverni SAS és SATA diszkeket.
A pool akkor a legjobb, ha teljesen egyforma VDEV-ek alkotják, szóval a tervezésnél érdemes figyelembe venni a későbbi bővítési igényeket és lehetőségeket (mennyi fizikai HDD hely van, stb.).
Alap, hogy 2TB-nál nagyobb HDD-ből RaidZ1-et nem csinálunk, mert ugye a RAID5 (RaidZ1) 2008 óta halott (nem biztonságos nagyobb tárkapacitású meghajtókkal).
Komoly tévhit még, hogy a mirror+stipe biztonságosabb nagy HDD-kkel, mint a RaidZ2-3, mert gyorsabb a resilver. Ez több okból sem teljesen igaz, mert mirror+stripe esetben egy VDEV csak 1 lemezig hibatűrő, és ha az kiesik, akkor az egész pool veszélyben van, mert ha az adott mirror másik fele is megáll, akkor vége. Ellenben a RaidZ2 bármely két lemez elvesztését tolerálja. Igaz, a tükör resilver sokkal gyorsabb (sok meghajtós pool-nál, pl. 4 meghajtónál ugyan annyi, mint a Z2), de nagy diszkekkel és nagy pool-okkal pont azért kell Z2-3, hogy legyen mozgástér (hibalehetőség) a resilver alatt.

A teljesítmény, kialakítás pedig:
- Minél több VDEV vagy egy pool-ban, annál több az IOPS és az írási sebesség.
- Egy VDEV egyre több eszközzel egyre nagyobb olvasási sebességet, de azonos IOPS-t nyújt.
- A mirror és a stipe nem igényel számottevő CPU időt, a RaidZ-k-nek kell CPU. LZ4 tömorítés elenyésző CPU igényű és nagyon jó hatásfokú (a többi tömörítés felejtős).
- A VDEV típusát és a pool összeállítását érdemes a várható terheléshez igazítani (inkább soros/random elérés, inkább olvasás/írás, ezek kombinációi). Nem minden VDEV jó minden terhelésre, és azt gondolom nincs olyan kombináció, ami mindenben jó.

Egy VDEV írási sebessége nagyjából egy meghajtójának írási sebességével egyezik. Egy VDEV olvasási sebessége majdnem lineárisan nő a benne lévő adat diszkek számával.
Magas IOPS-re és/vagy írási sebességre sok VDEV-ből álló stripe a legjobb. A legnagyobb (jó hibatűrésű) hasznos kapacitásra a sok diszkből álló RaidZ2 (vagy RaidZ2 VDEV-ek stripe-ban) a legjobb. Ha nem lehet gyorsan HDD-t cserélni hiba esetén (mondjuk pár napon belül), akkor RaidZ3 a RaidZ2 helyett.
Írási sebességben a több VDEV-es stripe-ok a jobbak (azon belül kellő CPU teljesítmény mellett mindegy, hogy mirror-ok vagy RaidZ-k), nagy olvasási sebességre majdnem minden mindegy, csak sok diszk legyen a pool-ban.
Az LZ4 jó, ha mindig be van kapcsolva. A ZFS intelligens, ha az első pár blokk nem tömöríthető jól, akkor egyáltalán nem is próbálja tovább a tömörítést az adott műveletre, nem viszi a CPU-t feleslegesen.

Hasznos ZFS pool méret kalkulátor (különböző méret adatok a VDEV, diszk szám alapján)
Eléggé alapos VDEV/pool teljesítmény összehasonlító a Calomel-en

Van még ezer téma ezzel kapcsolatban, most ennyi jutott hirtelen eszembe. Kérdésre szívesen válaszolok ha tudok. De nem vagyok orákulum, aki mindent tud.

Köszi szépen :) A HP (elég sok HP szerverrel dolgozom) a P sorozatú SmartArray kontrollerekben már a G8-as sorozat óta támogatja HBA módot. Azoknál még szívás volt, mer csak bios-ból lehetett állítani egy elvarázsolt billentyűkombináció után kellett kiadni egy parancssorban egy utasítást. Utána még hegeszteni kellett, mert boot-olni alapból nem szeretett rá. A G9-óta már simán támogatja a HBA módot, van rá gomb a SmartArray szoftverben https://i.stack.imgur.com/39NMQ.png
Apróság, hogy nem mindegyik kontroller tudja, csak a HP a megmondhatója, hogy mitől függ. A P440ar biztosan. Mixelni nem lehet a módokat, ha HBA akkor nincs kapacitor, cache memória és a raid menük is kikacsolódnak a szoftverben. Simán, gond nélkül boot-ol bárhogy, van több proxmox szerverem zfs-el p440-alatt. A tesztem a DeLock kontra P440-el a SAS lemezek is HBA módban voltak. Én úgy tapasztalom, hogy a több emez az írást is gyorsítja, ráadásul a caomel tesztben is az van. Ezt onnan másoltam példának:

4x 4TB, raidz2 (raid6), 7.5 TB, w=204MB/s , rw=54MB/s , r=183MB/s
6x 4TB, raidz2 (raid6), 15.0 TB, w=429MB/s , rw=71MB/s , r=488MB/s

Csinálhatnánk egy ZFS Fan Club topic-ot, mert jó lenne gyűjteni a tapasztalatot :D Pl. megbeszélhetnénk egy egységes mérési módszert.

Remek infók, ezeket nem tudtam, köszönöm! Bár épp távolodunk el a HP szerverektől, mert eléggé zavar, hogy nincs frissítés csak garancia időben vagy plusz pénzért (meg az, hogy 10x annyi erőfeszítésembe telt FW frissíteni egy G8-on, mint egy azonos korú Dell-en). És én az iLO komolyabb funkcióit is drágállom más gyártókhoz képest.

Igen, azóta észrevettem, hogy belegabalyodtam az IOPS és sebesség kérdésbe néhol. Az IOPS egyezik az adott VDEV-en egyetlen diszk értékével, az átviteli sebességek skálázódnak a diszkek számával (így is logikus). Az IOPS pedig a pool-ban lévő VDEV-ek számával skálázódik.

Én benne vagyok valami ZFS-es "közösség" összehozásában, csak kellene valami ötlet, hogy hol és milyen formában (gondolom valami fórum jellegű lenne jó, esetleg egy subreddit magyarul erről?).

Nekem vannak még VM-ben futtatott FreeNAS-os tapasztalataim és infóim is a "normál" rendszereken felül (VMware és Proxmox, a VM mindig PCI passthrough-val kapja a HBA-t, nem szoftveres HDD átadás van természetesen). Az is érdekelhet a mai világban többeket (mondjuk ez inkább otthoni laborozásra jó, mint éles rendszerre ügyfélnél).

A HP-s dologgal én is így vagyok, szerintem sem éppen a jó irányba megy a HP. Éppen összerakós szervereket nézegetek, ez pl nagyon király :) https://www.backblaze.com/blog/open-source-data-storage-server/
Indítok egy klubos témát, hogy van-e kettőnkön kívül érdeklődés :)

"Csinálhatnánk egy ZFS Fan Club topic-ot, mert jó lenne gyűjteni a tapasztalatot :D Pl. megbeszélhetnénk egy egységes mérési módszert."

Pont erre gondoltam én is. Én tagja lennék mindenképp.

---------------------------------------------------------------
Csak akkor szólok hozzá egy témához, ha értelmét látom.

Pl. VMware datastore NFS-en keresztül felvéve. A VMware csak szinkron írást használ/enged NFS-en. Azt gondolom, hogy ha más hypervisor nem is követeli meg, VM-et futtatni NFS-ről vagy iSCSI-ról jobb bekapcsolt sync írással.

Persze elsőre én is úgy gondolkodtam erről, hogy mi a halálnak NFS-re (vagy iSCSI-ra, mindegy) tenni több VM-et, aztán 1 GbE kapcsolaton kínlódni velük (régebben dolgoznom kellett egy pont ilyen felállású HP storage - VMware host párossal, nem volt öröm). De olvastam pár olyan FreeNAS és TrueNAS (élesben működő) eszközről, amelyek all-flash pool-lal futnak (vállalati SSD-kből), a mellé Intel Optane P4800X SLOG-gal és 10 GbE meg 40 GbE hálózattal szereltek. Szóval van értelme ennek, csak nem azon az árszinten amin én gondolkodtam akkor :-)

Érdekes, hogy a FreeNAS közösség jó része azt írogatja tanácsnak (nyilván ezt is egyvalaki kitalálta, aztán mindenki ismételgeti, azért), hogy ne NFS-t használj, hanem iSCSI-t, mert ott nem kötelező a VMware-ben a szinkron írás, és mennyivel jobb teljesítményű úgy. De ez butaság, mert pont a biztonságot kapcsolják így ki, ahelyett, hogy megfelelő hardverrel próbálnák a feladatot jól megoldani.
Meg iSCSI-n azért nem kötelező a (VMware) leírások szerint a szinkron írás, mert a vállalati SAN-ok, amik jellemzően iSCSI-t ajánlanak ki, megoldják házon belül a biztos kiírást anélkül, hogy a VMware számon kérné. Ezt sem megerősíteni, sem cáfolni nem tudom, mert sem nem olvastam el részletesen, nem nem dolgoztam ilyenekkel eddig.

Egyébként mindenhol, ahol nagyon fontos egy rendszer szempontjából, hogy csak akkor gondolja, hogy rögzítve van az adat, ha tényleg rögzítve van. Pl. adatbázis szerver NAS/SAN-on lévő adatbázissal.

Szinkron irással kapcsolatban van itt egy érdekes teszt, a tesztelő ís irja. hogy a végeredmény ellentétes az intuitív elgondolásnak, -csak egylemezes a teszt, de kikapcsolt lemezccache-el 4 szeresére nőtt a kis blokkoknál az írási sebesség . Nekem is furcsa habár máshol is olvastam. Nyilván egy ilyen pool-on az aszinkron tranzakcios io-nak lőttek.
itt a a teszt:
https://www.ixsystems.com/community/threads/on-disk-cache-and-zfs-perfo…

Ez azért eléggé speciális felállás, a valóságtól/gyakorlati megvalósításoktól elég messze áll. Így szerintem nem is mérvadó.

Ezen felül az elmélet bizonyításához több különböző meghajtóval is meg kellene vizsgálni, hogyan viselkedik be- vagy kikapcsolt gyorstárral. Egy mérés nem mérés.
Lehet ennek az egy modellnek az FW hibája okozza ezt a jelenséget, vagy épp pont nem ilyen használatra optimalizált benne a szoftver, stb.

Az a lényeg, hogy ki kell tudni szűrni a sok elérhető infóból a hozzá nem értők által félreértelmezett/rosszul használt részeket

Régen a ZIL elvesztése pool elvesztéssel járt, ezért javasolták a tükrözését, de a mostani ZFS verzióknál erre nincs szükség

Az egyik ilyen.hogy ZIL/SLOG mindenképpen tükrözve, mert elveszted a pool-t, ha elszáll az sLOG. Pedig írják , hogy 19-es zpool verziótól felfelé már nincs ilyen. Elvileg így már SLOG-nak elég 1 db SSD.
Használtan elég olcsón leht venni használt S3700 (sata) vagy P3700(NVMe) -as 400-800GB intel DC ssd-t, 7-8 petabájt írést adnak meg ezekre (7.3 PBW-JEDEC Workload),

Ezt én a gyakorlatban is igazolni tudom, mert pukkant el szimpla 1 db. SLOG SDD-m. Semmi baja nem lett a pool-nak. Az viszont fura volt, hogy nem kapcsolta le a ZFS és durva IO load lett a gépen. Az a nyomorult disk nem tisztességesen romlott el, hanem próbált irkálni, de persze nem ment neki. A ZFS meg csak erőltette, szép volt... Kézzel kellett lekapcsolnom.

Ez egészen pontosan nem a snapshot, hanem a replikáció esetén használt dedup. Ez valóban nem érinti a pool-t. Kicsit megtévesztő a fogalmazás, mert általában snapshot-ot replikálnak, de ez a replikációra vonatkozik, nem a snapshot-ra.
Normál snapshot-ot a dedup ugyan úgy érinti (a snapshot a pool adattartalmának része, a dedup blokk szintű, független a tárolt adat felépítésétől).

Vannak olyan speciális esetek, amikor jól jön az L2ARC mégis

Itt egy blog mérésekkkel, beállításokkal, 1500-ról 5000-IOPsre növelte a mysql olvasásást l2ARC-vel:

https://www.percona.com/blog/2018/05/15/about-zfs-performance/

Részlet innen:
"Nem szívesen emeltem az ARC-t 7 GB-ra, ami majdnem fele volt a teljes rendszermemóriának. A legjobb esetben a ZFS teljesítménye csak az XFS-nek felel meg. A nagyobb InnoDB oldalméret növeli a CPU terhelését a példány dekompressziójához, csak két vCPU-val; sem nagyszerű. Az utolsó lehetőség, az L2ARC volt a legígéretesebb."

> vagy a Samsung SM-xx3-ra végződő vállalati SSD-inek jó része (a PMxx3 nem PLP-s)

A PM983 U.2 PLP-s, es _nagyon_ jo arban van, mar ha tudtok belole itthon szerezni (elvileg OEM diszk).

https://samsungsemiconductor-us.com/labs/pdfs/Samsung_PM983_Product_Bri…
https://www.compuram.biz/documents/datasheet/Samsung_PM983-u2.pdf