ZFS speed test

Fórumok

Sziasztok!

Tesztelnék egy ój szervert, amelyben 8 db 1.92 TB-os NVMe Datacenter SSD van.
Az alábbi tesztkörnyezetet állítottam össze.

A szerveren Proxmox lesz, VM-ekben pedig 6 db Windows Server (RDP, vállalatirányítás, Firebird szerver, számlázás, könyvelés, bérszámfejtés, ÁNYK, irodai munka fog folyni) és 4 db Samba fájlszerver lesz. Kb. 30 user egyidőben.

Ajánljatok a tesztelésre alkalmas scripteket (bonnie++, fio, iostat, ... megfelelő paraméterekkel), amivel könnyedén el tudom dönteni, milyen kombinációban a leggyorsabb olvasás, írás és egyidejű írás/olvasás közben a rendszer.

Ezzel a scripttel próbálkoztam, de elqrhattam valamit, mert nem látok az eredményekben lényegi különbséget...

Érdekelne egy olyan awk/sed oneliner is, ami a keletkezett eredményfájlokból kigyűjti a lényeget...

3.84 TB használható tárhely bőven elegendő. Elsődleges szempont a lehető legnagyobb IOPS/RW sebesség.

Hozzászólások

Szerkesztve: 2024. 06. 14., p – 17:35

Azt ertem, hogy a RW sebesseg a fo szempont, de amikor ilyeneket latok, hogy 8 diszk egy stripe-ban, akkor azert felmerulnek bennem bizonyos kerdesek. :)

szerk: ja, latom update-elodik kozben

Szerkesztve: 2024. 06. 14., p – 19:06

Szerintem elsőre a redundancia szintet kellene eldöntened, aztán ahhoz választani tesztet.

Ha pl. 4x2 mirror, akkor objektíven 1 diszk potenciális meghibásodással számolhatsz, ergo kell egy hot spare, hogy ne álljon meg a pool adott esetben. Máris csak 7 diszked van. Ugyan ez igaz bármilyen kombinációban RAID5 (RaidZ1) vdev-ek esetén.

Ezen felül ilyen felállás esetén nem lesz egyszerű megmérni a tényleges különbséget szerintem, mert a diszkek önmagukban is nagyon nagy teljesítményt tudnak. Nagyon nagy teszt fájlon, nagyon hosszan futtatnék fio teszteket párhuzamosan (hogy az ARC bemelegedjen, valamint ki legyen zárva az ARC-ból futó teszt egyaránt), a VM-ek számának megfelelő darabszámban legalább. Ráadásul egy fio teszt sem lesz igazán olyan, mint egy futó OS.

Nem biztos, hogy lesz "kész" megoldás, mert Te tudod, pontosan (kb...) milyen IO terhelést fognak kapnak az egyes VM-ek, így a párhuzamos fio-kat ennek megfelelően kellene paraméterezni.

2x4 diszk RaidZ2 jó teljesítmény és biztonság szempontjából, 1x8 RaidZ2 sem hiszem, hogy sokkal rosszabb lenne NVMe meghajtókkal erre a felhasználásra, és sokkal kevésbé diszk-pocsékoló. Szerintem ne az abszolut maximális teljesítmény pontot keresd, hanem azt a legnagyobb kapacitást, ahol a teljesítmény még eléri a várt értéket.

Ezen felül ZFS esetén nagyon durván befolyásolja az eredményeket a RAM mérete (amit az ARC-nak adsz). Így lehet érdemes ott megtolni a gépet (ha még nincs).

Nem utolsó sorban nem lesz mindegy, hogy milyen volblocksize értékkel jön létre a VM diszk.Maga az NTFS és az ext4 4k-val, SQL-ek jellemzően 16-32-64k blokkmérettel a legoptimálisabbak. Lehet érdemes lenne több különböző beállítású storage Proxmox alatt a különböző célú diszkek optimális elhelyezésére.

Plusz, az sem mindegy, hogy a 30 user milyen terhelést produkál. Ha mind csak pögyög az ERP-ben, meg órákig dolgozik egy-egy xlsx-en, akkor az nem lesz nagy kihívás egyik konfignak sem. Míg, ha videót vágnak ketten hálózati megosztáson tásolva, akkor már érdekesebb lesz a dolog.

