Azure 基于 FPGA 的公有云网络加速

上次在看Google介绍自己网络设计的presentation，下面有观众提问和Azure网络加速的比较。才发现NSDI’18同期还有Azure介绍的基于FPGA的网络加速方案。这种区别于Google的纯软件实现和只能网卡纯硬件实现的Datapath还是很独特的就把论文也找来看了一下。这里主要介绍一下从Azure角度其他软硬件实现和FPGA方案的对比，工程上的经验以及Azure和AWS，GCP对比的性能评测。具体的软硬件设计细节，由于我对FPGA也不是很了解，感兴趣的读者可以参考文末的论文链接来看看。

背景

第一个大的背景是目前网卡的速率提升超过了CPU性能的提升速率。Azure在09年启动时网卡带宽是1Gbps,17年的时候来到了50Gbps，我刚刚去Mellanox的官网看了一下在卖的产品，现在的最大带宽已经到了200Gbps。十年的时间带宽提升了200倍，而CPU显然没有那么大的速率提升。在过去几乎不需要什么优化，单核CPU就可以轻松跑满1Gbps的带宽，10Gbps时代就需要很多优化了。而现在已经有了200Gbps，未来可能还会有带宽更大的网卡，基于CPU的网络处理面临着越来越大的挑战。

第二个背景和Azure的商业模式相关，也就是公有云靠出卖计算能力来获取收入。由于单机的带宽越来越大，那么就需要保留越来越的CPU核心来处理网络数据包，这会造成可对外售卖的CPU数量下降，这会影响Azure的利润率。

第三个背景是和GCP类似，Azure内部设计了自己的SDN，网络方面的能力和功能需要随着市场的变化和客户的需求进行高速的迭代，更新的周期往往也是周级别的，传统硬件加速方案无法保持如此快的更新节奏。

在这三个背景下Azure还是提出了相当高的设计目标：

1.接近硬件方案的吞吐量、延迟

2.支持SDN的编程能力，数据平面可高速迭代

3.未来可支持100Gbps带宽

4.尽可能少的使用CPU

还有其他的几个设计目标，但是在我看来和GCP在设计目标上最大的区别其实是第四条尽可能少的使用CPU，这也导致Azure选择了一条更靠近硬件的路线。

各种硬件的方案比较

其实所有的方案都可以看成是软硬结合的方案，所谓纯软方案是一种以CPU作为硬件基础的方案，而纯硬件的ASIC方案是基于硬件电路实现代码逻辑的方案。

ASIC

Azure早期采用了ASIC的方案来完成大量网络数据平面工作，最主要使用到了SR-IOV技术，这种方案可以达到几乎和物理网络一致的性能，从性能方面来看是最好的方案。但是这种方案缺点在于可编程性和扩展性是最差的，SDN只能使用ASIC所提供的能力，任何ASIC不提供的能力如果用软件实现都会成为一个瓶颈。此外ASIC开发周期通常需要1~2年，这意味着这块芯片是基于1~2年前的需求而设计的，并且硬件上架后通常要使用五年，这也意味着软件层面的能力需要和硬件绑定一段时间。

Multicore SoC-based NIC

一些ASIC上提供了额外的CPU可以专门做数据包的通用处理，论文中称其为Multicore SoC-based NICs，这种硬件提供了通用编程的能力，由专门的嵌入式CPU完成处理工作，牺牲了一定的性能来换取更好的可编程能力。这种方案在10Gbps的带宽下可以很好的工作，但是在40Gbps的带宽下就出现了明显的问题。由于带宽增大了4倍，CPU对应的也需要变为原来的至少4倍，这时CPU的调度的复杂度和延迟的抖动都明显上升。单链接的性能由于受限于单CPU的处理能力，无法随着带宽的提升得到提升，并且在未来面对100，200甚至400Gbps的带宽时，这种方案能否线性扩展也是个问题。

CPU

不依赖专门硬件的纯软件方案有着最好的灵活性和可编程性，通过DPDK这种OS Bypass和CPU poll-mode优化，可以显著降低数据包处理的延迟和消耗。但是这种方式需要消耗宝贵的宿主机CPU资源来处理网络，降低可对外提供售卖服务的CPU。并且基于CPU的方案在大流量和多核的情况下会出现延迟抖动的问题，也很难进行解决。此外通过Azure团队的计算，从性价比的考虑来看，这种方式的消耗甚至比Multicore SoC-based NIC消耗还要大。

