從Google Maglev到UCloud Vortex，如何造一個牛逼的負載均衡？

Maglev是谷歌爲本身的數據中心研發的解決方案，並於2008開始用於生產環境。在第十三屆網絡系統設計與實現USENIX研討會（NSDI ‘16）上， 來自谷歌、加州大學洛杉磯分校、SpaceX公司的工程師們分享了這一商用服務器負載均衡器Maglev的詳細信息。Maglev安裝後不須要預熱5秒內就能應付每秒100萬次請求使人驚歎不已。在谷歌的性能基準測試中，Maglev實例運行在一個8核CPU下，網絡吞吐率上限爲12M PPS(數據包每秒)，若是Maglev使用Linux內核網絡堆棧則速度會小於4M PPS。

無獨有偶，國內雲服務商UCloud進一步迭代了負載均衡產品——Vortex，成功地提高了單機性能。在技術實現上，UCloud Vortex與Google Maglev頗爲類似。以一臺普通性價比的x86 1U服務器爲例，Vortex能夠實現吞吐量達14M PPS(10G, 64字節線速)，新建鏈接200k CPS以上，併發鏈接數達到3000萬、10G線速的轉發。在本文中，UCloud網絡研發團隊分享UCloud Vortex的具體實現。

什麼是負載均衡

一臺服務器的處理能力，主要受限於服務器自身的可擴展硬件能力。因此，在須要處理大量用戶請求的時候，一般都會引入負載均衡器，將多臺普通服務器組成一個系統，來完成高併發的請求處理任務。

最先的負載均衡技術是經過DNS來實現的，將多臺服務器配置爲相同的域名，使不一樣客戶端在進行域名解析時，從這一組服務器中的請求隨機分發到不一樣的服務器地址，從而達到負載均衡的目的。

圖：多層次負載均衡

但在使用DNS均衡負載時，因爲DNS數據刷新的延遲問題，沒法確保用戶請求的徹底均衡。並且，一旦其中某臺服務器出現故障，即便修改了DNS配置，仍然須要等到新的配置生效後，故障服務器纔不會被用戶訪問到。目前，DNS負載均衡仍在大量使用，但多用於實現「多地就近接入」的應用場景。

1996年以後，出現了新的網絡負載均衡技術。經過設置虛擬服務地址（IP），將位於同一地域（Region）的多臺服務器虛擬成一個高性能、高可用的應用服務池；再根據應用指定的方式，未來自客戶端的網絡請求分發到服務器池中。網絡負載均衡會檢查服務器池中後端服務器的健康狀態，自動隔離異常狀態的後端服務器，從而解決了單臺後端服務器的單點問題，同時提升了應用的總體服務能力。

網絡負載均衡主要有硬件與軟件兩種實現方式，主流負載均衡解決方案中，硬件廠商以F5爲表明，軟件主要爲NGINX與LVS。可是，不管硬件或軟件實現，都逃不出基於四層交互技術的「報文轉發」或基於七層協議的「請求代理」這兩種方式。 四層的轉發模式一般性能會更好，但七層的代理模式能夠根據更多的信息作到更智能地分發流量。通常大規模應用中，這兩種方式會同時存在。

爲何要研發Vortex?

在研發UCloud Vortex以前，咱們一直在思考是否是在重造輪子。這要求咱們站在2016年這個時間點上去分析現狀，深刻思考各類負載均衡實現的優、劣勢。負載均衡大體可分爲以F五、Netscaler爲表明的硬件負載均衡和以 LVS 爲表明的軟件負載均衡。

不妨，咱們先以F5爲表明來看硬件負載均衡的優劣勢。

F5的硬件負載均衡產品又分單機和集羣系列。12250v是單機中的高端版本，能支撐每秒150萬新建鏈接數，8000萬併發鏈接數，84G數據吞吐量。從F5的datasheet中，咱們推算出併發鏈接數受限於內存，高端的12250v和次一級的11050內存相差4倍，併發鏈接數也是4：1的關係，後者大概爲2400萬；根據UCloud自身雲平臺的運營經驗，150萬新建鏈接在特定大壓力場景下是很是危險的，頗有可能被擊穿；而84G的吞吐量，通常來講是夠用的，數據中心南北向的流量有限。

圖：F5 12250v

集羣系列中VIPRION 4800陣列是旗艦產品，每一個陣列支持最多8個Blade，每一個Blade提供每秒290萬新建鏈接數，1.8億併發鏈接數以及140G數據吞吐量。按線性比例計算，一個頂配的VIPRION 4800陣列能知足絕大多數海量互聯網應用的業務需求了。其中，須要指出的是單片Blade都是用了普通X86架構，2塊Intel 12核CPU 配256G內存，這個轉變使其支撐量產生了飛越，也進一步證明併發鏈接數與內存呈相關性。

