iSCSI Dell ME5 – Proxmox környezetben I/O wait

Szerverek

Sziasztok,

Dell ME5 storage + Proxmox VE környezetben futó iSCSI alapú storage rendszerünknél komoly I/O wait és teljesítmény-anomáliák jelentkeznek (időszakos extrém IO-wait, VM-ek megfagynak, ME5 GUI lefagy, olvasási teljesítmény szélsőségesen változó).

Firmware frissek, multipath konfig Dell ajánlás szerint, RAID10 + SSD read-cache kipróbálva, PBS mentés optimalizálva, PVE friss telepítéssel is tesztelve. A jelenség változó, de vissza-térően tapasztalható, és szeretnénk helyben szakértővel kielemezni.

Keresek olyan szakembert, aki jártas:

  • Dell ME5 / ME-sorozatú storage-ban
  • iSCSI konfigurációban (ALUA, multipath, tuning)
  • Proxmox VE storage integrációban
  • teljesítményproblémák diagnosztikájában (I/O, latency, fio, multipath-d)

Helyszín: Székesfehérvár

Olyan valakit keresek, aki személyesen, helyben is tud foglalkozni vele (nem csak távoli) és lehetőleg számlaképes.

Köszönöm!

  • 1400 megtekintés

( szekelyk | 2025. 11. 06., cs – 17:17 )

A diszk konfigurációt leírod? Csak arra gondoltam ha HDD-k vannak RAID10-ben és előtte read-cache SSD, akkor letörhet a teljesítmény ami nincs cacheben és HDD-ről kell olvasni. A szélsőségesen változó olvasási teljesítmény is erre utal, amikor nem cacheből jön az adat.

( szekelyk | 2025. 11. 06., cs – 17:23 )

Switchen és direkt kapcsolaton is ugyanaz a helyzet?

( n.balazs v | 2025. 11. 06., cs – 22:32 )

Ha írnál kicsit bővebben az architektúráról, akkor szerintem itt mi is segítenénk.

Pár apró kérdés részemről:

  • Pontosan mi a ME5 storage konfigurációja? Modell, lemezek mérete és száma, SSD mérete stb.
  • Van-e storage replikáció?
  • Hogy áll a tiering? Mit mutat az ottani statisztika?
  • Az SSD az RI vagy Mixed Use?
  • Hogy néz ki a storage és host közötti hálózat?
  • Mit lehet tudni a hostról? Hány VM fut rajta? Mekkora az overcommit rate?
  • Használtok-e thin LUN-okat?
  • Csak egy pár adott VM-nél jelentkezik a hiba vagy bármelyiknél?
  • Mit mutat a storage statisztika az írott / olvasott adatok arányára nézve?

( orkenyi | 2025. 11. 07., p – 22:47 )

Sziasztok

Köszönöm a választ megpróbálom összefoglalni jobban, de már őszintén nem hiszem hogy én meg tudom oldani....

A storage egy Dell ME5012, 10×4 TB SAS HDD RAID10-ben (512 k chunk), és van mellette egy 1,9 TB SSD read cache (RI típus). Cache policy: write-back + adaptive read-ahead. Nincs tiering vagy replikáció, csak egy pool és volume. A firmware a legfrissebb.
iSCSI-n keresztül csatlakozik, 2×25 Gbit/s round-robin ALUA multipath (Dell multipath.conf ajánlás alapján), jumbo frame aktív.

Direkt Dell dac kábelkapcsolattal (switch nélkül)

Host oldalon Proxmox VE 9 (kernel 6.14), LUN thin, kb. 15 VM fut rajta, 60–70 % overcommit mellett. A gond leginkább Proxmox Backup mentés közben jön elő, amikor az I/O wait kilő és a VM-ek megállnak. Írás 600–1000 MB/s, de olvasás néha beesik 200 MB/s alá (fio-val 13–15 MB/s is előfordult). SSD cache-szel a GUI lefagy, nélküle stabilabb, de időnként továbbra is vannak I/O delay.

A multipath konfigot másold be ide kérlek, megy egy multipath -r kimentet is!

A round-robin hol van konfigurálva?

Ezt találtam ME5 ajánlásnak.

device {
  vendor "DellEMC"
  product "ME5"
  path_grouping_policy group_by_prio
  path_checker "tur"
  hardware_handler "1 alua"
  prio "alua"
  failback immediate
  rr_weight "uniform"
  path_selector "service-time 0"
  }

Nekem a 10x4TB NL-SAS meghajtó karcsúnak tűnik IO szempontból. Mondjuk a legjobb választás még a RAID10 volt, de a sizer így is csak alig több mint 1000 iops értéket ad erre a konfigurációra akárhogy csavargatom. Az 512k chunk méreten kívül próbáltatok mást? Igaz RAID10 esetén ez az ajánlás.

A megadott írás és olvasás értékek szerintem azzal magyarázhatók, hogy az írás elnyeli a write-back cache, az olvasás esetén pedig nem cacheből jön az adat hanem a diszkekről. Szerintem backup esetén nincs jelentősége a read-cache-nek pláne a read-aheadnek.
 

