Gluster RDMA

 ( VincentV | 2019. május 8., szerda - 11:29 )

Glusterfs volume-ot szeretnék RDMA (RoCE) transporttal összehozni, de nem akar működni. Két host-os tesztrendszer van jelenleg, mindkettőben 1-1 Mellanox kártya (ConnectX-3 EN MCX314A-BCBT). Switchen a pfc config oké, de amúgy tesztelek direkt linkkel is. Firmwarek frissek, OFED driver szintén, up2date Centos 7.6 mindkét gépen (selinux és firewall kikapcsolva).

RDMA tesztek:

# rping -c -a $server_address -C 3 -v
ping data: rdma-ping-0: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqr
ping data: rdma-ping-1: BCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrs
ping data: rdma-ping-2: CDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrst
client DISCONNECT EVENT...

# ib_send_bw -d mlx4_0 -i 1 -F --report_gbits 10.11.12.221
---------------------------------------------------------------------------------------
Send BW Test
Dual-port : OFF Device : mlx4_0
Number of qps : 1 Transport type : IB
Connection type : RC Using SRQ : OFF
TX depth : 128
CQ Moderation : 100
Mtu : 2048[B]
Link type : Ethernet
GID index : 1
Max inline data : 0[B]
rdma_cm QPs : OFF
Data ex. method : Ethernet
---------------------------------------------------------------------------------------
local address: LID 0000 QPN 0x022f PSN 0x45e802
GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:11:12:222
remote address: LID 0000 QPN 0x12c7 PSN 0xda3203
GID: 00:00:00:00:00:00:00:00:00:00:255:255:10:11:12:221
---------------------------------------------------------------------------------------
#bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps]
65536 1000 38.05 38.05 0.072569
---------------------------------------------------------------------------------------

Ezek alapján nekem a RoCE működőnek tűnik.

Gluster:

Glusterfs 6.1, "centos-release-gluster" repo-ból.


# gluster peer probe host2
peer probe: success.

(A "host2" host megfelelően feloldható, a hozzá tartozó forgalom a Mellanoxon megy, gluster peer status kimenete mindkét oldalon ok.)


# gluster volume create gvol0 replica 2 transport rdma host1:/data/nvme1n1 host1:/data/nvme2n1 host1:/data/nvme3n1 host1:/data/nvme4n1 host2:/data/nvme1n1 host2:/data/nvme2n1 host2:/data/nvme3n1 host2:/data/nvme4n1 force
volume create: gvol0: success: please start the volume to access data

Eddig jó, innét jön a baj:


# gluster volume start gvol0
Connection failed. Please check if gluster daemon is operational.

Majd mindkét oldalon crashel a gluster, amíg kézzel nem gyomlálom ki a volume-ot. Releváns glusterd.log részlet itt: pastebin

Eközben a glustershd.log-ban folyamatosan ezt látom:


[2019-05-08 09:27:32.910465] W [MSGID: 103071] [rdma.c:1277:gf_rdma_cm_event_handler] 0-gvol0-client-5: cma event RDMA_CM_EVENT_REJECTED, error 8 (me:$local_ip:49151 peer:$remote_ip:24008)

Ami nyilván érthető, hiszen elcrashelt a process, így a megadott porton nem figyel semmi.

Én rontok el valamit, vagy mehet egy bugreport?

TCP-n oké minden amúgy.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ugyan kibicelek, de...
"signal received: 11"
A 11 szignál a segmentation fault, ilyet jó érzésű program nem csinál. --> mehet a bugreport.

Fene se tudta, azért csak ott van pár custom kernel-modul (OFED driver), meg egyebek, szóval csak a sig11 miatt nem voltam benne biztos , gondoltam megkérdezem, hátha más is belefutott. De amúgy azóta kipróbáltam 5-ös Glusterrel, és ott "jól" megy, szóval reportolom majd.

