從 Google Maglev 說起，如何造一個牛逼的負載均衡？

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年這個時間點上去分析現狀，深入思考各種負載均衡實現的優、劣勢。負載均衡大致可分為以F5、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、非死book也能逼近甚至超越。

從商業角度來說，硬件負載均衡產品過于昂貴，高端產品動輒五十萬甚至數百萬的價格對于用戶是幾乎不可承受的負擔。在文章末尾，我們提供了一份根據網上數據整理后的比較內容，主要來源為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
• 采用批處理攤銷單個報文處理的成本
• 充分利用硬件特性

1. Intel DataDirect I/O Technology (Intel DDIO)
2. NUMA
3. 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，歷任研發工程師，高級研發主管，首席軟件開發經理，組建和帶領過實戰能力極強的研發團隊。

來自：https://zhuanlan.zhihu.com/p/22360384