G行全棧云環境負載均衡服務能力實踐—負載均衡服務關鍵技術介紹
?隨著云計算和云原生技術的發展,各大云計算廠商都在布局云計算數據中心,為用戶提供更加安全高效的計算、存儲、網絡資源以及應用服務資源。一些大型企業尤其是金融業需要建立自己的私有數據中心,保證數據的安全可控。目前各數據中心都在由傳統數據中心向云計算數據中心轉型,以滿足新興技術的發展和業務快速迭代的需求。G行作為金融行業數字化轉型的探索者與實踐者,提出“123+N”的數字化特色發展體系,即一個智慧大腦,兩大技術平臺——云計算和大數據,三項服務能力——移動化、開放化、生態化服務能力。根據數字化發展戰略要求,傳統數據中心的應用系統要逐步遷移到云平臺,實現服務云化,滿足業務快速迭代的需要,同時云平臺可提供快速便捷的資源交付和資源擴容能力,提升資源利用率,達到降本增效的目標。
針對應用上云,G行制定了相關的上云策略,強調優先容器化部署,對于無法容器化改造的產品組件可通過虛擬機或裸金屬方式上云,以多種部署形式滿足應用上云要求。針對傳統環境和云上應用,所使用業務流量負載方式是不同的。傳統環境主要使用硬件F5負載均衡,優點是性能好、功能強大,缺點是成本高、擴展性差、不符合信創要求。云環境使用云平臺提供的服務組件彈性負載均衡服務,優點是成本低、擴展性好、符合信創要求,缺點是相比硬件負載均衡性能略有下降。本文主要對云上負載均衡的實踐進行總結介紹。
一、負載均衡定義
負載均衡技術是通過硬件或者軟件定義的方法,來擴展網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。其主要作用如下。
1、高并發性
負載均衡通過負載算法將應用請求盡力均勻的分配到后端負載各節點,以此提高應用集群的并發處理能力。
2、高可用性
負載均衡可以通過健康檢查機制監控后端負載節點,當負載節點不可用時,自動隔離故障節點,并將請求分發給可用的負載節點,使得應用集群具備高可用的特性。
3、彈性伸縮性
通過動態添加或減少負載節點數量,然后由負載均衡進行分發控制,使得應用集群具備彈性及伸縮性。
二、負載均衡算法
負載均衡的功能是流量分發,即將接受的流量請求按照一定的算法規則轉發給后端的負載節點,實現高并發的同時,能夠最大限度地利用后端負載服務器的資源。常用的主要有以下幾種算法。
負載均衡算法 | 描述 | 使用場景 |
rr輪詢算法 | rr 算法就是將外部請求按順序輪流分配到集群中的負載節點上,但不考慮每臺負載節點的負載情況。 | 該算法適合后端負載節點配置一致,算力均等的場景。 |
wrr加權 輪詢算法 | wrr 算法在rr 算法的基礎上會考察每臺負載節點的負載情況,并嘗試讓負載較輕的節點承擔更多請求。 | 該算法適合后端負載節點算力配置不均等的場景。 |
lc最少連接數算法 | lc算法可以讓負載均衡設備嘗試把新的請求交給當前連接數最少的負載節點 ,直到此負載節點連接數不再屬于最少標準。 | 常用于長連接服務場景。 |
源 IP 算法 | 將請求的源 IP 地址進行 Hash 運算,得到一個具體的數值,同時對后端服務器進行編號,按照運算結果將請求分發到對應編號的服務器上。這可以使得對不同源 IP 的訪問進行負載分發,同時使得同一個客戶端 IP 的請求始終被派發至某特定的服務器。 | 該方式適合負載均衡無 cookie 功能的TCP 協議。 |
三、負載均衡健康檢查
負載均衡通過健康檢查來判斷后端負載實例的業務可用性,當后端負載實例的服務異常時,負載均衡根據健康狀態判斷自動隔離異常節點,不進行流量分發,待后端負載節點服務恢復后,根據健康狀態判斷自動上線該節點,從而提高前端業務整體可用性。健康檢查常用的兩種檢查機制如下。
1、七層HTTP監聽健康檢查機制
針對七層HTTP監聽,健康檢查通過HTTP HEAD探測來獲取狀態信息。
圖1 HTTP監聽健康檢查機制
負載均衡服務器根據監聽的健康檢查配置,向后端負載節點發送“IP+健康檢查端口+檢查路徑”的HTTP HEAD請求。后端負載收到請求后,根據相應服務的運行情況,返回HTTP狀態碼。
如果在響應超時時間之內,負載均衡服務器沒有收到后端負載節點返回的信息,則認為服務無響應,判定健康檢查失敗;如果負載均衡服務器成功接收到后端負載節點返回的狀態碼,且狀態碼與配置的狀態碼一致,則判定健康檢查成功,反之則判定健康檢查失敗。
2、TCP監聽健康檢查機制
圖2 TCP監聽監控檢查機制
針對四層TCP監聽,負載均衡服務器通過TCP的3次握手機制對后端負載節點進行TCP探測,根據監聽的健康檢查配置,向后端負載節點發送“IP+健康檢查端口”的TCP SYN數據包。后端負載節點收到請求后,如果相應端口正在正常監聽,則會返回SYN+ACK數據包。
如果在響應超時時間之內,負載均衡服務器接收到后端負載節點返回的數據包,則發送ACK數據包判定健康檢查成功,建立TCP連接;如果沒有收到后端負載節點返回的數據包,則認為服務無響應,判定健康檢查失敗并向后端負載節點發送RST數據包中斷TCP連接。
四、健康檢查周期
健康檢查機制有效提高了業務服務的可用性。但是頻繁的健康檢查一方面會增加后端負載節點的負載壓力,另一方面健康檢查失敗引起的頻繁切換對系統可用性也有一定的沖擊。因此需要對健康檢查周期進行設置,避免頻繁檢查和頻繁切換。健康檢查周期由下幾個因素決定。
1、檢查間隔
每隔多久進行一次健康檢查。
2、超時時間
等待健康檢查請求返回的時間,返回超時將會被判定為一次檢查失敗。
3、不健康閾值
健康檢查連續失敗的次數,達到閾值后端服務將被屏蔽。
4、健康閾值
健康檢查連續成功的次數,達到閾值后端服務將被恢復。
健康檢查周期的計算方法如下:
健康檢查失敗周期=超時時間×不健康閾值+檢查間隔×(不健康閾值-1)
健康檢查成功周期=(健康檢查成功響應時間x健康閾值)+檢查間隔x(健康閾值-1)
舉例:假設健康檢查間隔為2s,超時時間為5s,不健康閾值和健康閾值都為3。那么從從健康檢查狀態成功到到失敗需要19s(如圖3所示)。健康檢查失敗到狀態檢查成功耗時最短為7s(如圖3,健康檢查OK時間假設為1s)。其中健康檢查成功響應時間是一次健康檢查請求從發出到響應的時間。當采用TCP方式健康檢查時,由于僅探測端口是否存活,因此該時間非常短,幾乎可以忽略不計。當采用HTTP方式健康檢查時,該時間取決于應用服務器的性能、負載以及相應服務接口的響應時間,但通常都在秒級以內。
圖3 健康檢查周期計算方法
G行全棧云應用上云分為虛擬機上云和容器化上云。針對不同的上云方式,負載均衡均可提供流量負載均衡服務。應用通過負載均衡ELB將負載流量轉發給后端的多個虛擬機或者容器應用,通過TCP和HTTP兩種健康檢查方式對后端負載的存活狀態進行探查。TCP健康檢查只探測對應的應用端口是否存在,配置簡單,響應較快。HTTP檢查可以根據提供的端口和URL路徑準確判斷應用的健康狀態,檢查準確性高,覆蓋面更全,具體使用方式根據業務場景進行配置。針對流量轉發算法,一般負載均衡后端的負載節點配置相同,可采用輪詢算法進行負載流量轉發。
圖4 G行虛擬機上云與容器化上云的負載均衡示意
五、總結
全棧云負載均衡服務,一方面可以替代傳統硬件負載均衡設備提供負載能力;另一方面,云上負載均衡設備已云化,具備敏捷交付和彈性擴容能力,且后端負載節點既可以是虛擬機設備,也可以是容器節點,適用性廣,同時也擁有滿足信創要求的優勢。在全行應用系統上云中,它既可以作為負載均衡架構應用組件的負載能力組件,又作為容器應用的統一入口地址,統一對外暴露固定地址,在云環境中將發揮越來越大的作用。