ZFS storage tapasztalatok v2

 ( akoscomp | 2016. december 6., kedd - 14:56 )

2013-ban volt egy hasonló téma (http://hup.hu/node/121509), de azóta eltelt majdnem 4 év, megjelent és kiforrottá vált az openzfs, egyre több OSben támogatott vagy alapértelmezett a ZFS, stb.

Nem rég kezdtem neki egy komolyabb tárolónak, ami terveim szerint ZFS+NFS-en szolgálna ki 5 Dell PowerEdge szervert, kb 400 GB memóriával és 40 fizikai processzormaggal.
Maga a vas egy Supermicro SuperStorage Server 5028R-E1CR12L, 64 gb memóriával, 8x2 TB HGST NL-SAS HDD-vel és 2x150 GB Intel S3520 SSD-vel.

Érdekelnének mások tapasztalatai, illetve a megvalósítási/üzemeltetési tapasztalatok. Mennyire vált be egy ZFS alapú tároló és mennyire stabil a zfs replication alapú mentés.

Az első komolyabb teszteket ubuntuval végeztem, de az OS nincs rögzítve (OmniOS-t és FreeBSD-t teszteltem még). Tesztcéllal, ubuntu 14.04 alapokon van egy HP szerverem 4x2 TB sata hdd+2 SSD, 32 gb ram, ami most a kevésbé kritikus gépeket osztja ki a szervereknek. Itt majdnem 1 év az uptime, és még semmi negatívumot nem tapasztaltam, ameddig a HDDk bírják szépen skálázódik a gép.

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ő.

Nekem a 8db nl-sas keveskenek tunik :)
De kivancsi leszek meresekre.
Nalam jellemzoen a mentes veri oda igazan az io-t, azt nem tudom hogy gondoltad kivitelezni.
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

zfs replikával mentesz?
Én most naponta 1x mentek és nem érzi meg a gép. Így egy snapshot 20-30 GB.
Az összes vm-et lehet nem fogja elbírni, de ha beválik akkor valószínű kerül mellé még egy legalább ilyen, és ketten egymás kiesését is lefedve már meg kellene bírkózzanak az összes vm-el.

xenservereken futo vm-eket mentek full mentessel (snapshot majd export).
ez egy md1200-as storage tele nl-sas diskkel, es erezhetoen szarrawait-el amikor elkezdek menteni egy nagy (1,5T) vm-et.
Inkabb a diskek gyengesegere probaltam utalni, nem is a zfs-re.
Nyilvan lehet az ssd cache dob rajta, kerdes mennyit :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

A kerdes a zfs snapshotra vonatkozott. Azzal mented?

Mint irtak tobben, annyira minimal terhelest okoz, h meg sem erezni. Nalam a backup szerer oldalan egy atom is elvinne, a storage szerver oldalan pedig olyan, mintha nem is lenne.

Ha tobbszor mentesz naponta, akkor ertelemszeruen fokozottan igaz, nincs ideje megerezni.

Ha a VM(-ek)ben sok valtozas volt, sokat kell lemasolni, akkor persze igen. De ritka, h vki ilyen stuffot VM-be rakna.

t

nem zfs :)
Eleg negativ tapasztalataim voltak vele, varok meg... :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

A ZFS mentés az különbözeti mentés, ami futhat akár óránként, vagy elvileg percenként is (ha valakinek rendes terhelés esetén van ilyen tapasztalata, megoszthatná). Ha óránként fut akkor elvileg pár GB adatnál nem kell többet menteni, tehát szinte nulla a mentés terhelése.
Én most 25 VM-et (nagyon vegyes: exchange, tomcat, web, mail, stb) futtatok zfs tárolón és azok napi 20-40 GB adatot termelnek, aminek a mentése pár perc és nem érezhető az IO-ban.

ez jol hangzik, de ha storagerol kell mentenem zfs-re, akkor mar mas a leanyzoo fekvese ha jol gondolom :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Jól gondolod.
Ehhez maga a storage kell zfs legyen.
Mi két MD1000-et váltanánk ki evvel, és a banálisan egyszerű backup az egyik fő érv, amiért a zfs-re esett a választás.

Attól függ, mennyi a változás, mennyit mentesz. Nekem 10 percenként megy a ZFS repl., így a viszonylag kevés adatot különösebben meg sem érzi a szerver (Dell PR R510, 10x4TB WD RE SATA + 2x512 Samsung 850 Pro)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Milyen OS-t használsz?

16-os Ubuntu-t (és a tárolt guest OS-ek nagy része is az)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Ez a tema engem is foglalkoztat, de en nem VM-eket etetnek rola, hanem gyors eleresu NAS-t szeretnek ZFS Linux (ubuntu) alapon.
Jelenleg a 16.04 LTS verzio van hasznalatban, (probaltam FREEBSD-t /FreeNAS-t is), de en azota miota van ZFS a Linux kernelben azt jobban preferalom.
Nekem a halozattal meggyult a bajom, hiaba van jo hardverem nem tudok olyan gyorsan felszippantani a diskekrol fileokat.
Ha mar itt vagyunk inkabb NFS vagy SAMBA-n is erdemes probalkozom? Nekem most SAMBA -n van a share es nem igazan ertem mi bottleneck-el el.