Így látatlanban szerintem ez a rendszer alulméretezett. 10db HDD eleve nem sok, a 4T lemez gyaníthatóan ráadásul nem is 10k, hanem 7.2k. Ez IOPS-ban elég karcsú. VM-ek alá 7.2k lemezt tenni borítékolja a hasonló problémákat, ~15VM már elég jól tudja ráncigálni ide-oda, ahogy élik egyéni életüket, túlzott terhelésre sincs feltétlenül szükség (gondolj bele, 1 VM alá nem jut egy teljes lemez sem, az SSD ezen nyilván tud javítani, de az sem csoda).

Mindezt az is erősíti, hogy ezen leírásod alapján elsősorban mentéskor fordul elő a probléma.

Mennyi adatot ment a mentés? Ha 1,9T-nál többet, akkor könnyen kipucolódhat ez az ssd cache, a 7,2k lemez kínosan lassú lehet.

Az IOps értékeket is meg kellene nézni.

A VM-ek mit csinálnának, mikor belassúlnak? Írnának vagy olvasának? Milyen jellegű VM-ek?

Nem ismerem a tárolót, de egy ilyen cache akkor sem képes csodára. A https://www.dell.com/support/manuals/en-us/powervault-me5012/me5_series_ag/about-ssd-read-cache?guid=guid-0d8db30b-27a2-41c9-bfc5-a437c0699c64 alapján számol valami statisztikát ("as a read cache for "hot" pages only"), azaz egy mentés hatására valószínűleg nem potyog ki minden a cache-ből, de tudni kellene, hogy milyen alkalmazások vannak és mi indokolta a 4T lemez méretet (miként történt a méretezés, mi tette lehetővé a spórolást több 10k lemezhez képest).

A másik gond az, hogy az SSD cache miatt kb mérhetetlen a rendszer: nehezen fogod tudni, hogy amit mérsz, az most honnan jön és micsoda. Talán hétvégén (ha akkor nyugi van) lehetne célzott terhelésekkel lőni, majd mentést futtatni, megint terhelés stb, simán rámegy rengeteg idő, lehet, hogy valamennyit lehet ezen tuningolni, de 90% fölötti esélyt mondok arra, hogy a végső konklúzió alulméretezés lesz. Ha lesz egyáltalán explicit konklúzió.

