DPU應(yīng)用場(chǎng)景系列（一）網(wǎng)絡(luò)功能卸載

網(wǎng)絡(luò)功能卸載是伴隨云計(jì)算網(wǎng)絡(luò)而產(chǎn)生的，主要是對(duì)云計(jì)算主機(jī)上的虛擬交換機(jī)的能力做硬件卸載，從而減少主機(jī)上消耗在網(wǎng)絡(luò)上的CPU算力，提高可售賣計(jì)算資源。

圖云計(jì)算網(wǎng)絡(luò)架構(gòu)

目前除了公有云大廠采用自研云平臺(tái)，絕大部分私有云廠商都使用開(kāi)源的OpenStack云平臺(tái)生態(tài)。在OpenStack云平臺(tái)中，虛擬交換機(jī)通常是OpenvSwitch，承擔(dān)著云計(jì)算中網(wǎng)絡(luò)虛擬化的主要工作，負(fù)責(zé)虛擬機(jī)（VM）與同主機(jī)上虛擬機(jī)（VM）、虛擬機(jī)（VM）與其它主機(jī)上虛擬機(jī)（VM）、虛擬機(jī)（VM）與外部的網(wǎng)絡(luò)通信。虛擬交換機(jī)與網(wǎng)關(guān)路由器（GW）通常由同一SDN控制器來(lái)管理控制，為租戶開(kāi)通VPC網(wǎng)絡(luò)以及和外部通信的網(wǎng)絡(luò)。主機(jī)與主機(jī)間的網(wǎng)絡(luò)通常是Underlay網(wǎng)絡(luò)，是由TOR/EOR構(gòu)建的Spine-Leaf結(jié)構(gòu)的Fabric Network。虛擬機(jī)（VM）與虛擬機(jī)（VM）通信的網(wǎng)絡(luò)是Overlay網(wǎng)絡(luò)，是承載在Underlay網(wǎng)絡(luò)構(gòu)建的VxLAN，NVGRE或Geneve隧道之上的。通常VxLAN，NVGRE或Geneve的隧道端點(diǎn)（VTEP）在虛擬交換機(jī)和網(wǎng)關(guān)路由器（GW）上。也有部分對(duì)網(wǎng)絡(luò)性能要求比較高的場(chǎng)景，采用SR-IOV替代虛擬交換機(jī)，VF直通到虛擬機(jī)（VM）內(nèi)部，這樣就要求隧道端點(diǎn)（VTEP）部署在TOR上，TOR與網(wǎng)關(guān)路由器（GW）創(chuàng)建隧道，提供Overlay網(wǎng)絡(luò)服務(wù)。虛擬交換機(jī)的場(chǎng)景是最通用的應(yīng)用場(chǎng)景，所以，虛擬交換機(jī)的技術(shù)迭代也直接影響著虛擬化網(wǎng)絡(luò)的發(fā)展。

一、虛擬化網(wǎng)絡(luò)功能（Virtual Network Function)

行業(yè)內(nèi)主流的Hypervisor主要有Linux系統(tǒng)下的KVM-Qemu，VMWare的ESXi，微軟Azure的Hyper-V，以及亞馬遜早期用的Xen（現(xiàn)在亞馬遜已經(jīng)轉(zhuǎn)向KVM-Qemu）。KVM-Qemu有著以Redhat為首在持續(xù)推動(dòng)的更好的開(kāi)源生態(tài)，目前行業(yè)內(nèi)90%以上的云廠商都在用KVM-Qemu作為虛擬化的基礎(chǔ)平臺(tái)。

在KVM-Qemu這個(gè)Hypervisor的開(kāi)源生態(tài)里，與網(wǎng)絡(luò)關(guān)系最緊密的標(biāo)準(zhǔn)協(xié)議包括virtio和vhost，以及vhost衍生出來(lái)的vhost-vdpa。Virtio在KVM-Qemu中定義了一組虛擬化I/O設(shè)備，和對(duì)應(yīng)設(shè)備的共享內(nèi)存的通信方法，配合后端協(xié)議vhost和vhost-vdpa使用，使虛擬化I/O性能得到提升。

（1）內(nèi)核虛擬化網(wǎng)絡(luò)（vhost-net）

