单机 T 级流量转发吞吐提升 5 倍,可编程负载均衡网关 1.0 上线
1. 背景
单核计算能力受限。为了防止报文乱序,需要同一条业务流调度到同一个网关的同一个 CPU 核上处理。由于 CPU 单核能力已基本停止提升,因此单流的极限吞吐能力发展缓慢。如今,即使采用最新的 CPU,单流的实际吞吐能力也仅能做到 10-20Gbps,而这一数据也只是理想情况下的最优结果。
如果两个或更多的大流量被同时调度到同一个 CPU 核上,由于处理能力的限制,那么会因争抢 CPU 引起相互影响而降低业务整体吞吐量;更坏情况下,该 CPU 核上处理的其他流量也会受到影响,可能导致概率性的丢包。
时延不稳定。使用 CPU 软件处理相对于硬件转发而言,通常有较高的时延。在软件网关上,一个报文的处理流程要经过以下步骤:从网卡接收开始,经过 PCIe 送到 CPU 上的 DPDK 驱动,然后网关软件再做业务逻辑处理,之后提交给 DPDK 驱动,最后经过 PCIe 下发到网卡上再发送出去。
从实测结果来看,当前百度智能云的软件网关在一般负载水平下的报文平均处理时延通常在 30-50us,转发负载较高时 100us 以上的长尾时延也很常见,极端情况甚至会出现 ms 级的时延。另外时延波动和 CPU 缓存的实际命中情况密切相关,难以预期。较大时延波动尺度对于跨机房或跨地域的通信一般没什么实质影响,但是对于强依赖同机房内低时延的业务来说访问的影响却较大。
大带宽场景的 TCO(Total Cost of Ownership)较高。尽管 CPU 的核数在不断提升,但是在网关这种重 I/O 吞吐的业务上,软件处理报文的能力并不能随着 CPU 核数线性提升。例如,使用 64 物理核的 AMD Milan 服务器上运行 BGW,当 32 核以上增加 CPU 核数,对整体吞吐则没有明显的增加。这一现象和当前 CPU 的微架构(尤其是 L3 缓存)强相关。
实际上当前软件网关通常可承诺的带宽规格大致上是 100-200G(如果只考虑大包也能做到 400G)。如果需要一个网关的集群支撑 10T 带宽,那么即使在不考虑冗余的情况下,也需要部署 50-100 台服务器。
可编程交换芯片可提供 T 级别的带宽吞吐能力;
通过硬件网络芯片 + X86 CPU 同时支持硬件网关和传统软件网关的运行,提供强大的灵活性和超融合能力;
通过扩展插槽提供更多硬件加速扩展能力。
通过软硬结合、session 表硬件 offload 卸载提升网关吞吐的性能,可以提供单网关 T 级大带宽,同时大幅降低网关用量成本。
降低网关产品的网络延迟、解决高负载场景下网关丢包和抖动问题。
发送和接收 BGP 路由协议相关的数据包,与交换机形成路由关系,将流量引入这台设备;
在需要进行抓包时,把端口进入的流量镜像一份,送给 X86 用户空间虚拟网络设备,可以抓包排查问题。
Fast-Path:快速路径,命中 session 的流量由 ASIC 可编辑硬件转发,提供硬件 T 级别的转发能力和 us 级的低时延; Slow-Path:慢速路径,未命中 session 的流量上送 CPU,按配置指令决策是否下发 session 走快速路径。
容量:单机带宽吞吐扩大 5 倍以上,200Gbps 升级为大于 1Tbps 能力; 时延:平均转发时延降低 20 倍以上,高负载时 100us 降至稳定小于 4us 无抖动,转发更快速; 丢包率:十万分之一降至数亿分之一,网络更可靠; 成本:实现了单机转发能力的提升,承接更大规模流量时可以减少部署成本; 能耗:所需部署机器的减少,T 级别吞吐时整体能耗下降 50% 以上,实现碳减排。