負載均衡的原理說明

負載均衡的演進大家都知道一臺服務器的處理能力，主要受限于服務器自身的可擴展硬件能力。所以，在需要處理大量用戶請求的時候，通常都會引入負載均衡器，將多臺普通服務器組成一個系統(tǒng)，來完成高并發(fā)的請求處理任務。之前負載均衡只能通過DNS來實現(xiàn)，1996年之后，出現(xiàn)了新的網(wǎng)絡負載均衡技術。通過設置虛擬服務地址（IP），將位于同一地域（Region）的多臺服務器虛擬成一個高性能、高可用的應用服務池；再根據(jù)應用指定的方式，將來自客戶端的網(wǎng)絡請求分發(fā)到服務器池中。網(wǎng)絡負載均衡會檢查服務器池中后端服務器的健康狀態(tài)，自動隔離異常狀態(tài)的后端服務器，從而解決了單臺后端服務器的單點問題，同時提高了應用的整體服務能力。網(wǎng)絡負載均衡主要有硬件與軟件兩種實現(xiàn)方式，主流負載均衡解決方案中，硬件廠商以F5為代表目前市場占有率超過50%，軟件主要為NGINX與LVS。但是，無論硬件或軟件實現(xiàn)，都逃不出基于四層交互技術的"轉發(fā)”或基于七層協(xié)議的"代理”這兩種方式。四層的轉發(fā)模式通常性能會更好，但七層的代理模式可以根據(jù)更多的信息做到更智能地分發(fā)流量。一般大規(guī)模應用中，這兩種方式會同時存在。2007年F5提出了ADC(Applicationdeliverycontroller)的概念為傳統(tǒng)的負載均衡器增加了大量的功能，常用的有:SSL卸載、壓縮優(yōu)化和TCP連接優(yōu)化。NGINX也支持很多ADC的特性，但F5的中高端型號會通過硬件加速卡來實現(xiàn)SSL卸載、壓縮優(yōu)化這一類CPU密集型的操作，從而可以提供更好的性能。F5推出ADC以后，各種各樣的功能有很多，但其實我們最常用的也就幾種。這里我也簡單的總結了一下，并和LVS、Nginx對比了一下。HTTP丿弋理SS匸且載古縮優(yōu)化F57..LVSNGINXSSL卸載和壓縮優(yōu)化，主要是將CPU密集型的加解密和壓縮操作移到負載均衡器上進行；TCP連接優(yōu)化主要指的是用戶和負載均衡器短連接的同時，負載均衡器和后端服務器建立長連接。不過我們本次主要介紹四層負載均衡，所以這些高級ADC功能不會涉及到。F5的硬件負載均衡產(chǎn)品又分單機BigIP系列和集群VISRION系列，都是X86架構，配合自研的TMOS(TrafficManagementOperatingSystem)，再加上硬件加速卡(Cavium提供)處理SSL和壓縮等CPU密集型操作。L4CPS:四層每秒新建連接數(shù)。測試的時候一般采用TCP短連接，每次請求128字節(jié)。體現(xiàn)CPU性能，最重要的性能指標，沒有之一。L4最大并發(fā)連接數(shù)：體現(xiàn)內存大小L7RPS:七層每秒請求數(shù)。測試時每連接10個128字節(jié)HTTP請求。主要體現(xiàn)HTTP協(xié)議棧性能這些性能指標實際上就是一個負載均衡器最關鍵的指標了。大家如有采購硬件負載均衡器一定要看這個。有很多小牌子的硬件負載均衡器經(jīng)常不標注L4CPS，只是籠統(tǒng)地說10G負載均衡，其實差別很大的。硬件負載均衡在功能、易用性和可擴展性上都做得不錯，但是也有不少缺點。從商業(yè)角度來說，硬件負載均衡產(chǎn)品過于昂貴，高端產(chǎn)品動輒五十萬甚至數(shù)百萬的價格對于用戶是幾乎不可承受的負擔。從使用角度來說，硬件負載均衡是黑盒，有BUG需要聯(lián)系廠商等待解決，時間不可控、新特性迭代緩慢且需資深人員維護升級，也是變相增加昂貴的人力成本。相信除了很多不差錢的公司，大家還是用軟件負載均衡比較多。軟件四層負載均衡最常見的就是LVS了。