Én cache helyett lehet, hogy megpróbálnám inkább az automatikus rétegzést, például OS lemezeket és a kritikusabb adatokat gyorsabb réteghez kötve (tiering/affinity: https://www.dell.com/support/manuals/en-us/powervault-me5012/me5_series_ag/volume-tier-affinity?guid=guid-81370bfc-2eb8-4349-8391-3465e4e4f0d8&lang=en-us), de ehhez ismét tudni kellene, hogy milyen adatból mennyi van a látatlanban ~15T (+/- 2-3T) adatból.

Qcow2-val a proxmox backup használja a dirty-bitmap-et, igy csak az előző backup óta keletkezett változásokat menti át , ha naponta keletkezik új 1,9tbájtnyi adat, akkor az durva ja, vagy LVM (gondolom azt használnak iSCSI-val) esetén nincs ilyen (vagy minden nap leállításra kerülnek a gépek, de azt kétlem?!), aztán mindig mindent be kell olvasni. De akkor meg lehet az egész mentési stratégiát át kellene alakítani, és pl. storage-en menteni közvetlenül, vagy nem LVM-et használni ha az van.

Windows szerver tud olyant csinálni különösebb erőlködés nélkül, hogy a dirty bitmap naponta 80%-nyi változást mutat, mert valami háttérfolyamat hozzányúlkál minden blokkhoz. Ha meg be van kapcsolva a discard, és fut is a Windows-on a diszk optimalizálás (default hetente 1x minden diszkre aktív), akkor 100%-ot fog mutatni a változott blokkok száma, az a VM összes diszkjét teljes terjedelemben át fogja küldeni a PBS-nek.

Mi ki szoktuk kapcsolni az automata trim-et Windows-on (pláne, hogy ha van néhány TB virtuális diszk alatta, akkor az összes memóriát is megeszi ezalatt), és megnézünk minden folyamatot, ami non-stop lemezezik, hogy az tényleg kell-e.

Ez alapján azt mondom, hogy az infra el lett tervezve (=elcseszve). Nem a 2x25 GbE lesz a hiba forrása. 

Ahogy Krisztián is írta: Ez így nagyon kevés IOPS-t tud. 5*180 = 960. Ezt akár 1-2 VM is le tudja ültetni, ha nincs Proxmox oldalon szabályozva az IO per VM alapon.
Az az RI típusú SSD sok mindenre jó. Viszont cache-nek nagyon nem. Én ezért áttenném tierbe. Cache-nek csak MU vagy WI-t érdemes tenni. Lásd, egy jó kis összefoglaló a témában: https://www.serverstor.com/read-intensive-vs-write-intensive-vs-mixed-use-ssds-whats-the-difference/

Az 512k-n kívül én kipróbálnám a 4k-s chunk méretet is. Meg kell nézni, hogy a diskek milyenek hardveresen. Az alá nem érdemes menni - persze végezz mérést is erre vonatkozóan.

A talán legsúlyosabb hiba szerintem: az adatok ugyanazon a RAID tömbön / poolban vannak, mint ahová a mentés is történik.
Disk --> Storage controller --> iSCSI --> Host --> PBS VM --> Host - iSCSI --> Storage controller --> Disk
Én mindenképp különszedném a mentésre használt tömböt. Nem tudom, te látod, hogy mekkora terület kell a mentéshez. 6x lenne a normál adatoknak, 4x a mentéshez. Mindkettő RAID10-ben. Így a mentés nem fogja meg az adat tömböt. Az SSD-t az adat tömbhöz kösd be tieringbe, ne a mentéshez.

Összefoglalva amiket én tennék:

  • Limitálnám a VM-ek IOPS-t.
  • Áttenném az SSD-t tieringbe.
  • Szétszedném a RAID tömböt 2-re: adatok, mentés.
  • Megvizsgálnám a működést 4k-s chunk mérettel is. Különösen a PBS esetén.

A talán legsúlyosabb hiba szerintem: az adatok ugyanazon a RAID tömbön / poolban vannak, mint ahová a mentés is történik

+sok A PBX az másik fizikai gépen fut (akkor tudsz további lemezt tenni bele/rá) - vagy ezen egy VM-ként? Egy 4xLFF használt servert már "gombokért" kapsz ami PBS-nek tökéletes lehet, már csak az a kérdés, h mennyi tárhelyet szeretnél mentésre, mert 10TB körüli lemezek olyan 100k körül lesznek.

Én sehol nem látom azt, hogy a mentések ugyanide mennének. Ha mégis én értettem félre valamit, akkor sem az a megoldás, hogy másik tömbre mennek, hanem konkrétan másik tárolóra/szerverre kellene tenni (persze ismerni kellene a mentési architektúrát, de az esetek túlnyomó részében a mentések a produktív tártól eltérő helyre menjenek).

Az IOps korlátozás könnyen kontraproduktív lehet.

A chunk stb paraméterekkel lehet játszani, de én nem hiszem, hogy megváltást okozna + tipikusan elég bonyolult/időigényes ezzel játszani.

Szerintem egyszerűen az történik, hogy kevés a cache, a produktív adatok annál nagyobb méretben vannak elszórva, és mikor valami nincs cache-ben, akkor csak a nagyon lassú forgó lemezeken érhető el, ami óhatatlanul lassú lesz (ráadásul ez meglehetősen nehezen mérhető ki). A mentés úgy jön képbe, hogy vagy kiszórja az adatokat a cache-ből (esetleg hozzájárul a kiszóráshoz, mert úgy jön ki a statisztika), vagy egyszerűen azért, mert mikor mentés is fut, akkor a forgó lemezek eleve terheltek, így az onnan elérendő adatok még lassabban lesznek elérhetők.

A tieringgel egyetértek, lásd feljebb (OS + teljesítmény kritikus adatok odaragasztása). Ha ez nem hoz megoldást, akkor újra kell tervezni a rendszert. Több SSD és/vagy több+gyorsabb+kisebb HDD, de ezt ennyi információ alapján képtelenség meghatározni.

Egy fiot ki tudsz próbálni: (mármint a topiknyitó)

fio --name=ssdtest --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE

ha  400-500  kB/ sec jön ki,  akkor amit elöttem írtak. iops alacsony. Illetve ha nem titok megoszthatod mennyi lett. Ez csak egy 10 megás teszt, pár másodperc.
 

https://blog.claryel.hu

A tisztán HDD alapú tömb tuti nagyon kevés erre a terhelésre. Az 512k chunk méret sem biztos, hogy ideális ilyen lassú tárolónál, és az RI SSD kb. semmire sem jó szerver környezetben (az boot meghajtónak való meg webszerver alá statikus tartalomnak), nem még bármilyen cache-nek storage-ba, sokszor rosszabb ilyennel egy kötet, mint nélküle.

Az írás-olvasási adaton látszik, hogy nagy blokkmérettel, szekvenciális művelettel nézed/mérted. A VM terhelés nem ilyen, hanem kis blokkmérettel, random írás-olvasás. Ha futtatsz egy FIO-t random rw módban, 16k blokkmérettel, az így kaptt adat inkább lesz jellemző a VM futtatásra. Szerintem elképesztően gyászos számok lesznek RAID10 ide vagy oda, én kb. 500 IOPS-t és ehhez ~8 MB/s sebsséget tippelek. Ez vicc VM-ek alá. Szóval én megfordítanám, ez csoda hogy nem tűnik fel a VM-ek teljesítményén mentés nélkül, normál futás közben...

A PBS terhelés sem szekvenciális, hanem nagyon is random, ugyanis kicsi, ~4 MB-os blokkokat használ, milliószámra - ha a PBS is erre a tömbre ment.

Egyébként ha a Proxmox-ba tesztek egy SSD pool-t (nem kell nagy, nem feltétlen kell redundáns sem, és legyen thin provision), és azt megadjátok a mentésnél fleece-nek, akkor oda gyorstárazza a mentendő dolgokat a vzdump, így kevesebb ideig lesz nagy terhelés a VM diszkeken mentés közben.

az RI SSD kb. semmire sem jó szerver környezetben (az boot meghajtónak való meg webszerver alá statikus tartalomnak), nem még bármilyen cache-nek storage-ba, sokszor rosszabb ilyennel egy kötet, mint nélküle.

Én ezt túlságosan erős állításnak tartom, pláne úgy, hogy "mögötte" 7.2k lemezek vannak (én még nem láttam 10k 4T lemezt, a tároló adatlapján sincsen), nem is túl sok (konkrétan kevés, VM-enként 1db lemez sem jut).

Persze, jobb egy MLC SSD, de ki is kell fizetni, gazdagabb/nagyobb helyeken is megszámolják, hogy 10-20T-t miből raknak össze. Tekintve, hogy semmi információ nincs az adatokról, nehéz ez ügyben okosat mondani, számomra az a biztos, hogy a 7,2k lemezek nagyon jó eséllyel hozzájárulnak a problémához.

Az RI SSD-kben nincs PLP, így (részben emiatt, részben az RI-ség miatt) csapnivaló a random írás IOPS SSD-s mércével nézve. Mi is kísérleteztünk enterprise, de RI SSD-kkel néhány éve ügyfél virtualicció szerverbe, hogy olcsóbb legyen, de eléggé vegyes, inkább rossz tapasztalataink lettek teljesítmény terén.

Ezért mi MU SSD-ket teszünk szerverbe és NAS-ba VM tárolónak és cache-nek. Persze ahol sok adat van (főleg fájlszerver funkció, nem SQL alá), oda teszünk HDD-t is a sok, nem túl IOPS igényes adatnak, nem tisztán SSD-sek a szerverek. Mi jellemzően Kingston DC600M-et veszünk az utóbbi időben, régebben Samsumg PM sorozatot részesítettük előnyben. 1-2-4 TB méretben ezek azért kifizethetők egy szerverbe 2-4 darab. Mellé mehet valamilyen Exos diszk tárkapacitásnak, és már kész is költséghatékényan egy aránylag gyors Proxmox szerver.

Storage-dzsel pont azért nem próbálkozunk a legtöbb ügyfélnél (mi kisebb cégeknek, hivataloknak dolgozunk jellemzően), mert azok általában nagyon háklisak a betett meghajtókra (szeretnek márkahűek lenni, és egy Dell MU SSD arcpirító árban van), inkább csinálunk Ceph-fel osztott tárkapacitást, ha ilyen igény merülne fel. Abból is SSD és HDD pool-okat egyaránt az adattól függően.

( asm v | 2025. 11. 07., p – 23:13 )

Szerintem erdemes korulnezni a TCP Delayed Ack es az iSCSI Queue Depth beallitasok korul.

( szekelyk | 2025. 11. 09., v – 00:05 )

PowerVault ME50xx    

Latest code: 1.2.1.5    August 2025  

Recommended code: 1.2.0.3    May 2024   

Minimum supported code: 1.2.0.2    Oct 2023

( gabrielakos v | 2025. 11. 10., h – 08:59 )

proxmox backup jobok szervezéséről sem tudunk semmit.

célszerű úgy szervezni hogy ne zavarjon: 

  • csinálni mondjuk egy napi_mentes jobot és abba belerakni az összes vm-et amit mentenél
  • csinálni másik akármilyen mentéseket, ami akkor fut miután az első már várhatóan végzett

A lényeg az hogy egyszerre lehetőleg egy (v kevés) job fusson, az nem fogja agyonvágni a diszket.

Az inkrementális mentés miatt ez se fog drámaian sokáig tartani.

Amit még lehet: pbs inbound sávszélességet limitálni, de hogy ezt hol és hogyan - na ahhoz konkrétan látni kellene az egész infrát.

( wolfnet | 2025. 11. 14., p – 12:01 )

Sziasztok, Farkas Márk vagyok, Örkényi Petivel dolgozunk együtt a dell emc projekten. Olvastam a válaszaitokat, a teljesség igénye nélkül próbálok válaszolni. 

  • a Proxmox backup egyértelműen nagy latency-t okoz, 30-35% iowaitet nem ritkán. 15-20 perces inkrementális snapshot mentések vannak, tehát folyamatosan fut. Nem napi egy vagy ilyesmi, üzemeltetési szempontból nekünk nagyon fontos a legalább fél óránkénti mentés. A háttérben a backup szerver napi 1x rendezi a mentéseket. Ha korlátozzuk a backup szálakat és erőforrást jobb a szitu. A problémánk az hogy ha natívan fut valamelyik dell szerver merevlemezein a VM és úgy mentjük ugyan így, nincs iowait probléma nincs VM lagg. A natív storage megoldáskor ráadásul nem SAS merevmelezekkel dolgoziunk hanem sima 4TB WD PURPLE / RED vinyókkal, amelyek "lassúak", még sincs iowait gond csak ha EMC-n lévő VM-et mentünk.
  • A mentések alkalmanként kb 5-15GB méretet mentenek le. Ha újra fut tisztán akkor 500-800GB méretűek a VM diskek, ilyenkor megértem az iowaitet, de utána nem.
  • Eredeti DELL SAS 10GBPS 3.5" merevlemezeket használunk! Eredeti DELL SSD -t használunk cache-ra.
  • Próbáltunk mindent, próbáltunk korlátozni VM iops-t picit jobb de nem jó. Van olyan VM amelyik csak DB postgresql, van olyan vm 3-4 ami windows 11 / windows szerver. A többi ubuntu server.
  • A roundrobint debian multipath szinten próbáltuk. Nélküle a csúcs sebesség alacsonyabb, vele a csúcs sebesség 1200MB/S írás kb. Ami hibátkannak tartok nekünk bőven elég. Viszont tényleg itt kizárólag ilyen "LAGG" problémák vannak, elindul egy mentés és azonnal "megfagy" 1-1 vm. Ami főleg ADATBÁZIS műveletnél kínos... :D 

Én azt javaslom akinek van konkrét tapasztalata, Pénzért, nem ingyen várjuk el, és Székesfehérvár megközelíthető távolságban van neki, kérem telefonon / emailen keressen meg minket, egyeztessünk egy napot amikor kijön megnézi, kifizetjük a kiszállását, kifizetjük az idejét, biztosítunk végtelen Kávét és Pizzát :)))  és tudunk Tesztelni játszani úgymond, az egész DELL EMC le van resetelve jelenleg. Megnézhetjük elölről együtt, aki érez magában affinitást és van ideje foglalkozni vele és tudja mit csinál kérem jelentkezzen. 

 