Olyan is elképzelhető, hogy két pool-t csinálsz, az egyiken fut a terminál szerver, a másikon minden más. Így nem egyetlen pool-t terhel az összes user tevékenysége és a kiszolgálók tevékenysége egyszerre.

Szerkesztve: 2024. 06. 14., p – 19:29

az elso amit benezel:
ne a hoston tesztelj ha VM-ek lesznek rajta, hanem VM-ben. az lesz szamodra relevans.
ha ugyanazokat az eredmenyeket kapod, akkor pedig tobbszalusitsd a fio teszted. nvme egyik nagy elonye a queue depth.

Szerintem elsőre a redundancia szintet kellene eldöntened, aztán ahhoz választani tesztet.

Elegendő, ha csak 1 lemez kiesését bírja ki a rendszer. HA nincs, de 3-4 backup van mindenről és van még néhány szerver, ahová végszükség esetén át tudok relatíve gyorsan költözni.

Nagyon nagy teszt fájlon, nagyon hosszan futtatnék fio teszteket párhuzamosan (hogy az ARC bemelegedjen, valamint ki legyen zárva az ARC-ból futó teszt egyaránt), a VM-ek számának megfelelő darabszámban legalább

Erre a végén visszatárek.

2x4 diszk RaidZ2 jó teljesítmény és biztonság szempontjából, 1x8 RaidZ2 sem hiszem, hogy sokkal rosszabb lenne NVMe meghajtókkal erre a felhasználásra, és sokkal kevésbé diszk-pocsékoló. Szerintem ne az abszolut maximális teljesítmény pontot keresd, hanem azt a legnagyobb kapacitást, ahol a teljesítmény még eléri a várt értéket.

Kereshetem a legnagyobb teljesítményt, mivel 2 TB-nál több tárterületre nincs szükségem.

Ezen felül ZFS esetén nagyon durván befolyásolja az eredményeket a RAM mérete (amit az ARC-nak adsz). Így lehet érdemes ott megtolni a gépet (ha még nincs).

A gépben 256 GB RAM van. A VM-ek ha kell, 100 GB-al beérik, de az már határeset. Az ARC annyi RAM-ot kaphat, amennyit akar.

Plusz, az sem mindegy, hogy a 30 user milyen terhelést produkál. Ha mind csak pögyög az ERP-ben, meg órákig dolgozik egy-egy xlsx-en, akkor az nem lesz nagy kihívás egyik konfignak sem. Míg, ha videót vágnak ketten hálózati megosztáson tásolva, akkor már érdekesebb lesz a dolog.

A Firebird szerverek 1-1 Windows Server alatt futnak, NTFS-en. Tehát csak NTFS és exr4 van a VM-eken.

Plusz, az sem mindegy, hogy a 30 user milyen terhelést produkál. Ha mind csak pögyög az ERP-ben, meg órákig dolgozik egy-egy xlsx-en, akkor az nem lesz nagy kihívás egyik konfignak sem. Míg, ha videót vágnak ketten hálózati megosztáson tásolva, akkor már érdekesebb lesz a dolog.

17-en könyvelnek, mint állat (néhányan napi 16 órában!).
1 html gurunak hiszi magát, ő csinál néha érdekes dolgokat.
A többi csak átlagos irodai munkát végez...

Olyan is elképzelhető, hogy két pool-t csinálsz, az egyiken fut a terminál szerver, a másikon minden más. Így nem egyetlen pool-t terhel az összes user tevékenysége és a kiszolgálók tevékenysége egyszerre.

Ez megfontolandó! Ekkor viszont a storage (vagy a root) poolnak a kevés lehetséges lemezszám miatt kisebb lesz a teljesítménye. Pl. az rpool 2x3 lemezes RaidZ1, a storage csak egy 2 lemezes mirror lehet. Bár ez a terminál szervereknek elegendő lehet. Ezen még agyalok és méricskélek...

Le tudnád írni az általad javasolt fio parancsot a teszteléshez?
Időm van tesztelni és szeretném is kimaxolni a témát, úgyhogy nem gond, ha a fio-t sokáig kell futtatni.

Köszi az építő szándékú hozzászólást!

