Gluster RDMA

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.