在虛擬化網(wǎng)絡(luò)的初期，以打通虛擬機(jī)（VM）間和與外部通信能力為主，對(duì)功能訴求遠(yuǎn)高于性能，虛擬交換機(jī)OVS（Open vSwitch）的最初版本也是基于操作系統(tǒng)Linux內(nèi)核轉(zhuǎn)發(fā)來(lái)實(shí)現(xiàn)的。vhost協(xié)議作為控制平面，由Qemu做代理與主機(jī)kernel內(nèi)的vhost-net通信，主機(jī)內(nèi)核vhost-net作為virtio的backend，與虛擬機(jī)（VM）內(nèi)部的virtio NIC通過(guò)共享內(nèi)存的方式進(jìn)行通信。實(shí)現(xiàn)了虛擬機(jī)（VM）間和虛擬機(jī)（VM）與外部的通信能力，但是內(nèi)核轉(zhuǎn)發(fā)效率和吞吐量都很低。目前在虛擬化網(wǎng)絡(luò)部署中已經(jīng)很少使用。

（2）用戶空間DPDK虛擬化網(wǎng)絡(luò)（vhost-user）

隨著虛擬化網(wǎng)絡(luò)的發(fā)展，虛擬機(jī)（VM）業(yè)務(wù)對(duì)網(wǎng)絡(luò)帶寬的要求越來(lái)越高，另外，英特爾和Linux基金會(huì)推出了DPDK（Data Plane Development Kit）開(kāi)源項(xiàng)目，實(shí)現(xiàn)了用戶空間直接從網(wǎng)卡收發(fā)數(shù)據(jù)報(bào)文并進(jìn)行多核快速處理的開(kāi)發(fā)庫(kù)，虛擬交換機(jī)OVS將數(shù)據(jù)轉(zhuǎn)發(fā)平面通過(guò)DPDK支持了用戶空間的數(shù)據(jù)轉(zhuǎn)發(fā)，進(jìn)而實(shí)現(xiàn)了轉(zhuǎn)發(fā)帶寬量級(jí)的提升。OVS-DPDK通過(guò)將virtio的backend實(shí)現(xiàn)在用戶空間，實(shí)現(xiàn)了虛擬機(jī)（VM）與用戶空間OVS-DPDK的共享內(nèi)存，這樣虛擬機(jī)（VM）在收發(fā)報(bào)文時(shí)，只需要OVS-DPDK將從網(wǎng)卡收到的報(bào)文數(shù)據(jù)寫(xiě)入虛擬機(jī)（VM）的內(nèi)存，或從虛擬機(jī)（VM）內(nèi)存將要發(fā)送的報(bào)文拷貝到網(wǎng)卡DMA的內(nèi)存，由于減少了內(nèi)存拷貝次數(shù)和CPU調(diào)度干擾，提升了轉(zhuǎn)發(fā)通道的整體效率和吞吐量。

圖基于DPDK的虛擬化網(wǎng)

OVS-DPDK相對(duì)轉(zhuǎn)發(fā)能力有所提高，但也存在新的問(wèn)題。首先，目前大多數(shù)服務(wù)器都是NUMA（多CPU）結(jié)構(gòu)，在跨NUMA轉(zhuǎn)發(fā)時(shí)性能要比同NUMA轉(zhuǎn)發(fā)弱。而物理網(wǎng)卡只能插在一個(gè)PCIe插槽上，這個(gè)插槽只會(huì)與一個(gè)NUMA存在親和性，所以O(shè)VS-DPDK上跨NUMA轉(zhuǎn)發(fā)的流量不可避免。第二，在虛擬機(jī)（VM）與OVS-DPDK共享內(nèi)存時(shí)，初始化的隊(duì)列數(shù)量通常是與虛擬機(jī)（VM）的CPU個(gè)數(shù)相同，才能保證虛擬機(jī)上每一個(gè)CPU都可以通過(guò)共享內(nèi)存收發(fā)數(shù)據(jù)包，這樣導(dǎo)致不同規(guī)格的虛擬機(jī)（VM）在OVS-DPDK上收發(fā)隊(duì)列所接入的CPU是非對(duì)稱的，在轉(zhuǎn)發(fā)過(guò)程中需要跨CPU轉(zhuǎn)發(fā)數(shù)據(jù)。最后，OVS-DPDK在轉(zhuǎn)發(fā)數(shù)據(jù)時(shí)，不同虛擬機(jī)（VM）的流量由于CPU瓶頸導(dǎo)致?lián)砣瑫?huì)隨機(jī)丟包，無(wú)法保障租戶帶寬隔離。

（3）高性能SR-IOV網(wǎng)絡(luò)（SR-IOV）

在一些對(duì)網(wǎng)絡(luò)有高性能需求的場(chǎng)景，如NFV業(yè)務(wù)部署，OVS-DPDK的數(shù)據(jù)轉(zhuǎn)發(fā)方式，無(wú)法滿足高性能網(wǎng)絡(luò)的需求，這樣就引入的SR-IOV透?jìng)鳎╬assthrough）到虛擬機(jī)（VM）的部署場(chǎng)景。

