Disk test utility full-duplex

Merevlemezek, vezérlők

Sziasztok!

Szükségünk lenne nagy kapacitású és sebességű disk rendszerre. Fontos, hogy full-duplex kell, írás és olvasás a disk más részeiről egyszerre kell menjen.
Ezt a hdd-k még csak korlátozottan tudják csinálni, de az SSD-k nel ez mar jobban megy.
Ezt a SATA interface nem támogatja, az csak half-duplex, de a SAS interface már igen.

Ezért kellene egy olyan test program,amivel ez tesztelhető, hogy az elmélet a gyakorlatban is úgy működik-e?
Az adott SAS diszk+vezérlője tényleg tudja-e full-duplex működést.

Tudtok ilyen tesztelő programról? Google-n nem leltem.

  • 850 megtekintés

"Ha lemez rendszerre gondolsz akkor miért számít egyáltalán, hogy hogy oldja meg?"

Gondolom cache-sel játszanak  a lemez rendszerek, de itt ez elvérezne. Ismerve a megrendelőt, nagy méretű mérés adatgyűjtés és feldolgozás megy majd rajta, ahol hamar kifutnak a cache-ből és oda a performancia javító trükk.

Egyáltalán nem. Párhuzamosan tolják az adatokat több lemezre, olvasásnál ugyanúgy. A cache csak simítja a dolgokat.

Nagyon kéne itt tudnod, hogy mekkora adatmennyiségről van szó, mekkora átvitel, mennyi IOPS és mindjárt alakul a dolog. Olyan amit te szeretnél szerintem nincs, de nem is így kell megfogalmazni a kérdést.

( ggallo | 2023. 12. 12., k – 11:45 )

Mivel minden háttértár eszköz szekvenciálisan dolgozza fel a queue-ba érkező csinálnivalót, én nem igazán látom, hogy lesz valóban párhuzamos olvasás és írás akármilyen csatolóval is...

Egy ilyen feladatot szerintem nem így kell megközelíteni, hogy keresünk valami spéci hardvert és várjuk a csodát. Kellenek az elvárások a megrendelő részéről, és arra lehet tervezni/választani hardver-szoftver megoldást, ami az elvárást hozza vagy túlteljesíti.

Milyen IOPS igény van, mekkora blokkméret mellett? Milyen sávszélességen kapcsolódik a hálózathoz a tároló, azon milyen ütemezéssel érkezik a mennyi adat? Mennyi kliensről milyen ütemezésben olvassák vissza a tárolt adatot egy időben? Csak ez az adatfolyam mozog ki-be a tárolóról, vagy teljesen más feladat is lehet induláskor vagy később rábízva (ha már itt ez a drága storage, legyen már rajta a file share is...)? Satöbbi. Ezek a fontos kérdések egy ilyen projektnél, nem az, hogy melyik SAS diszk és vezérlő tud úgy dolgozni, hogy az egyidejűnek tűnjön valami tesztprogram szerint.

"Mivel minden háttértár eszköz szekvenciálisan dolgozza fel a queue-ba érkező csinálnivalót, én nem igazán látom, hogy lesz valóban párhuzamos olvasás és írás akármilyen csatolóval is..."

Ez a fele nekem is új volt, de neten utánanézve, az jött le, hogy valóban szimultán tud írni és olvasni. Ha úgy tetszik, 2 külön queue van SAS interfésznél erre.

Google-n most ezt találtam a témában, ami kicsit magyaráz: https://ciphertex.com/ssd-interfaces-sas-sata-nvme/

"SATA is a half-duplex (one-directional) interface, so it cannot execute read and write functions simultaneously. This can result in serious performance delays, particularly in applications with heavy I/O processing demands. "

"SAS can manage as many as 128 direct point-to-point connections, and its full-duplex capabilities enable simultaneous read and write functionality. "

Hát az, hogy a szabványban mi van, és, hogy az eszközök hogyan valósítják meg, az nem feltétlen fedi mindig egymást. Egy HDD bármilyen csatolóval sem fog szimultán írni meg olvasni különböző szektorokat, de szerintem még a dual aktuátoros újdonságok is csak a szimpla feladatot hajtják végre dupla gyorsan, nem két dolgot csinálnak egy időben.

Ha rendesen van megtervezve a lemez tömb vagy storage cluster (hova mi kell) és az azt kiszolgáló körítés (rétegezett gyorstár olvasásra, írásra), akkor kizárt, hogy számítana, hogy maguk a szóló diszkek full duplexek vagy sem.

