【更新SPDK NVMe-oF测试】爆炸的NVMf性能，SMB / NFS /NVMf 不严谨的性能比较

Dolfin · 发表于 2024-4-17 16:06

本帖最后由 Dolfin 于 2024-4-19 00:33 编辑

4月19日更新
截屏2024-04-19 00.27.18.png

SPDK NVMe-oF Target 服务端分配了4个核心，以上IO测试结果为单客户端 100GbE 连接，挂载后使用FiO测试。

原文

NAS 从Windows Server 切到了 Ubuntu Server，顺手就去试试NFS / NVMe-oF / Samba，跑一遍搭建再做些不那么严谨的IO测试。

SMB：之前用的 KSMBD，一个内核空间的服务，支持RDMA Direct，能跑满100GbE，不过 4K 随机读写差强人意，倒是关了RDMA后提升不少，深队列能超过70万的IOPS。这次试试Samba，不管是顺序还是随机，垮的不行。当然，没做什么优化配置，可能还有提升空间。

NFS：简单配置了一下，开启了 NFSoRDMA，local_lock=none，async，rsize wsize 1M，内核参数sunrpc.rdma_slot_table_entries和nfs线程数也都上了128，其他默认没动。顺序读写和CPU占有率都蛮惊艳，不过4k随机 IOPS 20万到头了，还是不够满意。

NVMe-oF：单客户端顺序读11.5 GB/s，和最大 220万的IOPS没什么说的了，CPU占有率还低，这玩意真爆炸。

测试环境

服务端：9800X / 128GB DDR4 / ConnectX 4 100GbE / PM1733 960GB *5 RAID0 （Mdadm) / Ubuntu Server 23.10
客户端：7945HX / 16G DDR5 / ConnectX 4 100GbE / Ubuntu Server 23.10

测试方法

客户端分别通过 SMB / NFS / NVMf 挂载服务端空间，使用 Fio 3.35 进行1M 顺序读及 4K 随机读测试，顺序使用Q2T4，随机使用Q32T32来跑满 100GbE 网络，测试文件大小1GB，直接IO读写。

测试结果

Screenshot 2024-04-17 at 15.27.30.png

其他想法

1.到底有没有可以单客户端随机读写上100万IOPS的网络文件存储方案？NFS应该是没戏了，跟服务器的通信交互太多，深目录/小文件情况更甚; 只能寄托在SMB上了，Windows间的SMB 4k 可以到50-60万，KSMBD 跑出过70万，再高就没见过了。其他开源方案应该也达不到，商业的weka（每年每TB费用几千块），估计也就五六十万IOPS的样子。

2.网络块存储上，NVMe-oF 确实厉害，后面试试Graid的方案（内核空间），或者SPDK方案（用户空间），看看还会有什么不一样。

mosigan · 发表于 2024-4-17 21:42

本帖最后由 mosigan 于 2024-4-17 21:45 编辑

ksmbd，nvme of方向不一样，希望ksmbd和bcache fs能早日转正

goat · 发表于 2024-4-17 21:58

weka毙了的话ceph估计一样？
不过这俩最起码得3台起步了吧

赫敏 · 发表于 2024-4-17 22:03

文件系统单机破百万iops应该没有，都卡在百万的门口无论开源还是商业

但如果只是底层性能DPU轻松破百万，两百万，可以做到跟local差不多
https://www.storagereview.com/re ... -to-the-data-center

Dolfin · 发表于 2024-4-17 22:57

赫敏发表于 2024-4-17 22:03
文件系统单机破百万iops应该没有，都卡在百万的门口无论开源还是商业

但如果只是底层性能DPU轻松破百万， ...

Fungible 客户端 Raw卷4k randread iodepth=4 –numjobs=6能上 200万iops还是很漂亮的，这么低的队列深度。

不过没有一站方案提升io性能的话，只单换一张Bluefield，那该让那颗ARM做点什么？

Dolfin · 发表于 2024-4-17 22:58

goat 发表于 2024-4-17 21:58
weka毙了的话ceph估计一样？
不过这俩最起码得3台起步了吧

weka现在得6台了

Dolfin · 发表于 2024-4-17 23:11

mosigan 发表于 2024-4-17 21:42
ksmbd，nvme of方向不一样，希望ksmbd和bcache fs能早日转正

确实这两个都已经被收编了，很看好ksmbd和samba的合并。

brucelee1126 · 发表于 2024-4-18 00:00

完全看不懂，我感觉我用了个假局域网

赫敏 · 发表于 2024-4-18 01:37

Dolfin 发表于 2024-4-17 09:57
Fungible 客户端 Raw卷4k randread iodepth=4 –numjobs=6能上 200万iops还是很漂亮的，这么低的队列深度 ...

bluefield的那几个arm应该跑自身的固件就占满了