在SRIOV passthrough的場(chǎng)景下，虛擬機(jī)（VM）可以獲得與裸金屬主機(jī)上相比擬的網(wǎng)絡(luò)性能。但是，仍然存在兩個(gè)限制：

（1）SRIOV VF passthrough到VM后，VM的遷移性會(huì)受限，主要原因在于SRIOV這種passthrough I/O借助了Intel CPU VT-d（Virtualization Technology for Directed I/O）或AMD的IOMMU（I/O Memory Management Unit）技術(shù)，在VM上VF網(wǎng)卡初始化的時(shí)候，建立了Guest虛擬地址到Host物理地址的映射表，所以這種“有狀態(tài)”的映射表在熱遷移的過(guò)程中會(huì)丟失。

（2）由于SRIOV VFpassthrough到VM，而SRIOV PF直接連接到TOR上，在這種部署環(huán)境中虛擬機(jī)（VM）對(duì)外的網(wǎng)絡(luò)需要自定義，如需要像OVS-DPDK那樣自動(dòng)開(kāi)通網(wǎng)絡(luò)，則需要將TOR加入SDN控制器的管理范疇，由SDN控制器統(tǒng)一管控，這樣做通常會(huì)使網(wǎng)絡(luò)運(yùn)營(yíng)變的非常復(fù)雜。

針對(duì)上面第二個(gè)問(wèn)題，Mellanox最早提出在其智能網(wǎng)卡上支持OVS Fastpath硬件卸載，結(jié)合SRIOV VF passthrough到VM一起使用，提供臨近線速轉(zhuǎn)發(fā)的網(wǎng)絡(luò)能力，解決了虛擬機(jī)（VM）租戶網(wǎng)絡(luò)自動(dòng)化編排開(kāi)通的問(wèn)題。

圖OVS Fastpath硬件卸載虛擬化網(wǎng)絡(luò)

在OVS Fastpath卸載后，OVS轉(zhuǎn)發(fā)報(bào)文時(shí)，數(shù)據(jù)流首包仍然做軟件轉(zhuǎn)發(fā)，在轉(zhuǎn)發(fā)過(guò)程中生成Fastpath轉(zhuǎn)發(fā)流表并配置到硬件網(wǎng)卡上，這個(gè)數(shù)據(jù)流的后續(xù)報(bào)文則通過(guò)硬件直接轉(zhuǎn)發(fā)給虛擬機(jī)（VM）。由于早期的Mellanox智能網(wǎng)卡還沒(méi)有集成通用CPU核，OVS的控制面依然在物理主機(jī)上運(yùn)行。

（4）Virtio硬件加速虛擬化網(wǎng)絡(luò)（vDPA）

為了解決高性能SRIOV網(wǎng)絡(luò)的熱遷移問(wèn)題，出現(xiàn)了很多做法和嘗試，尚未形成統(tǒng)一的標(biāo)準(zhǔn)。在Redhat提出硬件vDPA架構(gòu)之前，Mellanox實(shí)現(xiàn)了軟件vDPA（即VF Relay）。理論上講，Mellanox的軟件vDPA并不能算是vDPA，其實(shí)就是將數(shù)據(jù)在用戶空間的virtio隊(duì)列和VF的接收隊(duì)列做了一次數(shù)據(jù)Relay。Redhat提出的硬件vDPA架構(gòu)，目前在DPDK和內(nèi)核程序中均有實(shí)現(xiàn)，基本是未來(lái)的標(biāo)準(zhǔn)架構(gòu)。Qemu支持兩種方式的vDPA，一種是vhost-user，配合DPDK中的vDPA運(yùn)行，DPDK再調(diào)用廠商用戶態(tài)vDPA驅(qū)動(dòng)；另一種方式是vhost-vdpa，通過(guò)ioctl調(diào)用到內(nèi)核通用vDPA模塊，通用vDPA模塊再調(diào)用廠商硬件專有的vDPA驅(qū)動(dòng)。

1)軟件vDPA:軟件vDPA也叫VF relay，由于需要軟件把VF上接收的數(shù)據(jù)通過(guò)virtio轉(zhuǎn)發(fā)給虛擬機(jī)（VM），如Mellanox在OVS-DPDK實(shí)現(xiàn)了這個(gè)relay，OVS流表由硬件卸載加速，性能上與SR-IOV VF直通（passthrough）方式比略有降低，不過(guò)實(shí)現(xiàn)了虛擬機(jī)（VM）的熱遷移特性。