wolfnetteam@gmail.com

06 30 241 7826 

köszönjük és reméljük találunk alkalmas embert

üdv Márk

raid6 na az a tipikus oltári kibaszás mindennel.

nézd már meg hogy egy darab írás (a backup ugye írás) az mennyi plusz olvasást és checksumot eredményez. elméleti szinten.

ennyivel már oszthatod is tovább a rendelkezésre álló iops-t. Marad 15 iops-ed? Csodálkozol?

Még egyszer leírjuk hogy IOPS-nek hívják ami miatt a bajod van. Meg latency-nek.

Ha "elraksz" egy disket storage-ba akkor a natív latencyhez még az a késleltetés is hozzájön amíg a géptől a storage-ig elér a kérés meg vissza.

Arról nem is beszélve amit a "storage-ban" eltölt.

Szóval egy ilyen diszk alapból tud mondjuk 100-120 iops-t. Ha 4k-s írások vannak akkor ez 400kbyte/sec.

A 100 iops ugye átlagban 10msec latency-t ad neked. Ehhez adjál még mondjuk kettőt a storage miatt (és optimista voltam) máris ott tartasz hogy 12ms. Ott tartasz hogy 83 IOPS az elméleti maximumod. 

Mire elég ez?

Leirták előttem , utánam.  Jó átersztő képesség, gyenge iops. ISCSI , minden I/O műveletet TCP/IP csomagokba kell „becsomagolni”, majd a hálózaton továbbítani. Purple-nél meg nincs hálózati réteg.  Egy aszatli ssd , a leggyengébb is jobb lesz mint a Dell. 
Próbáljátok már kia a fio-t amit már irtam, illetve hogy mennyi lett : (a testfile1  file a dell-en jöjjön létre):

