ZFS paraméterek virtualizáció alá

 ( pista_ | 2017. december 2., szombat - 12:01 )

Hi!

4x4TB disk teljesen ZFS-nek lesz odaadva, Xen alatt virtuális gépek lesznek rajta. Teszteléshez jelenleg így készült a pool, de Ti milyen paramétereket használnátok?

zpool create -m none -o ashift=12 vol0 raidz2 disk1 disk2 disk3 disk4 -O atime=off -O compression=lz4 -O devices=off -O setuid=off -O exec=off

Előre is köszönöm!

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

Xen hanyas verzió-t használsz majd?
Támogatott a zfs ?

Ubuntu 17.10 és benne a Xen 4.9.

Mire gondolsz, hogy "támogatott" -e a ZFS?

Régebbi verzióknál nem bootol be zfs ről a xen.
Ha a domian0 -t is zfs.

Igen, átfutottam. Ami megmaradt ZFS-el kapcsolatban, hogy doom0-nak legalább 4GB-nak lenni kellene.

Ha nincs ZIL, akkor logbias=throughput. Egyebkent ha nincs zil,akkor halal lassu lesz, kapcsold ki a sync-et. Feltehetoleg akkor nem is olyan fontos az.
Elvileg a cache-t is jobb a vm-re bizni.
Elvileg a recordsize-t es erdemes hozzaigazitani csak ugy, mint a blocksize-t.
Elvileg a raidz2-nel a rad10 hatekonyabb lesz, mondjuk 4 HDD eseten tutira. Van egyaltalan ertelmes eset, amikor vki 4 HDD-re raidz2-t akar rakni?

Megjegyzem, ott fent pool-t csinaltal, nem volume-ot, igy is neveznem a helyedben.

Valamit nagyon elrontok, benézek, mert a sebességtesztek zvol-al borzalmasak.
Vegyük az "alapot", sda-ra 2TB ext4, a teszt ezt adja:


=====ext4 nativ==================================================================
#bonnie++ -u root -r 1024 -s 16384 -d /teszt/ -f -b -n 1 -c 4
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 4 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dell-4-doom0 16G 198457 13 100316 11 201004 12 575.0 5
Latency 231ms 2676ms 75501us 150ms
Version 1.97 ------Sequential Create------ --------Random Create--------
dell-4-doom0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
1 48 0 +++++ +++ 52 0 48 0 +++++ +++ 52 0
Latency 108ms 41us 75205us 66908us 18us 50548us
===================================================================================

