您的位置:首頁>正文

高性能負載均衡設計與實現

摘要: 2017阿裡雲網路技術高峰論壇線上技術峰會, 阿裡雲衛崢帶來題為高性能負載均衡設計與實現的演講。 本文主要從早期的負載均衡開始談起, 進而講解了高性能負載均衡, 著重分析了LVS和Tengine, 以及如何做到高可用, 最後作了簡要總結。

以下是精彩內容整理:

負載均衡

負載均衡是雲計算的基礎元件, 是網路流量的入口, 其重要性不言而喻。

什麼是負載均衡呢?使用者輸入的流量通過負載等化器按照某種負載均衡演算法把流量均勻的分散到後端的多個伺服器上,

接收到請求的伺服器可以獨立的回應請求, 達到負載分擔的目的。 從應用場景上來說, 常見的負載均衡模型有全域負載均衡和集群內負載均衡, 從產品形態角度來說, 又可以分為硬體負載均衡和軟體負載均衡。 全域負載均衡一般通過DNS實現, 通過將一個功能變數名稱解析到不同VIP, 來實現不同的region調度能力;硬體負載等化器常見的有F5、A10、Array, 它們的優缺點都比較明顯, 優點是功能強大, 有專門的售後服務團隊, 性能比較好, 缺點是缺少定制的靈活性, 維護成本較高;現在的互聯網更多的思路是通過軟體負載均衡來實現, 這樣可以滿足各種定制化需求, 常見的軟體負載均衡有LVS、Nginx、Haproxy。

阿裡雲高性能負載均衡使用LVS和Tengine, 我們在一個region區分不同的機房,每個機房都有LVS集群和Tengine集群, 對於使用者配置的四層監聽, LVS後面會直接掛載用戶ECS, 七層用戶監聽ECS則掛載在Tengine上, 四層監聽的流量直接由LVS轉發到ECS, 而7層監聽的流量會經過LVS到Tenigine再到用戶ECS。 每一個region裡都會有多個可用區, 達到主備容災目的, 每一個集群裡都有多台設備, 第一是為了提升性能, 第二也是基於容災考慮。

圖為高性能負載均衡控制管理概要圖, SLB產品也有SDN概念, 轉發和控制是分離的, 使用者所有配置通過控制台先到控制器, 通過集中控制器轉換將使用者配置推送到不同設備上, 每台設備上都有Agent接收控制器下發的需求, 通過本地轉換成LVS和Tengine能夠識別的配置, 這個過程支援熱配置, 不影響使用者轉發, 不需要reload才能使新配置生效。

LVS

LVS支援的三種模式

早期LVS支援三種模式, DR模式、TUN模式和NAT模式。 DR模式經過LVS之後, LVS會將MAC位址更改、封裝MAC頭, 內層IP報文不動, 報文經過LVS負載均衡查找到RS之後, 將源MAC頭改成自己的, 目的MAC改成RS位址, MAC定址是在二層網路裡, 對網路部署有一定的限定, 在大規模分散式集群部署裡, 這種模式的靈活性沒有辦法滿足需求;TUN模式走在LVS之後, LVS會在原有報文基礎上封裝IP頭, 到了後端RS之後, RS需要解開IP報文封裝, 才能拿到原始報文, 不管是DR模式還是TUN模式,

後端RS都可以看到真實客戶源IP, 目的IP是自己的VIP, VIP在RS設備上需要配置, 這樣可以直接繞過LVS返回給使用者, TUN模式問題在於需要在後端ECS上配置解封裝模組, 在Linux上已經支援這種模組, 但是windows上還沒有提供支援, 所以會對使用者系統鏡像選擇有限定。 NAT模式使用者訪問的是VIP, LVS查找完後會將目的IP做DNAT轉換, 選擇出RS位址, 因為用戶端的IP沒變, 在回包的時候直接向公網真實用戶端IP去路由, NAT的約束是因為LVS做了DNAT轉換, 所以回包需要走LVS, 把報文頭轉換回去, 由於ECS看到的是用戶端真實的源位址, 我們需要在使用者ECS上配置路由, 將到ECS的默認路由指向LVS上, 這對用戶場景也做了限制。