Elegendő, ha csak 1 lemez kiesését bírja ki a rendszer. HA nincs, de 3-4 backup van mindenről és van még néhány szerver, ahová végszükség esetén át tudok relatíve gyorsan költözni.

Fura felhasználóid vannak, ha a teljesítmény különbséget észreveszik (pláne könyvelés munka alatt ami nagyon alacsony IO igényű monoton adatbevitel...), de azt nem bánják, ha egy 16 órás műszaknyi adatot újra fel kell vinniük, mert backup-ból visszaállsz diszk hiba miatt. Komolyra fordítva, semmiképp se 1 lemez hibatűrésed legyen production szerveren. Pláne, ha olyan is történik rajta, mint pl. számlázás, ami megy a NAV-ba élőben, ugyanis az pláne extra szívás újra csinálni.

Kereshetem a legnagyobb teljesítményt, mivel 2 TB-nál több tárterületre nincs szükségem.

Most nem kell 2 TB-nál több, vagy 5 év múlva nem kell majd 2 TB-nál több? Ugyanis - gondolom - ez egy új szerver, 5 év garival, diszkek 5 év garival, így nyilván minimum ennyire tervezik a használatát. Innetől nem a mostra kell a kapacitást tervezni, hanem a várható bővüléssel legalább 2-3 évre (ha nem is 5-re). Nehéz eladni 1 év múlva, hogy újabb 1-2 millió kell SSD-re, mert elinfláltad a kezdeti befektetést IOPS-re (amit valójában senki sem érez ilyen meló mellett...).

A Firebird szerverek 1-1 Windows Server alatt futnak, NTFS-en. Tehát csak NTFS és exr4 van a VM-eken.

Ha egy VM-nek egy fő feladata van, ahhoz válaszd a blokkméretet, ne az FS-hez. A Firebird 1, 2, 4, 8, 16 kB-os lapméretet enged (az újabbak talán 32k-t is), szerintem azt nézd meg, milyenek a meglévő DB-k és ahhoz válassz volblocksize értéket ezen VM-ekhez (legalábbis a Firebird DB-t tartalmazó vdiszk-hez).

17-en könyvelnek, mint állat (néhányan napi 16 órában!).
1 html gurunak hiszi magát, ő csinál néha érdekes dolgokat.
A többi csak átlagos irodai munkát végez...

Ez nagyjából zéró terhelés lesz a valóságban úgy a CPU-n mint a diszk IO-n. A legnagyobb IO terhelést a sok futó Windows szerver háttérfolyamatai fogják csinálni meg a terminál szerver user kiszolgálása... Kis túlzással mindezt rátennéd egy 8 HDD-ből álló RAID 10 kötetre, és a felhasználók nem éreznék a különbséget könyvelés és klasszik irodai munka során az NVMe-s optimalizált csillagrombolóhoz képest...

Érdemes lenne a szükséges Windows licencek számát is megvizsgálni. Lehet-e funkciókat összevonni egy Windows szerverre. Felesleges erőforrás pocsékolás 0% VM-en belüli user/hasznos terheléssel ennyi fizetős VM-et futtatni. Ráadásul a VM-ben futó Windows-ra is a host-ban lévő magszámra kell licenc, tehát egy 2x14 magos CPU-s host esetén minden egyes VM-ben futó Windows szervernek 28 magos licenc kell majd attól függetlenül, mennyi vCPU-t kap a VM. Ez nem kevés pénz. Meg mindre ugye végpontvédelem szerver verzióban, stb...

Le tudnád írni az általad javasolt fio parancsot a teszteléshez?

Sajna nem. Meg szerintem ilyen leírható nem is létezik. A fio (és a többi hasonló disk beckmark) nagyon jó az alapszámok megismerésére, az orbitális hibák kiszűrésére, de pontos, működés közben válható eredményt csak annyi beletett munkaval ad (vagy úgy sem), mint amennyi munka az igazi rendszer feltelepíteni és kipróbálni.

