UCloud基于OpenvSwitch卸载的高性能25克智能网卡实践

  

伴随着电商等用户在双11日秒杀之类业务高峰期流量的迅猛增长,对虚拟机网络性能提升的需求日益迫切,25 g网络逐渐成为一种标配。为了解决传统纯软件虚拟交换机方案带来的性能瓶颈,我们在调研了业界主流的智能网卡方案之后,最终决定采用基于OpenvSwitch的开源方案,并成功在公有云落地应用。

  

相较于传统方案,新的智能网卡方案在整个开关的转发上性能为小包24 mpp,单VF的接收性能达15 mpp,网卡整体性能提升十倍以上。应用于云主机后,可将其网络能力提升至少4倍时延降低3倍,有效解决电商等业务高峰期的稳定性问题。本文将详细讲讲新方案从选型到落地过程中遇到的坑及解决之道,希望能给人以借鉴与启发。

  

<>强业界主流的智能网卡方案对比

  

传统的软件虚拟交换机的性能瓶颈,在于其从物理网卡接收报文后,是按照转发逻辑发送vhost给线程,vhost再传递给虚拟机的方式执行,如此一来,vhost的处理能力就成为了影响虚拟机网络性能的关键。

  

于是,在宿主机上通过25克SmartNIC对网络流量进行卸载成为业界公认的主流方向。现阶段,智能网卡的实现百花齐放,例如:AWS采用基于通用手臂的众核方案,Azure采用基于FPGA的方案,华为云采用基于专用网络处理器(NP)的方案,阿里云采用基于可编程ASIC芯片的方案。就目前来看各个方案各有优劣,并没有特别突出一统天下的方案。

  

 UCloud基于OpenvSwitch卸载的高性能25克智能网卡实践“> </p>
  <p>基于通用手臂,MIPS的众核方案,简单将原来跑在宿主机上的vSwitch移植到网卡上,既可以支持Linux内核也可以支持DPDK,从而达到释放宿主机计算资源的目的。而其他基于FPGA, NP和可编程ASIC的方案,大多在网卡上维护一个快速转发路径(快速路径),当收到报文后,首先检查是否在快速路径已经缓存了该类报文的处理规则,如果找到,则直接按照规则执行动作,否则就转发到缓慢的路径去处理。而这个慢路径可以是DPDK,也可以是Linux内核。</p>
  <p>因此,快捷路径最重要的是看是否支持足够多的行动,以及自定义行动的可扩展性.Slow路径和快速路径通信除了各厂商的私有接口外,也有标准的TC卸载接口和DPDK提供的RTE流接口。</p>
  <p>不过,FPGA的功耗和成本较高,研发周期长且不能快速地落地,从硬件到软件都需要投入大量的资源。而其他基于第三方网卡厂家的软件定制化方案,对于网卡软件的稳定性严重依赖于第三方厂商,遇到问题时不能快速的定位排障。</p>
  <p> <强>我们的选择</强> </p>
  <p>在业界没有非常完美的实现方案下,我们开始将目光转向开源技术,由于OpenvSwitch本身支持基于Linux Tc花卸载卸载接口,对现有控制管理面影响小,并且能够快速应用落地开发给用户使用,因此,我们选择了基于Tc花卸载的OpenvSwitch开源方案。</p>
  <p>报文处理可以被看做是通过一系列顺序操作将一个报文从接收发送到最终的目的地,最典型处理的是发送或者丢弃。这一系列操作通常是连续然的比赛后执行action.Linux内核TC子系统的TC花可以将报文基于流进行控制转发,而流通常是基于报文常见域来分的类,这些域组成了名关键的匹配项,叫流流主要包括了报文常见域和可选的隧道信息,TC行动对报文执行丢弃,修改,发送等操作。</p>
  <p> <img src=UCloud基于OpenvSwitch卸载的高性能25克智能网卡实践