summerq · 发表于 2024-4-18 03:10

你需求这么高，可以换个方向，考虑nvmeof plus multi targets。starwind有一些商业解决方案，是nvmeof plus spdk，具体在这里。
https://www.starwindsoftware.com/resource-library/starwind-nvme-of-initiator-creating-microsoft-failover-cluster-with-windows-server/

summerq · 发表于 2024-4-18 03:13

summerq 发表于 2024-4-18 03:10
你需求这么高，可以换个方向，考虑nvmeof plus multi targets。starwind有一些商业解决方案，是nvmeof plus ...

哦这个可能不行。这个还属于备份方案。很抱歉

赫敏 · 发表于 2024-4-18 04:21

summerq 发表于 2024-4-17 14:10
你需求这么高，可以换个方向，考虑nvmeof plus multi targets。starwind有一些商业解决方案，是nvmeof plus ...

啊？？下一步安装sql server

Dolfin · 发表于 2024-4-18 09:36

summerq 发表于 2024-4-18 03:10
你需求这么高，可以换个方向，考虑nvmeof plus multi targets。starwind有一些商业解决方案，是nvmeof plus ...

nvmf 多路径倒是个增加IO性能的方式，还能减少单点连接故障。Starwind那个nvmf initiator应该是现在Windows下唯一的 initiator，之前我在 Windows Server 下用他们的 Vsan + initiator 搞出来了 Win 下的 NVMe-oF，不过性能一般，回头我换了 Vsan，改成 Linux SPDK target再尝试一下，看看有没有提升。

summerq · 发表于 2024-4-18 10:24

赫敏发表于 2024-4-18 04:21
啊？？下一步安装sql server

哈哈确实。starwind的方案就是怎么贵怎么来

tasagapro · 发表于 2024-4-18 17:00

NVMEoF是块存储协议。。不能直接比吧

Dolfin · 发表于 2024-4-19 00:33

tasagapro 发表于 2024-4-18 17:00
NVMEoF是块存储协议。。不能直接比吧

顺道测一下

stepw · 发表于 2024-4-23 16:18

用NVMe-oF在WIN下面效率很差，Linux下会提高不少。
你可以把你的测试用例放出看看吗？
文件系统的测试，你用什么工具？
文件系统的测试个块存储不一样的，文件创建、删除、重命名等。
这跟块存储测试差距很大。

Dolfin · 发表于 2024-4-23 20:10

stepw 发表于 2024-4-23 16:18
用NVMe-oF在WIN下面效率很差，Linux下会提高不少。
你可以把你的测试用例放出看看吗？
文件系统的测试，你 ...

存储端/客户端（1机）点对点 CX4 单口 100GbE连接，

Kernel 版本 6.5.0-28-generic，文件系统 XFS

FIO 3.35

测试参数：

顺序读写：
--rw=read（or write) --bs=2M --iodepth=1（or 2） --direct=1 --name=fiotest --ioengine=io_uring --thread --group_reporting --numjobs=1(or 2) --size=1G --runtime=20 --time_based

随机读写
--rw=randread（or randwrite) --refill_buffers --norandommap --randrepeat=0 --invalidate=1 --time_based --ioengine=io_uring --thread --group_reporting --direct=1 --bs=4k --iodepth=1(or 32 )--numjobs=1(or 32) --size=1G --runtime=20

stepw · 发表于 2024-4-25 11:56

Dolfin 发表于 2024-4-23 20:10
存储端/客户端（1机）点对点 CX4 单口 100GbE连接，

Kernel 版本 6.5.0-28-generic，文件系统 XFS

你用的FIO测试，不涉及文件元数据操作，就是文件读写，你的CPU是16core，可以试试关闭超线程，在高IO负载下，只要保证单core包满就行了，超线程是负作用。建议你先用单个job，修改深度，监控CPU的单core，找到一个最大值，并且能把单core跑满，然后再修改单job数量，让整个CPU的core全跑满。服务端同样要注意CPU的单core，服务端和客户端都建议吃满所有的core。

Dolfin · 发表于 2024-4-30 16:39

stepw 发表于 2024-4-25 11:56
你用的FIO测试，不涉及文件元数据操作，就是文件读写，你的CPU是16core，可以试试关闭超线程，在高IO负载 ...

客户端单core跑满的测试（Windows客户端），是在StarNVMeoF_Ctrl.exe insert
<target_ip_addr[:port]> <local_ip_addr> <SubNQN> <HostNQN> [<num_io_queues>
<io_queue_depth> <first_core>调节最后这个参数定到最后一个core上吗？

另外你的Win下性能表现如何？

账号		自动登录	找回密码
密码			加入我们

[存储] 【更新SPDK NVMe-oF测试】爆炸的NVMf性能，SMB / NFS /NVMf 不严谨的性能比较

评分