Azure 基于 FPGA 的公有云網(wǎng)絡(luò)加速

上次在看Google介紹自己網(wǎng)絡(luò)設(shè)計(jì)的presentation，下面有觀眾提問和Azure網(wǎng)絡(luò)加速的比較。才發(fā)現(xiàn)NSDI’18同期還有Azure介紹的基于FPGA的網(wǎng)絡(luò)加速方案。這種區(qū)別于Google的純軟件實(shí)現(xiàn)和只能網(wǎng)卡純硬件實(shí)現(xiàn)的Datapath還是很獨(dú)特的就把論文也找來看了一下。這里主要介紹一下從Azure角度其他軟硬件實(shí)現(xiàn)和FPGA方案的對(duì)比，工程上的經(jīng)驗(yàn)以及Azure和AWS，GCP對(duì)比的性能評(píng)測(cè)。具體的軟硬件設(shè)計(jì)細(xì)節(jié)，由于我對(duì)FPGA也不是很了解，感興趣的讀者可以參考文末的論文鏈接來看看。

背景

第一個(gè)大的背景是目前網(wǎng)卡的速率提升超過了CPU性能的提升速率。Azure在09年啟動(dòng)時(shí)網(wǎng)卡帶寬是1Gbps,17年的時(shí)候來到了50Gbps，我剛剛?cè)ellanox的官網(wǎng)看了一下在賣的產(chǎn)品，現(xiàn)在的最大帶寬已經(jīng)到了200Gbps。十年的時(shí)間帶寬提升了200倍，而CPU顯然沒有那么大的速率提升。在過去幾乎不需要什么優(yōu)化，單核CPU就可以輕松跑滿1Gbps的帶寬，10Gbps時(shí)代就需要很多優(yōu)化了。而現(xiàn)在已經(jīng)有了200Gbps，未來可能還會(huì)有帶寬更大的網(wǎng)卡，基于CPU的網(wǎng)絡(luò)處理面臨著越來越大的挑戰(zhàn)。

第二個(gè)背景和Azure的商業(yè)模式相關(guān)，也就是公有云靠出賣計(jì)算能力來獲取收入。由于單機(jī)的帶寬越來越大，那么就需要保留越來越的CPU核心來處理網(wǎng)絡(luò)數(shù)據(jù)包，這會(huì)造成可對(duì)外售賣的CPU數(shù)量下降，這會(huì)影響Azure的利潤率。

第三個(gè)背景是和GCP類似，Azure內(nèi)部設(shè)計(jì)了自己的SDN，網(wǎng)絡(luò)方面的能力和功能需要隨著市場的變化和客戶的需求進(jìn)行高速的迭代，更新的周期往往也是周級(jí)別的，傳統(tǒng)硬件加速方案無法保持如此快的更新節(jié)奏。

在這三個(gè)背景下Azure還是提出了相當(dāng)高的設(shè)計(jì)目標(biāo)：

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

2.支持SDN的編程能力，數(shù)據(jù)平面可高速迭代

3.未來可支持100Gbps帶寬

4.盡可能少的使用CPU

還有其他的幾個(gè)設(shè)計(jì)目標(biāo)，但是在我看來和GCP在設(shè)計(jì)目標(biāo)上最大的區(qū)別其實(shí)是第四條盡可能少的使用CPU，這也導(dǎo)致Azure選擇了一條更靠近硬件的路線。

各種硬件的方案比較

其實(shí)所有的方案都可以看成是軟硬結(jié)合的方案，所謂純軟方案是一種以CPU作為硬件基礎(chǔ)的方案，而純硬件的ASIC方案是基于硬件電路實(shí)現(xiàn)代碼邏輯的方案。

ASIC

Azure早期采用了ASIC的方案來完成大量網(wǎng)絡(luò)數(shù)據(jù)平面工作，最主要使用到了SR-IOV技術(shù)，這種方案可以達(dá)到幾乎和物理網(wǎng)絡(luò)一致的性能，從性能方面來看是最好的方案。但是這種方案缺點(diǎn)在于可編程性和擴(kuò)展性是最差的，SDN只能使用ASIC所提供的能力，任何ASIC不提供的能力如果用軟件實(shí)現(xiàn)都會(huì)成為一個(gè)瓶頸。此外ASIC開發(fā)周期通常需要1~2年，這意味著這塊芯片是基于1~2年前的需求而設(shè)計(jì)的，并且硬件上架后通常要使用五年，這也意味著軟件層面的能力需要和硬件綁定一段時(shí)間。

Multicore SoC-based NIC

一些ASIC上提供了額外的CPU可以專門做數(shù)據(jù)包的通用處理，論文中稱其為Multicore SoC-based NICs，這種硬件提供了通用編程的能力，由專門的嵌入式CPU完成處理工作，犧牲了一定的性能來換取更好的可編程能力。這種方案在10Gbps的帶寬下可以很好的工作，但是在40Gbps的帶寬下就出現(xiàn)了明顯的問題。由于帶寬增大了4倍，CPU對(duì)應(yīng)的也需要變?yōu)樵瓉淼闹辽?倍，這時(shí)CPU的調(diào)度的復(fù)雜度和延遲的抖動(dòng)都明顯上升。單鏈接的性能由于受限于單CPU的處理能力，無法隨著帶寬的提升得到提升，并且在未來面對(duì)100，200甚至400Gbps的帶寬時(shí)，這種方案能否線性擴(kuò)展也是個(gè)問題。

CPU

