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!

  • 1885 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

sztem itt sokan felre ertik a topikot, szemmel lathatolag nekik az lenne az egyszerubb ha valaki hozzaerto oda menne es felterkepezne a problemat es megcsinalna nekik, amiert penzt is fizetnenek, siman nem tudnak idot szanni arra, hogy sajat maguk debuggoljak ki, de fizetnenek masnak aki tud.

Azt is ertem, hogy tul keves az info, hogy barki bele merjen ugrani, dehat nem sikerdijra kell ajanlatot adni hanem oradijra :)

Nem az egyszerűbb hanem olyan embert keresünk aki már használt ilyen tárolót és van tapasztalata.

A bejegyzések pár kivételel teljesen hülyeség mert ez nem NAS nem egy univerzális tároló ez egy SAN

És igen lehet óradíjas persze, csak tudja már mi a különbség egy SAN és NAS legalább..... És ismétlem önmagam hogy olyan ember keresek aki használt és látott is Dell storage-t 

A bejegyzések pár kivételel teljesen hülyeség mert ez nem NAS nem egy univerzális tároló ez egy SAN

Bocs, de ez erős.

Kiemelnék két "teljesen hülyeség"-et az oldalról:

  • "2×25 Gbit/s round-robin ALUA multipath"
  • "SAS 10GBPS 3.5" merevlemezek"

Szerintem alapvetően teljesen jó tippeket kaptatok, elvárjátok a mérnöki hozzáállást, de roppant pongyolán és hiányosan fogalmaztok, sok részletet nem közöltök, egyszer csak beesik egy NFS is.

Egyébként nekem nem tűnt fel, hogy bárki összekeverte volna a NAS-t a SAN-nal, hozzátéve, hogy itt nehezen tudunk SAN-ról beszélni, mivel "direct attach" iSCSI van. Maradjunk blokk szintű hálózati tárolónál. De rendben, fogjuk rá arra két kábelre, hogy ők a SAN, elvégre nélkülük nem lenne kapcsolat.

Értem én, hogy nem itt várjátok a megoldást, a "lehet óradíjas" bennem újabb kérdéseket vet fel az elvárások tekintetében. Az egyébként nem merült fel, hogy aki szállítja az eszközt, be is állítja vagy ad némi támogatást hozzá?

Részemről: érdekel a probléma oka/megoldása, legyen az akár konfigurációs hiba kompetencia hiányból (jó esélyt látok rá), akár valami különösebb együttállás, akár bug (kisebb esélyt látok rá), talán Proxmox specifikusan is szedek fel némi ismeretet. Szerintem ez belefér az itteni keretekbe.

De a kérdező , mint már leirta személyes közreműködőt  keres, ezen nem kell rugózni. (Sürgős határidő, időhiány, stb). Ezért nem is irogat részleteket, mert nem ez a célja. Gondolom valami igen sürgős megoldás kell.

Azon meg lehet elmélkedi hogy NAS vagy SAN, illetve hogy hol a határ, de ez csak ilyen mélázás,   az egycsipes kétlemezes usb-s NAS  is NAS, meg a trueNAS is nas (ráadásul open source).

TrueNAS  :iscsi  natív támogatás, így blokkszintű LUN‑okat tudsz exportálni Proxmox-nak, raw device-okkal, vagy zfs over iscsi-vel, ami szintén  blokkeszközöket ad, multipath, dual‑controller HA appliance funkció, diskpolcok egybe köthetők, stb. 

Vagyis : NAS lehet SAN, ha blokkszintű szolgáltatást nyújt.
SAN nem lehet NAS  mert a SAN mindig blokkszintű, és nem ad fájlszintű megosztást.Leginkább azért is mert a NAS egy fizikai eszköz, a SAN meg nem egy konkrét doboz, hanem egy logikai architektúra. ME5 mindig csak blokkokat ad.

https://blog.claryel.hu

Pl. az eszközt kiválasztó, konfiguráló embert miért nem hívták a HUP fórum tagsága helyett? Merthogy nyilván olyan valaki választotta ezt a modellt ezzel a konfigurációval a feladatra, aki ért hozzá és dolgozott már ezzel az eszközzel. Neki tudnia kell a megoldást.