Erről jut eszembe:

(David Nieven hallózik a telefonkagylóba,) - Elvágták a telefonvonalat.

- Mit hallottál?

- Azt, hogy NYISSZ!

/Meghívás egy gyilkos vacsorára/

Szóval, ha azt mondod: nyissz, akkor igazad van. Ha figyelembe veszel néhány apróságot, akkor leírhatatlan egy ilyen kis apró nüánsznak a hatása. ;)

ha az interface lenne a speed limit, de éppen nem az

Megint csak szűklátókörű hozzáállás. Ha egy blokkot vizsgálsz, figyelembe véve még a seek stb. késleltetést, akkor igaz. A technológiára pedig az igaz, hogy a mindenkori média sebesség összemérhető az interfész sebességével. Számottevő multitasking terhelésnél a legkisebb előny is számíthat, de a legkisebb botlástól is térdre rogyhat a performancia. Erre lehet elrettentő példa, ha magasan képzett zoftveres nekiáll 65535 vagy 317 bájtos blokkmérettel dolgozni.

Ha tudod hangolni 10-15 paraméterrel a diszk-alrendszert, akkor a duplex sebesség - bár abszolút nem hátrány -, de nem biztos, hogy domináns előnyt jelent.

Szekvenciálisan igen, de egyáltalán nem feltétlenül ugyanabban a sorrendben ahogy beküldted.
Pl. adott "deadline"-on belüli elkészülést ígér, azon belül olyan sorrendben ír-olvas ahogy gondolja.

Ekkor neked "puffertől-pufferig" bizony tök párhuzamosnak fog látszani az írás meg az olvasás: "egyszer csak ott van".

zászló, zászló, szív

readwrite=rw, rwmixread=, rwmixwrite= parameterek az erdekesek.

Tapasztalatom korabban az volt, hogy az SSD-k sem szeretik annyira, ha kevert a terheles. Kb kadgorbe-szeruseg szokott kijonni, ahogy a read/write arany valtozik. A tiszta iras es a tiszta olvasas a legjobb, a ketto kozott romlik az ossz-teljesitmeny. De mondjuk teny, hogy SAS SSD-vel nagyon regen volt dolgom es szerintem azt nem mertem igy.

Régóta vágyok én, az androidok mezonkincsére már!

Gondolkodom rajta, hogy van-e konkretan erre scriptem. Kb valami ilyesmi modon szoktam (fejbol irom, biztos van 1-2 dolog, amit elirtam vagy kihagyok, otthon majd elokeresem, ha nem felejtem el):

for ((WRITERATIO=0;WRITERATIO<=100;WRITERATIO+=10))
do
fio ioengine=libaio direct=true iodepth=1 blocksize=4096 readwrite=rw rwmixread=$((100-WRITERATIO)) rwmixwrite=${WRITERATIO} filename=/dev/nvme0n1 size=128G runtime=60s
done

A size-ot altalaban szandekosan tullovom, hogy a runtime legyen ami meghatarozza, hogy mennyit fut. (Korabban a size-ra mindenfele sajat heurisztikakat csinaltam, hogy ne legyen se tul rovid, se tul hosszu a teszt, aztan egyszer rajottem, hogy a fio-nak erre van beepitett megoldasa :D)

De kb vegtelen szamu teszttel el tudom cseszni az idot, iodepth, blocksize allitgatassal rengeteget lehet varialni es nagyon mas eredmenyek fognak kijonni. Annyi tapasztalatom meg van, hogy (ha jol emlekszem) blocksize=512k felett kezdi a kernel feldarabolni a request-eket, vagyis onnantol olyan, mintha az iodepth-et emelned.

Régóta vágyok én, az androidok mezonkincsére már!

( joco01 v | 2023. 12. 12., k – 19:41 )

Szerintem ezt úgy hívják, hogy implementation detail. Gy.k. semmi közöd hozzá, hogy a diszk hogy oldja meg. Kínálnak egy adott teljesítményt az adatlapon, és ha neked tetszik, vedd meg, ha nem tetszik, ne vedd meg.

Máshogy fogalmazva: Tegyük fel, hogy egyik diszk 100K IOPS-ot támogat a neked kellő workload esetén, és full duplex, és van egy másik diszk, ami 110K IOPS-ot támogat, de nem full duplex. Melyiket veszed meg: a jobb teljesítményűt, vagy a full duplexet? Ha a jobb teljesítményűt, akkor a duplex nem is számít, ugye? Ha a duplexet, akkor elárulod, hogy mit nyertél vele?