LVS基於Netfilter框架實現

Netfilter是Linux提供的網路開放平臺, 基於平臺可以開發自己的業務功能模組, 早期好多安全廠商都是基於Netfilter做一些業務模型實現, 這種模型比較靈活, 但通用模型裡更多的是相容性考慮, 路徑會非常長;而且通用模型中沒辦法發揮多核特性, 目前CPU的發展更多是向橫向擴展, 我們經常見到多路伺服器, 每路上有多少核, 早期通用模型對多核支援並不是特別友善, 在多核設計上有些欠缺, 導致我們在通用模型上做一些應用開發時的擴展性是有限的, 隨著核的數量越來越多,性能不增反降。

LVS的改進

早期模式的各種限制制約了我們的發展,所以我們首先做了FullNAT,相比原來的NAT方式,FullNAT多了SNAT屬性,將用戶端的原IP位址作了轉換;其次,我們在並行化上做了處理,充分利用多核實現性能線性提升;然後是快速路徑,我們在做網路轉發模型時很容易想到設計快速路徑和慢速路徑,慢速路徑更多是解決首包如何通過設備問題,可能需要查ACL或路由,需要判斷許多和策略相關的東西,後面所有報文都可以通過快速路徑轉發出去;還有指令相關優化,利用因特爾特殊指令提升性能;另外針對多核架構,NUMA多節點記憶體訪問,通過訪問Local節點記憶體可能獲得更好的延遲表現。

用戶端進來IP首先訪問LVS的VIP,原IP是用戶端的,目的IP是LVS的VIP,經過FullNAT轉換後,原IP變成LVS的Local位址,目的地址是LVS選擇出來的RS位址,這樣在RS回包時比較容易,只要路由可達,報文一定會交到LVS上,不需要在RS上做特殊的配置。右面就是DNAT+SNAT轉換,報文就可以通過LVS轉發回用戶端,這種方式主要帶來應用場景部署靈活性選擇。

通過並行化實現對LVS性能的改善,性能沒有辦法得到線性提升更多的是因為每條路徑都需要訪問全域資源,就會不可避免引入鎖的開箱,另外,同一條連結上的報文可能分散在不同的核上,大家去訪問全域資源時也會導致cache的丟失。所以我們通過RSS技術把同一個五源組報文扔到同一個CPU上處理,保證入方向的所有相同連接上的報文都能交給相同CPU處理,每個核在轉發出去時都用當前CPU上的Local地址,通過設置一些fdir規則,報文回來時後端RS訪問的目的地址就是對應CPU上的local位址,可以交到指定的CPU上去處理,這樣一條連接上左右方向報文都可以交給同一個CPU處理,將流在不同的CPU隔離開;另外,我們把所有配置資源包括動態緩存資源在每個CPU上作了拷貝,將資源局部化,這使整個流從進入LVS到轉發出去訪問的資源都是固定在一個核上的本地資源,使性能達到最大化,實現線性提升。

經過我們改進之後,LVS的具體表現如下:

出於對容災和性能提升的考慮,我們做了集群化部署,每個region有不同機房,每個機房有多個調度單元,每個單元有多台LVS設備;每台LVS經過優化後,都能達到更高性能,大容量,單台LVS可以達到4000W PPS,600W CPS、單個group可以到達1億併發;支援region、IDC、集群和應用級的高可用;實現了防攻擊功能,並在原版LVS上提供了更豐富的功能,可以基於各個維度做管理控制,精確的統計,流量的分析等。Tengine

Tengine在應用過程中也遇到了各種問題,最嚴重的就是性能問題,我們發現隨著CPU數量越來越多,QPS值並沒有線性提升;Nginx本身是多worker模型,每個worker是單進程模式,多worker架構做CPU親和,內部基於事件驅動的模型,其本身已經提供了很高的性能,單核Nginx可以跑到1W5~2W QPS。Nginx往下第一層是socket API,socket往下有一層VFS,再往下是TCP、IP,socket層比較薄,經過量化的分析和評估,性能開銷最大的是TCP協定棧和VFS部分,因為同步開銷大,我們發現橫向擴展不行,對此,我們做了一些優化。

