找回密码
 加入我们
搜索
      
查看: 9860|回复: 30

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

[复制链接]
发表于 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

Screenshot 2024-04-17 at 15.28.21.png

其他想法

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

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

评分

参与人数 1邪恶指数 +10 收起 理由
猪圈 + 10

查看全部评分

发表于 2024-4-17 21:42 | 显示全部楼层
本帖最后由 mosigan 于 2024-4-17 21:45 编辑

ksmbd,nvme of方向不一样,希望ksmbd和bcache fs能早日转正
发表于 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
 楼主| 发表于 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做点什么?
 楼主| 发表于 2024-4-17 22:58 来自手机 | 显示全部楼层
goat 发表于 2024-4-17 21:58
weka毙了的话ceph估计一样?
不过这俩最起码得3台起步了吧

weka现在得6台了
 楼主| 发表于 2024-4-17 23:11 | 显示全部楼层
mosigan 发表于 2024-4-17 21:42
ksmbd,nvme of方向不一样,希望ksmbd和bcache fs能早日转正

确实这两个都已经被收编了,很看好ksmbd和samba的合并。
发表于 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应该跑自身的固件就占满了
发表于 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/
发表于 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
 楼主| 发表于 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再尝试一下,看看有没有提升。
发表于 2024-4-18 10:24 来自手机 | 显示全部楼层
赫敏 发表于 2024-4-18 04:21
啊??下一步安装sql server

哈哈 确实。starwind的方案就是怎么贵怎么来
发表于 2024-4-18 17:00 | 显示全部楼层
NVMEoF是块存储协议。。不能直接比吧
 楼主| 发表于 2024-4-19 00:33 | 显示全部楼层
tasagapro 发表于 2024-4-18 17:00
NVMEoF是块存储协议。。不能直接比吧

顺道测一下
发表于 2024-4-23 16:18 | 显示全部楼层
用NVMe-oF在WIN下面效率很差,Linux下会提高不少。
你可以把你的测试用例放出看看吗?
文件系统的测试,你用什么工具?
文件系统的测试个块存储不一样的,文件创建、删除、重命名等。
这跟块存储测试差距很大。
 楼主| 发表于 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




发表于 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。
 楼主| 发表于 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下性能表现如何?
发表于 2024-7-23 17:57 | 显示全部楼层
SMB:之前用的 KSMBD,一个内核空间的服务,支持RDMA Direct,能跑满100GbE,不过 4K 随机读写差强人意,倒是关了RDMA后提升不少,深队列能超过70万的IOPS。这次试试Samba,不管是顺序还是随机,垮的不行。当然,没做什么优化配置,可能还有提升空间。
samba用户goole进来的,samba不要想啥优化了,全闪也就那样,多客户端还很费CPU。
看来ksmbd值得一试,研究下配ctdb集群。
 楼主| 发表于 2024-7-26 15:16 | 显示全部楼层
icyboy 发表于 2024-7-23 17:57
SMB:之前用的 KSMBD,一个内核空间的服务,支持RDMA Direct,能跑满100GbE,不过 4K 随机读写差强人意,倒 ...

ctdb下的samba没问题,ksmbd也能做吗?后端的集群存储准备用什么?
发表于 2024-7-28 20:09 | 显示全部楼层
FIO 这种测试除了自己看的爽有啥用吗, 自己写个文件系统?
 楼主| 发表于 2024-7-29 00:02 来自手机 | 显示全部楼层
本帖最后由 Dolfin 于 2024-7-29 00:07 编辑
wsbpj 发表于 2024-7-28 20:09
FIO 这种测试除了自己看的爽有啥用吗, 自己写个文件系统?


任何测试除了自己看的爽有啥用吗?自己手搓个电脑?

那你看别人5800X的测试爽吗?看完了自己发个帖?
发表于 2024-7-29 16:51 | 显示全部楼层
本帖最后由 icyboy 于 2024-7-29 16:53 编辑
Dolfin 发表于 2024-7-26 15:16
ctdb下的samba没问题,ksmbd也能做吗?后端的集群存储准备用什么?


查了下ksmbd目前还没法用ctdb,之前samba后端cephfs 2副本 全U.2测试,小文件规模上去了metadata开销太大,性能瓶颈,延迟10ms不到点,又转回ZFS单节点。RBD块设备速度可以,但是samba集群不现实。
最近又看到croit博客上关于cephfs优化,单节点开多个MDS来负载均衡,五个节点开出20个其中一个4 MDS standby其余四个共16 MDS active。当时我测试的时候MDS还只是2 active 1 standby。
等有机会再测试。

