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!
- 708 megtekintés
Hozzászólások
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.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Switchen és direkt kapcsolaton is ugyanaz a helyzet?
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Í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?
- A hozzászóláshoz be kell jelentkezni
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.
Azert csak nem olyan buta a cache benne, hogy csak LRU-t tud.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Szerintem erdemes korulnezni a TCP Delayed Ack es az iSCSI Queue Depth beallitasok korul.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni