ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Mellanox InfiniBand期货行情低延迟方案:RDMA与IPoIB选型及性能调优

Mellanox InfiniBand期货行情低延迟方案:RDMA与IPoIB选型及性能调优 简介这份PDF文档面向期货及金融交易系统的架构师、运维工程师与量化团队聚焦如何借助InfiniBand高性能互连技术降低交易延迟、提升并发能力与运行稳定性。文档系统梳理了InfiniBand技术概述、交易系统延迟优化、RDMA与IPoIB技术原理以及可扩展性与服务器兼容性等核心内容并说明该方案可与IBM、HP、DELL、浪潮、曙光、联想等厂商服务器集成满足不同规模期货公司对低延时、高并发的需求。资源包共1个PDF文件大小约2.56MB内容以方案说明与架构介绍为主便于快速通读与内部技术分享。目前已有239人学习下载。读者可从中获取交易系统延时降低90%以上的实现思路、RDMA与IPoIB版本交易软件的适配要点以及稳定性、易维护与易扩展的部署参考适合作为金融低延迟网络方案选型与落地的技术资料。1. 从一份“Mellanox期货行业InfiniBand解决方案”说起低延迟行情链路到底卡在哪如果你在期货公司做交易系统或机房运维大概率听过一个说法行情从交易所出来到策略进程收到中间每多一跳就多一份被对手抢跑的风险。这份名为“Mellanox期货行业InfiniBand解决方案”的材料讲的正是用 Mellanox 网卡加 InfiniBand 组网把行情分发和交易指令这条链路的延迟压到微秒级。它解决的不是“网络能不能通”而是“通得够不够快、够不够稳”。适合两类人看一类是正在做期货极速交易柜台、行情网关的工程师另一类是手里已经有 ConnectX 系列网卡、想搞清楚 RDMA 和 IPoIB 到底怎么选的基础设施同学。先把结论放前面InfiniBand 在这类场景里的价值主要来自 RDMA 的零拷贝和内核旁路而不是单纯的高带宽。2. InfiniBand 与 RDMA 在期货行情链路里的真实定位2.1 为什么期货行情分发会盯上 RDMA期货行情有一个很反直觉的特点单条行情报文很小通常几十到几百字节但每秒条数极高而且对“最新一笔”的到达时间极其敏感。传统 TCP/IP 路径下数据从网卡到用户态要经过内核协议栈、多次内存拷贝和中断处理单程延迟容易到几十微秒抖动还大。RDMA 的思路是把网卡直接暴露给用户态进程发送和接收都绕过内核数据直接从应用缓冲区 DMA 到对端缓冲区省掉拷贝和上下文切换。Mellanox 的 ConnectX 系列网卡是这套方案里最常见的硬件配合 InfiniBand 交换机组成独立的低延迟网络。这里要区分两个概念InfiniBand 是链路层协议RDMA 是这套链路上跑的传输能力。你可以把 InfiniBand 理解成一条专用高速路RDMA 是路上允许你直接开进对方仓库的通行证。期货行业选它核心诉求是确定性——延迟低是一方面更关键的是抖动小行情尖峰时不会因为内核调度而排队。2.2 IPoIB、RoCE 和原生 RDMA 怎么选实际落地时摆在面前的路不止一条。IPoIB 是把 InfiniBand 网络模拟成 IP 网络应用不用改代码就能跑代价是多一层封装延迟比原生 RDMA 高。RoCE 是在以太网上跑 RDMA好处是能复用现有以太网运维体系但对交换机 PFC、ECN 配置要求高配不好就容易丢包重传。原生 RDMA 也就是 verbs 编程性能最好但应用要改。方案是否改应用延迟水平运维复杂度适用场景IPoIB不改较高低快速验证、非核心链路RoCE v2少量改中高已有以太网、想逐步上 RDMA原生 RDMA需改最低中行情网关、极速柜台我一般建议先用 IPoIB 把网络连通性和基本延迟测出来确认硬件和交换机没问题再决定核心链路要不要上原生 verbs。别一上来就改代码否则网络和应用的锅分不清。2.3 最小验证用 ibstat 和 ib_send_bw 确认链路可用拿到机器后第一步不是写代码是确认 IB 链路真的起来了。下面这几条命令是我每次上架必跑的。# 查看 IB 设备状态State 应为 ActiveRate 看链路速率 ibstat # 查看端口信息确认链路层是 InfiniBand 还是 Ethernet ibv_devinfo # 服务端启动带宽测试等待客户端连接 ib_send_bw -d mlx5_0 -a # 客户端连接服务端并跑双向带宽 ib_send_bw -d mlx5_0 -a server_ipibstat里重点看 State 和 Physical state两个都必须是 Active如果停在 Init 或 Down先查线缆和子网管理器。ib_send_bw的-d指定设备名-a表示跑所有测试类型。带宽数字本身不是重点重点是延迟测试ib_send_lat那个才反映行情链路的真实水平。如果ibstat根本看不到设备多半是驱动没装或卡没被识别先解决这个再谈调优。3. 从零搭一套可复现的 InfiniBand 行情分发环境3.1 硬件与驱动准备Mellanox OFED 和固件版本对齐Mellanox 网卡对驱动和固件版本比较敏感版本不匹配会出现链路能起但性能异常的情况。常见做法是装 MLNX_OFED它自带 verbs 库、诊断工具和内核模块。装之前先确认系统内核版本OFED 对内核有支持范围太新的内核可能没有预编译包。# 查看网卡固件版本 mstflint -d 0000:03:00.0 q # 安装 MLNX_OFED 后检查版本 ofed_info -s # 查看 RDMA 设备列表 ibv_devicesmstflint的-d后面跟 PCI 地址可以用lspci | grep Mellanox查到。固件升级用mstflint -d pci -i fw.bin burn但生产环境升级前一定要在测试机验证固件刷坏只能返厂。ofed_info -s输出的是 OFED 版本号和固件版本要对照 Mellanox 的兼容性矩阵看别凭感觉。3.2 子网管理器与 IPoIB 配置让网络先通起来InfiniBand 网络需要一个子网管理器来分配 LID 和路由交换机通常自带如果没有就要在某一台主机上跑 opensm。IPoIB 则是在 IB 链路上再起一个 IP 接口方便先用 ping 和 iperf 验证。# 启动子网管理器如果交换机没开 opensm -g 0xport_guid # 查看 IPoIB 接口通常是 ib0 ip link show ib0 # 给 ib0 配 IP ip addr add 10.10.10.1/24 dev ib0 ip link set ib0 up # 对端配好后再 ping 验证 ping -c 4 10.10.10.2opensm的-g指定端口 GUID用ibstat能看到。IPoIB 接口默认是 datagram 模式MTU 较小可以改成 connected 模式提升性能命令是echo connected /sys/class/net/ib0/mode。注意 connected 模式会占用更多资源节点多的时候要评估。ping 通只说明 IP 层通了不代表 RDMA 层没问题后面还要用 perf 工具单独测。3.3 用 perftest 测出真实延迟和带宽perftest 是验证 RDMA 性能的标准工具集ib_send_lat测延迟ib_send_bw测带宽。期货行情更关心延迟所以重点看ib_send_lat的小包结果。# 服务端监听等待客户端 ib_send_lat -d mlx5_0 -i 1 -s 64 -n 10000 # 客户端连接并测试 64 字节小包延迟 ib_send_lat -d mlx5_0 -i 1 -s 64 -n 10000 server_ip-s 64表示报文大小 64 字节贴近行情报文量级-n 10000是迭代次数次数太少结果不稳。输出里的 t_avg 是平均延迟t_max 是最大延迟后者对交易系统更重要抖动大说明网络或主机有干扰。如果延迟明显高于同硬件同配置的预期先查 CPU 频率调节和中断亲和性别急着怀疑网卡。4. 避坑与排查InfiniBand 落地时最容易翻车的几件事4.1 链路显示 Active 但 RDMA 通信失败现象ibstat显示 ActiveIPoIB 也能 ping 通但 verbs 程序连接超时或报错。原因通常是子网管理器没正常运行或者两端 LID 分配异常。解决用ibstat确认 LID 是否有效sminfo查看 SM 状态必要时重启 opensm。如果 SM 在交换机上检查交换机配置。4.2 延迟忽高忽低t_max 异常大现象ib_send_lat平均延迟正常但最大值比平均值高一个数量级。原因多半是 CPU 频率调节或中断处理干扰。解决把测试进程绑核关闭 CPU 节能命令是cpupower frequency-set -g performance再用taskset绑核。另外确认没有其他进程在抢网卡。4.3 固件和 OFED 版本不匹配导致性能打折现象链路速率显示正常但带宽只有预期一半。原因可能是固件版本过旧或者 OFED 与内核模块不匹配。解决对照 Mellanox 兼容性矩阵升级固件和 OFED 到匹配版本。升级前记录当前版本方便回退。4.4 IPoIB 模式选错性能上不去现象用 IPoIB 跑行情延迟比预期高很多。原因是默认 datagram 模式 MTU 小、开销大。解决切到 connected 模式echo connected /sys/class/net/ib0/mode同时把 MTU 调大。但 connected 模式在节点多时会消耗更多内存和交换机资源要权衡。4.5 多网卡场景下设备选错现象机器有多张 Mellanox 卡程序跑起来延迟不对。原因是程序默认选了第一张卡而那张卡连的不是低延迟网络。解决在代码或配置里显式指定设备名用ibv_devices列出所有设备确认哪张卡对应哪个网络。测试时用-d参数指定别依赖默认。5. 进阶技巧把 RDMA 延迟再压一压的几个实操手段前面把链路跑通了接下来是抠细节。第一个手段是中断亲和性绑定。RDMA 网卡的中断如果落在同一个核上高负载时会成为瓶颈。用cat /proc/interrupts | grep mlx5找到中断号把对应中断绑到和业务进程不同的核上减少争抢。第二个手段是内存注册优化。verbs 编程里ibv_reg_mr注册内存是有开销的行情场景下建议预注册固定缓冲区避免在热路径里反复注册和注销。第三个手段是选对传输模式。RDMA 有 RC、UC、UD 几种RC 可靠但连接管理开销大UD 无连接但报文有 MTU 限制。行情分发常用 UD 做组播式分发交易指令用 RC 保可靠。这个选择没有标准答案要看你的行情网关架构。第四个手段是监控。perfquery能看端口计数器ibdiagnet能做全网诊断定期跑一遍能提前发现线缆劣化或误码。# 查看端口错误计数器重点看 symbol_error 和 link_error perfquery -x 1 # 全网诊断输出报告到当前目录 ibdiagnet -o ./ibdiag_outperfquery的-x是循环刷新间隔秒数自己定。计数器持续增长说明物理层有问题先换线缆。ibdiagnet输出内容多重点看 link 相关的告警。最后说个我自己的习惯每次调整完参数一定用ib_send_lat重测一遍并且记录 t_avg 和 t_max 两个值。只看平均值会被抖动骗过去交易系统里最怕的就是那个偶尔冒出来的大延迟。这套东西不难难的是耐心把每个环节都验证到位。希望帮到你。本文还有配套的精品资源点击获取
返回列表