fio --name=dell test --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE

 

https://blog.claryel.hu

kipróbáltam pár diszken:

nvme ssd single (eléggé dolgozik):
root@dell:/mpool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=23.3MiB/s (24.4MB/s), 23.3MiB/s-23.3MiB/s (24.4MB/s-24.4MB/s), io=10.0MiB (10.5MB), run=430-430msec

15 k sas raid 1 (2) nem csinál semmit:
root@dell:/rpool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=915KiB/s (937kB/s), 915KiB/s-915KiB/s (937kB/s-937kB/s), io=10.0MiB (10.5MB), run=11191-11191msec

régi intel enterprise ssd raid1 (2) nem csinál semmit:
root@dell:/spool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=9517KiB/s (9745kB/s), 9517KiB/s-9517KiB/s (9745kB/s-9745kB/s), io=10.0MiB (10.5MB), run=1076-1076msec

synology nas nfs (benne nvme ssd raid1 write cache, idle):

root@dell:/mnt/pve/proxmoxbk# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=10.4MiB/s (11.0MB/s), 10.4MiB/s-10.4MiB/s (11.0MB/s-11.0MB/s), io=10.0MiB (10.5MB), run=957-957msec

Elég pici ez a tesztfile de asszem látszik a diszkek hátránya így is. Pedig lokál diszkek.
A gépben levő NVME SSD-t pedig a PCIe busz sávszél korlátozza, az SSD többet tudna. (Dell R430, jó régi)

  • A mentések alkalmanként kb 5-15GB méretet mentenek le. Ha újra fut tisztán akkor 500-800GB méretűek a VM diskek, ilyenkor megértem az iowaitet, de utána nem.

Ez egy hibás állítás. Egy ekkora "VM inkrementális mentés" is bőven előhozza ugyanazokat a problémákat mint egy full mentés.

Ha jól értem, akkor ha minden VM-et átmigráltok helyi RAID6-ra (WD PURPLE/RED), akkor jól működik, ha a tárolón van, akkor nem működik jól? Ugyanazok a VM-ek itt is, ott is, egyszerűen átmozgatva egyik adattáról a másikra?

Helyileg milyen fájlrendszer van, milyen a fájlrendszer az iSCSI-n?

Azt próbáltátok, hogy kikapcsoljátok az SSD cache-t a tárolón? Ha helyi RAID6-on jól megy, akkor elvileg anélkül is elviselhetőnek kellene lennie a tárolón, a mérés is konzisztensebb tud lenni, mert az SSD biztosan nem torzít. Tárolón próbáltátok RAID6-tal? (biztos nem lenne gyorsabb, de kérdés, hogy lassabb-e, jobban hasonlítható a helyi felálláshoz)