2)硬件vDPA:硬件vDPA實(shí)際上是借助virtio硬件加速，以實(shí)現(xiàn)更高性能的通信。由于控制面復(fù)雜，所以用硬件難以實(shí)現(xiàn)。廠商自己開(kāi)發(fā)驅(qū)動(dòng)，對(duì)接到用戶空間DPDK的vDPA和內(nèi)核vDPA架構(gòu)上，可以實(shí)現(xiàn)硬件vDPA。目前Mellanox mlx5和Intel IFC對(duì)應(yīng)的vDPA適配程序都已經(jīng)合入到DPDK和kernel社區(qū)源碼。

圖virtio硬件加速虛擬化網(wǎng)絡(luò)

在硬件vDPA場(chǎng)景下，通過(guò)OVS轉(zhuǎn)發(fā)的流量首包依然由主機(jī)上的OVS轉(zhuǎn)發(fā)平面處理，對(duì)應(yīng)數(shù)據(jù)流的后續(xù)報(bào)文由硬件網(wǎng)卡直接轉(zhuǎn)發(fā)。

后來(lái)在Bluefield-2上，由于集成了ARM核，所以NVIDIA在與UCloud的合作中，將OVS的控制面也完全卸載到網(wǎng)卡到ARM核上，這樣主機(jī)上就可以將OVS完全卸載到網(wǎng)卡上。

二、網(wǎng)絡(luò)功能虛擬化（Network Function Virtualization）

伴隨著越來(lái)越多的業(yè)務(wù)上云，一些原來(lái)運(yùn)行在專用設(shè)備或者特定主機(jī)上的網(wǎng)絡(luò)產(chǎn)品也開(kāi)始重視上云后的按需擴(kuò)縮容能力，所以出現(xiàn)了網(wǎng)路功能虛擬化（NFV）產(chǎn)品。NFV產(chǎn)品主要以虛擬機(jī)（VM）或者容器（Container）的形態(tài)部署到云計(jì)算平臺(tái)上，對(duì)外提供對(duì)應(yīng)的網(wǎng)絡(luò)功能，如Load Balance，F(xiàn)irewall，NAT，vRouter，DPI和5G邊緣計(jì)算UPF等。這些NFV產(chǎn)品之前全部基于DPDK在X86 CPU上運(yùn)行，由于CPU算力上限問(wèn)題，通常難以提供對(duì)應(yīng)網(wǎng)絡(luò)帶寬的吞吐能力。DPU智能網(wǎng)卡的出現(xiàn)，為NFV加速提供了資源和可能。

（1）5G邊緣計(jì)算UPF（User PlaneFunction)

5G垂直行業(yè)對(duì)5G網(wǎng)絡(luò)提出了更高的要求，如大帶寬，高可靠，低時(shí)延，低抖動(dòng)等，這對(duì)用戶面數(shù)據(jù)轉(zhuǎn)發(fā)的核心5G UPF，提出了更高的實(shí)現(xiàn)要求。尤其在邊緣網(wǎng)絡(luò)，交互式VR/AR在大帶寬的要求下，還需要低時(shí)延，從而提高業(yè)務(wù)的用戶體驗(yàn)；而車路協(xié)同系統(tǒng)等，對(duì)高可靠和低時(shí)延低抖動(dòng)的要求更高，這是保障車路協(xié)同能夠?qū)崟r(shí)做出正確決策的關(guān)鍵；一些工業(yè)控制實(shí)時(shí)自動(dòng)化應(yīng)用，也是要求視頻數(shù)據(jù)實(shí)時(shí)傳輸?shù)椒?wù)端，并通過(guò)視頻識(shí)別等功能實(shí)時(shí)做出控制指令下發(fā)等等。這些典型的應(yīng)用，都對(duì)邊緣計(jì)算中5G UPF提出了更嚴(yán)苛的要求。

在5G邊緣計(jì)算中，未來(lái)的主要應(yīng)用場(chǎng)景包括：增強(qiáng)型視頻服務(wù)，監(jiān)測(cè)與追蹤類服務(wù)，實(shí)時(shí)自動(dòng)化，智能監(jiān)控，自動(dòng)機(jī)器人，危險(xiǎn)和維護(hù)傳感，增強(qiáng)現(xiàn)實(shí)，網(wǎng)聯(lián)車輛和遠(yuǎn)程操控等。對(duì)應(yīng)的5G技術(shù)指標(biāo)和特征也比較明顯。首先，超大帶寬（eMBB，Enhanced Mobile Broadband）要求單用戶峰值帶寬可達(dá)20Gbps，用戶體驗(yàn)數(shù)據(jù)速率在100Mbps；其次，超密連接（mMTC，Massive Machine Type Communication）要求每平方公里設(shè)備數(shù)量在10k到1M個(gè)終端，流量密度10Mbps每平方米；最后，超低時(shí)延（uRLLC, Ultra Reliable Low Latency Communication）要求時(shí)延在1～10ms，高可靠性達(dá)到99.999%。