macdroog

Az NFS-nek kisebb az overhead-je, mint a Samba-nak. Ha megírod, milyen hardvert használsz, kitalálhatjuk, hol lehet a bottleneck.

CPU(s)~2 Hexa core Intel Xeon X5680s (-HT-MCP-SMP-)
speed~3334 MHz (max)
Kernel~4.4.0-53-generic x86_64
Mem~14763.3/24100.4MB
Mobo: Supermicro model: X8DAH

A vezerlo >> ATTO Pciex8 6Gb/s ezen van 8x6tb Hitachi NAS HDD (RAIDZ2) 33TB
A masik vezerlo >> ATTO Pciex8 6Gb/s ezen van 4x512GB Samsung Pro (RAIDZ) 1.8TB

Halozat >> 2 port Myricom 10Gbe - ez most igazabol nincs hasznalatban
Halozat >> 2 port 40Gbe Mellanox kartya ami egy Mellanox Switchbe megy (sx1036) >> a kartya Pcie3-at ismer, de ezen a lapon csak Pcie2.0 van (5GT/s) aminek az elmeleti sebessege 4GigaByte/s, amibol en Iperf3-al csak 2GigaByte/s-t tudtam kicsikarni, aminek mar nagyon orulnek mert a diszk ami (SSD RAIDZ) az DD-vel 1.3GB/s-t tud olvasni..... ha ezt a sebesseget a 40Gbe-n tudnam mozgatni nagyon orulnek.

A sysctl.conf igy nez ki >>
######CUSTOM_00######
# allow testing with buffers up to 128MB
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
# increase Linux autotuning TCP buffer limit to 64MB
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
# recommended default congestion control is htcp
net.ipv4.tcp_congestion_control=htcp
# recommended for hosts with jumbo frames enabled
net.ipv4.tcp_mtu_probing=1
# recommended for CentOS7/Debian8 hosts
net.core.default_qdisc = fq
# recommended by performace experts to set net.core.optmem_max as in net.core.rmem_max and wmem_max
net.core.optmem_max = 134217728

Az smb.conf >>
[global]
socket options = TCP_NODELAY SO_RCVBUF=524288 SO_SNDBUF=524288 IPTOS_LOWDELAY

A kliens egy WIN10 gep szinten 40Gbe kartya ami a switchbe csatlakozik JUMBO FRAME mindenhol server-switch-kliens egy filetransfer sima wincopy elindul 1.3GB/s -el majd lemegy 500MB/s-re.
Kliens (64gb RAM, X99 chipset, sok lane-es cpu)

Az iperf3 a ket gep kozott 17-20Gbit/s en latja egymast. (ami 2GB/s) en ezt a sebesseget szeretnem, halozaton! :D

Ha a RAIDZ2 tombodrol olvasol akkor szerintem az 500 MB/s tartos olvasasi sebesseg teljesen jo.

--
http://blog.htmm.hu/

A RAIDZ2 (8x6tb HDD)-bol olvasasra kihoztam mar az 500MB/s-t halozaton, en az SSD-k (RAIDZ) olvasasi sebesseget szeretnem elerni, halozaton.
1.3GigaByte/s-el amire az elmeleti sebessegem adott, de sajnos a gyakorlat nem ezt mutatja.

Én kipróbálnám a 2xraidz felállást. Nekem kb 10%al gyorsabb volt ez mint a raidz2, és majdnem hasonlóan megbízható, ugyanakkor egyenletesebb a terhelése.
A compress-t a tárolandó adatok függvényében megint érdemes bekapcsolni, mivel gyorsabb a modern CPUval ki/be csomagolni az adatot, mint kiolvasni a lemezről, tehát ha van legalább 20% hatásfoka a tömörítésnek gyorsabb lesz az átvitel.

Szintetikus teszteken (fio, bonnie++) sikerült 1,3TB/s olvasási sebességet mérnem 160GBs tesztadattal, 2x4hdd raidz-ben, compress bekapcsolva.
Elvileg úgy az NFS mint a Samba is tud elég gyors lenni, de ennyi adat kiküldéséhez 10Gbps kell, én LACP-vel bondolom a 4 hálókártyát, ami a 2x1 Gbps HP szerverből kiindulva bőven elég lesz.

> sikerült 1,3TB/s olvasási sebességet mérnem 160GBs tesztadattal [...] de ennyi adat kiküldéséhez 10Gbps kell

Tenyleg?:)

ja...
1.3GB/s

Az meg mindig sok lesz, de kozelit:)

OmniOS-t en kifejezetten szeretem. Pici, handy, mukodik betonstabil.