A "DELL SAS 10GBPS 3.5"" és "MB/S" jellegű írások alapján szerintem simán elmentek valami mellett, fogalmam sincs, mi lehet a Dell SAS 10GPS lemez. A merevlemezeknek tipikusan van egy csatolójuk, ami lehet például SAS, annak van egy sávszélessége, de biztosan nem 10GBPS (inkább 3/6/12), van egy fordulatszámuk, jelen esetben elvileg 7200, jobb esetben kis valószínűséggel 10000, de ahogy néztem a tároló adatlapját ez kb kizárt, így nem tudom, honnan jöhet ez a 10GBPS-es szám.

A sok "MB/S" érték pedig szintén félrevezető, mert teljesítmény esetén IOps+blokkméret és késleltetés számok mondanak valamit. A "MB/S" nyilván összefügg a többivel, ha kicsi, akkor lehet rossz, de kis blokkméret esetén nem fogsz túl nagy számot kapni. Például az 1200MB/S sebességet milyen műveletekre kaptad? (tippre biztosan nem 1k véletlen írásra)

Arról sem írtál, hogy a lokális lemezek milyen RAID vezérlőre csatlakoznak, van-e valami gyorsítótára? Utóbbi nagyon sokat tud dobni a teljesítmény, hiánya nagyon fájó tud lenni főleg ennyi VM esetén + lásd fájlrendszer kérdést.

A tárolóval mi a célotok egyébként, miért terveztétek iSCSI-re tenni?

Kérdező személyes segitséget keres, nem annyira tanácsokat, de egy két használható ötlet talán elhangzott. 
Ez egy enterprise storage, elvileg akár több száz alacsony terhelésű vm elmehet rajta.
De akár egy -két nagy iops igényű adatbázis leültetheti a tárolót , vagy hirtelen nagy random write , iops igény , hdd lemezekkel.
Ilyenkor akár nálam is előjön az az axioma,hogy drága hardver , enterprise minőség, tehát a beállítás a rossz.
Ami aztán vagy így van, vagy nem. 

Össze lehetne hasonlítani a az ME5 -öt a purple lemezekkel , amikor dell laggol egy sima iostat paranccsal, 
a hdd util és az await értékek összehasonlitása alapján valamit csak látni kellene, a referencia purple-től miben tér el.
 

https://blog.claryel.hu

Nem világos, mit is akartál ezzel mondani. Értem én, hogy személyes segítséget keres, de az ember megpróbál neki segíteni, ha már személyesen jelenleg nem is tud. Ő is jobban jár, ha már itt jobban körülírja a helyzetet, nem ott a helyszínen megy vele az idő.

Ez egy enterprise storage, elvileg akár több száz alacsony terhelésű vm elmehet rajta.

De jó, hogy írod, én azt hittem a székesfehérvári bolha piacon rakta össze 3-4 árustól.

Attól, hogy vállalati tároló, még nem feltétlenül fog elmenni rajta több száz alacsony (?) terhelésű virtuális gép. Néhány 7.2k lemezre néhány száz VM-et tipikusan nem egészséges tenni, SSD gyorsítással sem.

Attól, hogy vállalati tároló, még lehet vacak, sőt, az ár sem feltétlenül jelent minőséget. Kérdés, hogy a kompatibilitási listán szerepel-e adott verziójú Proxmox vagy sem. Ez elvileg egy "ALUA tároló", kérdés, hogy ezt figyelembe vették-e, mert még az is lehet, hogy nem optimalizált útvonalon mennek a kérések.

Szóval vannak kérdések, amiket akkor is jobb előre tisztázni, ha helyszínre megy az ember. Ez egy kockázatos tanácsadás, aminek könnyen lehet rossz szájíz a vége (értsd: nem sikerül érdemit megállapítani).

Szia, igen pontosan így van. Ha az R720 natív Raid6jára teszünk rá minden VM-et NFS megosztással 10G SFP+ switchelt hálózaton akkor hibátlan minden. Ott 5400rpm-es WD purple lemezek vannak. Ha az ISCSI Dell EMC-re teszünk (5.5millió+ÁFA volt a konfig egyébként), akkor iowait van. 

Pontosan jól mondod, használunk dell SSD-t cache-re. Ha kivesszük a cache-t a tömbből akkor fura módon JOBB a teljesítmény az ISCSI -n. A Disk írással sosincs gond, ezt is tegyük hozzá. 1200MB/S körül írünk, és a kis 4M blokkokat is 400-450MB körül. Az olvasás a lasú. pedig az SSD elvileg READ CACHE-re van állítva. 

A dell r720 esetében sima gyári raid kártyát használunk 1G cache-el. 

Szóval ráadásul úgy működik hibátlanul az R720 esetében, hogy a natív disk megvan osztva NFS-el, mennek a disk move-k és a backuppok és a VM-ek és továbbra sincs 2-3% iowaitnél több. 

Még volt olyan kérdése másnak, a Dell szerverekben egyesével 256G ram van, a 640-ben több. A VM-ek kb 40%-ot használnsak egységesen. 

Azért van a Dell EMC mert szeretnénk a 3 szerverrel Proxmox HA-t megvalósítani ami kész is jó is megy is, de a Dell EMC random kifagy. Fontos adalék, amikor az iodwait felszökik 50%-ra akkor a DELL EMC IDRAC -ja sem elérhető. Egyik vezérlőn sem, se A se B. A vezérlők és a Szervereink direkt 25G linkenvannak összedugva, nincs SW. 
 