從技術角度來講，咱們認爲硬件負載均衡最終的路線是回到X86服務器架構，經過橫向擴展來提高性能。這裏軟硬件的區分已經再也不存在，由於若是F5能作到，具有深刻研發能力的技術公司如Google、Facebook也能逼近甚至超越。

從商業角度來講，硬件負載均衡產品過於昂貴，高端產品動輒五十萬甚至數百萬的價格對於用戶是幾乎不可承受的負擔。在文章末尾，咱們提供了一份根據網上數據整理後的比較內容，主要來源爲Google搜索：F5 Networks - Price List - January 11th, 2014 - Amended for the WSCA-NASPO JP14001 Request for Proposal，供你們參考。

從使用角度來講，硬件負載均衡是黑盒，有BUG須要聯繫廠商等待解決，時間不可控、新特性迭代緩慢且需資深人員維護升級，也是變相增長昂貴的人力成本。

再來看（開源）軟件負載均衡表明LVS. LVS做爲目前互聯網時代最知名的負載均衡軟件，在性能與成本方面結合地很好，阿里雲的SLB產品也經過LVS實現，所以也繼承了LVS的優勢和缺點。LVS最經常使用的有NAT、DR以及新的FULL NAT模式。如下是各模式詳細的優缺點比較：

圖:NAT、DR和FULL NAT模式 優缺點對比

咱們認爲LVS的每種模式都有較大的缺點，但這並非最爲致命的。最爲致命的是LVS本質上是一個工做於Linux內核層的負載均衡器，它的上限取決於Linux內核的網絡性能，但Linux內核的網絡路徑過長致使了大量開銷，使得LVS單機性能較低。所以，Google於2016年3月最新公佈的負載均衡Maglev實現徹底繞過了Linux內核（Kernel Bypass），也就是說Google已經採用了與LVS不一樣的技術思路。

LVS在運維層面還要考慮容災的問題，大多使用Keepalived完成主備模式的容災。有3個主要缺點：

1. 主備模式利用率低；

2. 不能橫向平行擴展；

3. VRRP協議存在腦裂Split Brain的風險。Split Brain從邏輯角度來講是無解的，除非更換架構。

也有少數公司經過ECMP等價路由協議搭配LVS來避免Keepalived的缺陷。綜合來看，ECMP有幾個問題：

1. 須要瞭解動態路由協議，LVS和交換機均須要複雜配置；

2. 交換機的HASH算法通常比較簡單，增長刪除節點會形成HASH重分佈，可能致使當前TCP鏈接所有中斷；

3. 部分交換機（華爲6810）的ECMP在處理分片包時會有BUG。

這些問題均在生產環境下，須要使用者有資深的運維專家、網絡專家確保運營結果。

理性的剖析下，咱們發現沒有任何的負載均衡實如今價格、性能、部署難度、運維人力成本各方面能達到最優，因此Vortex必然不是在重造輪子而是在推進這個領域的革新: Vortex必須不能像LVS那樣被Linux內核限制住性能，Vortex也不能像F5那麼的昂貴。

Vortex負載均衡器的設計理念

用戶使用負載均衡器最重要的需求是「High Availability」和「Scalability」，Vortex的架構設計重心就是知足用戶需求，提供極致的「可靠性」和「可收縮性」，而在這二者之間咱們又把「可靠性」放在更重要的位置。

1. Vortex的High Availability實現

四層負載均衡器的主要功能是將收到的數據包轉發給不一樣的後端服務器，但必須保證將五元組相同的數據包發送到同一臺後端服務器，不然後端服務器將沒法正確處理該數據包。以常見的HTTP鏈接爲例，若是報文沒有被髮送到同一臺後端服務器，操做系統的TCP協議棧沒法找到對應的TCP鏈接或者是驗證TCP序列號錯誤將會無聲無息的丟棄報文，發送端不會獲得任何的通知。若是應用層沒有超時機制的話，服務將會長期不可用。Vortex的可靠性設計面臨的最大問題就是如何在任何狀況下避免該狀況發生。Vortex經過ECMP集羣和一致性哈希來實現極致程度的可靠性。

