Sziasztok!
Freenas rendszerrel összeraktam egy storage szervert ami a a következőképpen néz ki:
HP DL380E G8
64GB DDR3 1333mhz memória
Xeon E5-2450L
LSI 9207-8i HBA
Qlogic QLE2562 FC
Merevlemezek:
3DB HGST 6TB 4Kn
2DB Seagate Enterprise capacity 6TB 512e
2DB Seagate EXOS 7E2 6TB 512e
A probléma a következő:
FC-n oda van adva egy ESxi host-nak egy zvol.
Ha szintetikus teszteket végzek rajta (RDM vagy VMFS-el) akkor teljesen rendben van a sebesség 820MB/s olvasás és írás (Q8 1MiB) Atto diskmark-al úgyszintén rendben vagyunk. [benchmarkok]
De ha elkezdek másolni rá fájlt egy ssd-ről akkor elindulunk szép nagy sebességgel majd lecsökkenünk folyamat 50-80MB/s közé de van, hogy ez alá is lemegy, szerintem többet kéne tudnia.
Nincsen SLOG/L2ARC beállítva most még csak szeretném ezek nélkül kipróbálni, hogy mit produkál.
Próbáltam már sync=disabled -el azzal nagyon halványan növekedett csak.
Valahogy ezt a sebességet kevésnek érzem ennyi merevlemeznél.
Köszönöm a segítséget
Hozzászólások
Az SSD fizikailag a gépben van amiről másolsz? A pool hogyan van szervezve amin a zvol van?
Próbáld ki a benchmark-ot nagyobb mérettel is, mondjuk 32GB-val, hogy akkor mit mond.
Igen az ssd az esxi hostban van benne és egy virtuális gépnek van odaadva ahogy a zvol is RDM-el.
32GB-al
BIOSban SATA mód legyen AHCI ha nem az és próbáld meg úgy is.
AHCI-n van
Én azt mondanám lehet már kéne neki az a read cache, l2arc buff hogy azt is hozza.Annak ha jól tudom az lenne a szerepe hogy a kilens általi limitációkon dobjon. Mondjuk zfs nagy fileokkal sokaknak van gondja Linuxon az is gond, ott nem teljesít alapból csücskösen sajnos.
Próbáld meg kikapcsolni a primary cache-t, zfs set primarycache=none volname.
Hát elég érdekes eredmények vannak.
Kinyomtam
Ezek a tesztek semennyire sem relevánsak a rendszer teljesítményét tekintve. Mind 1 GB-os teszt-mérettel készült, ami úgy a host, mint a NAS oldalán bőven memóriából megy, így nem mutat kb. semmit. Azaz de, látod, hogy a 8Gb-es FC csatolód tudja amit ígért a két host között...
Olyan teszteket futtass, ahol a teszt-méret a két gép közül a több memóriával rendelkezőnek a memóriaméret kétszeresen-négyszerese. Tehát ha az ESXi 64GB, a NAS 32 GB, akkor a 64GBx2x/x4, 128GB vagy 256GB legyen a teszt éret. Az mutatja meg a diszk-alrendszer valódi teljesítményét. Ráadásul ebből a random IO lesz az érdekes, ha VM-eket akarsz futtatni, függetlenül a virtuális diszk méretétől.
Írd meg, milyen szervezésben van ez a 7 db 6 TB-os diszk. Tippre RaidZ2, ami IOPS-ben egyetlen HDD teljesítményét hozza (ami nem-SSD diszk esetén, random műveleteknél 100-200 IOPS), és igazából alkalmatlan VM diszkek tárolására, VM-ek futtatására, hiába kötötted be gyors FC-n a host-ot. Ezt mutatja a 0.44 MB/s Q1T1 mérés, ami reális érték.
Amennyiben RAID10 jellegű (2-way mirror VDEV-ek egy pool-ban) 6 diszkből, akkor már háromszoros lesz az IOPS, amivel kb. 3 db VM-et futtathatsz olyan minőségben, mintha local HDD-ről futnának.
Az L2ARC vagy az SLOG bevezetése ezeken a terheléseken mit sem segít, azok nem ilyen feladatok "gyorsítására" alkalmasak.
Én úgy variálnám át, hogy a 6TB-os HDD-kből lévő RaidZ2 pool legyen a VM-ek adat diszkjeinek fenntartva (ha nem DB vagy hasonló a terhelés, hanem mondjuk sima file share), és csinálnék egy RAID1 vagy RAID10 pool-t 2 vagy 4 db (vagy több) SSD-ből VM boot/rendszer diszkeknek.
Raidz2-ben vannak és nem VM futtatásra használnám őket egyáltalán csakis adatok tárolására és az onnan való elérésére a vmeken keresztül
Nemí derült ki pontosan a használat, ezért irta GGALLO a válaszát, kitűnően összefoglalva a lényeget, már már olyan jól mintha én írtam volna :-)
Én inkább fio-t használok (van windowsra is) , nálam is 100 iops a random, (400 kB/sec) egy HDD lemez ZFS alatt:
#fio --name=teszt_1 --filename=./testfile1 --size=100M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1 |grep WRITE
WRITE: bw=432KiB/s (442kB/s), 432KiB/s-432KiB/s (442kB/s-442kB/s), io=100MiB (105MB), run=237268-237268msec
Nagy fájlok másolásakor ha elfogynak a pufferek, akkor kb. annyi a sebesség amit tapasztalsz.
https://blog.claryel.hu
Egy gyors mérés 6 db wd red , raidz2, nincs ssd - freeNAS,
windows alól gigabites háló:
SAMBA share:
PS R:\> fio --name=ssdtest --size=10G --bs=256k --iodepth=16 --rw=read
fio: this platform does not support process shared mutexes, forcing use of threads. Use the 'thread' option to get rid of this warning.
ssdtest: (g=0): rw=read, bs=(R) 256KiB-256KiB, (W) 256KiB-256KiB, (T) 256KiB-256KiB, ioengine=windowsaio, iodepth=16
fio-3.13
Starting 1 thread
ssdtest: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=0): [f(1)][100.0%][r=67.9MiB/s][r=271 IOPS][eta 00m:00s]
ssdtest: (groupid=0, jobs=1): err= 0: pid=9112: Tue Mar 9 11:29:30 2021
read: IOPS=269, BW=67.5MiB/s (70.8MB/s)(10.0GiB/151742msec)
slat (usec): min=15, max=34390, avg=39.68, stdev=229.86
clat (msec): min=5, max=338, avg=59.22, stdev= 6.92
lat (msec): min=5, max=338, avg=59.26, stdev= 6.93
clat percentiles (msec):
| 1.00th=[ 57], 5.00th=[ 58], 10.00th=[ 58], 20.00th=[ 58],
| 30.00th=[ 58], 40.00th=[ 58], 50.00th=[ 58], 60.00th=[ 58],
| 70.00th=[ 59], 80.00th=[ 60], 90.00th=[ 63], 95.00th=[ 67],
| 99.00th=[ 82], 99.50th=[ 84], 99.90th=[ 92], 99.95th=[ 124],
| 99.99th=[ 334]
bw ( KiB/s): min= 762, max=71394, per=79.71%, avg=55081.33, stdev=27987.55, samples=201
iops : min= 2, max= 278, avg=214.50, stdev=109.23, samples=201
lat (msec) : 10=0.01%, 20=0.01%, 50=0.09%, 100=99.81%, 250=0.05%
lat (msec) : 500=0.04%
cpu : usr=0.00%, sys=0.66%, ctx=0, majf=0, minf=0
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.1%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=40960,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=16
Run status group 0 (all jobs):
READ: bw=67.5MiB/s (70.8MB/s), 67.5MiB/s-67.5MiB/s (70.8MB/s-70.8MB/s), io=10.0GiB (10.7GB), run=151742-151742msec
https://blog.claryel.hu
Milyen adatok? Kis vagy nagy állományok, kevés vagy sok darab? Egy-egy állományt szekvenciálisan olvasol vagy állományon belül random műveletek vannak?
Milyen jellegű eléréssel? Egymás után az állományokatbatch feldolgozás jelleggel, vagy össze-vissza mint egy hálózati file share?
Mennyi VM-ről egyszerre? Egyetlen VM mögé van téve bulk tárolónak vagy a ZFS pool-on több dataset van, amin párhuzamosan dolgoznak VM-ek? Vagy valami cluster FS-en keresztül egyszerre haszhálja több VM?
Most újra elővettem a dolgot és nem tudom felfogni hogy miért lassú továbbra is az írás része, másolok rá fájlokat és így 10 MB/s és ott vége utána felmegy 60-70-re aztán megint leugrik, nem éppen reszponzív. Itt éppenségel egy smb megosztásról van szó.
A legérdekesebb, hogy csak akkor ilyen rossz az eredmény ha a VM-en keresztül másolok rá ha a truenas intézi az smb-t is akkor teljesen rendben van a sebesség.
Nagy fájlok (filmek,sorozatok,képek) ez lenne az egyik zvol feladata.
Egy db VM mögé menne ez az egy ZVOL ami csak ezt a részét tárolná, 1db esxi használja.
Természetesen lenne több zvol is más VM-nek, de először ezt kellene helyretenni.
Valakinek bármilyen ötlet?
Próbáld ki natív ZFS fájlként feltölteni a storage-ra, meg próbáld meg a zvol-ba is dd-vel beletolni (a storage-on is megpróbálhatod, meg az ESXi hoston is). Én azt várnám (az alapján, ami még úgy 2006 magasságából megmaradt a fejemben a ZFS-ről), hogy a ZFS fájlos verzió gyors lesz, az zvolos megoldás meg dd-vel sem lesz gyors. De persze lehet, hogy tényleg a VM miatt lassú csak.
Na de milyen eredmények születnek, ha fio-val vagy dd-vel írod a VM-ből ezt a NAS-on lévő zvol diszket? Ebből talán közelebb juthatnánk ahhoz, hogy a VM-ben futó Samba a gond, vagy a NAS-ról FC-n felcsatolt zvol diszk, vagy az ESXi-n keresztüli FC csatolt diszk elérés, vagy más.
Az a baj, hogy regeteg réteg kerül egymásra ebben a felállásban, mire az adat a kliensről a NAS-ra kerül. Nem olyan könnyű megmondani, melyik réteg lassítja így meg, és azt sem, hogy lehet-e azon segíteni, vagy együtt kell élni vele.
Valamerre el kell indulni, de ahhoz teszt eredmények kellenek.
Azon nem gondolkodtál esetleg, hogy a NAS-ról iSCSI-n a VM-be felcsatolsz egy diszket? Akkor kikerülnéd az ESXi virtuális diszk alrendszerét (igaz, az FC-t is). De egy tesztnek érdekes lehet, mit mutat. Vagy egy olyan teszt, hogy az FC vezélőt odaadod a VM-nek, hogy úgy mit változik a teljesítmény (csak egy próbára persze).
Esetleg az nem lehet, hogy az FC-vel van a baj ESXi vagy FreeNAS, vagy mindkét oldalon? Gondolom a NAS direkt SMB elérése sima Ethernet hálózaton történt (amikor is az elvárhatót hozta sebességben).
Kíváncsiságból beletettem egy SSD-t a szerverbe majd átadtam az esxinek ugyanúgy ahogy a merevlemezes pool-al tettem majd pedig a virtuális gépnek RDM diskként physical és virtual módba is.
Ez egy Intel 545s SSD ami 550/500MB/s-re képes. Ehhez képest nem annyira akarta hozni amit kellett volna és sokszor lement 0bájt/s-re is meg a sebességben nagyon ugrált 100-400MB/s között. KÉP
Érdekes.
A merevlemezes poolt még nem tudtam tesztelni majd azt is nemsokára le fogom tudni.
Tehát jól értem, hogy FC-n megkapja a NAS-ról az ESXi a diszket, és nem VMFS-t teszel rá, arra pedig VMDK-t a virtuális gépnek, hanem az ESXi-n RDM-mel átadod az FC-n kapott diszket a virtuális gépnek?
Ha jól értettem, akkor szerintem inkább próbáld úgy, hogy az FC-n, a NAS-ról kapott diszkre VMFS-t teszel, és azon hozol létre sima VMDK-t a virtuális gépnek. Az RDM-et sok mindenre lehet használni ugyan, de pont nem sima diszk elérésre van kitalálva, hanem speciális esetekre.
Szerintem ott veszik el az IOPS és az átviteli sebesség, hogy valamelyik réteg (vagy több is) szinkron műveleteket csinál, és azt a többeknek meg kell várniuk. Ha kiveszel ilyen rétegeket, akkor csökkented az egymásra épülő szinkron műleteket számít, és esetlen az ESXi-nek és/vagy a NAS-nak lesz esélye cache-t használni.
Igen így néz ki a dolog.
Megcsináltam vmfs/vmdk-val most sokkal egyenletesebb de a sebesség 230-340 ig ment de itt is lement 0-ra, a zvol-on a sync disabled-re van állítva a fő dataseten meg standard. KÉP
Egyébként a speciális eset mit takarhat? :)
Az esetleg okozhat ilyet, hogy a memóriák csak 800mhz-n mennek? Én úgy tudom, hogy a zfs-nek inkább memóriamennyiség mint sem sebesség kell.
+1 kérdés, hogy miért mennek csak 800mhz-n? forceolni se tudom őket, hogy 1333mhz-n menjenek pedig próbáltam mindent high-ra tenni a szerver beállításaiban de 0 siker. DDR3L modulok.
A memória sebesség szerintem ezen tesztek közben nem játszik szerepet. Még 800 MHz-en is elvileg 6.4 GB/s az elméleti RAM csúcssebesség, az FC 8 Gb/s meg elméletileg tud 1 GB/s átvilelt. Szóval nem igazán látom, hogy a RAM lehetne szűk keresztmetszet ebben az esetben bárhogyan.
Biztos, hogy egyformák (sebességre) a memória modulok? Nem nagyon jut eszembe semmi más ok, hogy ne a max. frekvencián működjön a memória egyébként.
Az RDM akkor jön jól általában (ez a "speciális eset" az én olvasatomban, alapból a VMFS javasolt ugye), ha egy "fizikai" diszkhez (ami lehet persze DAS/SAN LUN is) valami okból tényleges, kvázi közvetlen hozzáférés szükséges (spéci SCSI parancsok kiadásához, fizikai gépről virtuálisba migráláskor HDD másolással, ilyesmik).
Elvileg az RDM-nek jobb teljesítményt kellene nyújtania egyébként. Az persze nehéz kérdés, hogy ebben a konkrét felállásban hol van a szűk keresztmetszet, ami miatt ez nem így van.
Az biztos, hogy az ESXi NFS-en mindig szinkron írást végez, függetlenül az NFS szerver oldal beállításától. Számomra nem elképzelhetetlen, hogy az FC-n felcsatolt LUN-okkal is így van. Mert egyébként Te hiába tiltod le a szinkron írást ZFS oldalon, az csak annyit csinál, hogy ha a kliens nem jelöli meg az írás módját, akkor nem sziknron lesz. De ha a kliens megjelöli, hogy neki szinkron művelet kell, akkor mindenképp az lesz, hiába van a dataset-en/zvol-on letiltva.
Mondjuk egy jó SLOG device lehet segítene ezen a fajta terhelésen, ha valóban a feltételezésem szerinti szinkron írásokkal működik a rendszer. De nem 100%, ki kellene próbálni. A 8 Gbit-es FC-t alapul véve elég nenne 5-10 GB-nyi SLOG. Viszont szerintem az említett Intel 545-ös desktop SSD erre nem jó. Az szinkron írásban, pláne kis blokkméret esetén nem remekelhet annyira (mondjuk tesztre... HDD-n lévő ZIL-nél tuti gyorsabb).
Azt, hogy async vagy sync lesz-e ZFS szinten az írás azt a zpool iostat -l 2 paranccsal teszt közben is lehet ellenőrizni.
Egyébként általános tippként én azt mondanám, hogy a disk-től indulva kellene mérni, később hogy egyre több réteget használva, hátha kibukik, hogy hol van a szűk keresztmetszet.
Én többet sajnos így nem mondanék, mert egy ilyen hiba kivizsgálása nagyon sok időt, és utánaolvasást igényel, amit én nem szeretnék a kérdező helyett elvégezni. :)
Szia!
CPU elég gyengének tűnik (E5-2450L: 8x 1.80 GHz), kellene bele legalább ami 3.0 Ghz megy alapból.
Ezt miért gondolod/mondod?
Nem írta, hogy lenne bármilyen komolyabb igényű (nem LZ4 és nem ZStd) titkosítás, vagy egyéb olyan funkció használatban, ami CPU intenzív. Nekem is pont ilyen energiatakarékos CPU van az itthoni szerverben, és az 1 GbE hálózatot mindenféle módon ki tudom terhelni vele (úgy, hogy a TrueNAS egy VM-ben fut Proxmox-on, HBA átadással, nem is natívan a hardveren) különösebb CPU terhelés nélkül.
De ha valamiért itt mégis CPU limites lenne, akkor is hihetetlen, hogy a proci miatt 10-60 MB/s a max. sebessége. Még CPU limit esetén is jóval magasabban lennének a vágások.
Úgy tűnik meglett a megoldás
Az LSI HBA-t kicseréltem.egy újabb modellre ami lsi 3008-as vezérlővel van ellátva azóta rendben vannak a sebességek a komplett poolon meg mindenhol. 230-300 MB/s között van stabilan az írás. :)
Illetve a 64GB ramot amit valamiért a szerver 800Mhzn kezelt (1333Mhz LV modulok) azt kicseréltem 32GB-ra 1600Mhz-es modulokra. Azóta 1600Mhzn ketyeg
Ami érdekes, hogyha 1 ssd van benne és azon csinálok poolt odaadom az esxinek akkor az meg valamiért 300MB/s +- 40MB/s amennyivel tudok rá másolni VM ből ezt még nem teszteltem ki csak első látásra ez van vele.