NFV DPDK以及部分使用者態協議研究

2022-03-28 11:14:16 字數 3925 閱讀 7887

對筆者而言,這是乙個挺新的領域,比較有意思。

一、解釋名詞:

nfv(network function virtualization):通過使用x86等通用性硬體以及虛擬化技術,來承載很多功能的軟體處理。從而降低網路昂貴的裝置成本。 這項技術的目的在於軟硬體的解耦合,讓網路裝置功能不再依賴於底層硬體,為啥呢,因為硬體研發周期長,貴啊。

dpdk(intel data plane development kit):intel資料面開發包,它是一組快速處理資料報的開發平台介面。

二、我們的網路存在什麼問題?

目前伺服器併發量達到c10k是沒有問題的,通過軟體作出了比較好的解決方案,例如nginx、lighthttp等基於事件驅動的web框架和tornado這類非阻塞web框架,都能夠較好的解決萬級別的使用者請求。目前的非阻塞或者非同步,原理上都是執行緒的非同步模式,也就是說還是需要執行緒進行上下文切換,只不過區別在於核心何時產生中斷。 

但是這種非同步模式到了c10m基本就不夠用了,網路請求達到了千萬級,這在以前也許是網路裝置廠商需要考慮的事情,隨著硬體裝置的發展,越來越趨於模組的統一化。例如曾經網路專用處理器是intel公司的主力產品線,誕生了ixp4xx~ixp28xx等一系列專用處理晶元,而在2023年左右,amd和intel曾經爆發過一場多核之戰,隨著新一代core架構的誕生(intel要感謝以色列的工程師),這場戰爭基本宣告結束,但是在當時,amd在技術上曾經一度領先,我的第一台電腦cpu就是amd的。這次商業大戰讓intel思考使用通用多核處理器取代ixp專用處理器,由此ixp的研發體系開始向intel多核cpu轉型,這為dpdk的誕生創造了條件。

為啥為intel向通用cpu轉型就會產生dpdk呢,因為使用通用的底層硬體我們就可以不必太關注底層,大家都是用的x86,都是用的risc,所以更多的功能可以放在軟體層面來完成,尤其是硬體開發成本和週期是遠遠超過軟體的,所以何樂而不為呢。再回到前面的問題,為什麼非同步解決不了c10m的問題呢?因為執行緒的頻繁排程是需要核心進行上下文切換的,而cpu是存在指令週期的,尤其是當cache不命中的時候,切換上下文的指令週期會延長很多,要解決這個問題就要避開這種中斷模式:即採用輪詢的方式來提公升效能。

從資料報角度分析:這就要求我們必須繞開現有的核心協議,因為現有的核心協議棧是基於中斷模式的,如果要繞開核心,那就要解決驅動問題,解決網絡卡介面資料怎麼到記憶體的問題,這些就是dpdk所提供的功能。

從多核角度分析:要儘量減少執行緒的排程和切換,最好每個os程序繫結乙個核,每個核上資料結構都大致相同,在numa架構(非一致性訪存體系結構,分多節點,每個節點多個cpu,內部共享乙個記憶體控制器)下提高訪存速度。  

從記憶體角度分析:要儘量減少cache miss,如果每個使用者占用2k空間,10m的使用者將使用20g記憶體,這麼多併發連線一定會產生cache miss,一旦失效cpu執行時間會提高乙個數量級,因此我們可以通過大頁的方法,盡量把記憶體劃分更少的塊數,以此提高命中率。

綜上,千萬級資料報的處理思路就是:摒棄核心協議(pf_ring,netmap,inteldpdk)、多核的os繫結、記憶體大頁。[1]

三、使用者態協議

傳統x86架構網路資料報處理是cpu中斷方式:網絡卡驅動接收資料報->中斷通知cpu處理->cpu拷貝資料並交給協議棧,當資料量大時會產生大量cpu中斷,導致cpu無法執行其他程式。dpdk採用輪詢方式處理:dpdk過載網絡卡驅動(接管網絡卡),dpdk接收資料報後不中斷,直接將資料報通過零拷貝技術存入記憶體,應用層直接通過dpdk介面直接從記憶體讀取資料報。 dpdk目前正在成為實現nfv的一項標桿技術,它主要為intel architecture(ia)處理器架構下使用者空間高效的資料報處理提供庫函式和驅動的支援,它不同於linux系統以通用性設計為目的,而是專注於網路應用中資料報的高效能處理,執行在使用者空間上利用自身提供的資料平面庫來收發資料報,繞過了linux核心協議棧對資料報處理過程。[2]

需要注意的是,dpdk本身並不是一項協議,它不提供諸如ip協議、防火牆等網路協議功能,它只是我們在os下的一套資料處理介面。因為多年來,高效能網路背後的傳統思想就是將所有的資料報處理功能,盡可能的推向核心,資料報傳輸時需要跨越核心和使用者,資料報中斷產生的上下文切換和資料複製的成本都極大限制了資料報文處理的速度,所以我們可以用dpdk來繞過核心,這就是使用者態協議要完成的工作。