不依賴專門硬件的純軟件方案有著最好的靈活性和可編程性，通過DPDK這種OS Bypass和CPU poll-mode優(yōu)化，可以顯著降低數(shù)據(jù)包處理的延遲和消耗。但是這種方式需要消耗寶貴的宿主機(jī)CPU資源來處理網(wǎng)絡(luò)，降低可對(duì)外提供售賣服務(wù)的CPU。并且基于CPU的方案在大流量和多核的情況下會(huì)出現(xiàn)延遲抖動(dòng)的問題，也很難進(jìn)行解決。此外通過Azure團(tuán)隊(duì)的計(jì)算，從性價(jià)比的考慮來看，這種方式的消耗甚至比Multicore SoC-based NIC消耗還要大。

FPGA

和CPU相比，F(xiàn)PGA有著不同的計(jì)算模式。CPU需要一邊取指令一邊取數(shù)據(jù)進(jìn)行計(jì)算處理，而FPGA中指令是以微代碼形式編輯在電路中，然后讓數(shù)據(jù)從電路中流過。同時(shí)FPGA中有大量可并行計(jì)算的資源，并且每個(gè)處理步驟也可以設(shè)計(jì)多級(jí)的流水線進(jìn)一步加強(qiáng)處理的并行度。因此盡管單核的頻率上FPGA比不過CPU，但是借助大量的并行可以達(dá)到遠(yuǎn)超CPU的吞吐量。此外由于FPGA的可編程性，能同時(shí)兼顧性能和靈活性，最終Azure選擇了FPGA作為網(wǎng)絡(luò)的數(shù)據(jù)平面方案。

關(guān)于FPGA的疑問

作者在論文中列舉了幾個(gè)關(guān)于FPGA的常見疑問并做出了解答。

1.FPGA的體積是否比ASIC要大很多？

單純比邏輯處理部分的體積，完成同樣的計(jì)算能力FPGA大概是ASIC的10到20倍。然而目前來說網(wǎng)卡中的主要部分并不是邏輯處理，SRAM，Transceivers，PCIe，網(wǎng)絡(luò)接口等占據(jù)了更大的空間。并且現(xiàn)代智能網(wǎng)卡增加了可編程的通用部分增加了體積，而FPGA也可以根據(jù)功能固化一部分邏輯來減小體積。最終的效果是FPGA網(wǎng)卡體積是ASIC的2~3倍，考慮到FPGA可編程的靈活性，這部分代價(jià)是值得的。

2.FPGA是否很昂貴？

作者說不能透露供應(yīng)商的價(jià)格，而是很奇葩的通過完成相同功能使用到的硅片成本來計(jì)算，由于規(guī)模效應(yīng)以及節(jié)省下來的大量CPU，F(xiàn)lash和DRAM，F(xiàn)PGA的投資還是值得的。

3.FPGA的編程是否很困難？

FPGA的編程需要用到Verilog，是一種硬件編程語言，對(duì)于普通的軟件工程師來說門檻還是存在的。不過微軟研究院曾經(jīng)做過基于FPGA的加速網(wǎng)卡，幫助Azure團(tuán)隊(duì)處理了很多早期啟動(dòng)的問題。現(xiàn)在Azure內(nèi)部有一個(gè)5人規(guī)模的硬件工程師團(tuán)隊(duì)來負(fù)責(zé)FPGA相關(guān)開發(fā)。通過軟硬件工程師聯(lián)合開發(fā)，并通過軟件工程的方法論來管理FPGA的開發(fā)，達(dá)到了很好的迭代速率。

性能數(shù)據(jù)

通過FPGA的加速方案，Azure做到了VM和VM之間的網(wǎng)絡(luò)平均延遲為17微秒，P99為25微秒，P99.9為80微秒。相比之前軟件方案的50，100，300，在延遲和穩(wěn)定性上都有了很大的提升。

單線程的吞吐量上，軟件的方案受限于單核CPU的瓶頸只能做到8Gbps，而使用了FPGA的方案可以跑到30 Gbps。如果達(dá)到同樣的帶寬，軟件方案需要4個(gè)CPU的額外消耗，而FPGA在這方面的消耗是0 CPU。

不過從性能指標(biāo)來看對(duì)比的軟件方案應(yīng)該是非OS Bypass的方案，換成類似DPDK的方案作對(duì)比或許會(huì)更有說服力一些。

最后作者雞賊的做了個(gè)Azure，GCP和AWS三者的網(wǎng)絡(luò)性能對(duì)比?？梢夾zure是完勝的，當(dāng)然這種自賣自夸還是讓人值得懷疑的。不過作者也提到2018年由于Intel CPU爆出了大量安全相關(guān)的問題(Meltdown和Spectre)，公有云不得不打相關(guān)補(bǔ)丁導(dǎo)致CPU性能下降，對(duì)于基于CPU的網(wǎng)絡(luò)方案會(huì)有更明顯的沖擊，基于FPGA的方案反而躲過一劫。

總結(jié)

和GCP的網(wǎng)絡(luò)方案比，同樣是面臨性能，靈活性和成本之間的權(quán)衡，Azure選擇了可編程硬件來解決問題。對(duì)于Azure這種規(guī)模的基礎(chǔ)設(shè)施，可編程硬件盡管初期投入和開發(fā)成本都比較高，但是長遠(yuǎn)來看提供了更好的性能，同時(shí)節(jié)約了成本。不過這種軟硬高度結(jié)合的玩法也只有這種成規(guī)模的玩家才玩得起，我們普通人就當(dāng)看科幻片就好了。

參考資料：https://www.usenix.org/conference/nsdi18/presentation/firestone