圖5G業(yè)務(wù)網(wǎng)絡(luò)特征

傳統(tǒng)的5G UPF通常由軟件實(shí)現(xiàn)，運(yùn)行在X86 CPU上，雖然在吞吐上可以通過(guò)增加CPU來(lái)實(shí)現(xiàn)更大能力，但是，時(shí)延和抖動(dòng)通常都會(huì)比較高，很難穩(wěn)定支撐低時(shí)延低抖動(dòng)業(yè)務(wù)。對(duì)于超大帶寬，超低時(shí)延的需求，這類數(shù)據(jù)轉(zhuǎn)發(fā)業(yè)務(wù)更適合在硬件中實(shí)現(xiàn)，硬件實(shí)現(xiàn)更容易做到低時(shí)延低抖動(dòng)和大帶寬。

5GUPF業(yè)務(wù)模型復(fù)雜，需要選擇性卸載轉(zhuǎn)發(fā)，將高可靠低時(shí)延低抖動(dòng)業(yè)務(wù)要求的用戶會(huì)話卸載到硬件中。如圖3-5所示，數(shù)據(jù)流首包通過(guò)軟件轉(zhuǎn)發(fā)，然后將對(duì)應(yīng)的流表卸載到智能網(wǎng)卡，后續(xù)報(bào)文通過(guò)智能網(wǎng)卡硬件轉(zhuǎn)發(fā)，這樣可以在5G邊緣計(jì)算中，提供低時(shí)延低抖動(dòng)和超大帶寬網(wǎng)絡(luò)能力的同時(shí)，還能降低邊緣計(jì)算的整體功耗。

圖5G邊緣計(jì)算UPF硬件卸載方式

（2）智能DPI（Deep Packet Inspection）

DPI不論在運(yùn)營(yíng)商網(wǎng)絡(luò)還是互聯(lián)網(wǎng)數(shù)據(jù)中心，都是重要的配套設(shè)備。而且DPI功能是很多網(wǎng)絡(luò)功能產(chǎn)品的基礎(chǔ)功能，如IPS/IDS，5G UPF，DDoS防攻擊設(shè)備等，具有重要的產(chǎn)品價(jià)值。DPI具有高新建、高并發(fā)、高吞吐等特點(diǎn)，使得性能成為虛擬化部署的瓶頸。通過(guò)DPU智能網(wǎng)卡實(shí)現(xiàn)DPI流量卸載，性能可以提升在30%以上。

圖智能DPI硬件卸載

智能DPI基于智能網(wǎng)卡卸載DPI流量，軟件規(guī)則庫(kù)下發(fā)到硬件形成流識(shí)別的規(guī)則，再將軟件策略下發(fā)到硬件形成對(duì)應(yīng)的動(dòng)作。這樣數(shù)據(jù)流進(jìn)入網(wǎng)卡通過(guò)打時(shí)間戳進(jìn)行硬件解析，匹配識(shí)別規(guī)則庫(kù)，根據(jù)匹配的規(guī)則尋找對(duì)應(yīng)的策略，根據(jù)策略進(jìn)行計(jì)數(shù)，鏡像，丟棄和轉(zhuǎn)發(fā)等行為。通過(guò)硬件卸載DPI流量，不僅可以節(jié)省虛擬化DPI的CPU，還可以提升其吞吐量，同時(shí)降低了整體TCO。一些公有云的運(yùn)維系統(tǒng)也是通過(guò)DPI功能做流日志，除了運(yùn)維使用以外，還對(duì)用戶提供對(duì)應(yīng)的流日志服務(wù)。

三、云原生網(wǎng)絡(luò)功能

（1）云原生網(wǎng)絡(luò)架構(gòu)

云原生，從廣義上來(lái)說(shuō)，是更好的構(gòu)建云平臺(tái)與云應(yīng)用的一整套新型的設(shè)計(jì)理念與方法論，而狹義上講則是以docker容器和Kubernetes（K8S）為支撐的云原生計(jì)算基金會(huì)（CNCF）技術(shù)生態(tài)堆棧的新式IT架構(gòu)。對(duì)比虛擬機(jī)，容器應(yīng)用對(duì)磁盤(pán)的占用空間更小，啟動(dòng)速度更快，直接運(yùn)行在宿主機(jī)內(nèi)核上，因而無(wú)Hypervisor開(kāi)銷，并發(fā)支持上百個(gè)容器同時(shí)在線，接近宿主機(jī)上本地進(jìn)程的性能，資源利用率也更高。以K8S為代表的云原生容器編排系統(tǒng)，提供了統(tǒng)一調(diào)度與彈性擴(kuò)展的能力，以及標(biāo)準(zhǔn)化組件與服務(wù)，支持快速開(kāi)發(fā)與部署。