轉發(fā)欖武優(yōu)葩 1NAT■后端RS不需任何特殊配供6LV呂必須作為兩黃樸VIP和FNP必狽柚于下同網(wǎng)段.都是客戶端源IF信息DR回程報丈不經(jīng)過LVS九囹不対稱流量性能優(yōu)化明顯□同名保留源IP地址-LVS^RS必須在相同?護網(wǎng)，必煩「層可達，R益無法叛到零配儘，需要配f§VIP,同時耍對ARP做特殊址理FULLNAT:幣端RS不需任何特殊配爵“物理冏絡僅要求三層可達*丟失源舊倍息CTOAJj-式對只営改動過大）q雅護及具匍雜；FULLNAT無法進入LM其內LVS最常用的有NAT、DR以及新的FULLNAT模式。上圖比較了幾種常見轉發(fā)模式的優(yōu)缺點。我們認為LVS的每種轉發(fā)模式都有其優(yōu)點和缺點，但最大的問題還是其復雜性。我第一次看到這三種轉發(fā)方式、還有F5的單臂模式、雙臂模式都會有云里霧里的感覺。雪上加霜的是咱們還需要考慮LVS的性能擴展和容災方法，這使得整個方案更加的復雜。常見的有基于Keepalived的主備方式和ECMP兩種。Keepalived主備模式設備利用率低；不能橫向擴展；VRRP協(xié)議，有腦裂的風險。而ECMP的方式需要了解動態(tài)路由協(xié)議，LVS和交換機均需要較復雜配置；交換機的HASH算法一般比較簡單，增加刪除節(jié)點會造成HASH重分布，可能導致當前TCP連接全部中斷；部分交換機的ECMP在處理分片包時會有Bug，說起來心中滿滿的都是血淚呀。可靠性:ECMP+—致性哈希保證連接不中斷當負載均衡器發(fā)主變化可伸縮性橫向擴展半ECMP集群縱向擴展：DPDF：提升單機勺虛擬化網(wǎng)絡中的DR轉發(fā)模式當兩者同時發(fā)生變更如圖：UCIoudVortex負載均衡器的設計理念用戶使用負載均衡器最重要的需求是"HighAvailability”和"Scalability”，Vortex的架構設計重心就是滿足用戶需求，提供極致的"可靠性”和"可收縮性”，而在這兩者之間我們又把“可靠性”放在更重要的位置。

值得一提的是今年3月舉辦的第十三屆網(wǎng)絡系統(tǒng)設計與實現(xiàn)USENIX研討會(NSDI'16)上，來自谷歌、加州大學洛杉磯分校、SpaceX公司的工程師們分享了《Maglev:快速、可靠的軟件網(wǎng)絡負載均衡器》，介紹了從2008年開始在生產(chǎn)環(huán)境投入使用的軟件負載均衡器。其設計理念和我們非常相似，同樣是ECMP+一致性哈希；同樣是KernelBypass模式；單機性能也和我們的Vortex非常接近。關于Vortex的HighAvailability實現(xiàn)四層負載均衡器的主要功能是將收到的數(shù)據(jù)包轉發(fā)給不同的后端服務器，旦必須保證將五元組相同的數(shù)據(jù)包發(fā)送到同一臺后端服務器，否則后端服務器將無法正確處理該數(shù)據(jù)包。以常見的HTTP連接為例，如果報文沒有被發(fā)送到同一臺后端服務器，操作系統(tǒng)的TCP協(xié)議棧無法找到對應的TCP連接或者是驗證TCP序列號錯誤將會無聲無息的丟棄報文，發(fā)送端不會得到任何的通知。如果應用層沒有超時機制的話，服務將會長期不可用。Vortex的可靠性設計面臨的最大問題就是如何在任何情況下避免該情況發(fā)生。Vortex通過ECMP集群和一致性哈希來實現(xiàn)極致程度的可靠性。首先，我們來考察一下負載均衡服務器變化場景。這種場景下，可能由于負載均衡服務器故障被動觸發(fā)，也可能由于運維需要主動增加或者減少負載均衡服務器。此時交換機會通過動態(tài)路由協(xié)議檢測負載均衡服務器集群的變化，旦除思科的某些型號外大多數(shù)交換機都采用簡單的取模算法，導致大多數(shù)數(shù)據(jù)包被發(fā)送到不同的負載均衡服務器。

Vortex服務器的一致性哈希算法能夠保證即使是不同的Vortex服務器收到了數(shù)據(jù)包，仍然能夠將該數(shù)據(jù)包轉發(fā)到同一臺后端服務器，從而保證客戶應用對此類變化無感知，業(yè)務不受任何影響。這種場景下，如果負載均衡器是LVS且采用RR(RoundRobin)算法的話，該數(shù)據(jù)包會被送到錯誤的后端服務器，且上層應用無法得到任何通知。R^ialServiceInstances菇詢轉發(fā)算注LVS腕務器變i!1h05T;lR|n$M肝卅瞞6,3irl=-Ji鬲t_￡S甩羌霽S5i崖嶺生靈貯河一虧涯陛就S5酮爾3ha&h^Rf^ihashl-iR)%^聲臨=5陽誦溜L翩g務甌鎖比iWWB四曲陽上空斷屆陶魁氏X”叭，.二阿為"式海諄目瑕運咅:!問2妙M剎l^^KA,耳例甲拐閆呂剛§罷密’淫舶人覘各發(fā)生蠻狂如果LVS配置了SH(SourceHash)算法的話，該數(shù)據(jù)包會被送到正確的后端服務器，上層應用對此類變化無感知，業(yè)務不受任何影響；