Ok, de ez a kérdezők dolga. Elvileg találhatnak itt is valakit, lehet hogy privátban van is jelentkező. 
Sajnos az van, hogy papirforma szerint az ME5 targetnek tudnia kellene ebben a felállásban  azt amit a raid6/purple megoldás tud. Ehhez megkaptuk az elegendő információt, ha többet nem is. 

https://blog.claryel.hu

Alma körte, de ha a purple-lel gond nélkül működik akkor egy jól működő me5 target-tel sem lehetne gond , de az egyikkel megy jól,a másik mag durván laggol. 
Persze ha "egyforma" a környezet, ahogy gondolom, csak a storage a különbség, semmi más. 

https://blog.claryel.hu

Amit már más is írt, valaki méretezte ezt a tárolót - jó esetben -, eladta, az nem nyújt supportot vagy gyártói support, ha nem az elvártak szerint működik? Alapból így indul a dolog egy tárolónál. 

Ez egy DAS direct attached storage felállás, nem is értem miért nem SAS lett akkor, persze lehet későbbi terv a switchek használata, ez nem is gond, bár ritka.

A TrueNAS egy termék/szoftvercsomag, ami nyújt blokkos tároló szolgáltatást is, de attól a NAS nem lehet SAN is néha.

A NAS a network attached storage, jellemzően NFS, SMB szolgáltatást nyújt.

Ezzel a hozzászólással bezárólag az eddigiek alapján bennem az a kép alakult ki, hogy vannak ilyen-olyan hardveren PVE szerverek amik az idők során gyűltek, és a vezetőség felé el lett adva, hogy egy drága tárolóval ezek rettentő jól hasító HA rendszert fognak kiadni. Mert ha valami enterprise, akkor az mindenképp megoldás lesz a feladatra, mert benne van a varázsszó (sőt több varázsszó is: storage, SAN, 25G).

Aztán beütött a valóság, hogy a drága tárólóba a feladathoz passzoló SSD-k már nem férnek bele a büdzsébe, és így lettek HDD-k meg pár RI SSD cache-nek mentendő a helyzetet.

Ez össze lett rakva direkt kábelezéssel, mert kiugrott a szeme a döntéshozónak a 25G-képes switch-ek árától a már elköltött 5.5 millió után, pláne, hogy legalább kettő kell belőle.

Aztán mikor elindult az új enterprise SAN rendszer, elmaradt a csoda...

Az az ember, aki ezt a tárolót, erre a feladatra, ezzel a konfiggal kiválasztotta, na Ő mit mond, hol lehet a gond? Feltételezem olyan választotta, konfigurálta, aki ért hozzá, látott már ilyent, ismeri a képességeit és a feladatot is.

Ha már szavakon lovaglás is van, akkor ezen felül ez így magában egy NAS, magasabb redundanciával, mint egy kis Synology. Miféle SAN-ról beszélünk (Storage Area Network; a SAN nem egyetlen eszköz, hanem egy hálózat, ami a szerverek és tárolók összekötésére szolgál, és csak egy szemantikai megkülönböztetés, semmi extra műszaki tartalmat nem jelent), mikor még egy nyomorult switch sincs? Sőt, nem is NAS, hanem majdnem hogy DAS ezzel a bekötési móddal, hamár itt tartunk, csak nem klasszik SCSI/SAS hanem iSCSI mert más a csatoló protokoll...

Ezen felül a nagy szakmaiságba elsőre mondjuk kifejthetnétek a szempontrendszert, hogyan került HW RAID6 tömb virtualizáció alá például, amin aztán teszteltetek (meg gondolom fut az éles rendszer, amíg az enterprise SAN probléma megoldódik)?
Utána érdekelne megvételre az a 10 db HDD, ami RAID10-be szervezve 4k random írás terhelésre (a storage memóriájánál nagyobb adathalmazra mérve) 1000-1200 MB/s (256000-307200 IOPS) teljesítményt adott le nektek. Másnak ez csak server-grade WI NVMe SSD-kkel szokott sikerülni, és abból is sok kell hozzá.

 

Persze ez egy erősen offenzív hozzászólás. De erre az arroganciára nem érzem soknak.