首先，咱們來考察一下負載均衡服務器變化場景。 這種場景下，可能因爲負載均衡服務器故障被動觸發，也可能因爲運維須要主動增長或者減小負載均衡服務器。此時交換機會經過動態路由協議檢測負載均衡服務器集羣的變化，但除思科的某些型號外大多數交換機都採用簡單的取模算法，致使大多數數據包被髮送到不一樣的負載均衡服務器。

圖：負載均衡服務器變化場景

Vortex服務器的一致性哈希算法可以保證即便是不一樣的Vortex服務器收到了數據包，仍然可以將該數據包轉發到同一臺後端服務器，從而保證客戶應用對此類變化無感知，業務不受任何影響。

這種場景下，若是負載均衡器是LVS且採用RR (Round Robin)算法的話，該數據包會被送到錯誤的後端服務器，且上層應用沒法獲得任何通知。若是LVS配置了SH(Source Hash)算法的話，該數據包會被送到正確的後端服務器，上層應用對此類變化無感知，業務不受任何影響；若是負載均衡器是NGINX的話，該數據包會被TCP協議棧無聲無息地丟棄，上層應用不會獲得任何通知。

圖：後端服務器變化的場景

其次，來考察後端服務器變化的場景。 這種場景下，可能因爲後端服務器故障由健康檢查機制檢查出來，也可能因爲運維須要主動增長或者減小後端服務器。此時，Vortex服務器會經過鏈接追蹤機制保證當前活動鏈接的數據包被送往以前選擇的服務器，而全部新建鏈接則會在變化後的服務器集羣中進行負載分擔。

同時，Vortex一致性哈希算法能保證大部分新建鏈接與後端服務器的映射關係保持不變，只有最少數量的映射關係發生變化，從而最大限度地減少了對客戶端到端的應用層面的影響。這種場景下，若是負載均衡器是LVS且SH算法的話，大部分新建鏈接與後端服務器的映射關係會發生變化。某些應用，例如緩存服務器，若是發生映射關係的突變，將形成大量的cache miss，從而須要從數據源從新讀取內容，由此致使性能的大幅降低。而NGINX在該場景下若是配置了一致性哈希的話能夠達到和Vortex同樣的效果。

圖：Vortex 一致性哈希算法的計算公式

最後，讓咱們來看一下負載均衡服務器和後端服務器集羣同時變化的場景。 在這種場景下，Vortex可以保證大多數活動鏈接不受影響，少數活動鏈接被送往錯誤的後端服務器且上層應用不會獲得任何通知。而且大多數新建鏈接與後端服務器的映射關係保持不變，只有最少數量的映射關係發生變化。

圖：負載均衡服務器和後端服務器集羣同時變化的場景

若是負載均衡器是LVS且SH算法的話幾乎全部活動鏈接都會被送往錯誤的後端服務器且上層應用不會獲得任何通知（圖四）。大多數新建鏈接與後端服務器的映射關係一樣也會發生變化。若是是NGINX的話由於交換機將數據包送往不一樣的NGINX服務器，幾乎全部數據包會被無聲無息的丟棄，上層應用不會獲得任何通知。

圖：不一樣變化帶來的影響對比

2. Vortex的Scalability實現

2.1 基於ECMP集羣的Scaling Out設計

Vortex採用動態路由的方式經過路由器ECMP（Equal-cost multi-path routing）來實現Vortex集羣的負載均衡。通常路由機支持至少16或32路ECMP集羣，特殊的SDN交換機支持多達256路ECMP集羣。而一致性哈希的使用是的ECMP集羣的變化對上層應用基本無感知，用戶業務不受影響。

2.2 基於DPDK的Scaling Up設計

雖然ECMP提供了良好的Scaling Out的能力，可是考慮到網絡設備的價格仍然但願單機性可以儘量的強。例如，轉發能力最好是可以達到10G甚至40G的線速，同時可以支持儘量高的每秒新建鏈接數。Vortex利用DPDK提供的高性能用戶空間 (user space) 網卡驅動、高效無鎖數據結構成功的將單機性能提高到轉發14M PPS（10G, 64字節線速），新建鏈接200K CPS以上。

內核不是解決方案，而是問題所在！

圖：DPDK性能數據圖

從上圖能夠看到隨着高速網絡的發展64字節小包線速的要求愈來愈高，對10G網絡來講平均67ns，對40G網絡來講只有17ns。而於此同時CPU、內存的速度提高卻沒有那麼多。以2G主頻的CPU爲例，每次命中L3緩存的讀取操做須要約40個CPU週期，而一旦沒有命中緩存從主存讀取則須要140個CPU週期。爲了達到線速就必須採用多核併發處理、批量數據包處理的方式來攤銷單個數據包處理所須要的CPU週期數。此外，即便採用上述方式，若是沒有獲得充分的優化，發生屢次cache miss或者是memory copy都沒法達到10G線速的目標。