srsr頂Iflf■LYSSOufMn-abh\LV5——\\ 二DODDBBBBHgfilSriuiceIns^nai：:s能服務器孌噩宋塞e頓叭旌厠加、*割iait卿§駆伽?第I■引.陽創(chuàng)輸啤5;hr!i托21L1=I2;'r：35h2ILISiiE衿RS確樹限生蠻出時，般陽Kb芒舷媚珈1he倚1(R|=fl,hash1斛砸;刁hs&Ji?(LF=12;h0^2>LI^7在RS畫飆砂主謝8融一畠舷的協(xié)比廈不兌W^z臨i/「￡T認，洛町胡坯U.7 產(chǎn)舌宙為-K比(抵H剃密更判距町□如果負載均衡器是NGINX的話，亥數(shù)據(jù)包會被TCP協(xié)議棧無聲無息地丟棄，上層應用不會得到任何通知。其次，來考察后端服務器變化的場景。這種場景下，可能由于后端服務器故障由健康檢查機制檢查出來，也可能由于運維需要主動增加或者減少后端服務器。此時，Vortex服務器會通過連接追蹤機制保證當前活動連接的數(shù)據(jù)包被送往之前選擇的服務器，而所有新建連接則會在變化后的服務器集群中進行負載分擔。同時，Vortex一致性哈希算法能保證大部分新建連接與后端服務器的映射關系保持不變，只有最少數(shù)量的映射關系發(fā)生變化，從而最大限度地減小了對客戶端到端的應用層面的影響。這種場景下，如果負載均衡器是LVS且SH算法的話，大部分新建連接與后端服務器的映射關系會發(fā)生變化。某些應用，列如緩存服務器，如果發(fā)生映射關系的突變，將造成大量的cachemiss，從而需要從數(shù)據(jù)源重新讀取內容，由此導致性能的大幅下降。而NGINX在該場景下如果配置了一致性哈希的話可以達到和Vortex一樣的效果。最后，讓我們來看一下負載均衡服務器和后端服務器集群同時變化的場景。在這種場景下，Vortex能夠保證大多數(shù)活動連接不受影響，少數(shù)活動連接被送往錯誤的后端服務器且上層應用不會得到任何通知。并且大多數(shù)新建連接與后端服務器的映射關系保持不變，只有最少數(shù)量的映射關系發(fā)生變化。源地址俯希尊法LVSE?源地址俯希尊法LVSE?器與恣同肚孌建Ji. ：71也j站旦注il曰ki肚inpmnn陽;阿叫COI1I旳C1K>[itJLkrilflM=|ER3-a.haah1-lRW&hd3h?il.^t2esjarinoconnMnionu￡sconnaeWfitraekiAQelse:hashzrimi如果負載均衡器是LVS且SH算法的話幾乎所有活動連接都會被送往錯誤的后端服務器且上層應用不會得到任何通知。大多數(shù)新建連接與后端服務器的映射關系同樣也會發(fā)生變化。如果是NGINX的話因為交換機將數(shù)據(jù)包送往不同的NGINX服務器，幾乎所有數(shù)據(jù)包會被無聲無息的丟棄，上層應用不會得到任何通知?？墒湛s性的設計是基于ECMP集群的ScalingOut設計Vortex采用動態(tài)路由的方式通過路由器ECMP(Equal-costmulti-pathrouting!來實現(xiàn)Vortex集群的負載均衡?！懵酚蓹C支持至少16或32路ECMP集群,特殊的SDN交換機支持多達256路ECMP集群。而一致性哈希的使用是的ECMP集群的變化對上層應用基本無感知，用戶業(yè)務不受影響。雖然ECMP提供了良好的ScalingOut的能力，但是考慮到網(wǎng)絡設備的價格仍然希望單機性能夠盡可能的強。例如，轉發(fā)能力最好是能夠達到10G甚至40G的線速，同時能夠支持盡可能高的每秒新建連接數(shù)r：0.?.M]D丸衛(wèi)OGOWJUGXWC13drncx},rwn20,000,?IO.O(K1.DOT￡11281522*fi32030444B51257S640704768￡33B9E9601D241D8B,115212l￡t20Q13JJpucoIIll^」ald巾一dj左UEaPackBLSiz&10Z4byt1QGPjcke(s.'se￡opid-1aMillionearPscKeiajnvaira.i&2OBBns2GlizC4ocxcycles417cydtTy口lealServerPaGk^tSizesPacketSizeS4bytes■ICGPucketSj'Eecorid59.5MilllOEiuact!wayPacketarrivalrate16.0fK2GrtzCIdciccydes33cyclesNelwciKInFra^tructurePacketSizes內核不是解決方案，而是問題所在！從上圖可以看到隨著高速網(wǎng)絡的發(fā)展64字節(jié)小包線速的要求越來越高，對10G網(wǎng)絡來說平均67ns，對40G網(wǎng)絡來說只有17ns。而于此同時CPU、內存的速度提升卻沒有那么多。以2G主頻的CPU為例，每次命中L3緩存的讀取操作需要約40個CPU周期，而一旦沒有命中緩存從主存讀取則需要140個CPU周期。為了達到線速就必須采用多核并發(fā)處理、批量數(shù)據(jù)包處理的方式來攤銷單個數(shù)據(jù)包處理所需要的CPU周期數(shù)。此外，即使采用上述方式，如果沒有得到充分的優(yōu)化，發(fā)生多次cachemiss或者是memorycopy都無法達到10G線速的目標。