Egyébként sok sikert a szakember kereséshez, ha már úgy alakult, hogy itt csak ilyen dilettáns kockáknak sikerült összegyűlni. Én a storage forgalmazónál kezdeném, aki ilyent árusít, mindnél van komoly szakember is, aki ért hozzá (merthogy ez általában elvárás a gyártó oldaláról, hogy legyen), és pénzért tuti vállalják a feladatot. Csak nehogy azt találják mondani, hogy a konfig nem jó a feladatra és/vagy a hálózati kapcsolat módja nem jó a feladatra...

Pár gondolat részemről:

  • Igen, ez így egy DAS. Nem NAS, nem SAN. Örülök, hogy végre valaki leírta!
  • Ha a szekelyk nicknév mögött az a kolléga van, akire én gondolok, akkor az ő szavára adnék. Még a Comparextől ismerek egy ilyen nevű kollégát. Kente-vágta a storage-okat.

Csak megérzés: Azért nem tudnak a szállítóhoz menni, mert ők csak hardvert vettek mindenféle extra support nélkül. A basic support meg simán elhajtja őket, hiszen unsupported lehet a konfiguráció. Láttam már ilyet.

Igen, ez így egy DAS. Nem NAS, nem SAN. Örülök, hogy végre valaki leírta!

Nem irta le senki, kérdező is 25G linkről ir switch nélkül. Vagyis SAN. 
A szerver nem közvetlenül a diszkeket látja, hanem egy ME5 hálózati targetet, ami blokkokat ad át.

Es az megáll, hogy ha a purple alatt nincs lag, hiába körte és alma, me5 alatt sem lehetne.


 

https://blog.claryel.hu

Igen, SAN. 
DAS akkor ha :  közvetlenül a szerverhez csatlakoztatott tároló, hálózati réteg nélkül. (ME5 tudja elvileg, de biztos, hogy nem igy akarják használni)
Nem az hogy egy kábel megy direktbe , attól még nem DAS. 
Das akkor lenne ha nem lenne hálózati réteg. A DAS mindig közvetlen, hálózat nélküli kapcsolatot jelent (SAS, NVMe, USB).
Ebben a felállásban hálózati targetet lát a szerver. Tehát nem direct, Az legfeljebb csak a kábel neve. DAC kábel, már ha az van .

https://blog.claryel.hu

Nem, semmiképpen nem SAN, mert ahhoz switchek kellenek, hogy hálózat legyen. A direkt kapcsolat az nem hálózat, attól, hogy FC vagy iSCSI protokollt használsz. Értem a logikát amit írsz, de akkor is a DAS a helyes ahogy írod direkt csatlakoztatott tároló esetén, pontosabban ezt direct attach FC vagy iSCSI elnevezéssel illetik. Legalábbis EMC/Dell nevezéktan szerint.

ok , az én terminológiámban a DAS storage lehet egy usbs külsőházas ssd, vagy olyan ahol nincs tcp/ip kapcsoalat , pl ha a dell szerver host bus adapter sas kábellel , mini sas csatlakozókkal van összekötve az ME5 storiggal. Nincs tcp, nincs hálózati rétrg. Mintha a HBA -hoz kötnéd közvetlenül  a lemezeket. Persze ha switc nélkülkötöd ossze sfp+ on keresztül az is direct , hiszen nincs semmi a két gép között. De az már hálózati rétegen megy, mégha ilyen pont pont kapcsolatban. Nálam ez nem direkt, mert ott ahálózati réteg,  csak annyi hogy kihagytad a switchet. 

https://blog.claryel.hu

Ha már szavakon lovaglás is van, akkor ezen felül ez így magában egy NAS, magasabb redundanciával, mint egy kis Synology.

Nem, NAS-t hálózati fájlmegosztó eszközre szoktak mondani (tipikusan SMB, NFS), blokk szintű megosztásra képes tárolóra nem. Igen, a Network Attached Storage jelentésébe akár a blokk is beleférne, de arra nem szokás ezt használni, azok blokk tárolók, amiket tipikusan SAN-on keresztül érnek el a szerverek. Igen, vannak olyan tárolók, amik fájl és blokk szintű protokollokat is támogatnak. De az ME5 nem NAS, hanem "block storage".