為啥叫使用者態協議呢?它和現有的tcp/ip協議有什麼區別呢?簡而言之就是現有的tcp/ip協議都是基於核心執行的,而使用者態協議就是另外開發一套協議執行於核心之外。自2023年起在osdi、nsdi、tocs 等頂會期刊上出現了不少使用者態協議,列舉如下:

1. ix project:stanford & epfl git、**位址

ix是乙個專門的資料面lib os,解決了高吞吐量,低延遲,強大的保護和能源效率之間的4路權衡。ix使用硬體虛擬化將控制面與資料面分開,從而保持現有核心的健壯性。控制面負責資源分配,資料面負責提供高效能網路i / o。通過對事件驅動關鍵應用的延遲和吞吐量進行優化,主要方法是按批次繫結處理資料報,最小化這些連續傳輸,並保持多核同步。 ix的團隊則認為不應信任那些直接訪問裝置的應用,一方面擔心應用的穩定性,另一方面這種方式對網路安全產生的巨大威脅。因此ix通過intel虛擬化擴充套件讓i/o路徑和應用程式**共存,將佇列對映到核心,但是仍然設法在隔離的保護域中執行網路堆疊,在這個隔離的保護域中,應用程式不能使用資料。

簡而言之,ix自己實現了乙個叫dune的安全核,因為需要使用硬體虛擬化,所以ix目前支援的網絡卡有限,我後續會發布測試的文章。

2. mtcp:kaist(韓)git、**位址

mtcp是乙個基於多核的高效能使用者態協議,這個團隊認為由於核心和使用者空間之間移動資料所採取的機制(如資料拷貝和上下文切換),核心正在阻礙實現良好可擴充套件的網路效能,所以他們完全拋棄核心,利用新的網絡卡nic和cpu功能(如multiqueue),將裝置驅動程式和網路堆疊直接移入應用程式,並將核心完全從io路徑中取出。 

3. arrakis:git

做法和mtcp類似,它不僅在應用資料上繞過了核心,它不僅對網路資料報進行核心遮蔽,對資料儲存也進行了遮蔽。

比mtcp在層和api方面更深入一些,它保留了到客戶端應用程式的posix套接字介面,儘管它們被重新編譯鏈結到mtcp而不是網路的libc,它還實現了乙個使用者級堆疊,對網路**進行特定應用調整,為web和dns伺服器實現提供加速。

5. 國內的幾個大的使用者態協議棧 

四、其他解決方案

上面的分析我們可以看到,主要瓶頸就是核心,繞過核心就能夠獲更高的效能,安全性咋辦呢,ix似乎更好一些,他們的專案中整合了乙個dune的系統,這套系統類似於乙個安全殼,也就是他們所言的

dataplane operating system

,dune這個專案是10年就開始做的,所以他們相當於是搞了一套結合運用。

我在跑這套專案的時候還注意到了另一套標準rdma(remote direct memory access)遠端直接資料訪問,就是為了解決網路傳輸中伺服器端資料處理的延遲而產生的。rdma這種技術以前只能執行在專用網路下(例如超算平台),為了將這種技術用在乙太網環境下,就逐步發展出了roce/iwarp兩種協議。roce目前主要是由mellonax主導(以色列一家專注高效能網路裝置研發的公司),和tcp協議無關,效能更好。iwarp主要由chelsio主導,下層會依賴tcp協議,效能和可擴性行都差一些,優點是考慮了對廣域網的支援。目前來看roce比iwarp前景更好,實際使用也更廣泛。對比dpdk,dpdk是intel主導,提供了基於使用者態的資料鏈路層的功能,可以在上面構建出基於使用者態的網路棧。實際使用中乙個顯然的缺點是只有poll功能,沒有陷入中斷來減少對cpu的消耗。明顯rdma偏專用線路(需要專用網絡卡支援),dpdk則走通用路線(intel自己就搞定了)。[3]

發展出這麼多協議和實現,根本原因在於網路硬體發展很快,而目前佔據主導的tcp/ip協議仍然是為了適配當初低速網路環境設計的。關注了一下最近dpdk在學術界的走向,以及開始向底層網件發展了,相信不久就會出現成熟商用的通用型快速網路體系。

參考:[1]

[2][3]

gitlab整合ladp部分使用者登入403

gitlab賬號登入,一直報403 跟蹤日誌如下 gitlab ctl tail gitlab rails production.log processing by ldap omniauthcallbackscontroller ldapmain as html parameters comple...

C 將使用者名稱部分用 代替

簡要 很多時候中獎使用者並不希望讓別人知道他的id。程式中我們就將他們的賬號部分設定為 號顯示。例如 王小二 王 二 asadjsahd a d include include define tostar str,start,end do ch starname len 1 尾字元 if ch 0x...

Exchange中限制部分使用者外網訪問

最近遇到乙個需求,公司某業務部門需要讓本部門一部分員工不能通過公網使用exchange郵件系統。然後,公司郵件系統是發布公網使用的,要直接限制部分員工不能外網訪問有一定的困難,經過討論想到了兩個解決方案。第乙個方案,利用方向 來提供身份認證。使用一台反向 裝置來提供郵件系統公網發布,使用者通過int...