像NGINX這樣的代理模式，轉發程序由於須要TCP協議棧的處理以及至少一次內存複製性能要遠低於LVS。而LVS又由於通用Kernel的限制，會考慮節省內存等設計策略，而不會向Vortex同樣在一開始就特別注重轉發性能。例如LVS缺省的鏈接追蹤HASH表大小爲4K，而Vortex直接使用了50%以上的內存做爲鏈接追蹤表。

下圖簡明地比較了三者在實現上的差別：

圖：LVS、Google Maglev和UCloud Vortex 實現差別

Vortex經過DPDK提供函數庫充分利用CPU和網卡的能力從而達到了單機10G線速的轉發性能。

• 用戶空間驅動，徹底Zero-Copy

• 採用批處理攤銷單個報文處理的成本

• 充分利用硬件特性

  • Intel DataDirect I/O Technology (Intel DDIO)

  • NUMA

  • Huge Pages，Cache Alignment，Memory channel use

Vortex直接採用多隊列10G網卡，經過RSS直接將網卡隊列和CPU Core綁定，消除線程的上下文切換帶來的開銷。Vortex線程間採用高併發無鎖的消息隊列通訊。除此以外，徹底不共享狀態從而保證轉發線程之間不會互相影響。Vortex在設計時儘量的減小指針的使用、採用連續內存數據結構來下降cache miss。經過這樣一系列精心設計的優化措施，Vortex的單機性能遠超LVS。單機性能橫向測試比較，參見下圖：

圖：單機性能橫向測試比較

基於DR轉發方式

LVS支持四種轉發模式：NAT、DR、TUNNEL和FULLNAT，其實各有利弊。Vortex在設計之初就對四種模式作了評估，最後發如今虛擬化的環境下DR方式在各方面比較平衡，而且符合咱們追求極致性能的理念。

DR方式最大的優勢是絕佳的性能，只有request須要負載均衡器處理，response能夠直接從後端服務器返回客戶機，不管是吞吐仍是延時都是最好的分發方式。

其次，DR方式不像NAT模式須要複雜的路由設置，並且不像NAT模式當client和後端服務器處於同一個子網就沒法正常工做。DR的這個特性使他特別合適做爲內網負載均衡。

此外，不像FULLNAT同樣須要先修改源IP再使用 TOA 傳遞源地址，還得在負載均衡器和後端服務器上都編譯非主線的Kernel Module，DR能夠KISS（Keep It Simple, Stupid）地將源地址傳遞給後端服務器。

最後，虛擬化環境中已經採用Overlay虛擬網絡了，因此TUNNEL的方式變得徹底多餘。而DR方式最大的缺點：須要LB和後端服務器在同一個二層網絡，而這在UCloud的虛擬化網絡中徹底不是問題。主流的SDN方案追求的正是大二層帶來的無縫遷移體驗，且早已採用各類優化手段（例如ARP代理）來優化大二層虛擬網絡。

結語

採用Vortex做爲UCloud負載均衡產品ULB的核心引擎，經過一致性哈希算法的引入，並結合ECMP與DPDK的的服務架構，解決了利用commodity server實現 high availability + high scalability 的高性能軟件負載均衡集羣的課題。

此外，本次ULB的更新還對原有功能進行了擴展，從新調整了用戶交互並增長了數10個新的feature，如優化了批量管理場景下的操做效率， SSL證書提升爲基本資源對象管理。將來，Vortex將以ULB爲產品形態輸出更多的創新理念。

附錄：

按7折折扣並考慮每一年25%的降價幅度，上文提到的一套12250v價格約87萬人民幣（生產環境中須要主備2臺），一套包含一個機櫃與4刀片的VIPRION 4800價格約爲188萬人民幣。

做者介紹：

Y3(俞圓圓)，UCloud基礎雲計算研發中心總監，負責超大規模的虛擬網絡及下一代NFV產品的架構設計和研發。在大規模、企業級分佈式系統、面向服務架構、TCP/IP協議棧、數據中心網絡、雲計算平臺的研發方面積累了大量的實戰經驗。曾經分別供職於Microsoft Windows Azure和Amazon AWS EC2，歷任研發工程師，高級研發主管，首席軟件開發經理，組建和帶領過實戰能力極強的研發團隊。

（文章首發於：http://www.infoq.com/cn/articles/Maglev-...）