容器平臺(tái)包括容器引擎Runtime（如containerd，cri-o等），容器網(wǎng)絡(luò)接口（CNI，如calico，flannel，contiv，cilium等）和容器存儲(chǔ)接口（CSI，如EBS CSI，ceph-csi等）。

云原生平臺(tái)可以部署在裸金屬服務(wù)器上，也可以部署在虛擬機(jī)（VM）上。通常為了追求更高的性能，云原生平臺(tái)會(huì)部署在裸金屬上。如果考慮故障后更容易恢復(fù)，通常會(huì)部署在虛擬機(jī)（VM）上。

圖云原生網(wǎng)絡(luò)架構(gòu)介紹

云原生對(duì)于網(wǎng)絡(luò)的需求，既有基礎(chǔ)的二三層網(wǎng)絡(luò)聯(lián)通，也有四至七層的高級(jí)網(wǎng)絡(luò)功能。二三層的網(wǎng)絡(luò)主要是實(shí)現(xiàn)K8S中的CNI接口，具體如calico，flannel，weave，contiv，cilium等。主要是支持大規(guī)模實(shí)例，快速?gòu)椥陨炜s，自愈合，多集群多活等。四至七層網(wǎng)絡(luò)功能，主要是服務(wù)網(wǎng)格（Service Mesh）。服務(wù)網(wǎng)格的本質(zhì)是提供安全、可靠、靈活、高效的服務(wù)間通信。服務(wù)網(wǎng)格還提供了一些更加高級(jí)的網(wǎng)絡(luò)功能，如有狀態(tài)的通信，路由限流，灰度流量切換，熔斷監(jiān)控等。

（2）eBPF的硬件加速

eBPF是一項(xiàng)革命性的技術(shù)，可以在Linux內(nèi)核中運(yùn)行沙盒程序，而無(wú)需重新編譯內(nèi)核或者加載內(nèi)核模塊。在過(guò)去幾年，eBPF已經(jīng)成為解決以前依賴于內(nèi)核更改或者內(nèi)核模塊的問(wèn)題的標(biāo)準(zhǔn)方法。對(duì)比在Kubernetes上Iptables的轉(zhuǎn)發(fā)路徑，使用eBPF會(huì)簡(jiǎn)化其中大部分轉(zhuǎn)發(fā)步驟，提高內(nèi)核的數(shù)據(jù)轉(zhuǎn)發(fā)性能。Cilium是一個(gè)基于eBPF實(shí)現(xiàn)的開(kāi)源項(xiàng)目，提供和保護(hù)使用Linux容器管理平臺(tái)部署的應(yīng)用程序服務(wù)之間的網(wǎng)絡(luò)和API連接，以解決容器工作負(fù)載的新可伸縮性，安全性和可見(jiàn)性要求。Cilium超越了傳統(tǒng)的容器網(wǎng)絡(luò)接口（CNI），可提供服務(wù)解析，策略執(zhí)行等功能，實(shí)現(xiàn)了組網(wǎng)與安全一體化的云原生網(wǎng)絡(luò)。Cilium數(shù)據(jù)平面采用eBPF加速，能夠以Service/pod/container為對(duì)象進(jìn)行動(dòng)態(tài)地網(wǎng)絡(luò)和安全策略管理，解耦控制面等策略管理和不斷變化的網(wǎng)絡(luò)環(huán)境，具有應(yīng)用感知能力（如https，gRPC等應(yīng)用），從而實(shí)現(xiàn)對(duì)流量的精確化控制。同時(shí)它的狀態(tài)通過(guò)K-V數(shù)據(jù)庫(kù)來(lái)維護(hù)實(shí)現(xiàn)可擴(kuò)展設(shè)計(jì)。

基于eBPF的Cilium已經(jīng)被證明是Kubernetes云原生網(wǎng)絡(luò)的最佳實(shí)踐，國(guó)內(nèi)阿里云和騰訊云勻已在自己的公有云中引用了Cilium構(gòu)建自己的云原生平臺(tái)。