A tombot illetoen:
* raidz-hez en 2^n+1, raidz2-hoz 2^n+2 db diszket hasznalnek.
* Az intel-eket zil-nek, vagy l2arc-nak tervezed hasznalni? Hint: hasznalj kulon zil-t es l2arc-t is. Kulon lemezekkel! egesz lemezt adj hozza, ne particionald!
* Erdemes a vezerlot IT modba tenni, es az illumos-ra bizni a raid megszervezeet
* valami kis pottomnyi ssd-re telepiteni az os-t. Vagy amire jol esik. Magyaran valaszd kulon a "tank" es az "rpool" funkciokat.

Ahh, most nezem, hogy ez a kis intel valami 40k koruli iops-t tud.
En zil / l2arc celokra inkabb valami nvme / pcie csatlakozasu brutal cuccost hasznalnek.

Vagy ezeket a kis intel vackokat az rpool-nak gondoltad?

Így utólag OSnek marad. Teszt közben jöttem rá, hogy nem biztos, hogy tud gyorsítani.
Mivel a hdd hely adott, én úgy képzeltem, hogy minden az ssdken van, az OS és a zil mirrorban és az l2arc stipe-ban, particiokon.

A zil és az arc kizárólag SSD-ken legyen. Ha HDD-re teszed, azzal éppen az értelmüket vesztik el. BTW FreeBSD és *Solaris rendszereken nincs (performance)hátrány abból, hogy partíciókra teszed a ZFS-t/zil-t/arc-ot.

Linuxon sincs, csak akkor kezzel kell noop-ra allitani.

Jó tudni, köszi.

A lenti példában, az sde,f,g deadline-on van:
/sys/block/sda/queue/scheduler:[noop] deadline cfq
/sys/block/sdb/queue/scheduler:[noop] deadline cfq
/sys/block/sdc/queue/scheduler:[noop] deadline cfq
/sys/block/sdd/queue/scheduler:[noop] deadline cfq
/sys/block/sde/queue/scheduler:noop [deadline] cfq
/sys/block/sdf/queue/scheduler:noop [deadline] cfq
/sys/block/sdg/queue/scheduler:noop [deadline] cfq

Nekem ezek az SSDk tehát ubuntu 16.04-en az SSD és usb flash default deadline-ra kerül.

Googli szerint a noop az a natív átvilelnél segít, még a deadline az IO-t gyorsítja. Ha így van, akkor a deadline tűnik nekem jobbnak cache esetén.

Azt szoktak mondani deadline v. noop....de igazabol papir szerint a noop kellene, h jobb legyen, mert a zfs-nek aztan sajatja van.
Eros a gyanum, h valojaban tokmind1.

Az világos, hogy SSD-re kell kerüljön, a kérdés csak az, hogy hogy oldjam meg.
A szerverbe 12 SAS (hdd) és 2 SATA (SSD) megy bele natívan és ennyi is van tervezve bele, tehát nincs több hely.
PCIExpress kártyával lehet még megoldani a cache-t, de az nem biztos, hogy belefér a keretbe/megéri-e.
A jelenlegi demó szervernél soha nem ment 1 GB fölé a ZIL tehát teljes disk biztos nem kell neki, a l2arc méretben lehet jó lenne ha 100 GBnél több lenne, de mint sebesség szintén a tesztszerverből kiindulva, elég kellene legyen a SATA SSD.
Az elmúlt 3 hónapban a maximális terhelés 1200 IOps volt, ami bőven az SSD maximuma alatt van.

Találtam pár skriptet ami elég rendesen leterheli a rendszert:
https://github.com/zfsonlinux

A zfsstress pár perc alatt kibuktatja a ZFS. Ez magát a fájlrendszert stresszteszteli, úgy hogy dataseteket, fájlokat, linkeket, stb hoz létre töménytelen mennyiségben. Pár perc után egyszerűen eltűnik a pool és újra kell importálni. A system load ekkor 3 körül mozgott.

A filebench-el mind a 8 proci 100%on teker, a system load 60 köré is felmegy. Evvel már jól lehet követni, hogy viselkedik a rendszer terhelés alatt.
Sajnos a filebanch kihal a tesztprocessek elindítása után, de maga a terhelés nem áll le, csak ha kilövöm.

Kipróbáltam OpenIndiana-val is a teszteket. Itt már mindkét teszt tökéletesen működött de kb 5 perc zfssterss után itt is elszállt a pool (ubuntun kevesebb mint 1 percig bírta).
A filebench alatt kissebbnek tűnt a rendszer terhelése, mint linuxon, igaz a htop valamivel látványosabb és jobban követhető mint a top, és más monitorizáló tool-t nem ismerek solarishoz.

A top nem hogy nem Solaris eszköz, de nem is igazán ad valós képet rajta - ott a prstat szolgál erre a célra. (Nem nekromanciának szántam, talán még nem is minősül annak. :D)
------------------------
{0} ok boto
boto ?

sub

+1

sub