( 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

( debtamas88 | 2025. 11. 16., v – 00:47 )

Sziasztok!

Szerintem csak az ethernet kártya offload-ja szórakozik, ami tud ilyet okozni:

Ennek mi a kimenete?

$> ethtool -k eth0

Offload kikapcsolása:

$> ethtool -K eth0 rx off tx off sg off tso off ufo off gso off gro off lro off

Ezek után próbáld meg, van-e lagg.

( vasla_ | 2025. 11. 17., h – 00:15 )

Esetleg hátha, nem ismerem az me5 -öt de ezen is vannak cli parancsok, amikor laggol, az ME5-ön  cli paranccsal  néztétek a show disk, meg a show performance-statistics parancsokat?

https://blog.claryel.hu

Nem ismerem a konkret tipust, de az ilyen storage eszkozok webes/cli vezerlese out-of-band IP-n szokott elerheto lenni. Az eleg sulyos gondnak latszik, ha az iSCSI-ra hasznalt "halozat" problemaja elerhetetlenne teszi a management feluletet is. Legalabbis ezt irtak. Azt is meg kellene nezni, hogy nincs-e vmi felrekonfiguralas (IP utkozes, atfedo subnetek, ilyesmik).

( gabrielakos v | 2025. 11. 17., h – 09:27 )

végigolvasva, fejben valamiféle architektúrát felrajzolva...

egy-két kérdés azért marad:

  • hova ment a pbs? amikor a Dell storage-t méritek illetve amikor az R720 mint NFS server-t méritek...
  • hol fut a pbs? az egyik cluster node-on? külön node-on?

állítások

  • a Dell storage I/O-ban karcsú, a 10 diszk "sustained iops" (ugye igazából 5 diszk) az valahol 400-600 körül lehet
  • a storage-ban 2 cpu és cpu-nként 16gb ram van
  • ezt a RI SSD íráskor nem tudja eltakarni, az se tud ennél többet
  • az R720-as kiajánlás azért tud sokkal jobb lenni mert:
    • több RAM van benne mint a storage-ban
    • kisebb a chunk size, nincs annyi chunk-waste kis írások esetén
      • következtetés: lehet hogy a kisebb chunksize tudna segíteni a storage-on (nem várnék tőle sokat)
    • az nfs mint protokoll eltakarja az "atime, mtime" jellegű adminisztratív írásokat, azt elvégzi háttérben míg az iscsi-nél ezeket is "át kell tolni"
  • a storage amikor belerakod a diszket akkor a diszken kikapcsolja az összes cache-t, azért hogy az írásban biztos lehessen. az r720-n a linux nem teszi ezt meg alapból. teljesítménye nagyobb, adatbiztonsága kisebb.

következtetések

  • ezt a storage-ot ennyi diszkkel megvásárolni drága hiba volt

ajánlás

  • vagy vennék bele 4 ssd-t és (diszket kivéve) tennék rá tieringet, úgy talán elég lesz (de akkor rendes ssd-ket bele nem a legalját)
  • de leginkábbis megpróbálnám visszaadni és csinálnék local storage-ot a node-okon ssd-vel és zfs sync-el oldanám meg (külön networkon) a migrációt, plusz vennék még memóriát a node-okba
  • esetleg meg lehet próbálni felhúzni csak az egyik host mögé és onnan nfs-en kiadni, de a sustained io ettől se fog megjavulni 

 

ui

  • én láttam dell emc storage-ot ami 64k iops-t szolgált ki 2ms latencyvel (egy egész bank, sokezer vm). az nem egy doboz volt, nem 10 diszkkel (igaz nem is 5.5M volt) 

  • a storage-ban a nagyon durva növelhetőséget a támogatást és a mindenféle compliance-t fizeted meg, de nem hazudik neked, alá kell tenni a kapacitást. az nagyjából úgy néz ki hogy "veszünk 1 dobozt tele ssd-vel meg 3 dobozt tele diszkkel"

     

a storage amikor belerakod a diszket akkor a diszken kikapcsolja az összes cache-t, azért hogy az írásban biztos lehessen. az r720-n a linux nem teszi ezt meg alapból. teljesítménye nagyobb, adatbiztonsága kisebb.

Ez simán lehetne ok, de a az me5 gondolom bekapcsolja a saját nvm  ram-cache-ét. És ha tényleg  a purple és az me5 pontosan ugynaz , semmi különbség a használatban,  akkor ekkora különbség nem lehetne, me5 meg durván laggol....

https://blog.claryel.hu

ez nem "lehetne ok" hanem ezt "tudni illik" amikor az ember iops-t méretez.

alapvetően szerintem a mai konfigurációk és árak mellett a "kis storage" nem megérős.
sőt a ceph és hasonlókkal elmentünk abba az irányba hogy "nagy storage"-t is inkább commodity-ből építenek.

ennek az egész szegmensnek eléggé leáldozóban van

Igen ,leáldozóban. Csakhát távoztak a pénztártól.
 Most ezzel kell főzniük, és fura,  hogy még a GUI is leakad. Régi Proxmox hetesben, zfs mirrorban két ssd -t  fioval itegnap iostat szerint 100 % utilitire terheltem,  await et elfelejtettem megnézni, de nem történt semmi különös.  Lefagyás nem volt.

https://blog.claryel.hu

Egy hivatalos Dell Gold partner-től vettük, elmondtuk az igényeket megmutatva az akkori infrastruktúrát. Ezt javasolták annyi hogy azóta vettük bele +4 db HDD-t természetesen ugyan olyat ami bent volt.

Az eredeti konfigurációt ők rakták össze és amúgy 1-2 VM futott rajt nem volt észrevehető a hiba mikor felraktuk a 15 vm-et kb akkor jött elő ez a hiba. 

Most nem tudok tesztet csinálni mert gyári resetet csináltuk újra építettük a tömböt, hátha valami olyan bug van ami fw hiba. Storage HDD SSD-n a legfrissebb firmware van. 

Egy hibát viszont észrevettem amiben bízok hogy ez volt. Aki csinálta valamiért /16 tartományba vette fel az IP címeket ISCSI interfészen és ezt csak most vettem észre és persze a tartományok egymásba csúsztak. Lehet nem ez volt a hiba de az egyetlen egy olyan kapaszkodó jelenleg amiben bízok. Majd pár napon belül amint lesz rá idő vissza rakjuk PVE-re a storage-t és meglátjuk, hogy ez volt e vagy sem.

Mindket vegen vagy csak storage oldalon volt atlapolodo subnetek?

Mert ezzel az lehetett a gond, hogy IP kommunikacioban ugralhatott a kimeno NIC, ami egyreszt "martian packet"-hez vezet (amit a kernelek eloszeretettel eldobnak -> TCP retransmission), masreszt nem az ALUA preferred path szerinti kontroller kaphatta meg az IO-t. A volume ownership valtasnak nagy az overheadje (feltetelezem ez nem fullos aktiv-aktiv kontrolleres storage, leven ALUA-s). Ez magyarazhatja azt, hogy alacsony terhelesnel nem tunt fel.

jó találat, az biztosan rossz volt. emiatt eddig a multipath-od teljesen kuka volt, ha ezt átírod akkor jó lesz. 

azért vö. korábbi kijelentés: "multipath-t kipróbáltuk, teljesen jó ..." 

és persze sajnos a sustained iops ettől nem lesz jobb, de mondjuk a menedzsment interfész nem fog leakadni.

Tekintve, hogy iSCSI target, szerintem emiatt nem ment félre (initiator kezdeményezi a kapcsolatot, ha ott jó a maszk akkor nem fogja máshol keresni a targetet), illetve az útvonalak is szakadoztak volna, ha ellenőriztétek a multipath-t, ez előjött volna. De rend a lelke mindennek, nyilván legyen jó a maszk.

Nekem sokkal gyanúsabb ez az ALUA round-robin 2 kapcsolaton...

Fentebb írta h 256G van benne. Saccra az egész filesystem metadata memóriában van, nem csoda hogy pörög.

Itthon is mióta a fing kis NASomban kicseréltem az NVMe cache ssd-ket 32-ről 512-re azóta nagyjából minden ami "ma-tegnap" volt plusz az összes metadata NVMe-n van, tök mindegy mit szarakodnak a diszkek a háttérben :)