為進(jìn)一步提升性能，Netronome將eBPF路徑上的部分功能卸載到硬件網(wǎng)卡，如XDP和Traffic Classifier cls-bpf，實(shí)現(xiàn)了對(duì)于用戶無(wú)感知的eBPF卸載加速。硬件卸載的eBPF程序可以直接將報(bào)文送到任意內(nèi)核eBPF程序，eBPF中map的維護(hù)對(duì)于用戶程序和內(nèi)核程序是透明的。

eBPF程序的編譯需要在生成內(nèi)核微碼的基礎(chǔ)上，加入編譯硬件可識(shí)別的微碼程序，并將對(duì)應(yīng)的硬件微碼程序裝載到網(wǎng)卡中。從而實(shí)現(xiàn)eBPF硬件卸載。

（3）云原生Istio服務(wù)網(wǎng)格

Istio是CNCF主推的微服務(wù)框架，實(shí)現(xiàn)了云原生四至七層網(wǎng)絡(luò)能力。Istio在數(shù)據(jù)平面通過(guò)Sidecar對(duì)流量進(jìn)行劫持，實(shí)現(xiàn)了無(wú)代碼侵入的服務(wù)網(wǎng)格?？刂破矫娼M件中，pilot負(fù)責(zé)下發(fā)控制，mixer收集運(yùn)行的狀態(tài)，citadel則負(fù)責(zé)安全證書(shū)方面的處理。

圖服務(wù)網(wǎng)格Istio架構(gòu)

在Istio中，原生的七層代理使用的是Envoy，Envoy提供了動(dòng)態(tài)服務(wù)發(fā)現(xiàn)，負(fù)載均衡的能力，同時(shí)支持TLS連接，可以代理HTTP/1.1 & HTTP/2 & gRPC等協(xié)議。同時(shí)支持熔斷器，流量拆分，故障注入等能力和豐富的度量指標(biāo)。另外，阿里還提出了MOSN作為Istio的七層代理，這里不再介紹細(xì)節(jié)。由于引入七層代理后，增加數(shù)據(jù)轉(zhuǎn)發(fā)時(shí)延。Broadcom嘗試在StingrayDPU智能網(wǎng)卡將Enovy以網(wǎng)關(guān)模式卸載到智能網(wǎng)卡的ARM核上，用了八個(gè)ARM核中的六個(gè)來(lái)做Enovy卸載支持100G網(wǎng)卡上的流量。這種方式是否能夠適用于當(dāng)前Sidecar上代理模式的Enovy，還有待探索，另外，編排和管理方式也需要進(jìn)一步調(diào)研。

圖Envoy卸載實(shí)例

OVS硬件卸載的加速方式主要由OVN-Kubernetes和AntreaCNI做控制面。由于OVS的數(shù)據(jù)面在OpenStack云平臺(tái)上已經(jīng)有了硬件卸載的先例，所以，在云原生網(wǎng)絡(luò)再做硬件卸載，基本上沒(méi)有技術(shù)障礙，只需要增加NAT處理能力即可。但是，這種硬件卸載方式，由于沒(méi)有涉及到七層代理，所以不可避免的還是會(huì)將報(bào)文上送到內(nèi)核轉(zhuǎn)發(fā)，進(jìn)而在數(shù)據(jù)轉(zhuǎn)發(fā)性能上的提升相對(duì)有限。

圖OVS硬件加速

總體而言，在云原生網(wǎng)絡(luò)中智能網(wǎng)卡的應(yīng)用場(chǎng)景還需要進(jìn)一步探索，目前尚無(wú)一個(gè)相對(duì)完美的能夠解決服務(wù)網(wǎng)格性能和時(shí)延問(wèn)題的方案。

四、RDMA網(wǎng)絡(luò)功能

（1）RDMA網(wǎng)絡(luò)功能介紹

面對(duì)高性能計(jì)算、大數(shù)據(jù)分析和浪涌型IO高并發(fā)、低時(shí)延應(yīng)用，現(xiàn)有TCP/IP軟硬件架構(gòu)和應(yīng)用高CPU消耗的技術(shù)特征根本不能滿足應(yīng)用的需求。這主要體現(xiàn)在處理時(shí)延過(guò)大——數(shù)十微秒，多次內(nèi)存拷貝、中斷處理，上下文切換，復(fù)雜的TCP/IP協(xié)議處理，以及存儲(chǔ)轉(zhuǎn)發(fā)模式和丟包導(dǎo)致額外的時(shí)延。而RDMA通過(guò)網(wǎng)絡(luò)在兩個(gè)端點(diǎn)的應(yīng)用軟件之間實(shí)現(xiàn)Buffer的直接傳遞，相比TCP/IP，RDMA無(wú)需操作系統(tǒng)和協(xié)議棧的介入，能夠?qū)崿F(xiàn)端點(diǎn)間的超低時(shí)延、超高吞吐量傳輸，不需要網(wǎng)絡(luò)數(shù)據(jù)的處理和搬移耗費(fèi)過(guò)多的資源，無(wú)需OS和CPU的介入。RDMA的本質(zhì)實(shí)際上是一種內(nèi)存讀寫(xiě)技術(shù)。