Köszönöm a válaszod, ha van ötlet várjuk szívesen. 

Esetleg valakinek még valami konstruktív hozzászólás? Aki nem olvassa el a kérdést kérem ne kommenteljen nincs időm végig olvasni 30 darab neharagudjatok a szóért, F*szságról szóló kommentet :)) 

 

üdv 

Márk

Hát, most is leírtál egy csomó mindent amit eddig nem. De ez is félinformáció legjobb esetben.
Úgy néz ki sikerült egy jó komplex ámde összességében mégse jó rendszert összerakni. 
Az az 1G cache controller például egy klasszik hiba. 

Az az érzésem hogy ha odamennék és javasolnék, nem hinnétek nekem. 
A felesleges konfliktus meg nem hiányzik.

Rendben nem konfliktust generálni szeretnék viszont kezdem elveszíteni a hitem... hogy valaha valaki tud még olvasni ebben az országban. Azt írtam le hogy a NATÍV Raid6 mögött van egy 1G cache raid vezérlő. 

A Dell EMC ISCSI-megoldásban 2TB dell SSD van betéve. Kérlek szépen olvasd el amit írok ALAPOSAN! Mérnöki szemléletmód... 

 

szerk: és még az 1G cachelt raid is tökéletesen működik. 

üdv, 

Nem olvastam félre. Attól hogy "működik" még egy klasszik hiba.
fio méréseket szeretnék látni, mérnöki módon leírva a környezetet is.
a hostról meg kéne "fio-zni" az emc-t is meg a lokál tömböket is.
device config, fs config, minden részlet számíthat.

össze lehet hasonlítani az itthoni nulla forintos retkeimmel.

Ha már számon kéred a mérnöki szemléletmódot (amit egyébként gabrielakos és a többiek is végig tolnak, merthogy definiálnak szükséges méréseket és várják az eredményüket a további segítséghez, valamint kérdéseket tesznek fel az architektúra eddig "titkos" (nem fontosnak gondolt) részeiről), akkor eddig miért nem sikerült senkinek leírnia, milyen és mennyi PVE hoszt kapcsolódik a Dell-hez és milyen módon vannak ezek összekötözgetve, ha nincs storage oldalon switch, csak direkt kábelezés?

Persze össze lehet csipegetni (gyakorlatilag elszólásokból), hogy van egy R720, egy R640 meg még legalább egy (vagy több) valami más. De, hogy pl. az R720-on helyben van használva a HDD-s RAID6 tömb, vagy az R720 egy PVE szerver és másik NFS szerveren vannak a VM diszkek, és azon van ez a RAID6 tömb, eddig nekem nem derült ki.

Azt nem tudjuk, hogy Proxmox alatt a 25G interfészeket teszteltétek-e más módon, hogy azok egyébként nem-storage felhasználás esetén jól működnek-e valóban? Próbáltátok-e 1G és 10G összekötéssel, hogy a sávszéltől eltekintve véletlen nem javul-e a helyzet (mondjuk 10G-n) a 25G-hez képest?

Bevallom, én azt sem tudom elképzelni, hogy a 15 VM egy lokális, 5400 rpm-es HDD-kből álló RAID6 tömbön jól futna... Annak az írási IOPS képessége valahol 200 körül van. Pláne, hogy van köztük DB szerver is, ami önmagában elég IO igényes. Persze lehet a storage verzióhoz képest már ez is jó, de abszolut értékben jó-e, hát...

Nagyon érdekes a probléma, érdekel a megoldás, szeretnék is segíteni ha tudok, de úgy kell kiharapófogózni minden kis infót belőletek...

+1

Már csak azért is érdemes leírni, lerajzolni az architektúrát, mert ha valaki elmegy személyesen az OP-hoz és számláz per óra alapon, akkor nem mindegy, hogy 3-4 óra csak azzal megy-e el, hogy az OP-ból a személy / személyek kiszedjék az információt vagy érdemben lehet előre haladni a probléma megoldásában.
Ez kőkemény anyagi kérdés. Szerintem.

Fontos adalék, amikor az iodwait felszökik 50%-ra akkor a DELL EMC IDRAC -ja sem elérhető.

Ha jól olvastam, akkor ezt eddig nem említetted. Ez számomra azt jelenti, hogy elfogy a storage CPU-ja. Ha nagyon sok lemez, nagyon sok host és nagyon sok funkció van bekapcsolva (dedup, thin provision stb.) egyszerre, akkor láttam már ilyet élőben.
Én megkockáztatnám, hogy valami fw bugba futottatok bele (velem volt már ilyen kb. 12 éve). Ahhoz meg EMC partner vagy maga az EMC kellene.

Nem véletlenül írtam, hogy az SSD-t tegyétek külön tierre és legyen bekapcsolva az automatikus tiering. A régi iskola szerint nem ajánlott különböző lemezeket (NLSAS, SAS, SSD) azonos tömbbe tenni. Azonos poolban lehetnek.
Az SSD csak akkor segít bármit is, ha azon van az olvasott adat vagy oda tud írni a host. Amikor a storage cache elfogy, akkor jön a nyers diszk teljesítmény.