Azt gondolom, hogy a SATA/SAS link olyan gyors, hogy nem az lesz a szűk keresztmetszet. Itt inkább arról van szó, hogy ha van egy meghajtó, ami tud X IOPS-ot vagy Gbps-t olvasni, és Y-t írni külön-külön (és X≈Y), mit csinál, ha egyszerre kapja a két terhelést. Egy half duplex drive ekkor X/2 olvasást és Y/2 írást tud, és fürdőkád görbét mutat a teljesítmény, míg full duplex esetben továbbra is X írás és Y olvasás lesz. Ezt gondolom ki lehet mérni bármilyen tesztprogrammal, ha nincs rajta az adatlapon, hogy változtatgatod az írás/olvasás arányát, legalább 0:100, 50:50, és 100:0 esetben. De továbbra is azt gondolom, hogy nem önmagában a duplex viselkedés, hanem a performancia számít. Egy full duplex meghajtó el fogja laposítani a görbét, de a kérdés mégis inkább az, hogy a görbe az adott szint felett legyen azokon a munkapontokon, ahol a valóságban terhelve lesz. És ha azokon a pontokon felette van, akkor mindegy, hogy hogyan görbül, a plusz teljesítmény ajándék és talán nem is lesz kihasználva.

Utálom, amikor a megrendelő lemegy a legaljára. Neki ott van a vége, hogy megmondja, mekkora terhelést fog csinálni, milyen irányokban.
Volt már olyan, hogy a megrendelő a storage-ban kezdett el turkálni (ami egyébként bőven hozta amit kért), hogy szerinte nem OLYAN SZÍNŰ diszk kellene bele, hanem AMOLYAN.
Mi ott akkor dobtuk el messzire a pöttyöst. 

Ha nagy mennyiségű duplex írás kell, akkor az egész rendszert nézze, ne egy adott diszket vagy csatolót.

Ez a kérés, plusz a "látni szeretné" nekem azt sugallja, hogy amolyan műkedvelőként olvasott erről valahol, megtetszett neki, és pénz nem számít alapon olyant venne, csak mutasd meg élőben. Mert ha szakember kérné ezt valami tervezési szempont alapján tőled, akkor azt mondaná, hogy Z gyártó W típusa kell, mert az felel meg a megtervezett modellnek, igénynek. De ez, a "keress ilyen tudásút és bizonyítsd, hogy tudja" nekem sántít...

Engem már nagyon érkelelne az, hogy elolvasta-e bárki (én nem), hogy az alkalmazás, OS, firmware szintjén valóban használva van-e ez a full duplex működés. Mert ugye az vajmi kevés, ha a meghajtó tudja papíron, de az OS szekvenciálisan küldi a tennivalót, amit a FW úgy is hajt végre.

Persze lehet, hogy az OS által queue-ba öntött melót a FW szétválogatja és egyszerre hajtja végre az írásokat és az olvasásokat a valóságban, de ez a mérés szintjén úgy fog jelentkezni, hogy X IOPS írás, Y IOPS olvasás az eredmény. Az meg igazából tök mindegy, hogy ezt a tároló half vagy full duplex csinálta meg, a lényeg, hogy ha X-Y írás-olvasás IOPS-t várunk tőle, azt tudja vagy sem...

Minden esetre mi úgy vállalunk melót, hogy megmondja az ügyfél, hogy mit szeretne elérni, és mi tervezük hozzá rendszert a meglévő tudásunk/ismereteink alapján. Van, amikor (számunkra) újdonságot használunk eközben. de az sohasem ügyfél kérés, hanem funkcionálisan valamiért megyünk az újdonság irányába (és először tesztelünk vele, utána ajánljuk ki azt a megoldást).

( n.balazs v | 2023. 12. 12., k – 23:51 )

Mekkora az a nagy kapacitás és sebesség - ha nem titok?

Én egy kis hibát érzek a teszt létjogosultságában. Ugyanis nagyon félre fog vinni, ha 1 db lemez / SSD teljesítményét akarod összevetni egy 100 lemez / SSD-t tartalmazó enterprise szintű storage-dzsal.
Pl: egy 10 éves EMC VNX 5300-assal tieringben (fast cache SSD 100 GB + SAS lemezek + SATA lemezek) simán tudott 20000 - 25000 IO/sec-t úgy, hogy a storage még bírt volna többet is.

