作者簡介:KIKI,中國科學(xué)院計算技術(shù)研究所在讀博士生
01引言
遠(yuǎn)程直接內(nèi)存訪問(Remote Direct Memory Access,RDMA)技術(shù)允許應(yīng)用程序繞過操作系統(tǒng)內(nèi)核,以零拷貝的方式和遠(yuǎn)程計算機(jī)進(jìn)行網(wǎng)絡(luò)通信,具有低延遲和高帶寬的優(yōu)勢。RDMA協(xié)議主要包括Inifiband、RoCE以及iWARP。實(shí)現(xiàn)RDMA協(xié)議的I/O設(shè)備被稱為RNIC。主流云服務(wù)提供商已經(jīng)開始廣泛部署RNIC,例如亞馬遜云推出的彈性網(wǎng)絡(luò)適配器(Elastic Network Adapter,ENA)[1]。同時,云服務(wù)提供商通過硬件虛擬化技術(shù)對物理資源進(jìn)行池化管理,提升資源效率。
硬件虛擬化(Virtualization)技術(shù)是一種計算機(jī)資源管理技術(shù),在各類計算機(jī)硬件(例如CPU、內(nèi)存、存儲、網(wǎng)絡(luò)設(shè)備)上創(chuàng)建一個抽象層,將單個物理硬件資源模擬為多個虛擬資源。本文討論針對RDMA網(wǎng)卡(RDMA Network Interface Controller,RNIC)的虛擬化技術(shù),即將一個RNIC模擬為多個RNIC供虛擬機(jī)(Virtual Machine,VM)使用。根據(jù)實(shí)現(xiàn)方式,I/O虛擬化可以分為直通,全虛擬化、半虛擬化以及基于硬件輔助的全虛擬化。
RNIC虛擬化方案既要維持RDMA的高性能優(yōu)勢,又要滿足云環(huán)境的部署要求。RDMA網(wǎng)絡(luò)相對于傳統(tǒng)TCP網(wǎng)絡(luò)的性能優(yōu)勢包括更低的延遲、更高的帶寬以及更低的CPU占用,因此針對RNIC的虛擬化方案首先應(yīng)該盡可能降低虛擬化引入的RDMA性能開銷。同時,云計算對虛擬實(shí)例之間的隔離性,虛擬實(shí)例的可遷移性以及虛擬實(shí)例的可管控性都有比較高的要求。本文針對虛擬機(jī)和容器兩種實(shí)體的典型RDMA虛擬化技術(shù)進(jìn)行了調(diào)研,并且對相關(guān)領(lǐng)域的研究內(nèi)容進(jìn)行了總結(jié)和展望。
02背景知識介紹
RDMA關(guān)鍵特征簡介
如Figure 1所示,RDMA技術(shù)采用了控制路徑(Control path)-數(shù)據(jù)路徑(Data path)分離的思想。RDMA的控制面包括設(shè)備管理,Queue Pair、Completion Queue、Memory Region等資源的管理,以及異常處理等功能。RDMA的數(shù)據(jù)面包括請求的發(fā)起以及請求的完成確認(rèn)。RDMA用戶態(tài)的庫向應(yīng)用提供統(tǒng)一的、標(biāo)準(zhǔn)的動詞(Verbs)接口。Verbs接口定義了控制面和數(shù)據(jù)面的具體內(nèi)容,因此Verbs接口也可以進(jìn)一步分為控制Verbs和數(shù)據(jù)Verbs。控制Verbs都會經(jīng)過內(nèi)核態(tài)RNIC驅(qū)動的轉(zhuǎn)發(fā)到達(dá)RNIC內(nèi)部的控制Verbs處理單元。控制Verbs和內(nèi)核驅(qū)動交互的過程涉及系統(tǒng)調(diào)用和上下文切換,被認(rèn)為是慢路徑。數(shù)據(jù)Verbs通過內(nèi)存映射I/O的方式直接和RNIC內(nèi)部的數(shù)據(jù)Verbs處理單元交互。數(shù)據(jù)Verbs直接訪問RNIC的過程被認(rèn)為是快路徑。RDMA的數(shù)據(jù)傳輸性能取決于數(shù)據(jù)Verbs的實(shí)現(xiàn)。
Figure 1 RDMA控制和數(shù)據(jù)路徑
RDMA數(shù)據(jù)Verbs的高性能依賴于數(shù)據(jù)傳輸過程中的零拷貝實(shí)現(xiàn)。零拷貝實(shí)現(xiàn)要求RNIC具有主動發(fā)起PCIe DMA直接讀寫應(yīng)用緩沖區(qū)的能力。應(yīng)用在RDMA數(shù)據(jù)傳輸中使用進(jìn)程虛擬地址,然而PCIe DMA需要總線映射后的DMA地址。RNIC需要主動將應(yīng)用緩沖區(qū)的虛擬地址翻譯為DMA地址。在具體的實(shí)現(xiàn)中,RNIC會緩存應(yīng)用進(jìn)程頁表的一部分到其管理的內(nèi)存翻譯表(Memory Translation Table,MTT)。在RDMA虛擬化的實(shí)現(xiàn)中,由于Guest OS中映射的DMA地址不一定連續(xù),MTT表中的DMA地址需要由Hypervisor提供。
Figure 2 RNIC通過主動的內(nèi)存翻譯實(shí)現(xiàn)零拷貝傳輸
虛擬機(jī)和容器簡介
虛擬化技術(shù)使軟件應(yīng)用程序能夠運(yùn)行在虛擬硬件(通過虛擬機(jī)和虛擬機(jī)監(jiān)控程序(Virtual Machine Monitor,VMM)實(shí)現(xiàn)虛擬化)或虛擬操作系統(tǒng)(通過容器(Container)實(shí)現(xiàn)虛擬化)上。虛擬機(jī)(VM),也稱為客戶機(jī),是一個軟件模擬的硬件平臺,為客戶操作系統(tǒng)(Guest OS)提供虛擬操作環(huán)境。VMM也稱為Hypervisor,是一個運(yùn)行在實(shí)際主機(jī)(Host)的軟件程序,監(jiān)督虛擬機(jī)上客戶操作系統(tǒng)的執(zhí)行。Hypervisor包括Type 1和Type 2兩類,其中Type 1 Hypervisor直接控制Host的硬件,而Type 2 Hypervisor通過Host操作系統(tǒng)間接控制硬件。目前主流的Hypervisor實(shí)現(xiàn)多屬于Type2,包括KVM,VMware以及VirtualBox等。容器是一個虛擬運(yùn)行時環(huán)境集合,包含執(zhí)行目標(biāo)軟件應(yīng)用所需的所有資源(例如文件系統(tǒng)、CPU、內(nèi)存、進(jìn)程空間以及網(wǎng)絡(luò)接口等)。
容器可以看作是對操作系統(tǒng)的虛擬化(也有觀點(diǎn)認(rèn)為容器不能歸類到虛擬化技術(shù)),并不模擬底層硬件。相對于虛擬機(jī),容器更加輕量化,啟動速度也更加快。容器引擎是運(yùn)行容器的基礎(chǔ)環(huán)境,主流實(shí)現(xiàn)包括Docker以及LXC等。在容器規(guī)模比較大的情況,需要使用諸如Docker Swarm或Kubernetes(K8s)等容器編排(Containter Orchestration)工具管理容器的部署。
Figure 3 虛擬機(jī)和容器對比
03針對虛擬機(jī)的RDMA虛擬化技術(shù)
Figure 4 RDMA虛擬化技術(shù)發(fā)展歷程
最基礎(chǔ)的RNIC虛擬化方案是使用Hypervisor作為虛擬機(jī)和RNIC的唯一中間層,RDMA全部的數(shù)據(jù)和控制路徑的全部請求都被Hypervisor截獲、翻譯以及執(zhí)行,即全虛擬化I/O技術(shù)。如Figure 5所示,Hypervisor中的RDMA Proxy處理VM1和VM2的控制路徑和數(shù)據(jù)路徑。VM每次執(zhí)行RDMA相關(guān)操作都需要通過VM-Exit將控制權(quán)交給VMM,VMM處理完后再通過VM-entry重新進(jìn)入到VM。全虛擬化具有靈活可控的優(yōu)勢,不需要為VM提供專有驅(qū)動,且云計算的各類要求可以在RDMA Proxy中實(shí)現(xiàn)。VM Exit/Entry過程涉及從VM到Hypervisor之間的上下文切換,會產(chǎn)生相當(dāng)大的性能開銷。由于全虛擬化的性能開銷較大,并未在工業(yè)界和學(xué)術(shù)界調(diào)查到基于全虛擬化技術(shù)的RNIC虛擬化方案。
Figure 5 全虛擬化RDMA實(shí)現(xiàn)示意
另外一種純軟件實(shí)現(xiàn)的虛擬化技術(shù)是半虛擬化(Paravirtualization),其由前端驅(qū)動和后端驅(qū)動共同模擬實(shí)現(xiàn)。在客戶機(jī)中運(yùn)行的驅(qū)動程序稱之為前端(Frontend),在主機(jī)上與前端通信的驅(qū)動程序稱之為后端(Backend)。前端發(fā)送VM請求給后端,后端驅(qū)動處理完這些請求后再返回給前端。相對于全虛擬化,半虛擬化能夠減少VM Exit/Entry次數(shù),性能相對提升。VMware公司提出的vRDMA [2]屬于半虛擬化RDMA方案,其整體架構(gòu)如Figure 6所示。vRDMA向Guest OS的RDMA應(yīng)用提供VMCI虛擬設(shè)備,libvrdma是VMCI虛擬設(shè)備的用戶態(tài)驅(qū)動,vRDMA Driver是VMCI虛擬設(shè)備的用戶態(tài)驅(qū)動。同時,VRDMA Driver也是半虛擬化框架中的前端驅(qū)動,后端驅(qū)動是Hypervisor中的vRDMA VMCI Endpoint。vRDMA VMCI Endpoin最終通過RDMA內(nèi)核Verbs調(diào)用RDMA內(nèi)核態(tài)驅(qū)動。
Figure 6 VMvare vRDMA實(shí)現(xiàn)架構(gòu)
硬件輔助虛擬化包括直通和SR-IOV兩種主流方案。RNIC以一個PCIe設(shè)備的形式接入到現(xiàn)有系統(tǒng),因此最基礎(chǔ)的硬件輔助RNIC虛擬化方案是采用Intel VT-D或者AMD Vi技術(shù)將RNIC直接綁定到一個虛擬機(jī),這種虛擬化方法也被稱為直通(Passthrough)。直通方式能夠使得虛擬機(jī)獨(dú)占RNIC,RNIC性能可以實(shí)現(xiàn)零損耗。然而一臺主機(jī)上會存在多個虛擬機(jī),如果采用直通方式實(shí)現(xiàn)RNIC虛擬化,則主機(jī)上安裝的RNIC數(shù)量需要和主機(jī)最大支持虛擬機(jī)數(shù)量相等。顯然,直通方式的并不具備虛擬機(jī)層面的可擴(kuò)展性。SR-IOV(Single Root Input/Output Virtualization)技術(shù)能夠?qū)⒁粋€物理PCIe設(shè)備模擬成多個虛擬的PCIe設(shè)備(基于SR-IOV引入的Virtual Function,VF),專門用于針對VM的網(wǎng)卡虛擬化。根據(jù)OSU大學(xué)公開的性能評估結(jié)果 [3],SR-IOV虛擬化RDMA的小消息延遲相對于非虛擬化RDMA只增加了0.5us~1us,大消息延遲和非虛擬化RDMA無明顯差距。此外,基于SR-IOV的虛擬化RDMA和非虛擬化RDMA的可達(dá)帶寬無明顯差距。Purdue大學(xué)的Malek等人 [4]提出了針對SR-IOV虛擬化RDMA的參數(shù)(例如中斷聚合閾值、共享接收隊列水線)優(yōu)化方法,進(jìn)一步減小了SR-IOV虛擬化RDMA和非虛擬化RDMA的性能差距。僅就RDMA虛擬化的性能而言,SR-IOV可以被認(rèn)為是最優(yōu)的選擇。然而SR-IOV并不靈活,不能滿足云計算的可遷移性和可管控性要求。例如,Mellanox ConnextX-4/5/6系列RNIC在重新配置SR-IOV的VF數(shù)量時需要首先將VF數(shù)量清零 [5],清零意味著當(dāng)前正使用VF的VM需要放棄其對應(yīng)的虛擬RNIC。假設(shè)當(dāng)前主機(jī)RNIC的SR-IOV配置了4個VF,因?yàn)闃I(yè)務(wù)需求需要從其他主機(jī)遷入一個VF,則需要將SR-IOV的VF數(shù)量重新配置為8,則當(dāng)前4個VM都需要放棄其虛擬RNIC。此外,基于SR-IOV的虛擬化方案需要在RDMA網(wǎng)卡內(nèi)部集成支持虛擬網(wǎng)絡(luò)的2層交互模塊(L2 Switch),在將VM從一個主機(jī)熱遷移到另外一個主機(jī)時需要重新配置L2 Switch,硬件重配置通常被認(rèn)為是不靈活的。
Figure 7 基于Passthrough和SR-IOV虛擬化方案對比
混合虛擬化利用了RDMA設(shè)計中的控制-數(shù)據(jù)路徑分離的特點(diǎn),對控制路徑使用半虛擬化,對數(shù)據(jù)路徑采用基于內(nèi)存映射的硬件直通。IBM研究人員提出的HyV [6]是混合虛擬化的代表案例,相應(yīng)的論文發(fā)表在2015年的VEE會議。在控制路徑上,VM中的前端驅(qū)動攔截用戶態(tài)驅(qū)動的ibv_create_qp, ibv_create_cq等控制Verbs轉(zhuǎn)發(fā)到到Hypervisor中的后端驅(qū)動。后端驅(qū)動對接受到的控制Verbs調(diào)用實(shí)現(xiàn)VM層面的隔離、安全以及資源管控等要求后,將控制Verbs轉(zhuǎn)發(fā)給RNIC設(shè)備驅(qū)動。在后端驅(qū)動中,內(nèi)存映射相關(guān)的控制路徑需要實(shí)現(xiàn)1)將RNIC提供的隊列門鈴映射到VM進(jìn)程的地址空間;2)QP等資源占用的內(nèi)存在后端驅(qū)動的地址空間分配,需要映射到VM進(jìn)程的地址空間;3)VM進(jìn)程數(shù)據(jù)緩沖區(qū)對應(yīng)的Guest VA到Host PA映射需要同步到RNIC。在數(shù)據(jù)路徑上,應(yīng)用通過映射后的門鈴和直接和RNIC交互,實(shí)現(xiàn)post_send,post_recv以及poll_cq。在具體實(shí)現(xiàn)上,HyV使用成熟的Virtio框架實(shí)現(xiàn)了控制路徑的前后端驅(qū)動。實(shí)驗(yàn)評估顯示HyV的性能和SR-IOV相近,在資源管理的靈活性上接近半虛擬化。微軟提出的Endure(Enlighteded Network Direct On Azure) [7]以及華為提出的virtio-RDMA [8]都沿用了類似HyV的設(shè)計。在具體的實(shí)現(xiàn)上,Endure采用自定義的VMBus實(shí)現(xiàn)控制路徑Guest-Host交互,而不是沿用virtio。Virtio-RDMA將HyV的前端驅(qū)動重新實(shí)現(xiàn)在Guest OS的用戶態(tài),減少上下文切換的次數(shù)。
以HyV為代表的RDMA混合虛擬化提出后,通過半虛擬化實(shí)現(xiàn)控制面和通過內(nèi)存映射方式實(shí)現(xiàn)數(shù)據(jù)面直通硬件的方案已經(jīng)成為共識。如何改造繼續(xù)改造RDMA虛擬化方案,使得其更好地適應(yīng)云計算特定的需求成為新的研究關(guān)注的。例如華為在SGICOMM 2021提出的MasQ [9],進(jìn)一步在虛擬化控制面強(qiáng)化了租戶隔離、安全隔離以及服務(wù)質(zhì)量的設(shè)計,使得虛擬化RDMA能夠在VPC(Virtual Private Cloud)網(wǎng)絡(luò)部署。
Figure 8 HyV混合虛擬化和半虛擬對比
04針對容器的RDMA虛擬化技術(shù)
容器可以看作是在主機(jī)操作系統(tǒng)上執(zhí)行的進(jìn)程,由主機(jī)操作系統(tǒng)提供資源隔離和命名空間(Namespace)的隔離。Namespace是Linux內(nèi)核提供的資源隔離技術(shù),可以實(shí)現(xiàn)網(wǎng)絡(luò)、文件系統(tǒng)以及進(jìn)程資源等的隔離。針對容器的RDMA虛擬化技術(shù),本質(zhì)上是在網(wǎng)絡(luò)Namespace的基礎(chǔ)上創(chuàng)建虛擬RDMA設(shè)備接口的過程。針對虛擬機(jī)的RDMA虛擬化技術(shù)是可以直接遷移到容器上的。Mellanox公司在2018年推出出了針對Docker容器網(wǎng)絡(luò)設(shè)備SR-IOV和Passthrough插件 [10],該插件能夠在容器內(nèi)部創(chuàng)建虛擬RDMA設(shè)備或?qū)⑽锢碓O(shè)備綁定到某一個具體的容器。此外,Mellanox SR-IOV/Passthrough插件還利用網(wǎng)卡的的VLAN卸載功能對容器提供基于VLAN的虛擬網(wǎng)絡(luò)支持。
SR-IOV能夠提供良好的性能,但是不能完全滿足云計算所需要的靈活性需求。特別地,容器對虛擬化方案的靈活性需求更高,現(xiàn)有研究工作主要從這個角度入手。微軟的研究人員認(rèn)為基于SR-IOV的虛擬化方案不能滿足容器需要的便攜性(Portability)要求。在基于SR-IOV的方案種,更新容器的IP需要同時更新網(wǎng)卡上的VLAN路由表。此外,基于SR-IOV的方案使得容器可以直接訪問物理RDMA網(wǎng)卡,云服務(wù)提供商不能靈活地對容器的RDMA業(yè)務(wù)進(jìn)行管控。
FreeFlow [11]是微軟提出的容器虛擬化方案,該方案包括FreeFlow NetLib、FreeFlow Router以及FreeFlow Orchestrator。FreeFlow可以看作是半虛擬化設(shè)計,F(xiàn)reeFlow Netlib相當(dāng)于容器內(nèi)部的前端,而FreeFlow Router相當(dāng)于主機(jī)上的后端。FreeFlow Netlib以標(biāo)準(zhǔn)的用戶態(tài)Verbs API作為基礎(chǔ),從而保持對應(yīng)用透明。FreeFlow Netlib通過劫持控制路徑上的RNIC文件描述符請求,避免直接劫持Verbs API調(diào)用帶來的RDMA數(shù)據(jù)結(jié)構(gòu)序列化復(fù)雜度。FreeFlow Netlib將劫持到的RNIC文件描述符請求通過Unix Socket File Descriptor或者共享內(nèi)存的方式轉(zhuǎn)發(fā)到FreeFlow Router。FreeFlow Netlib和FreeFlow Router都是兩個進(jìn)程,通過Unix Socket File Descriptor可以實(shí)現(xiàn)兩個進(jìn)程之間的通信,但是這種通信方式延遲開銷在5us以上,不能維持RDMA的低延遲要求。FreeFlow同時設(shè)計了基于共享內(nèi)存的進(jìn)程間通信方式,這種通信延遲低但是需要CPU資源輪詢共享內(nèi)存。FreeFlow Route是位于主機(jī)的一個進(jìn)程,代替同一主機(jī)上的容器和物理RDMA網(wǎng)卡交互。為了實(shí)現(xiàn)數(shù)據(jù)路徑上的零拷貝,F(xiàn)reeFlow Router將其內(nèi)部的共享數(shù)據(jù)緩沖區(qū)(Shared Memory)和容器內(nèi)應(yīng)用緩沖區(qū)映射到同一塊物理內(nèi)存。為了實(shí)現(xiàn)這種映射,F(xiàn)reeFlow提供主動分配和被動重映射的方法。主動分配方法需要應(yīng)用主動調(diào)用FreeFlow自定義的ibv_malloc和ibv_free接口分配和釋放FreeFlow Router內(nèi)部預(yù)留的Shared Memory。被動重映射需要FreeFlow Netlib在FreeFlow Router處理完內(nèi)存注冊請求后,將應(yīng)用通過malloc申請的內(nèi)存物理頁重新映射到FreeFlow Router返回的Shared Memory。FreeFlow Orchestrator負(fù)責(zé)集群內(nèi)全部容器的網(wǎng)絡(luò)編排,例如編址、訪問控制。此外,F(xiàn)reeFlow Orchestrator還需要管理容器內(nèi)應(yīng)用緩沖區(qū)虛擬地址到FreeFlow Router內(nèi)部Shared Memory指針的映射關(guān)系。
Figure 9 FreeFlow的總體架構(gòu)
在標(biāo)準(zhǔn)的容器生產(chǎn)中,容器網(wǎng)絡(luò)接口應(yīng)遵循云原生計算基金會(Cloud Native Computing Foundation,CNCF)規(guī)定的容器網(wǎng)絡(luò)接口(Container Network Interface,CNI)規(guī)范 [12],然而FreeFlow和CNI標(biāo)準(zhǔn)并不兼容。Mellanox在2021年推出了針對K8s容器編排平臺的CNI插件RDMA CNI plugin [13],使得基于SR-IOV的RDMA網(wǎng)絡(luò)設(shè)備資源池能夠集成到K8s。Container Runtime (例如Docker)在創(chuàng)建容器時,先創(chuàng)建好Network Namespace (netns),然后調(diào)用RDMA CNI plugin為這個netns配置RDMA網(wǎng)絡(luò),其后再啟動容器內(nèi)的應(yīng)用。
Figure 10 CNI插件關(guān)系圖
05總結(jié)與展望
本文分別從虛擬機(jī)和容器2個方面闡述了對RDMA虛擬化的相關(guān)研究。從虛擬機(jī)角度來看,以HyV為代表的混合虛擬化方案利用了RDMA控制-數(shù)據(jù)分離的設(shè)計特征,能夠在控制面的靈活性和數(shù)據(jù)面的性能上取得很好的權(quán)衡。未來的研究應(yīng)該重點(diǎn)關(guān)注控制面的靈活性,面向云計算業(yè)務(wù)實(shí)際需求優(yōu)化。從容器角度來看,容器和物理RDMA網(wǎng)卡之間的軟件中間層比虛擬機(jī)更輕薄,但是容器網(wǎng)絡(luò)的復(fù)雜性是要高于虛擬機(jī)的,同時容器的規(guī)模也要比虛擬機(jī)大。容器網(wǎng)絡(luò)和容器規(guī)模要求網(wǎng)絡(luò)2層交換層具有高靈活性,高可擴(kuò)展性,因此目前主流的SR-IOV的容器虛擬化方案必須要在網(wǎng)卡硬件上實(shí)現(xiàn)滿足容器部署需求的交換層。DPU上同時具備了靈活可編程網(wǎng)絡(luò)引擎,RDMA引擎以及SR-IOV的支持,有潛力能夠在性能、靈活性以及可擴(kuò)展性層面取得比較好的權(quán)衡。
-
cpu
+關(guān)注
關(guān)注
68文章
10698瀏覽量
209329 -
計算機(jī)
+關(guān)注
關(guān)注
19文章
7168瀏覽量
87144 -
內(nèi)存
+關(guān)注
關(guān)注
8文章
2902瀏覽量
73534 -
硬件
+關(guān)注
關(guān)注
11文章
3112瀏覽量
65842 -
RDMA
+關(guān)注
關(guān)注
0文章
74瀏覽量
8894
原文標(biāo)題:RDMA RNIC虛擬化
文章出處:【微信號:SDNLAB,微信公眾號:SDNLAB】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論