详解超融合如何让RDMA跨网卡高可用，让高性能业务更可靠

金融低延迟交易、核心数据库等高性能业务经常使用 RDMA 网络满足极低延迟需求。而针对 RDMA 网络的可靠性，传统方案往往仅提供网口级冗余保护，若发生网卡硬件故障，核心业务系统仍面临宕机风险。

对此，榫卯超融合 6.3新增了对 RDMA 多链路跨网卡 Bonding 能力的支持，基于 OVS Bond 实现跨网卡多链路绑定，将存储网络的冗余级别从 "网口级" 提升至 "网卡级"，在保持 RDMA 微秒级低延迟优势的同时，实现网卡级故障的无缝切换，让 RDMA 存储网络具备媲美 FC 网络的高可靠性，满足核心业务对性能与稳定的双重极致要求。

以下，我们将针对该功能的实现机制与亮点进行深入解读。

为什么需要 RDMA 多链路 Bonding？

RDMA（Remote Direct Memory Access）是一种面向高性能场景的远程内存访问技术，能够绕过操作系统内核与协议栈，实现节点之间的直接数据传输，具备微秒级延迟、高吞吐、低 CPU 占用三大核心优势。尤其是在金融低延迟交易、核心数据库、高性能计算、AI 训练等延迟敏感场景中，传统 TCP/IP 网络无法满足微秒级响应诉求，而 RDMA 能够显著提升 I/O 效率、降低业务处理时延，成为核心业务高性能架构的必选技术。

尽管 RDMA 性能极强，但对于其高可用保护，业内的传统方案存在明显的短板：

仅支持 Linux Bond：只能将同一块物理网卡的多个网口做绑定，无法跨网卡。
一旦物理网卡故障，整条 RDMA 链路直接断开：Linux Bond 无法处理网卡级故障，会导致存储 I/O 中断、业务卡顿甚至宕机。
核心业务场景无法满足高可用需求：低延迟交易类核心业务要求网络具备网卡级、交换机级的高可用能力，传统方案无法覆盖。

因此，支持跨网卡的 RDMA Bonding成为榫卯超融合 6.3.0 版本的重要升级方向。

榫卯超融合 6.3：实现完整的 RDMA 网络高可用

榫卯超融合 6.3 版本对 RDMA 网络架构进行了重构：将 RDMA 从 Linux Bond 切换为 OVS Bond，并支持跨物理网卡的多网口绑定。这意味着，两块不同网卡的网口可以加入同一个 Bond，单网卡故障、单交换机故障都不会导致业务中断，实现网卡级故障高可用，并兼容存量集群升级，让 RDMA 高性能与企业级高可用得以同时实现。

技术解读：功能演进与新版本实现机制

SmartX 榫卯超融合对 RDMA 网络高可用机制的探索，经历了一系列的技术演进：

早期版本：Linux Bonding + OpenFabrics 方案

超融合 RDMA 网络普遍采用网卡硬件 Bonding 方案（基于 OpenFabrics Alliance 行业标准），该方案依赖网卡硬件能力，在同一网卡内部实现多端口负载分担，核心前提是 RDMA 队列对（QP）状态可在同网卡的多个物理端口间共享。不过，该方案也存在一定的限制：

仅支持同网卡内绑定：无法跨物理网卡聚合，网卡级故障时业务直接中断。
双活 / 双交换机架构无法落地：LACP 场景下，若 QP 从网口 A 发包、网口 B 收包，因网口 B 无法感知 QP 状态，会直接丢弃报文。
高可用能力不完整：无法满足金融、核心业务对双网卡、双交换机冗余的要求。

本质问题：QP 状态与物理端口强绑定，无法跨设备共享，从根源上限制了 RDMA 网络的高可用能力。

榫卯超融合 6.3 版本：全新 OVS + RDMA 软件协同 Bonding 方案

为彻底突破硬件限制，榫卯超融合 6.3 采用 OVS Bonding + RDMA 软件层多路径的创新方案：

1. 网络层统一抽象：OVS Bonding 做底座

基于 OVS Bonding 将多个物理网口聚合为一个逻辑端口，对外提供统一存储 IP，对上层应用完全透明：

支持跨物理网卡绑定，彻底突破硬件限制。
完美兼容传统 TCP 应用（如 ZooKeeper 集群）。
原生支持负载均衡与故障切换，高可用能力完整。

2. RDMA 软件层创新：多路径机制解决核心痛点

在 RDMA 层引入应用层多路径机制，从根源解决硬件方案的 QP 绑定问题：

多 QP 并行：为同一逻辑连接建立多个 QP，每个 QP 绑定不同物理网口。
L4 路径探测：通过 L4 层探测识别五元组对应的实际转发路径，筛选出收发一致的稳定路径。
秒级快速重连：某路径异常时，应用层快速切换到备用 QP，故障切换无感知、不丢包。

同时，充分解决 OVS Bonding 架构的历史遗留问题，全面实现「跨网卡绑定 + 高稳定 + 高性能」三者兼得，完美适配金融核心、双活等高端场景。

MAC 漂移问题

问题：RDMA 流量向交换机不同端口发送了相同的MAC包，导致交换机上的 MAC 漂移、丢包。
解决方案：
- 定期获取 OVS Bond 的 Active Slave。
- 强制 RDMA 只在 Active 网口建立连接。
- 保持流量路径一致，从根源避免 MAC 漂移。

故障切换重连时间长、不可控

问题：Failover 时网络断开、重连慢、影响副本安全与 I/O 延迟。
解决方案：
- 采用类 L3/L4 探测机制快速感知可用网口。
- 优化连接重建与 QP 重连逻辑。
- 大幅降低切换延迟，提升稳定性。

balance-tcp 模式连接不稳定

问题：交换机 Port Channel 哈希不一致，导致回包从非连接网口到达被丢弃。
**解决方案：
- 先发探测包确定双方可用网口。
- 再建立 RDMA 连接并绑定网口。
- 确保收发路径一致，连接稳定可依赖。**

方案对比：Linux Bond vs. OVS Bond、

功能亮点

真正实现网卡级高可用：支持不同物理网卡的网口绑定，单网卡故障不中断业务。
双交换机高可用架构成为标准配置：满足金融、交易、核心数据库最严苛的可靠性要求。
彻底解决历史技术问题：修复 MAC 漂移、重连不可控、balance-tcp 不稳定等问题。
支持两种生产级绑定模式：active-backup（主备高可用）和 balance-tcp（负载均衡 + 多网口带宽叠加）。
Data Channel 自动多路径：balance-tcp 模式下自动开启多路径，充分利用多网卡带宽，提升集群写性能。
兼容存量集群，平滑升级：低版本 Linux Bond 可通过 network-tool 一键切换，无需重构架构。
统一网络架构：存储网络统一使用 OVS Bond，管理更简单、运维更高效。

总结

榫卯超融合 6.3 通过 RDMA 跨网卡 Bonding 能力，解决了"RDMA 性能强但高可用不足"的行业难题：

高性能不打折：保留 RDMA 微秒级低延迟优势。
高可用全面升级：支持网卡 / 交换机级故障防护。
核心业务敢用、能用、放心用。
无需昂贵 FC 网络，即可获得金融级高可靠架构。
双网卡、双交换机高可用架构真正落地，为核心业务保驾护航。