Csak tanácsot tudok hozzá adni: ne kérj tőle kötelező szinkron írást, mert a Proxmox/ZFS sem fog ilyent kérni alap beállítás mellett (nem is kell, UPS-sel ellátott szerver mellett a ZFS is bőven biztosítva van véletlen megállás esetére), és jelentősen rosszabb számokat fogsz látni, ami a valós működéssel nem lesz partiban. IOdepth ne 1 legyen, mert nem életszerű, ráadásul az NVMe pont abban erős, hogy jól kezeli a párhuzamos terhelést. A VM-ekben ZFS mellett simán bekapcslhatod a "writeback" diszk cache beállítást, az sokkal jobb írási eredményt fog adni pláne Windows alatt.

mint pl. számlázás, ami megy a NAV-ba élőben, ugyanis az pláne extra szívás újra csinálni.

A számlázó adatbázisa on-the-fly szinkronizálva van máshová is georedundánsan.

Most nem kell 2 TB-nál több, vagy 5 év múlva nem kell majd 2 TB-nál több? Ugyanis - gondolom - ez egy új szerver, 5 év garival, diszkek 5 év garival, így nyilván minimum ennyire tervezik a használatát. Innetől nem a mostra kell a kapacitást tervezni, hanem a várható bővüléssel legalább 2-3 évre (ha nem is 5-re). Nehéz eladni 1 év múlva, hogy újabb 1-2 millió kell SSD-re, mert elinfláltad a kezdeti befektetést IOPS-re (amit valójában senki sem érez ilyen meló mellett...).

Bérlem a szervert. Ha kérem, néhány órán belül kicserélik a diskeket 3.84, vagy 7.68 TB-osokra, ha hirtelen megugrana a tárhelyigény.

Ha egy VM-nek egy fő feladata van, ahhoz válaszd a blokkméretet, ne az FS-hez. A Firebird 1, 2, 4, 8, 16 kB-os lapméretet enged (az újabbak talán 32k-t is), szerintem azt nézd meg, milyenek a meglévő DB-k és ahhoz válassz volblocksize értéket ezen VM-ekhez (legalábbis a Firebird DB-t tartalmazó vdiszk-hez).

A Firebird-öt és a hozzá tartozó adatbázist a vállalatirányításért felelős cég üzemelteti, én csak az alatta lévő Windowsért felelek. Nem tudom, milyen beállításokkal fut a FB szerver.

[...] NVMe-s optimalizált csillagromboló [...]

Törekszem a maximumra. :)

Érdemes lenne a szükséges Windows licencek számát is megvizsgálni.[...]

A licencek rendben vannak, minden cég megvette a maga Windowsához szükségeseket. Összevonni nem lehet a windowsokat.

writeback

Be van kapcsolva minden VM-ben.

Köszi!

Szerkesztve: 2024. 06. 14., p – 22:05

256 GB ram a gépben, a 2-4 Gb-os tesztfájlokkal szerintem  ram-ot tesztelted,  egy 16 GB -oo gép és HDD-k:
 

 NAME                                            STATE     READ WRITE CKSUM
        S6                                              ONLINE       0     0     0
          raidz2-0                                      ONLINE       0     0     0
            gptid/80c09a84-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0
            gptid/80d86d0b-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0
            gptid/8151dc44-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0
            gptid/818f98b7-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0
            gptid/81e1fab6-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0
            gptid/81f0a588-51c9-11ea-8987-04d9f5ada4c8  ONLINE       0     0     0


 fio --filename=test.file --name=async_cached_seqwrite --rw=write --bs=4M   --iodepth=32 --size=2G |grep write
async_cached_seqwrite: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=32
async_cached_seqwrite: (groupid=0, jobs=1): err= 0: pid=68316: Fri Jun 14 21:45:27 2024
 
 write: IOPS=825, BW=3303MiB/s (3464MB/s)(2048MiB/620msec); 0 zone resets



fio --filename=test.file --name=async_cached_seqwrite --rw=write --bs=4M   --iodepth=32 --size=20G |grep write
async_cached_seqwrite: (g=0): rw=write, bs=(R) 4096KiB-4096KiB, (W) 4096KiB-4096KiB, (T) 4096KiB-4096KiB, ioengine=psync, iodepth=32
async_cached_seqwrite: (groupid=0, jobs=1): err= 0: pid=68328: Fri Jun 14 21:46:36 2024
  
 write: IOPS=104, BW=418MiB/s (438MB/s)(20.0GiB/49006msec); 0 zone resets