七層反向代理的路徑更長,處理更複雜,所以它的性能比LVS低很多,我們比較關注單機和集群的性能,集群性能可以靠堆設備去解決,單機如果不提升,成本會一直增加,從性能角度來看,有以下的優化思路和方向:

基於Kernel做開發,比如優化協議棧;基於Aliscoket的優化,Alisocket是阿裡研發的高性能TCP協定棧平臺,底層是DPDK,它將資源做了局部化處理,報文分發不同核處理,性能非常出色;HTTPS業務越來越多,流量逐步遞增,我們採用硬體加速卡方式做一些加解密的性能提升,還有HTTPS的會話複用;基於Web傳輸層的性能優化。

從彈性角度看,比如一些公司的應用和用戶熱點有關,當發生一個社會網路熱點後,訪問量會急劇變高,我們固有的基於物理機器實現的負載均衡模型在彈性擴展方面是有限制的,對此,我們可以使用VM去做,把反向代理功能放在VM去跑,我們會監控實例負載情況,根據即時需求做彈性擴容縮容;除了VM,還有調度單元,我們可以在不同調度單元做平滑切換,根據不同的水位情況,通過切換可以把負載均衡實例調度到不同的單元中去,改善使容量上管理。Tengine本身也做了集群化部署,我們在一個region裡有不同的機房,不同的調度單元,每個調度單元有多組設備;LVS到Tengine也有健康檢查,如果一台Tengine有問題,可以通過健康檢查方式摘除,不會影響使用者轉發能力;Tengine具備靈活的調度能力,可以幫助我們應對更多的複雜情況;另外,Tengine也有很多高級的特性,比如基於cookie的會話保持、基於功能變數名稱/URL的轉發規則、HTTP2、Websocket等功能;目前,我們7層單VIP可以支撐10W規格的HTTPS QPS。

高可用

Group

高可用是整個產品很重要的一部分,圖為集群內的高可用架構圖,可以看到,在網路路徑上是全冗余無單點的。具體情況如下:

雙路伺服器,每節點雙網口上聯不同交換機,增加頻寬,避免跨節點收包VIP路由兩邊發不同的優先順序,不同的VIP,高優先順序路由在不同的交換機上單機160G轉發能力,單VIP 80G頻寬,單流 40G頻寬網卡故障不影響轉發,上下游路由自動切換ECMP,VIP路由發兩邊,通過優先順序控制從入口集群640G轉發能力,單vip 320G頻寬會話同步,多播、包觸發同步、定時同步單機故障不影響轉發交換機故障不影響轉發,路由秒級切換用戶無感知的升級變更,部分未及時同步的連接重連即可

AZ

每個機房連接兩個不同路由器,當一個AZ出現故障之後,我們可以無縫切換到另外一個機房,具體情況如下:

VIP在不同的AZ發不同優先順序的路由(秒級切換、自動切換)VIP區分主備AZ,不同的VIP主備AZ不同多個AZ的負載通過控制系統分配缺省提供VIP多AZ的容災能力不支援跨AZ的session同步,跨AZ切換後,所有連接都需要重連

Region

當用戶訪問功能變數名稱時,通過DNS解析,可以設定DNS解析到多個regionVIP位址,下沉到某一個Region來看,如果一個機房出現故障,流量可以切換到另一個可用區繼續轉發,如果流量進到機房發現一台LVS轉發設備出現故障後,我們可以切換到另外一台LVS作處理,如果LVS後面掛載的RS出現問題,通過健康檢查也可以快速摘掉設備,將流量轉換到健康的設備上去。我們從多個維度實現高可用,最大限度的滿足用戶的需求。

總結

目前,高性能負載均衡應用主要在幾個方面:

1. 作為公有雲基礎元件,為公有雲網站、遊戲客戶、APP提供負載均衡功能,也針對政府、金融等安全性高的客戶提供專有雲支援;

2. 為阿裡雲內部雲產品RDS、OSS、高防等提供了負載均衡的功能;