Btw "jól" megy: nyilván nem várok a ib_send_bw -nél látható értéket (38Gbit), de egyszerűen nem tudok a kétlábú Glusterből 8-12Gbit-nél többet kihozni, egy szintén 40G-n kapcsolódó 3. node-ról. Nagy méretű file-ok szekvenciális írása és olvasása a cél, fio-val ennek megfelelő workloadot generálok. A két gluster node-ban 2-2 db Mellanox van, szóval a frontend (jelenleg benchmark) és a backend forgalom nem bántják egymást.

CPU-ból nem fogy ki, iowait nincs, ram van bőven, és mindkét node-ban van 4db nvme ssd. Fio szerint az átlag latancy egy 500GB-s írás teszt alatt 1 ms alatti. Teszt jelleggel kipróbáltam, hogy berakok 8db-ot egy node-ba, és Gluster nélkül egy sw raid0 tömbbe rendezem őket. Így ugyanazokat a fio méréseket lefuttatva 12-15 GByte/s-t kaptam local írásban és olvasásban is. A fio futtatása közben a másik node-ról indítottam iperf és ib_send_bw teszteket, 35-39Gbit lett az eredmény, tehát azt sem mondanám hogy valahol a pci-e busz környékén van bottleneck.

Tettem még kitérőt ezzel a Gluster nélküli block device-al, pl. kiexportáltam nfs-en, majd iscsi-n. Valamivel jobb lett a helyzet, de nem sokkal. NFS-en el tudtam menni mindenféle tcp stack tweak-ekkel úgy 20Gbps-ig, de sejtésem szerint egy real world tesztnél (pl. file másolásnál) ez se ennyi lett volna (nem néztem még meg).

Szóval a fentiek alapján nem hinném, hogy a Gluster miatt lenne lassú, de kíváncsi lennék rá, hogy akkor mégis mitől, szóval bármilyen ötletet szívesen fogadok.

pedig de.
2x100Gbit es IB-n se tudtam kiszedni belőle az igért kapacitást. Ellenben minnél több volt a node, annál jobb lett a kapott sebesség. Valamint amit kipróbáltam, hogy egy gluster-mount pontra kezdtem írni több nagy fájlt (több szálon).

A szál kb 2-3Gbit -en mozgott, és 10-12 szálig ezt tartotta is (így lett 10x3 vagyis 30Gbps.
6 node, node-onként 8 db 4GB -os SATA-SSD JBOD mode-ban. Igaz mindez dispersed volume-on készült.

Az egész nagy adatbázis mentéséhez készült, ahol is több szálon szerették volna elosztott tárra másolni.

Viszont nálam gluster nélkül is elvérzik, nfs-en és smb-n sem tudtam 8-10Gbit-nél többet kicsikarni, mindezt fio-val, 8-16 szálon mérve (illetve nfs esetén el tudtam jutni 20Gbit-ig, ha úgy tekertem a fio-t, de az elég szintetikus volt).

A több szálat úgy érted, hogy több fizikai kliensről mérted, vagy 1db 100G-s kliensen indítottál több másolást?

Amúgy azzal is tisztában vagyok, hogy a Gluster és a Ceph is akkor mutatja ki a foga fehérjét, ha minél több node-ra van szétterítve az írás/olvasás. Tud valaki esetleg olyan megoldásról, ami két node esetén is képes legalább 20-25Gbps-t kihozni az nvme-kből? A cél valamiféle RAID1 vagy RAID10 szerű működés lenne a 2x4 nvme ssd-vel, hálózaton, és ahogy írtam is: nagy file-okat szeretnék szekvenciálisan írni/olvasni.

Mennyi is a latencyd? Mennyi a readahead? Ezekből elég jól kiszámolható a max. elérhető throughput (readahead * szálak száma / latency az elméletben kihozható max.)

Holnap ránézek, mert most nem érem el, és csak fejből írnék értékeket, amiket ilyen összefüggésben ráadásul nem vizsgáltam (ezért köszi is a tippet).

egy gépről másoltam, de 10 különbözö fájlt írtam. Itt olyanok is beleszámítottak, hogy ki kellett kapcsolni (a 100G-hez) a BIOS nyújtotta összes "intelligens" energiamegtakarítási lehetőséget, a gépet gyakorlatilag max-ra kellett pörgetni.