Szerintem egy ilyen tesztet high level szinten kellene lebonyolítani, amikor az adott NAS / SAN megoldást méred le. Továbbá beleveszed a fájlrendszert, hálózatot és egyéb overheadeket. Ha eloszott rendszer (GFS) vagy object storage (pl: Ceph, MinIO, Scality), akkor még tovább bonyolódik a történet.

Másrészt igen, a SAS full duplex. Nem véletlenül képes kétszer akkora IO/sec-re, mint a SATA (durván közelítve). SATA ~90 IO/sec, SAS ~180 IO/sec.

Szerintem.

Csak a példa kedvéért: ha van egy 1TB-os wd black SATA3 csatolóval és SAS12Gbit-es csatolóval is (kapacitás, tányérok száma, fordulatszám mind megegyezik a 2-nél) akkor pusztán csak az eltérő csatoló miatt automatikusan jobb (több) IOPS-t tud a SAS-os változat?

Eltérő csatoló, eltérő firmware szóval valószínűleg igen. A fizikát nem fogja meghazudtolni de egy csomó féle terhelési profilra jobban fog reagálni.
Az az IOPS amit ráírnak a marketing anyagra az az optimális körülmények közötti maximális IOPS. A nagy különbség ott lesz hogy a "nem optimális" körülményekre mennyire szopódik be az adott cucc.

zászló, zászló, szív

Elképzeltem egy olyan meghajtót, aminél a gyár lemérte a legrosszabb körülmények közötti teljesítményt, és utána direkt belassítják, hogy minden körülmény között ugyanazt a teljesítményt hozza. Így pont full duplexnek fog tűnni, mert nem lassul be semmilyen esetben :).

A sata illtve a sas platformok,  nem sebességek. Nem az a helyzet, hogy egyik irányban 100k az iop ,  másik irányban is 100k , akkor 200k-t tud  a lemez, hanem 5 msec a latency egyik irányban, 5 ms másik irányban , összesen marad továbbra is 5 msec a latency. (HDD esetén legyen kb. 5 msec. ) Az meg nagyon sok. Ezért is rossz ötlet a

Fontos, hogy full-duplex kell, írás és olvasás a disk más részeiről egyszerre kell menjen.

Gyakorlatiag ha lenne is szekvenciális írás/olvasás , azt is átalakítod szépen lassabb , random írássá/olvasássá.
Ha sok gyors ssd  kellene ,  akkor  nem elég a sata vezérlő chip alacsony sávszélessége, kellhet a sas, de ez nem 4 -5 hdd  lemez.
Nagyobb sebességhez jobb ssd-t, ahogy gabrielakos írta:

Ebben a speciális esetben egy lokális nvme ssd-vel(legyen akár raid1-ben) sokkal jobban jársz.
 

Az ssd-k között akár két nagyságrend különbség is lehet, nagyon magas iops esetén.  

https://blog.claryel.hu

Amiről még nem beszéltünk az a "hány szálon kell hozni az adott teljesítményt" kérdése.
Nekem volt dolgom enterprise storage-el ami simán hozott több mint 60k IOPS-t (és valószínűleg sokkal többet is), ellátott egy fél bankot.
Na de ezt sok-sok VM-et kiszolgálva jóég tudja hány szálon hozta.

Attól hogy egy adott storage tud mondjuk 60k IOPS-t attól még lehet hogy egy művelet átlagos kiszolgálási ideje 10ms.
Ez a 10ms azt jelenti hogy _egy szálon_ tud 100IOPS-t. Oké, tud 600 szálat full speed kiszolgálni párhuzamosan, szuper.
De ez rajtad nem segít ha mondjuk 2ms alatt szeretnéd az IO-t mindig(!) letudni. Ami ugye elvileg még mindig "csak" 500 IOPS tehát messze van a "marketing határtól".

Ebben a speciális esetben egy lokális nvme ssd-vel(legyen akár raid1-ben) sokkal jobban jársz.
 

zászló, zászló, szív

( gabrielakos v | 2023. 12. 13., sze – 08:36 )

Abban persze egyetértek a többi hozzászólóval hogy ez a kérdés egy rossz irányt sejtet a megrendelő részéről. Vagy nem mondtál el mindent arról amit feladatba kaptál...
Ez az egy kérés "full duplex diszk legyen" egy abszolút low level, elsőre viszonylag felesleges "implementation detail" ahogy valaki írta is fentebb.

A "teljes rendszert kell nézni": azaz kb "tessék itt egy filerendszer endpoint, kínáld meg x írással, lássuk"

zászló, zászló, szív