Amit még én látok különbséget: az R720-nál az iSCSI hálózat switchelt, míg az ME5012 esetén nem. Meg tudnátok azt próbálni, hogy az ME5012-t ugyanúgy 2 darab különálló switchen keresztül kötitek rá a hostra? Nem baj, ha csak 10 GbE és nem 25 GbE.

Jó lenne egy komplett rendszerleírás, ábrával, az NFS most megint új információ. Én azt hittem a PVE-nek helyben van a RAID6 WD lemezekkel.

Akkor most hány vas van összesen? Van a Dell tároló, van egy Dell R720 szerver, amin - gondolom - Linux megoszt egy tárterületet NFS-sel a Proxmox(ok?) számára. Ezen Dell R720 alatt vannak a WD lassú lemezek RAID6 tömbben, gondolom PERC vezérlő van az 1GB cache-sel. Nem feltétlenül túlzottan lényeges, de az NFS mögött milyen fájlrendszer van?

Hány Proxmox (PVE) szerver van?

iSCSI-n milyen fájlrendszer van? Miként van használva? Most hány PVE csatlakozik NFS-re, iSCSI-re?

Amennyire én tudom, iSCSI alatt nem igazán jól megoldott Proxmox alatt a több PVE általi párhuzamos elérés, most V9-ben van valami újítás, illetve van ZFS over iSCSI, mi a tervetek? (többek között én azért sem vállalkoznék helyszíni megjelenésre, mert egyelőre nincs kellő Proxmox tapasztalat)

Van egy érzésem, hogy itt még vannak nem mellékes információk a háttérben, hiába próbálok figyelmes lenni, sok részlet nem derült ki.

Az például biztos, hogy optimalizált útvonalon éritek el az iSCSI területet? Ha több PVE van, miként vannak a portbekötések? Egy PVE-nek hány kapcsolata van a tárolóval? Például ha kettő, mindkét vezérlőre 1-1, valamint RR van, akkor az RR-ből az egyik útvonal biztosan nem optimalizált lesz.

Amennyire én tudom, iSCSI alatt nem igazán jól megoldott Proxmox alatt a több PVE általi párhuzamos elérés, most V9-ben van valami újítás, illetve van ZFS over iSCSI, mi a tervetek? (többek között én azért sem vállalkoznék helyszíni megjelenésre, mert egyelőre nincs kellő Proxmox tapasztalat)

Itt mire gondolsz, hogy párhuzamos elérés nem megoldott? iSCSI-ra raksz LVM-et, aztán LVM-re rakord a VM-eket, (és persze minden node-ra odarakod az LVM storage-ot) ebbe semmi extra nincs, különösebb proxmox támogatás se kell hozzá, OS szinten kell megoldani a shared LVM-et, mondjuk ott nem támogatott a snapshot, de hát ez van.

Dell szerverekben egyesével 256G ram van,

Azert ez sokat ad a rendszerhez. Jo par éve "sima" szervereket használunk NFS storage-nak.  Van tobbfele konfig, sima HW raid60 + debian + nfs-kernel szerver van, openmediavault + ZFS stb. A lényeg a sok ram, az ki tudja simitani a dolgokat ... 

Fedora 43, Thinkpad x280

Support is van rá, mert akkor érdemes bejelentni, lehet valami csúnya bug, bár megnézve a release notesokat nem látok benne említést ilyen hibáról, akár ismert akár valamelyik kiadásban javított. A másik ALUA tárolón szerintem a round robin nem nyerő, mivel akkor a nem optimális útvonalat is használja. Amúgy nekem is az a véleményem és írtam, is hogy karcsú a konfig a gyártói méreztező szerint is. Az írás azért van rendben mert elnyeli a DRAM cache, meg az SSD cache, de amikor olvasol és a diszkekről jön az adat az már karcsú. A RAID 10 az 5 RAID1 mirror stripeolva.

( vasla_ | 2025. 11. 14., p – 13:41 )

Ok, látszik ezen a mini teszten is   nativ sas: 937kB/s iops terhelésnél (150-200)  ,  iscsi nél még rájön a hálózati réteg, ami már lehet hogy nagyon levesz. Az ssd-kkel nincsenek egy univerzumban. HDD-kkel én olyan 100 ra tippelem a dell-t.

https://blog.claryel.hu

( vasla_ | 2025. 11. 14., p – 13:51 )

Na most találgatások helyett nem lenne célszerűbb megcsinálni két fiot, egyet a dell lemezekre egyet meg a nativ purple lemezekre. Ha másre nem,  összehasonlitásra jó. 
Vagy elmélkedhetünk , hogy szopik e a kacsa ?

https://blog.claryel.hu

( gabrielakos v | 2025. 11. 14., p – 14:06 )

RAM ról még nem beszéltünk. Mennyi ram van a gépben és ebből mennyi jut a VM-eknek / mennyi marad filesystem cache-nek?
Nálam a ZFS eléggé "szárnyakat kapott" amikor kapott +64GB-t a szerver. Most 160GB van benne, swap nincs.

( szekelyk | 2025. 11. 15., szo – 23:08 )


Van egy egész friss firmware.

Dell PowerVault ME5 Series Storage Controller Firmware ME5.1.2.1.5 Kritikus 12 Nov 2025

Illetve megnézném a drive firmwareket is.


Dell PowerVault ME Series Storage merevlemez/SSD firmware Recommended 18 Jun 2025