评分

参与人数 1邪恶指数 +10 收起 理由
猪圈 + 10 支持一下

查看全部评分

 楼主| 发表于 2024-7-30 09:45 | 显示全部楼层
icyboy 发表于 2024-7-29 16:51
查了下ksmbd目前还没法用ctdb,之前samba后端cephfs 2副本 全U.2测试,小文件规模上去了metadata开销太大 ...

增多mds会对高并发小文件IO有明显提升吗?
发表于 2024-8-1 16:03 | 显示全部楼层
本帖最后由 icyboy 于 2024-8-1 16:11 编辑
Dolfin 发表于 2024-7-30 09:45
增多mds会对高并发小文件IO有明显提升吗?


参考这篇 ceph-performance-test-and-optimization
对cephfs肯定是有帮助的,至少多客户端情况下有提升,通常单个MDS daemon只会用单核心单线程

另外RBD块设备比cephfs快的原因是块设备的metadata操作主要是在客户端那头完成
RBD协议性能也远超iSCSI
参考这篇ceph-on-windows-performance

以下为ceph官方文档
The present version of the MDS is single-threaded and CPU-bound for most activities, including responding to client requests. An MDS under the most aggressive client loads uses about 2 to 3 CPU cores. This is due to the other miscellaneous upkeep threads working in tandem.

Even so, it is recommended that an MDS server be well provisioned with an advanced CPU with sufficient cores. Development is on-going to make better use of available CPU cores in the MDS; it is expected in future versions of Ceph that the MDS server will improve performance by taking advantage of more cores.

When should I use multiple active MDS daemons?

You should configure multiple active MDS daemons when your metadata performance is bottlenecked on the single MDS that runs by default.

Adding more daemons may not increase performance on all workloads. Typically, a
single application running on a single client will not benefit from an increased number of MDS daemons unless the application is doing a lot of metadata operations in parallel.

Workloads that typically benefit from a larger number of active MDS daemons are those with many clients, perhaps working on many separate directories.
 楼主| 发表于 2024-8-2 14:52 | 显示全部楼层
本帖最后由 Dolfin 于 2024-8-2 14:57 编辑
icyboy 发表于 2024-8-1 16:03
参考这篇 ceph-performance-test-and-optimization
对cephfs肯定是有帮助的,至少多客户端情况下有提升, ...


谢谢推荐,ceph在ws上的访问和优化。rbd的表现在ws上的性能确实不错。

顺带看到了Ceph: A Journey to 1 TiB/s 这个文,大为惊艳。

croit 是做什么用的?
发表于 2024-8-3 10:13 | 显示全部楼层
Dolfin 发表于 2024-8-2 14:52
谢谢推荐,ceph在ws上的访问和优化。rbd的表现在ws上的性能确实不错。

顺带看到了Ceph: A Journey to 1  ...

croit是新公司,主要做ceph(docker部署方案) 还有DAOS,自家开发面板,卖技术支订阅持和培训。
Graid的方案(内核空间)这个还有另外一个方案xiRAID,Raidix换名,毛子的东西。
 楼主| 发表于 2024-8-3 13:25 | 显示全部楼层
icyboy 发表于 2024-8-3 10:13
croit是新公司,主要做ceph(docker部署方案) 还有DAOS,自家开发面板,卖技术支订阅持和培训。
Graid的 ...

Graid和xiRAID前面都有了解,一个硬一个软,确实会有更好的性能表现,也都可以作为块分享出去。不过块分享这部分,SPDK NVMF已经可以做的非常好了。

DAOS是很神秘一事,IO500常年霸榜,Croit是给了一个web UI用来运维管理的吗?
一直有个原始的问题,这种分布式或者并行文件系统,只谈性能部分,会比单网络存储服务器性能更好吗,譬如SMB传输要达到100GB/s的顺序读写,千万以上的IOPS
您需要登录后才可以回帖 登录 | 加入我们

本版积分规则

Archiver|手机版|小黑屋|Chiphell ( 沪ICP备12027953号-5 )沪公网备310112100042806 上海市互联网违法与不良信息举报中心

GMT+8, 2025-4-26 17:45 , Processed in 0.015508 second(s), 7 queries , Gzip On, Redis On.

Powered by Discuz! X3.5 Licensed

© 2007-2024 Chiphell.com All rights reserved.

快速回复 返回顶部 返回列表