ZFS vagy SoftRAID egy HP N36L Microserver-en

 ( zamolxyse | 2019. augusztus 22., csütörtök - 11:51 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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.

Van két szerver ami müxik már 1 éve MD+LVM-el eddig semmi probléma nem volt. Igazából nem szeretnék teljesítmény vesztést ZFS esetében.

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.

Ha kivezettem a cache-t SSD-re az mennyivel javít a helyzeten miszerint kisebb lesz a HDD Disk IO?

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.

Az lett volna a terv hogy 1db SSD mint Cache közreműködik, de ezek szerint nem segít a dolgon, kicsit tehermentesítse a diszkeket.

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

Mennyi írást bírtak evok es melyik széria volt? Valamint hogyan haltak meg, csak írásvédetté váltak vagy olvashatatlanok lettek?

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.

Pont a 840 evo-val sok hiba volt, cikk a HUP-ról:

https://hup.hu/cikkek/20150510/folytatodik_a_samsung_evo_840_kalvariaja

Azóta sok minden változott, pl 860 EVO : új vezérlő (ugynaz mint a PRO és DC verzióban) , új 3D vnandok, DDR4 cache, talán több is, slc cache.

Sehol sem ajánlják production környezetbe a consumer ssd-ket, a Samsungok mellet egy Kingston ssd-m is kipurcant ZFS alatt. Ennek ellenére lehet, hogy teszek egy próbát valami nem annyira fontos gépen egy új EVO-val, elég nagy az árkülönbség egy megérjen egy tesztet.

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.

Azért egy DVR írási terhelése nem egészen annyi mint egy szerver fájlrendszer io cache terhelése. Nem mindegy hogy hetente írod tele a lemezt, vagy óránként :) Nálam a 30%-ot 90 nap alatt érte el a lemez, de akkor már nem igazán akart működni.

Sync=always a beállitásod? 50 Terrabájt szinkron írás 3 hónap alatt.

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/optane-dc-persistent-memory.html
https://www.intel.com/content/www/us/en/products/memory-storage/solid-state-drives/data-center-ssds/optane-dc-ssd-series/optane-dc-p4800x-series.html
(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-freenas-nas-servers/

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)

persze a P sorozat az igazi lognak, de az S3700-at is jónak mondták.

ATX lapból meg van olyan, amin U2 csatlakozó van supermicro-ból.

SATA-nak jó még az M1015 kártya is IT módra flashelve (ez is van eltéve 1 db !-) )

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 )

Hát ez magárt beszél.
Ezt nézted már: https://calomel.org/zfs_raid_speed_capacity.html
Engem meglepett a sebesség növekedés nagysága a lemez darabszám növeléssel.

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)

Hogy konfiguráltad a zil-hez a lemezeket? Jól gondolom hogy a zil 3 lemezes raidz1-en volt?
500-ból lett 10 sec, az nem semmi.

Hat db. 3 TB-os TOSHIBA DT01ACA3 HDD RaidZ2 , LSI LSI9211-8i, 8 GB ram, freenas.

+a ZIL ssd, a teszt miatt csak 1 db.
dd egyszerű, talán a viszonyitáshoz jó.
Lehet megnézem bonnie++ -al is, ha már nekiálltam.

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

Ezt a memória limitaciot próbáltam, de ugyanúgy felnyalta a 8GB-t. Hogyan lehet hardosan limitálni?

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.

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.

Én ugyan N40L-en, de használok ZFS-t és semmi bajom nincs. Igaz, FreeBSD-vel.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Hogy nincs baja egy dolog. Hogy rendes performance van-e egy masik.

+1 Ennél a gépnél 5x gyorsabb a kis netezős gépem (Brix) és eszembe nem jutna ZFS-t használni rajta.

Ext4 vagy zfs helyett ext4,md-raid(x)/lvm/snapshot vagy zfs -t kell összehasonlítani.

Akkor ha jól látom a ZFS ebben környezetben nem igazán jó választás, nagyobb a teljesítmény igénye mint a régi ext4-md-raid1-LVM megoldás.

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.

Igazából én is erre a következtetésre jutottam nem nyerek annyit a ZFS-el, amiért váltani kellene.

Ha proxmoxot feltolod, bármikor tudsz zfs és lvm storage között vm-et mozgatni. Mindkettő helyben létrehozott storage.

Igy müxik már két ilyen mikrokocka, gond nélkül kluszterben, de gondoltam kihasználom a replikációt a PROXMOX-ban, illetve a Live Snapshotot is.

+1

Továbbá nekem az rémlik, hogy a Proxmox softraid-et tud alapból. A telepítő megkérdezi, csak nem LVM-en. Tehát én így próbálnám, megnézném. Akár egy virtuális gépen, adj hozzá 2 disk-et és látni fogod.

Sakk-matt,
KaTT :)

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

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.

Az árkülönbséget nézve nem rossz, már ha bírja a gyűrődést.
Lassan egy blog bejegyzést csinálhatsz a sok tesztelésből :)

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.