圖對(duì)比RDMA和TCP/IP收發(fā)數(shù)據(jù)

RDMA和TCP/IP網(wǎng)絡(luò)對(duì)比可以看出，RDMA的性能優(yōu)勢(shì)主要體現(xiàn)在：

（1）零拷貝——減少數(shù)據(jù)拷貝次數(shù)，由于沒(méi)有將數(shù)據(jù)拷貝到內(nèi)核態(tài)并處理數(shù)據(jù)包頭部到過(guò)程，傳輸延遲會(huì)顯著減少。

（2）Kernel Bypass和協(xié)議卸載——不需要內(nèi)核參與，數(shù)據(jù)通路中沒(méi)有繁瑣的處理報(bào)頭邏輯，不僅會(huì)使延遲降低，而且也節(jié)省了CPU的資源。

（2）RDMA硬件卸載方式

原生RDMA是IBTA（InfiniBand Trade Association）在2000年發(fā)布的基于InfiniBand的RDMA規(guī)范；基于TCP/IP的RDMA稱作iWARP，在2007年形成標(biāo)準(zhǔn)；基于Ethernet的RDMA叫做RoCE，在2010年發(fā)布協(xié)議，基于增強(qiáng)型以太網(wǎng)并將傳輸層換成IB傳輸層實(shí)現(xiàn)；在2014年，IBTA發(fā)布了RoCEv2，引入IP解決擴(kuò)展性問(wèn)題，可以跨二層組網(wǎng)，引入U(xiǎn)DP解決ECMP負(fù)載分擔(dān)等問(wèn)題。

圖RDMA協(xié)議棧介紹

InfiniBand是一種專為RDMA設(shè)計(jì)的網(wǎng)絡(luò)，從硬件級(jí)別保證可靠傳輸。全球HPC高算系統(tǒng)TOP500大效能的超級(jí)計(jì)算機(jī)中有相當(dāng)多套系統(tǒng)在使用InfiniBand Architecture（IBA）。最早做InfiniBand的廠商是IBM和HP，現(xiàn)在主要是NVIDIA的Mellanox。InfiniBand從L2到L4都需要自己的專有硬件，成本非常高。

iWARP直接將RDMA實(shí)現(xiàn)在TCP上，優(yōu)點(diǎn)就是成本最低，只需要采購(gòu)支出iWARP的NIC即可以使用RDMA，缺點(diǎn)是性能不好，因?yàn)門CP協(xié)議棧本身過(guò)于重量級(jí)，即使按照iWARP廠商的通用做法將TCP卸載到硬件上實(shí)現(xiàn)，也很難超越IB和RoCE的性能。

RoCE（RDMA over Converged Ethernet）是一個(gè)允許在以太網(wǎng)上執(zhí)行RDMA的網(wǎng)絡(luò)協(xié)議。由于底層使用的以太網(wǎng)幀頭，所以支持在以太網(wǎng)基礎(chǔ)設(shè)施上使用RDMA。不過(guò)需要數(shù)據(jù)中心交換機(jī)DCB技術(shù)保證無(wú)丟包。相比IB交換機(jī)時(shí)延，交換機(jī)時(shí)延要稍高一些。由于只能應(yīng)用于二層網(wǎng)絡(luò)，不能跨越IP網(wǎng)段使用，市場(chǎng)應(yīng)用場(chǎng)景相對(duì)受限。

RoCEv2協(xié)議構(gòu)筑于UDP/IPv4或UDP/IPv6協(xié)議之上。由于基于IP層，所以可以被路由，將RoCE從以太網(wǎng)廣播域擴(kuò)展到IP可路由。由于UDP數(shù)據(jù)包不具有保序的特征，所以對(duì)于同一條數(shù)據(jù)流，即相同五元組的數(shù)據(jù)包要求不得改變順序。另外，RoCEv2還要利用IP ECN等擁塞控制機(jī)制，來(lái)保障網(wǎng)絡(luò)傳輸無(wú)損。RoCEv2也是目前主要的RDMA網(wǎng)絡(luò)技術(shù)，以NVIDIA的Mellanox和Intel為代表的廠商，均支持RoCEv2的硬件卸載能力。