3. 負載均衡作為電商平臺入口,向淘寶、天貓、1688提供VIP統一接入功能;

4. 交易平臺的流量入口也在負載均衡設備上,如支付寶、網上銀行。

未來,我們希望有更好的彈性擴展能力,更高的單機處理能力,我們希望VIP主動探測使用者,以及網路全鏈路監控。

隨著核的數量越來越多,性能不增反降。

LVS的改進

早期模式的各種限制制約了我們的發展,所以我們首先做了FullNAT,相比原來的NAT方式,FullNAT多了SNAT屬性,將用戶端的原IP位址作了轉換;其次,我們在並行化上做了處理,充分利用多核實現性能線性提升;然後是快速路徑,我們在做網路轉發模型時很容易想到設計快速路徑和慢速路徑,慢速路徑更多是解決首包如何通過設備問題,可能需要查ACL或路由,需要判斷許多和策略相關的東西,後面所有報文都可以通過快速路徑轉發出去;還有指令相關優化,利用因特爾特殊指令提升性能;另外針對多核架構,NUMA多節點記憶體訪問,通過訪問Local節點記憶體可能獲得更好的延遲表現。

用戶端進來IP首先訪問LVS的VIP,原IP是用戶端的,目的IP是LVS的VIP,經過FullNAT轉換後,原IP變成LVS的Local位址,目的地址是LVS選擇出來的RS位址,這樣在RS回包時比較容易,只要路由可達,報文一定會交到LVS上,不需要在RS上做特殊的配置。右面就是DNAT+SNAT轉換,報文就可以通過LVS轉發回用戶端,這種方式主要帶來應用場景部署靈活性選擇。

通過並行化實現對LVS性能的改善,性能沒有辦法得到線性提升更多的是因為每條路徑都需要訪問全域資源,就會不可避免引入鎖的開箱,另外,同一條連結上的報文可能分散在不同的核上,大家去訪問全域資源時也會導致cache的丟失。所以我們通過RSS技術把同一個五源組報文扔到同一個CPU上處理,保證入方向的所有相同連接上的報文都能交給相同CPU處理,每個核在轉發出去時都用當前CPU上的Local地址,通過設置一些fdir規則,報文回來時後端RS訪問的目的地址就是對應CPU上的local位址,可以交到指定的CPU上去處理,這樣一條連接上左右方向報文都可以交給同一個CPU處理,將流在不同的CPU隔離開;另外,我們把所有配置資源包括動態緩存資源在每個CPU上作了拷貝,將資源局部化,這使整個流從進入LVS到轉發出去訪問的資源都是固定在一個核上的本地資源,使性能達到最大化,實現線性提升。

經過我們改進之後,LVS的具體表現如下:

出於對容災和性能提升的考慮,我們做了集群化部署,每個region有不同機房,每個機房有多個調度單元,每個單元有多台LVS設備;每台LVS經過優化後,都能達到更高性能,大容量,單台LVS可以達到4000W PPS,600W CPS、單個group可以到達1億併發;支援region、IDC、集群和應用級的高可用;實現了防攻擊功能,並在原版LVS上提供了更豐富的功能,可以基於各個維度做管理控制,精確的統計,流量的分析等。Tengine

Tengine在應用過程中也遇到了各種問題,最嚴重的就是性能問題,我們發現隨著CPU數量越來越多,QPS值並沒有線性提升;Nginx本身是多worker模型,每個worker是單進程模式,多worker架構做CPU親和,內部基於事件驅動的模型,其本身已經提供了很高的性能,單核Nginx可以跑到1W5~2W QPS。Nginx往下第一層是socket API,socket往下有一層VFS,再往下是TCP、IP,socket層比較薄,經過量化的分析和評估,性能開銷最大的是TCP協定棧和VFS部分,因為同步開銷大,我們發現橫向擴展不行,對此,我們做了一些優化。

七層反向代理的路徑更長,處理更複雜,所以它的性能比LVS低很多,我們比較關注單機和集群的性能,集群性能可以靠堆設備去解決,單機如果不提升,成本會一直增加,從性能角度來看,有以下的優化思路和方向:

基於Kernel做開發,比如優化協議棧;基於Aliscoket的優化,Alisocket是阿裡研發的高性能TCP協定棧平臺,底層是DPDK,它將資源做了局部化處理,報文分發不同核處理,性能非常出色;HTTPS業務越來越多,流量逐步遞增,我們採用硬體加速卡方式做一些加解密的性能提升,還有HTTPS的會話複用;基於Web傳輸層的性能優化。

從彈性角度看,比如一些公司的應用和用戶熱點有關,當發生一個社會網路熱點後,訪問量會急劇變高,我們固有的基於物理機器實現的負載均衡模型在彈性擴展方面是有限制的,對此,我們可以使用VM去做,把反向代理功能放在VM去跑,我們會監控實例負載情況,根據即時需求做彈性擴容縮容;除了VM,還有調度單元,我們可以在不同調度單元做平滑切換,根據不同的水位情況,通過切換可以把負載均衡實例調度到不同的單元中去,改善使容量上管理。Tengine本身也做了集群化部署,我們在一個region裡有不同的機房,不同的調度單元,每個調度單元有多組設備;LVS到Tengine也有健康檢查,如果一台Tengine有問題,可以通過健康檢查方式摘除,不會影響使用者轉發能力;Tengine具備靈活的調度能力,可以幫助我們應對更多的複雜情況;另外,Tengine也有很多高級的特性,比如基於cookie的會話保持、基於功能變數名稱/URL的轉發規則、HTTP2、Websocket等功能;目前,我們7層單VIP可以支撐10W規格的HTTPS QPS。

高可用

Group

高可用是整個產品很重要的一部分,圖為集群內的高可用架構圖,可以看到,在網路路徑上是全冗余無單點的。具體情況如下:

雙路伺服器,每節點雙網口上聯不同交換機,增加頻寬,避免跨節點收包VIP路由兩邊發不同的優先順序,不同的VIP,高優先順序路由在不同的交換機上單機160G轉發能力,單VIP 80G頻寬,單流 40G頻寬網卡故障不影響轉發,上下游路由自動切換ECMP,VIP路由發兩邊,通過優先順序控制從入口集群640G轉發能力,單vip 320G頻寬會話同步,多播、包觸發同步、定時同步單機故障不影響轉發交換機故障不影響轉發,路由秒級切換用戶無感知的升級變更,部分未及時同步的連接重連即可

AZ

每個機房連接兩個不同路由器,當一個AZ出現故障之後,我們可以無縫切換到另外一個機房,具體情況如下:

VIP在不同的AZ發不同優先順序的路由(秒級切換、自動切換)VIP區分主備AZ,不同的VIP主備AZ不同多個AZ的負載通過控制系統分配缺省提供VIP多AZ的容災能力不支援跨AZ的session同步,跨AZ切換後,所有連接都需要重連

Region

當用戶訪問功能變數名稱時,通過DNS解析,可以設定DNS解析到多個regionVIP位址,下沉到某一個Region來看,如果一個機房出現故障,流量可以切換到另一個可用區繼續轉發,如果流量進到機房發現一台LVS轉發設備出現故障後,我們可以切換到另外一台LVS作處理,如果LVS後面掛載的RS出現問題,通過健康檢查也可以快速摘掉設備,將流量轉換到健康的設備上去。我們從多個維度實現高可用,最大限度的滿足用戶的需求。

總結

目前,高性能負載均衡應用主要在幾個方面:

1. 作為公有雲基礎元件,為公有雲網站、遊戲客戶、APP提供負載均衡功能,也針對政府、金融等安全性高的客戶提供專有雲支援;

2. 為阿裡雲內部雲產品RDS、OSS、高防等提供了負載均衡的功能;

3. 負載均衡作為電商平臺入口,向淘寶、天貓、1688提供VIP統一接入功能;

4. 交易平臺的流量入口也在負載均衡設備上,如支付寶、網上銀行。

未來,我們希望有更好的彈性擴展能力,更高的單機處理能力,我們希望VIP主動探測使用者,以及網路全鏈路監控。

同類文章
喜欢就按个赞吧!!!
点击关闭提示