FPGA

和CPU相比，FPGA有着不同的计算模式。CPU需要一边取指令一边取数据进行计算处理，而FPGA中指令是以微代码形式编辑在电路中，然后让数据从电路中流过。同时FPGA中有大量可并行计算的资源，并且每个处理步骤也可以设计多级的流水线进一步加强处理的并行度。因此尽管单核的频率上FPGA比不过CPU，但是借助大量的并行可以达到远超CPU的吞吐量。此外由于FPGA的可编程性，能同时兼顾性能和灵活性，最终Azure选择了FPGA作为网络的数据平面方案。

关于FPGA的疑问

作者在论文中列举了几个关于FPGA的常见疑问并做出了解答。

1.FPGA的体积是否比ASIC要大很多？

单纯比逻辑处理部分的体积，完成同样的计算能力FPGA大概是ASIC的10到20倍。然而目前来说网卡中的主要部分并不是逻辑处理，SRAM，Transceivers，PCIe，网络接口等占据了更大的空间。并且现代智能网卡增加了可编程的通用部分增加了体积，而FPGA也可以根据功能固化一部分逻辑来减小体积。最终的效果是FPGA网卡体积是ASIC的2~3倍，考虑到FPGA可编程的灵活性，这部分代价是值得的。

2.FPGA是否很昂贵？

作者说不能透露供应商的价格，而是很奇葩的通过完成相同功能使用到的硅片成本来计算，由于规模效应以及节省下来的大量CPU，Flash和DRAM，FPGA的投资还是值得的。

3.FPGA的编程是否很困难？

FPGA的编程需要用到Verilog，是一种硬件编程语言，对于普通的软件工程师来说门槛还是存在的。不过微软研究院曾经做过基于FPGA的加速网卡，帮助Azure团队处理了很多早期启动的问题。现在Azure内部有一个5人规模的硬件工程师团队来负责FPGA相关开发。通过软硬件工程师联合开发，并通过软件工程的方法论来管理FPGA的开发，达到了很好的迭代速率。

性能数据

通过FPGA的加速方案，Azure做到了VM和VM之间的网络平均延迟为17微秒，P99为25微秒，P99.9为80微秒。相比之前软件方案的50，100，300，在延迟和稳定性上都有了很大的提升。

单线程的吞吐量上，软件的方案受限于单核CPU的瓶颈只能做到8Gbps，而使用了FPGA的方案可以跑到30 Gbps。如果达到同样的带宽，软件方案需要4个CPU的额外消耗，而FPGA在这方面的消耗是0 CPU。

不过从性能指标来看对比的软件方案应该是非OS Bypass的方案，换成类似DPDK的方案作对比或许会更有说服力一些。

最后作者鸡贼的做了个Azure，GCP和AWS三者的网络性能对比。可见Azure是完胜的，当然这种自卖自夸还是让人值得怀疑的。不过作者也提到2018年由于Intel CPU爆出了大量安全相关的问题(Meltdown和Spectre)，公有云不得不打相关补丁导致CPU性能下降，对于基于CPU的网络方案会有更明显的冲击，基于FPGA的方案反而躲过一劫。

总结

和GCP的网络方案比，同样是面临性能，灵活性和成本之间的权衡，Azure选择了可编程硬件来解决问题。对于Azure这种规模的基础设施，可编程硬件尽管初期投入和开发成本都比较高，但是长远来看提供了更好的性能，同时节约了成本。不过这种软硬高度结合的玩法也只有这种成规模的玩家才玩得起，我们普通人就当看科幻片就好了。

参考资料：https://www.usenix.org/conference/nsdi18/presentation/firestone

相关推荐: 中国家电企业折戟巴西之痛

作为一家在国内及东南亚市场做得风生水起的家电企业，福朋集团却在投资巴西中损失惨重，并拖累了其国内业务的发展。其惨痛教训值得其他企业引以为戒。 作为一片尚未被中国企业深度开发的投资热土，巴西受到了越来越多的中国企业的关注。坦率地讲，走进巴西的中国企业，失败案例远…