简介面向数据中心架构师、云平台工程师及虚拟化/网络加速方向学习者的一份技术资料聚焦 NVIDIA BlueField-2 DPU 的架构与解决方案可用于理解以 DPU 卸载网络、存储、安全与基础设施管理负载的思路。压缩包仅含 1 个 PDF约 4.7MB内容以图文幻灯片形式组织便于快速浏览 BlueField-2 的模块框图、Arm 核与加速引擎、ConnectX-6 Dx、PCIe 交换及 DOCA 软件栈等要点。资料还涉及裸金属云、VMware 混合云架构、安全加速与 BlueField 生态对构建“软件定义、硬件加速”的数据中心方案有参考价值。已有 807 人学习适合作为方案调研、技术分享或选型前的概览材料。1. 为什么把安全与存储卸载到 DPU一块芯片替掉 125 个 CPU 核的账一台裸金属服务器交付给租户时最尴尬的往往不是 CPU 不够而是管理面、存储面、安全面三套 agent 加两张网卡先在 16 个核里吃掉 4 个。BlueField-2 DPU 这类基础设施芯片要解决的就是这件事把虚拟化、存储加速、安全加速从主机 CPU 上整体搬走单卡标称可替代 125 个 x86 核的卸载能力5M NVMe IOPS、100 Gbps IPsec、50 Gbps 正则匹配都在卡内完成主机只看到一个“干净”的 PCIe 设备。这套方案适合正在做裸金属云、超融合、边缘安全网关的团队也适合把它当成毕设或课设里“软硬件协同卸载”的完整案例来拆——因为它每一层都有明确的接口和可量化的验收口径。2. 需求边界与选型把「网卡加壳」和「基础设施芯片」分开看很多方案在立项阶段就偏了方向把 DPU 当成“性能更好的智能网卡”于是只把 OVS 挪过去存储和安全仍在主机里跑。真正的分界线在于这块卡上有没有独立的 Arm 子系统、有没有独立的带外管理口、有没有可编程的加速引擎。三者缺一卸载就只卸载了一半。2.1 四类负载先分清网络面、存储面、安全面、管理面做需求梳理时我一般会把主机上所有“不是业务逻辑”的东西列成四张清单逐条判断能不能下沉。网络面包括 vSwitch 转发、overlay 封装解封装、NAT、负载均衡、云网络 ACL。这一层的特征是包处理密集、规则变化频繁适合放进可编程流水线控制面留在 Arm 核上。存储面包括 NVMe-oF 发起端、virtio 后端、压缩去重、静态数据加密特征是 IO 深度大、对延迟敏感适合用硬件队列加轮询模式。安全面包括状态防火墙、深度包检测、IPS/IDS、微隔离、IPsec 加解密特征是流表规模大、单包计算重。管理面包括固件升级、信任根校验、遥测上报、带外控制特征是完全独立于业务数据通路。这四类分完落地形态基本就定了数据面走硬件加速引擎控制面走 Arm 核管理面走独立的 1GbE 带外口。BlueField-2 之所以能把这四层都装进去靠的是 8 个 64 位 Arm A72 核、双 16 路 VLIW 加速引擎和一颗 200 Gbps 的网络引擎被放进同一块 Die。常见的误判是只做网络面。结果 OVS 确实不占主机核了但 virtio-blk 的后端线程、IPsec 的软加密、防火墙的 netfilter 仍在主机里跑软中断照样打满一个核。评审时被问一句“那你主机上还剩什么”就答不上来。提示四张清单里凡是有“每包/每 IO 都要执行一遍”的优先下沉凡是“一天改一次”的留在控制面。2.2 规格怎么对标需求一张表把参数翻译成容量选型阶段最容易犯的错是拿着参数表比大小却不翻译成自己能用的容量。下表是我常用的翻译方式。硬件参数数值对方案的直接含义Arm 子系统8× A72 64 位最高 2.5 GHz四 Tile8 MB L2 6 MB L3卡上可跑完整 Linux 用户态控制面服务不必外挂管理机网络能力200 Gbps 以太网与 InfiniBand支持 NRZ 与 PAM4单口 200G 或双口 100G两种拓扑按机架布线选PCIe集成 PCIe Switch16 lane Gen4 可拆分支持 Root Complex 与 Endpoint 双模既能当加速卡插主机也能自己枚举下游 NVMe带外管理1 GbE Out-of-Band 管理口管理面与数据面物理隔离重装主机不影响卡上策略加速引擎100 Gbps IPsec、50 Gbps RegEx、100 Gbps 视频流转码、5M NVMe IOPS决定安全与存储两条线能不能单卡跑满等效算力替代约 125 个 x86 核机架级 TCO 测算的基准数字厂商给的负载倍数可以作为容量粗算的起点弹性块存储约 2.5 倍、云 overlay 网络约 150 倍、新一代状态防火墙约 8 倍恶意样本模式匹配、视频流、IPsec 加密落在 10 到 50 倍区间。这些数字不是让你直接写进容量规划而是用来判断“值不值得为这条负载上卡”。举个具体的账一台双路 32 核机器网络面占 2 核、存储面占 3 核、安全面占 2 核、管理面占 0.5 核合计 7.5 核接近四分之一。按 200 台规模算被吃掉的算力相当于 50 台整机。这个数拿出来方案的必要性就不用再解释了。2.3 三条否决线什么情况下不该上 DPU第一集群规模太小。低于十个节点时卡上那套控制面、镜像升级、遥测采集的运维成本会盖过收益团队还没攒够经验就先被运维拖住。这种情况一般建议先在测试环境把一条负载跑通再谈规模。第二PCIe 通道已经排满。集成 PCIe Switch 虽然能拆分但整机槽位和 lane 是固定的如果已经有 GPU 直通和专用加速卡占满 x16再插一张需要 x16 的卡就会掉链路宽度性能打折还不如不插。第三团队没有内核态调试能力且平台版本很旧。DOCA 生态能兜住标准场景但涉及 virtio-blk SNAP 的模拟设备路径、OVS 硬件流表下发出问题时仍然要能看 dmesg、看流表、看固件日志。旧版本虚拟化栈对模拟设备的识别也有兼容问题需要提前验证。把这三条写进方案的“适用范围”一节评审时反而更容易过——说明你想清楚了边界而不是拿着产品册做推介。3. 总体架构主机、DPU、控制面三层怎么切职责架构图画得再漂亮落到实现只需要回答三个问题主机看得见什么、卡上跑什么、谁来下发策略。这三个问题答清楚剩下的都是接线和调参。3.1 三层结构与两条数据通路主机层尽量“空”。业务操作系统或虚机里只保留 inbox 驱动网卡侧看到的是 virtio-net 或标准 VF存储侧看到的是模拟出来的 NVMe 或 virtio-blk 设备。主机不知道背后是远端存储还是本机 NVMe也不需要装多路径软件和发起端。这层越薄重装、迁移、快照就越简单。DPU 层是真正的执行体。Arm 上跑一个精简 Linux承载 OVS 转发面、SPDK 轮询驱动、SNAP 模拟框架、状态防火墙和遥测代理。这一层对外只暴露两类接口面向主机的 PCIe 设备面向控制面的管理 API。控制面负责策略与生命周期。编排系统通过带外口下发网络 ACL、存储映射、镜像版本通过带内通道下发流表。控制面不参与每个包的处理只保证策略最终一致。数据通路有两条。快路径走硬件流水线加解密、正则匹配、封装解封装都在加速引擎里完成Arm 核完全不参与这是能跑到 100 Gbps 的前提。慢路径走 Arm 核处理首包、异常包、控制协议和需要查大表的场景。设计时要明确哪些流量允许走慢路径否则一条异常流就能把 Arm 核打满把整机拖垮。3.2 Arm 子系统与加速引擎的分工以及为什么值得按 Tile 绑核Arm 子系统是四个 Tile每个 Tile 两个核带私有 L2四个 Tile 共享 6 MB L3。这个结构决定了绑核不是可选项如果 OVS 的轮询线程和 SPDK 的轮询线程被调度到同一个 Tile它们会在私有 L2 上互相踢表现就是吞吐没掉但长尾延迟抖得厉害。我一般的分配是Tile0 给网络转发Tile1 给存储轮询Tile2 给安全策略与会话表Tile3 留给控制面服务和遥测。这样每类负载的缓存局部性最好出问题时也容易定位是哪一类把核吃满了。# 查看卡上 Arm 核的拓扑与在线状态确认四个 Tile 的核编号分布 lscpu -eCPU,NODE,SOCKET,CORE,ONLINE # 把 OVS 的轮询线程固定在 Tile0 的两个核上掩码 0x3 表示 CPU0、CPU1 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask0x3 # SPDK 侧通过启动参数绑定到 Tile1避免与转发线程抢 L2 # 具体核号按上一条 lscpu 的实际输出替换掩码的写法是按位对应 CPU 编号0x3 就是最低两位。改掩码之后必须重启转发服务才生效热改容易留下没绑定的残留线程这是排查“绑了核却没效果”时最先要看的地方。SPDK 的核绑定在进程启动时确定运行期改不了所以规划核号要在部署前一次做完。3.3 PCIe 拓扑与工作模式Endpoint 还是 Root Complex决定你能接什么16 lane Gen4 可以拆成 x16、x8x8、x4×4拆分方式在固件里配。两种工作模式的差别很大Endpoint 模式下卡是主机的从设备主机枚举到它适合当加速卡Root Complex 模式下卡自己是主设备能枚举下游的 NVMe 盘适合把本地盘接管过来做 SNAP 的本地通路。选错模式的典型表现是主机里根本看不到设备而卡上的系统一切正常。这个时候不要怀疑驱动先看链路和模式。# 主机侧枚举确认加速设备与网口是否被正确识别 lspci -Dnn | grep -i -E processing accelerators|ethernet # 看指定设备的链路状态与 ACS 能力 # ACS 影响直通与 P2P链路速率掉到 Gen3/x8 会直接限制吞吐上限 lspci -vvv -s 0000:3b:00.0 | grep -i -E ACSCtl|LnkStaLnkSta那一行如果显示的是 8GT/s 而不是 16GT/s说明链路协商掉了一档常见原因是插槽本身只支持 Gen3或者金手指、转接卡接触不良。这类问题在实验室很难复现一到批量上架就集中爆发属于典型的部署期问题。ACSCtl里如果 ACS 没开多个 VF 之间的直通隔离会出问题微隔离策略也就形同虚设。4. 三大加速面的落地安全、存储、网络各走一条路三条线的落地顺序有讲究。安全先行因为它决定了信任边界存储其次因为它决定主机侧驱动形态网络最后因为它的策略依赖前两者确定的拓扑。4.1 安全加速把信任根从主机挪到卡上安全这条线的核心不是“加个防火墙”而是把信任根的位置换掉。传统方案里安全策略跑在主机操作系统上主机被攻破策略就被改。把安全控制面放到卡上的独立 Arm 环境里主机只剩数据面改不了策略这就是隔离的意义。实现上分四步走。第一步是硬件信任根与固件签名校验保证卡上跑的是可信镜像升级走带外通道并做回滚保护。第二步是 Arm TrustZone 划出安全世界把密钥、证书、策略库放在里面。第三步是内联加密IPsec 与静态数据加密走硬件流水线主机的加解密开销归零。第四步才是 L4 到 L7 的状态防火墙、深度包检测、主机内省和微隔离。顺序不能反。没有信任根就直接上防火墙等于把策略库放在一个随时可能被改写的地方没有内联加密就先做 DPI包在进出主机时已经被解开过一次检测点就选错了。策略下发我习惯用声明式描述控制面负责编译成流表# 安全策略下发示意字段命名以实际控制面接口为准结构保持一致即可 policy: name: tenant-a-isolation scope: workload # 作用域为工作负载而非主机 direction: both rules: - action: allow proto: tcp port: 443 src: tenant-a-frontend # 允许前端访问后端 dst: tenant-a-backend - action: deny proto: any src: tenant-a-frontend dst: tenant-b-any # 跨租户默认拒绝微隔离的关键一条 crypto: mode: inline # 内联加密走硬件加速引擎 cipher: aes-xts # 静态数据加密算法 rekey_interval: 3600 # 密钥轮换周期秒这份描述的关键在scope和dst。作用域是工作负载而不是主机意味着同一台主机上不同租户的流量也要过策略dst写的是租户标识而不是网段意味着地址变化不影响策略生效。这两点决定了微隔离是真隔离还是形式隔离。rekey_interval设得太短会增加控制面负担太长则失去轮换意义一小时的量级在多数场景够用。4.2 存储加速SNAP 框架把远端盘伪装成本地盘存储这条线的价值最容易被低估。主机侧只要看到一块本地 NVMe就不需要发起端、不需要多路径、不需要为不同存储协议准备不同驱动老的操作系统也能直接用。SNAP 做的就是这件事把 NVMe-oF、iSCSI、iSER、NFS、Ceph 等远端存储在 PCIe 层模拟成本地设备暴露给主机。实现上有两种入口。NVMe SNAP 模拟的是标准 NVMe 控制器主机用 inbox 驱动就能识别性能上限高virtio-blk SNAP 模拟的是 virtio 块设备兼容性更好适合老系统和对驱动有洁癖的场景。两者都支持直连和间接两种后端路径直连走本地盘间接走远端。# SNAP 配置结构示意字段名按实际版本核对层次关系如下 [device] # 主机侧看到的模拟设备类型nvme 或 virtio-blk emulation nvme # 模拟设备的容量按后端实际可用容量规划不要超过远端卷大小 capacity_gb 2048 # 序列号要在集群内唯一否则主机会把两块盘认成同一块 serial snap-0001 [backend] # 远端存储协议与地址iSCSI 与 NVMe-oF 二选一 protocol nvme-of target 10.0.0.10:4420 # 队列深度决定能跑多高的 IOPS与远端 target 的承受能力匹配 queue_depth 128 # 传输层选择RDMA 需要链路已配置无损 transport rdma [acceleration] # 静态数据加密走卡上硬件引擎 encryption aes-xts # 压缩与去重按业务数据类型决定文本类收益大已压缩数据无收益 compression on dedup offcapacity_gb是最容易翻车的字段。设成远端卷的实际大小主机写满时远端直接报错设成超配值就要在控制面做容量水位告警否则一个租户能把共享池写穿。我一般按远端卷的 90% 设置剩下 10% 作为告警缓冲。queue_depth要和远端 target 的队列数对齐卡上开了 128 而 target 只支持 64多出来的请求会在卡内排队表现为延迟随并发线性上升。dedup默认关掉是有原因的去重表本身占内存且对已压缩数据没有收益只有在明确是文本、日志、镜像仓库这类场景才打开。性能侧的口径要提前定好。标称的 5M IOPS 是 4K 随机读的理想值实际方案里要按 70% 到 80% 折算再扣掉加密和压缩的开销。做验收时我一般跑三组纯本地盘、SNAP 直连、SNAP 间接三组数据的差值就是这条链路真实的成本。4.3 网络加速vSwitch 上卡与 overlay 卸载网络面的落地相对成熟关键是别只做转发不做封装卸载。只把 OVS 挪到卡上VXLAN 的封装解封装仍在软件里跑收益有限把封装也卸载到硬件流水线才是云 overlay 场景那个量级的提升来源。实现路径是 OVS 的硬件 datapath 加 representor 端口。每个主机侧的 VF 在卡上对应一个 representor控制面通过 representor 下发流表转发和封装由硬件执行。# 创建硬件卸载类型的网桥datapath_type 必须是 netdev ovs-vsctl add-br br-dpu -- set bridge br-dpu datapath_typenetdev # 把卡上的物理口加入网桥作为 overlay 的隧道出口 ovs-vsctl add-port br-dpu uplink_repr -- set Interface uplink_repr typedpdk # 把主机侧 VF 对应的 representor 加入网桥 ovs-vsctl add-port br-dpu vf_repr_0 # 开启硬件卸载未开启时流表仍走软件 datapath ovs-vsctl set Open_vSwitch . other_config:hw-offloadtruedatapath_typenetdev是前提设成系统类型就走内核 datapath卸载不生效。hw-offloadtrue要在建桥之后、加流表之前设顺序错了已下发的流表不会自动迁移到硬件需要清表重下。representor 的命名在不同版本里不一样上机第一件事是列出来确认对应关系别照着文档里的名字硬套。验证卸载是否真的生效看流表的 offloaded 计数而不是看 CPU 占用。CPU 占用下降可能只是因为流量小流表计数才是硬证据。4.4 裸金属云从「给一台机器」到「给一个可编排的计算单元」裸金属云是这套架构收益最明显的场景。传统裸金属交付存储和网络配置写死在主机里重装一次要重配一遍跨租户隔离靠交换机 ACL扩容靠加机器。把这三件事挪到卡上之后主机变成纯粹的算力存储和网络变成可编排的资源。交付流程大致是这样带外管理把机器拉起卡上系统先启动并连上控制面控制面注入网络策略和存储映射主机侧通过 PXE 装业务系统装完看到的是一块本地 NVMe 和一张网卡背后是远端存储与 overlay 网络。租户退租时只回收卡上的映射主机重装不影响卡上策略下一家租户接上就是干净的。这条路带来的两个能力值得单独说。一是存储超配物理容量按机架甚至集群池化单机看到的容量可以超过本地盘只要控制面盯着水位。二是异构兼容主机侧用的是标准 inbox 驱动老版本操作系统、不常见的发行版都能接进来不需要为每个系统准备一套存储客户端。5. 避坑与排查五个最容易翻车的现场这些坑基本都在批量上架或者第一次压测时集中出现实验室单机验证很难暴露。每条按现象、原因、解决写方便对着排查。5.1 主机里看不到设备卡上一切正常现象是登录卡上的系统网口在、服务在、日志干净但主机lspci里就是没有对应设备。原因通常是工作模式配错。卡被配成了 Root Complex 模式自己是主设备主机自然枚举不到它或者卡处于 Endpoint 模式但上游端口没使能链路根本没起来。还有一种情况是 SR-IOV 的 VF 数量被设成 0主机只能看到 PF业务侧按 VF 去找就找不到。解决方法是先确认模式再看链路。模式在固件配置里查链路用lspci -vvv看LnkSta是否有速率和宽度。链路没起来就先查物理连接和插槽供电链路起来了但设备名不对再查 VF 数量和驱动绑定。顺序不能反先查驱动会浪费很多时间。5.2 卸载之后吞吐上去了长尾延迟反而抖动现象是平均值好看P99 明显劣化压力越大抖得越厉害。原因多半是绑核。网络转发和存储轮询被调度到同一个 Tile共享 L3 的同时互相踢私有 L2缓存命中率掉下来延迟就抖。另一种可能是慢路径流量比例上升比如首包、分片包、异常包变多这些都要回 Arm 核处理把控制面的核占住了。解决办法是按 Tile 做隔离转发、存储、安全、控制各占一块然后观察慢路径的包计数占比。占比超过 5% 就要回头看规则是不是 ACL 写得太细导致每条新流都走慢路径或者分片没做重组。5.3 模拟盘挂上后主机 IO 超时内核日志反复报设备重置现象是主机侧dmesg不断刷 NVMe 控制器重置业务侧表现为间歇性 IO 卡住几秒。原因有三个常见来源。一是链路上 MTU 不一致卡侧开了巨帧而交换侧没开大包被丢表现为小 IO 正常、大 IO 超时。二是流控没配RDMA 场景下没有无损链路拥塞时丢包触发重传超时阈值一到就重置。三是远端 target 的队列深度小于卡侧配置请求在卡内堆积。解决办法是按顺序排查先统一 MTU 并端到端验证再确认 PFC 与流控配置在整条路径上一致最后把卡侧队列深度降到 target 能承受的值。第三点最容易被忽略因为它不报错只表现为延迟随并发上升。5.4 IPsec 跑不满标称带宽现象是压测时加密吞吐只有标称值的一小部分且 CPU 侧看不出瓶颈。原因通常是流量模型不对。单条安全联盟、单个五元组的流量硬件只能用一个引擎实例处理跑不到线速标称值是多流并发下的聚合能力。另一种情况是包太小小包场景下每包的处理开销占比高吞吐自然下降。解决办法是压测时用多流、混合包长至少覆盖 64 字节、512 字节、1500 字节三档。同时检查安全联盟数量是否合理联盟太少无法并行太多则查表开销上升。做方案时把“多流聚合”这个前提写进性能指标验收时才不会扯皮。5.5 固件升级之后整机进不了系统现象是升级流程显示成功重启后主机停在引导阶段卡上系统也起不来。原因一般有两条。一是升级走了主机侧通道升级过程中主机断电或者进程被杀镜像写了一半。二是信任根校验失败卡上的安全启动发现镜像签名不匹配直接拒绝引导。解决办法是把固件升级严格限制在带外通道升级前做配置备份升级后先做签名校验再重启。生产环境要保留上一个版本的镜像做回滚回滚开关放在带外管理里不要依赖主机侧工具。这条我吃过亏一次批量升级里有几台机器恰好赶上机房掉电恢复花了整整一个晚上。6. 验收与答辩用三张表证明这块卡真的卸载了验收最怕的是拿一句“性能提升明显”交差。评审要看的不是倍数而是你有没有把口径讲清楚。我一般准备三张表。第一张是功能验收表逐项对应四类负载每项写清楚验证方法和判据。验收项验证方法通过判据设备识别主机侧枚举设备与链路状态设备可见链路协商到 Gen4 x16网络卸载压测并查看流表卸载计数卸载计数占比高于 95%存储模拟主机侧识别模拟盘并跑随机读写4K 随机读达到折算值的 80%安全内联多流并发压测加密吞吐达到标称带宽的 70% 以上隔离能力跨租户发起连接并抓包连接被拒绝策略不可从主机侧修改带外管理断网后通过带外口登录可登录、可升级、可回滚第二张是性能口径表把每一组数字的来源写清楚测试工具、并发数、包长、队列深度、基线取的是裸机还是上一代方案。这张表的价值在于别人拿同样的口径能复现你的数复现不出来也能定位差异在哪。第三张是回退表写清楚每一项失败时的退路网络卸载失败就关硬件卸载走软件 datapath存储模拟失败就回退到主机侧发起端安全内联失败就先旁路掉加密只保留策略。有退路的方案才敢上生产答辩时被问“万一不行怎么办”这张表就是答案。答辩现场还有一个技巧别急着放吞吐曲线先放主机侧的核占用曲线。从“16 个核里有 7 个在跑非业务逻辑”变成“只剩 1 个”这条曲线比任何倍数都有说服力因为它直接对应成本。讲完占用再讲策略注入的耗时从分钟级降到秒级这是运维视角的收益。两组数据支撑一个结论比堆十张性能图管用。从那以后我每次做这类卸载方案都强制先跑一遍“主机还剩什么”的清单再谈性能。清单对不上性能数字再漂亮也是虚的。希望这套结构和口径能帮你把手上那份方案写得更站得住。本文还有配套的精品资源点击获取