iMTrnHWHYVORTEX?iMTrnH縣楝k也世遲1.*侍Llset用審rbfI&inlp賈l優(yōu)碘2梅玉了Sak金特斷匸桎円G3罟冷SKB釗fig珂軒療也的艮雋虧輛4^^Sa-fcHtCI .UMfSfiaiDB^!5S像NGINX這樣的代理模式，轉發(fā)程序因為需要TCP協(xié)議棧的處理以及至少一次內存復制性能要遠低于LVS。而LVS又因為通用Kernel的限制，會考慮節(jié)省內存等設計策略，而不會向Vortex—樣在一開始就特別注重轉發(fā)性能。例如LVS缺省的連接追蹤HASH表大小為4K,而Vortex直接使用了50%以上的內存作為連接追蹤表。Vortex通過DPDK提供函數(shù)庫充分利用CPU和網(wǎng)卡的能力從而達到了單機10G線速的轉發(fā)性能。?用戶空間驅動，完全Zero-Copy采用批處理攤銷單個報文處理的成本?充分利用硬件特性?IntelDataDirectI/OTechnology(IntelDDIO)?NUMA?HugePages,CacheAlignment,MemorychanneluseVortex直接采用多隊列10G網(wǎng)卡，通過RSS直接將網(wǎng)卡隊列和CPUCore綁定，消除線程的上下文切換帶來的開銷。Vortex線程間采用高并發(fā)無鎖的消息隊列通信。除此之外，完全不共享狀態(tài)從而保證轉發(fā)線程之間不會互相影響。Vortex在設計時盡可能的減少指針的使用、采用連續(xù)內存數(shù)據(jù)結構來降低cachemiss。通過這樣一系列精心設計的優(yōu)化措施，最終Vortex的單機性能遠超LVS，甚至超過了GoogleMaglev的水平。LVS支持四種轉發(fā)模式：NAT、DR、TUNNEL和FULLNAT，其實各有利弊。Vortex在設計之初就對四種模式做了評估，最后發(fā)現(xiàn)在虛擬化的環(huán)境下DR方式在各方面比較平衡，并且符合我們追求極致性能的理念。DR方式最大的優(yōu)點是絕佳的性能，只有request需要負載均衡器處理，response可以