Ezt követően a 4 diskből építek egy raidz2-t, azon egy 2TB zvol-t, amire ext4-et teszek (majd egy virtuális gép menne erre) és mountolás után borzalmas teszt eredményt produkál. :-((

#zpool status
pool: vol0
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
vol0 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
scsi-35000c50094710e87 ONLINE 0 0 0
scsi-35000c50094717fdf ONLINE 0 0 0
scsi-35000c5009471a887 ONLINE 0 0 0
scsi-350000397b80a0341 ONLINE 0 0 0

# zfs create -V 2T vol0/xen01

#bonnie++ -u root -r 1024 -s 16384 -d /mnt/ -f -b -n 1 -c 4
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 4 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dell-4-doom0 16G 52252 4 15099 3 526915 65 676.2 19
Latency 935ms 1670ms 105ms 713ms
Version 1.97 ------Sequential Create------ --------Random Create--------
dell-4-doom0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
1 42 0 +++++ +++ 47 0 46 0 +++++ +++ 47 0
Latency 805ms 47us 148ms 223ms 16us 151ms
====================================================================================

Amennyiben nem zvol-t csinálok, hanem sima zfs filerendszert és azt tesztelem, különösen, ha tömörítés is van rajta, akkor egészen szép eredményt hoz(na), de nekem virtuális gépekhez ez így nem lesz jó:


================
# zpool status
pool: vol0
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
vol0 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
scsi-35000c50094710e87 ONLINE 0 0 0
scsi-35000c50094717fdf ONLINE 0 0 0
scsi-35000c5009471a887 ONLINE 0 0 0
scsi-350000397b80a0341 ONLINE 0 0 0

# df -h
vol0/teszt 6,9T 128K 6,9T 1% /zfs

#bonnie++ -u root -r 1024 -s 16384 -d /zfs/ -f -b -n 1 -c 4
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 4 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dell-4-doom0 16G 718212 89 346988 64 1055258 74 713.8 19
Latency 4145us 166ms 61046us 202ms
Version 1.97 ------Sequential Create------ --------Random Create--------
dell-4-doom0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
1 119 1 +++++ +++ 113 1 126 1 +++++ +++ 137 1
Latency 67807us 16us 75833us 75417us 18us 79329us
=======================================================================================

Ötlet?

Előre is köszönöm!

Igaz mi csak Solarison de elfelejtettük nem kicsit a zvol használatát. Sokkal lassabb, fura errorokat generál, kint hiába tükrözöd , ha beadod virtuális gépnek onnantól redundancia is oda.Mi ha tehettük beadtuk a diszket direktbe a virtális gépnek és belül csináltunk zfs fájlrendszert de ugye itt az neked nem jó. Az hogy zpool-zvol majd arra ext4, lehet hogy csak a Solarisos multam miatt de nem erőltetném. Max még próbáld meg úgy hogy zpool-zvol-zfs és azt adod rootként oda ha lehet. Amugy meg blockméret, memória neki (arc cache), még több memória neki és minden más amit fent is említettek előttem.

ZFS+ZVOL+ZFS egész tűrhetően ment, már próbáltam, de még így is jócskán elmaradt a várt teljesítménytől. :-( (sajna az eredményt nem mentettem el)

Még a mai napot rászánom és tesztelem, de ha nem lesz értelmes megoldás, akkor megyünk vissza a kályhához: MD raid10 + LVM.

Nem tudom mennyire vagy eleresztve memóriával de lehet neki bőven tolni, bőven 4 fölé.
Esetleg ha a diszkek méretét tudod szabályozni és kisebb diszkekre széjjelszedni a 4x4 tb-ot, majd abból mindenkinek külön poolt csinálni azzal is nyerhetsz kraftot.50 MB -100 Mb is diszkeket használtunk zfsnél még egy 4tb-os poolnál is.Ha egy pool-od tud x-et és úgy kellene kiszolgálnia 10 gépet belőle, de ha szétszeded és 1 rootpool és másik 10 pool a virt gépeknek az nekünk gyorsabb volt.Egy 1 TB-os Oracle Db alatt asszem 4 vagy 5 poolra szedtük szét, oradata-nak 1 külön, archnak egy külön és stb. és sokkal jobbat produkált ügyfél mérése alapján.

Úgy tűnik marad az doom0-nak az MD10+LV.
Tesztnek készítettem ismét egy 2TB-os logikai kötetet és erre húztam ext4-et illetve zfs-t, ezek tesztjei alább. M

=========== Z F S ================
# bonnie++ -u root -r 1024 -s 16384 -d /zfs/ -f -b -n 1 -c 4
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 4 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dell-4-doom0 16G 540837 65 400703 73 1356339 86 967.4 24
Latency 651us 46277us 38911us 136ms
Version 1.97 ------Sequential Create------ --------Random Create--------
dell-4-doom0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
1 111 1 +++++ +++ 111 1 116 1 +++++ +++ 114 1
Latency 66681us 12us 88241us 74814us 18us 63945us
================================================================================

========= E X T 4 ============================
# bonnie++ -u root -r 1024 -s 16384 -d /mnt/ -f -b -n 1 -c 4
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 4 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dell-4-doom0 16G 382361 25 181780 14 354838 12 651.1 15
Latency 1727ms 2085ms 69963us 150ms
Version 1.97 ------Sequential Create------ --------Random Create--------
dell-4-doom0 -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
1 53 0 +++++ +++ 54 0 55 0 +++++ +++ 56 0
Latency 616ms 42us 83532us 100ms 17us 83503us

======================================================================================

Igen, tisztában vagyok vele, hogy a VM-ből picit megint csak más lesz, de alapnak nem tűnik rossznak egyenlőre.

Nade, ha "kívül" már van redundancia, akkor belül miért akarsz még egy redundancia-réteget?
A VM-be akár UFS is lehetne, az ott már... részletkérdés!

Mondjuk, én eleve az összvér megoldáson csodálkozom. Ha stabil és skálázható rendszert akar valaki, akkor a storage réteget és a vm-eket kiszolgáló host-ot/-okat különválasztja.

Storage mehet valamilyen rendes illumos-based OS-ről, és akkor lehet vele játszani, hogy a zvol-okat iSCSI-n, vagy valamilyen hba-n keresztül ajánlja ki, és ha a storage rosszul performál, akkor lehet annak a RAM-ját bővíteni.
A másik gép(ek)en meg futhatnak a vm-ek.

Kívül - doom0 - mondjuk a VM-ek backupjához jönne jól a ZFS, belül (dommU) pedig samba alá, szintén snapshot miatt (krypto vírusok), de ott már tényleg nem kellene raidz.

A szétválasztási észrevételedet értem és elfogadom, de jelenleg 1 szerver van, ezzel kell főzni.

Ha jól, értem, akkor a VM-ben lévő adatok mentése miatt akarsz "belül" is snapshotolni.

Hint1: külön virtuális diskre az OS és külön virtuális diskre az adat-diszk.
Így tudsz külön ütemezést a kettő snapshotjára.

Hint2: Írsz valami kis "api"-t, amivel a VM ki tud hívni dom0-hoz, hogy snapshotoljon.
Én pl. anno egy ssh kulcsot engedtem root-ra, és force command-dal mindig az ellenörző scriptet hívtam meg, amiben ellenőriztem, hogy mit szabad:
https://github.com/pasztor/svnscripts/tree/master/svnag
Kicsit más volt ott a cél, de a módszer itt is működhet.

Kicsit el is felejtkeztem arról, hogy linuxot használsz, ahol nem csak zfs van.
A domU-ban akár ext4-et is használhatsz.
Plusz, ha xen-el virtualizálsz, akkor a zvol-okat lehet menet közben átméretezni, menet közben újabb zvol-t csinálni, és mint új diszket hozzáadni a domU-hoz, stb.

Van valami oka, hogy ezt az adminisztrációt a domU-n belülre akarod tenni? Ennyire elválik a két réteg üzemeltetői csapata? A gép méretéből nem gondolnám, hogy akkora enterspájz környezet lenne, ahol minden apró lépés hosszas csapatok közti folyamatokkal lennének szabályozva.
Ebben az esetben viszont, az "lv"-adminisztrációt én a dom0 szintjére kiszervezném, és az lv-k helyett zvol-okat csinálnék a dom0 szintjén, és ahány lv lenne belül, az mind külön diszkként jelenik meg a domU-ban, arra meg mehet egy natív ext4, közvetlenül az xvdb, xvdc, ... lemezekre.

Hu mennyit szivtam vele mire egy uj szervert szolgáltatást, (nginx proxy-t) be vittem alá.
Jó lett volna egy leírás.

Kiemelnék pár jelentős zfs szolgáltatást, amiért többek közt érdemes használni virtualizációra:
1. cache
2. egyszerű backup
3. tömörítés

Ha te ezeket nem akarod használni, akkor visszatérhetsz a régi módszerhez, de ha ezeknek hasznát vennéd, akkor érdemes még próbálkozni.

Alapból érdemes raid10-be konfigurálni, ha 2 HDD-t szánsz redundanciára. Csak akkor van előnye a raidz2-nek, ha egyszerre két HDD esik ki, ráadásul ugyanabban a mirror párban, aminek elég kicsi az esélye. Nagyon ajánlott még SSD cache-t betenni.

Ha nem megy a zvol, próbálj meg image fájlokat odaadni a xen-nek.
Annak én nem látom értelmét, hogy zfs+valami+zfs, mivel a zfs egy memóriaigényes fájlrendszer, ezért elég sok erőforrást elhasznál, ha mindenfele azt telepíted. Alapbeállításban a memória felét használja el, evvel számolj a memóriavásárlásnál.

Ha visszatérnél a régi módszerhez, ott én megfontolnám az md raid helyett, az lvm raid-et használni az lvm thin provision és lvm cache társaságában (nem használtam, de szinte biztos jobb teljesítményt lehet vele kihozni és a backup/snapshot is jobban megoldható vele).

lvm & snapshot? Meg jobban megoldható? Ez mióta? Utoljára még egy vicc volt az lvm féle snapshot a zfs-hez képest.
Már nem kell neki méretet mondani? Vagy már nem lesz invalid, ha több változik, mint a snapshot mérete?
Vagy már nem csinál olyat, hogy ha van egy vol-ről 25 snapshotod, akkor minden egyes írási művelet, kezdődik egy olvasással, majd 26 másik írással?
Vagy mégis milyen téren lesz "jobb teljesítménye" egy lvm-nek?

Bocs ha félreérthető volt ami írtam. Én nem az lvm-et hasonlítottam az zfs-hez, hanem az mdraid+lvm-re adtam egy talán jobb alternatívát.
A zfs minden szinten nagyságrendekkel felülteljesít az mdraid, lvm, lvmsnapshot, lvmraid megoldásaihoz képest.

A backupot nagyon szerettem volna, a tömörítést is sajnálom picit, de így a VM-ben lesz intézve (samba adatok).

A raidz2 esetén értettem, hogy sok tárterületet vesztek - bevállaltam volna a biztonság érdekében - és jól jött volna egy SSD, amire a cache-t rakhattam volna, de sajna nincs.

A zfs+zfs úgy jött volna ki, hogy zvol-okra ment volna a VM, így abackup és a tömörítést is jól jött volna, majd a VM-ben azért lett volna zfs, hogy a samba-n tárolt fileokról lehessen snapshotot készíteni a ma oly népszerű krypto vírusok ellen.

Átgondolva az egészet a következőre jutottam: a zfs erőforrásigényesebb mint az MD+LVM (a zfs+zfs felállásról nem is beszélve). A zfs tömörítése a VM-ek oprendszerén segíthetett volna, ami darabonként 10GB-on elfér - ergo sok jelentőségét nem látom -, a VM adatok egyébként is külön logikai kötetre kerülnek, azon viszont már lehet zfs a tömörítési és snapshotolós előnyeivel.

RaidZ2 csak 4 lemezzel nem túl hatékony, se területre, se sebességre. Két pár tükörrel érdemes lenne megpróbálni, az hasolnó szintű redundancia, de sokkal gyorsabb, flexibilesebb. Ha a zvol volblocksize a default 8KB, akkor az ext4 is ilyen blokkmérettel érdemes.

Csak ameddig a raidz2-nek mindegy melyik 2 lemez esik ki, a raid10-nek nem.
A mai procik simd utasításkészleteivel meg eléggé cpu-optimalizált kódok fogják azt a részt kezelni.

Én valahogy nem aggódnék a raid10 vs. raidz2 közti sebességen.
A megmozgatandó adatmennyiség ugyanannyi, (ha nem kevesebb raidz2 esetén), max a cpu-nak kell pár ciklussal többet malmoznia. Arra meg lásd amit írtam.

Az atime, meg többi szerintem fölösleges.
Úgyis zvol-okat fogsz kreálni, és direktben a vol-t adod a virtuális gép diszkjének.
Inkább egy gyors nvme-s ssd-t tegyél be l2arc-nak, meg egy másikat log device-nak.
Minden más már max csak csokireszelék a tortán lévő habon.

Igen, ezek jól hangzanak, de sajna abból kell főzni ami van.

Legközelebb megpróbálok ilyen felépítésű masinát átverni a vezetésen... ;-)

Köszi a javaslatokat, mindenképp hasznos volt!

ezt az nvme/l2arc légyszi részletezd egy kicsit
--
Gábriel Ákos