歡迎光臨
每天分享高質量文章

分佈式架構系列: 負載均衡軟體詳解

 

一、軟體負載均衡概述

 

硬體負載均衡性能優越,功能全面,但是價格昂貴,一般適合初期或者土豪級公司長期使用。因此軟體負載均衡在互聯網領域大量使用。常用的軟體負載均衡軟體有Nginx,Lvs,HaProxy等。本文參考大量文件,部分為直接拷貝。

 

二、Ngnix負載均衡

 

Ngnix是一款輕量級的Web服務器/反向代理服務器,工作在七層Http協議的負載均衡系統。具有高性能、高併發、低記憶體使用等特點。是一個輕量級的Http和反向代理服務器。Nginx使用epoll and kqueue作為開發模型。能夠支持高達 50,000 個併發連接數的響應。

 

  • 操作系統:Liunx,Windows(Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows)
  • 開發語言:C
  • 併發性能:官方支持每秒5萬併發,實際國內一般到每秒2萬併發,有優化到每秒10萬併發的。具體性能看應用場景。

 

2.1.特點

 

  • 1.模塊化設計:良好的擴展性,可以通過模塊方式進行功能擴展。
  • 2.高可靠性:主控行程和worker是同步實現的,一個worker出現問題,會立刻啟動另一個worker。
  • 3.記憶體消耗低:一萬個長連接(keep-alive),僅消耗2.5MB記憶體。
  • 4.支持熱部署:不用停止服務器,實現更新配置檔案,更換日誌檔案、更新服務器程式版本。
  • 5.併發能力強:官方資料每秒支持5萬併發;
  • 6.功能豐富:優秀的反向代理功能和靈活的負載均衡策略

 

2.2.功能

2.2.1 基本功能

 

  • 支持靜態資源的web服務器。
  • http,smtp,pop3協議的反向代理服務器、快取、負載均衡;
  • 支持FASTCGI(fpm)
  • 支持模塊化,過濾器(讓文本可以實現壓縮,節約帶寬),ssl及圖像大小調整。
  • 內置的健康檢查功能
  • 基於名稱和ip的虛擬主機
  • 定製訪問日誌
  • 支持平滑升級
  • 支持KEEPALIVE
  • 支持url rewrite
  • 支持路徑別名
  • 支持基於IP和用戶名的訪問控制。
  • 支持傳輸速率限制,支持併發數限制。

2.2.2 性能

 

Nginx的高併發,官方測試支持5萬併發連接。實際生產環境能到2-3萬併發連接數。10000個非活躍的HTTP keep-alive 連接僅占用約2.5MB記憶體。三萬併發連接下,10個Nginx行程,消耗記憶體150M。淘寶tengine團隊測試結果是“24G記憶體機器上,處理併發請求可達200萬”。

 

2.3架構

2.3.1Nginx的基本工作樣式

 

 

一個master行程,生成一個或者多個worker行程。但是這裡master是使用root身份啟動的,因為nginx要工作在80端口。而只有管理員才有權限啟動小於低於1023的端口。master主要是負責的作用只是啟動worker,加載配置檔案,負責系統的平滑升級。其它的工作是交給worker。那麼當worker被啟動之後,也只是負責一些web最簡單的工作,而其他的工作都是有worker中呼叫的模塊來實現的。

 

模塊之間是以流水線的方式實現功能的。流水線,指的是一個用戶請求,由多個模塊組合各自的功能依次實現完成的。比如:第一個模塊只負責分析請求首部,第二個模塊只負責查找資料,第三個模塊只負責壓縮資料,依次完成各自工作。來實現整個工作的完成。

 

他們是如何實現熱部署的呢?其實是這樣的,我們前面說master不負責具體的工作,而是呼叫worker工作,他只是負責讀取配置檔案,因此當一個模塊修改或者配置檔案發生變化,是由master進行讀取,因此此時不會影響到worker工作。在master進行讀取配置檔案之後,不會立即的把修改的配置檔案告知worker。而是讓被修改的worker繼續使用老的配置檔案工作,當worker工作完畢之後,直接當掉這個子行程,更換新的子行程,使用新的規則。

 

2.3.2Nginx支持的sendfile機制

 

Sendfile機制,用戶將請求發給內核,內核根據用戶的請求呼叫相應用戶行程,行程在處理時需要資源。此時再把請求發給內核(行程沒有直接IO的能力),由內核加載資料。內核查找到資料之後,會把資料複製給用戶行程,由用戶行程對資料進行封裝,之後交給內核,內核在進行tcp/ip首部的封裝,最後再發給客戶端。這個功能用戶行程只是發生了一個封裝報文的過程,卻要繞一大圈。因此nginx引入了sendfile機制,使得內核在接受到資料之後,不再依靠用戶行程給予封裝,而是自己查找自己封裝,減少了一個很長一段時間的浪費,這是一個提升性能的核心點。

 

 

以上內容摘自網友發佈的文章,簡單一句話是資源的處理,直接通過內核層進行資料傳遞,避免了資料傳遞到應用層,應用層再傳遞到內核層的開銷。

 

目前高併發的處理,一般都採用sendfile樣式。通過直接操作內核層資料,減少應用與內核層資料傳遞。

 

2.3.3Nginx通信模型(I/O復用機制)

 

  • 開發模型:epoll和kqueue。
  • 支持的事件機制:kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。
  • 支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF,可用資料的數量,錯誤代碼.
  • 支持sendfile、sendfile64和sendfilev;檔案AIO;DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP。
  • 以上概念較多,大家自行百度或谷歌,知識領域是網絡通信(BIO,NIO,AIO)和多執行緒方面的知識。

 

2.4均衡策略

 

nginx的負載均衡策略可以劃分為兩大類:內置策略和擴展策略。內置策略包含加權輪詢和ip hash,在預設情況下這兩種策略會編譯進nginx內核,只需在nginx配置中指明引數即可。擴展策略有很多,如fair、通用hash、consistent hash等,預設不編譯進nginx內核。由於在nginx版本升級中負載均衡的代碼沒有本質性的變化,因此下麵將以nginx1.0.15穩定版為例,從原始碼角度分析各個策略。

 

2.4.1. 加權輪詢(weighted round robin)

 

輪詢的原理很簡單,首先我們介紹一下輪詢的基本流程。如下是處理一次請求的流程圖:

 

 

圖中有兩點需要註意,第一,如果可以把加權輪詢演算法分為先深搜索和先廣搜索,那麼nginx採用的是先深搜索演算法,即將首先將請求都分給高權重的機器,直到該機器的權值降到了比其他機器低,才開始將請求分給下一個高權重的機器;第二,當所有後端機器都down掉時,nginx會立即將所有機器的標誌位清成初始狀態,以避免造成所有的機器都處在timeout的狀態,從而導致整個前端被夯住。

 

2.4.2. ip hash

 

ip hash是nginx內置的另一個負載均衡的策略,流程和輪詢很類似,只是其中的演算法和具體的策略有些變化,如下圖所示:

 

2.4.3. fair

 

fair策略是擴展策略,預設不被編譯進nginx內核。其原理是根據後端服務器的響應時間判斷負載情況,從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性,但是實際的網絡環境往往不是那麼簡單,因此要慎用。

 

2.4.4 通用hash、一致性hash

 

這兩種也是擴展策略,在具體的實現上有些差別,通用hash比較簡單,可以以nginx內置的變數為key進行hash,一致性hash採用了nginx內置的一致性hash環,可以支持memcache。

 

2.5場景

 

Ngnix一般作為入口負載均衡或內部負載均衡,結合反向代理服務器使用。以下架構示例,僅供參考,具體使用根據場景而定。

 

2.5.1入口負載均衡架構

 

 

Ngnix服務器在用戶訪問的最前端。根據用戶請求再轉發到具體的應用服務器或二級負載均衡服務器(LVS)

 

2.5.2內部負載均衡架構

 

 

LVS作為入口負載均衡,將請求轉發到二級Ngnix服務器,Ngnix再根據請求轉發到具體的應用服務器。

 

2.5.3Ngnix高可用

 

 

分佈式系統中,應用只部署一臺服務器會存在單點故障,負載均衡同樣有類似的問題。一般可採用主備或負載均衡設備集群的方式節約單點故障或高併發請求分流。

 

Ngnix高可用,至少包含兩個Ngnix服務器,一臺主服務器,一臺備服務器,之間使用Keepalived做健康監控和故障檢測。開放VIP端口,通過防火牆進行外部映射。

 

DNS解析公網的IP實際為VIP。

 

三、LVS負載均衡

 

LVS是一個開源的軟體,由畢業於國防科技大學的章文嵩博士於1998年5月創立,用來實現Linux平臺下的簡單負載均衡。LVS是Linux Virtual Server的縮寫,意思是Linux虛擬服務器。

 

基於IP層的負載均衡調度技術,它在操作系統核心層上,將來自IP層的TCP/UDP請求均衡地轉移到不同的 服務器,從而將一組服務器構成一個高性能、高可用的虛擬服務器。

 

  • 操作系統:Liunx
  • 開發語言:C
  • 併發性能:預設4096,可以修改但需要重新編譯。

 

3.1.功能

 

LVS的主要功能是實現IP層(網絡層)負載均衡,有NAT,TUN,DR三種請求轉發樣式。

 

3.1.1 LVS/NAT方式的負載均衡集群

 

NAT是指Network Address Translation,它的轉發流程是:Director機器收到外界請求,改寫資料包的標的地址,按相應的調度演算法將其發送到相應Real Server上,Real Server處理完該請求後,將結果資料包傳回到其預設網關,即Director機器上,Director機器再改寫資料包的源地址,最後將其傳回給外界。這樣就完成一次負載調度。

 

構架一個最簡單的LVS/NAT方式的負載均衡集群Real Server可以是任何的操作系統,而且無需做任何特殊的設定,惟一要做的就是將其預設網關指向Director機器。Real Server可以使用局域網的內部IP(192.168.0.0/24)。Director要有兩塊網卡,一塊網卡系結一個外部IP地址 (10.0.0.1),另一塊網卡系結局域網的內部IP(192.168.0.254),作為Real Server的預設網關。

 

LVS/NAT方式實現起來最為簡單,而且Real Server使用的是內部IP,可以節省Real IP的開銷。但因為執行NAT需要重寫流經Director的資料包,在速度上有一定延遲;

 

當用戶的請求非常短,而服務器的回應非常大的情況下,會對Director形成很大壓力,成為新的瓶頸,從而使整個系統的性能受到限制。

 

3.1.2 LVS/TUN方式的負載均衡集群

 

TUN是指IP Tunneling,它的轉發流程是:Director機器收到外界請求,按相應的調度演算法,通過IP隧道發送到相應Real Server,Real Server處理完該請求後,將結果資料包直接傳回給客戶。至此完成一次負載調度。

 

最簡單的LVS/TUN方式的負載均衡集群架構使用IP Tunneling技術,在Director機器和Real Server機器之間架設一個IP Tunnel,通過IP Tunnel將負載分配到Real Server機器上。Director和Real Server之間的關係比較鬆散,可以是在同一個網絡中,也可以是在不同的網絡中,只要兩者能夠通過IP Tunnel相連就行。收到負載分配的Real Server機器處理完後會直接將反饋資料送回給客戶,而不必通過Director機器。實際應用中,服務器必須擁有正式的IP地址用於與客戶機直接通信,並且所有服務器必須支持IP隧道協議。

 

 

 

該方式中Director將客戶請求分配到不同的Real Server,Real Server處理請求後直接回應給用戶,這樣Director就只處理客戶機與服務器的一半連接,極大地提高了Director的調度處理能力,使集群系統能容納更多的節點數。另外TUN方式中的Real Server可以在任何LAN或WAN上運行,這樣可以構築跨地域的集群,其應對災難的能力也更強,但是服務器需要為IP封裝付出一定的資源開銷,而且後端的Real Server必須是支持IP Tunneling的操作系統。

 

3.3.3 LVS/TUN方式的負載均衡集群

 

DR是指Direct Routing,它的轉發流程是:Director機器收到外界請求,按相應的調度演算法將其直接發送到相應Real Server,Real Server處理完該請求後,將結果資料包直接傳回給客戶,完成一次負載調度。

 

構架一個最簡單的LVS/DR方式的負載均衡集群Real Server和Director都在同一個物理網段中,Director的網卡IP是192.168.0.253,再系結另一個IP: 192.168.0.254作為對外界的virtual IP,外界客戶通過該IP來訪問整個集群系統。Real Server在lo上系結IP:192.168.0.254,同時加入相應的路由。

 

LVS/DR方式與前面的LVS/TUN方式有些類似,前臺的Director機器也是只需要接收和調度外界的請求,而不需要負責傳回這些請求的反饋結果,所以能夠負載更多的Real Server,提高Director的調度處理能力,使集群系統容納更多的Real Server。但LVS/DR需要改寫請求報文的MAC地址,所以所有服務器必須在同一物理網段內。

 

3.3 架構

 

LVS架設的服務器集群系統有三個部分組成:最前端的負載均衡層(Loader Balancer),中間的服務器群組層,用Server Array表示,最底層的資料共享儲存層,用Shared Storage表示。在用戶看來所有的應用都是透明的,用戶只是在使用一個虛擬服務器提供的高性能服務。

 

LVS的體系架構如圖:

 

 

LVS的各個層次的詳細介紹:

 

Load Balancer層:位於整個集群系統的最前端,有一臺或者多台負載調度器(Director Server)組成,LVS模塊就安裝在Director Server上,而Director的主要作用類似於一個路由器,它含有完成LVS功能所設定的路由表,通過這些路由表把用戶的請求分發給Server Array層的應用服務器(Real Server)上。同時,在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord,此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除,恢復時重新加入。

 

Server Array層:由一組實際運行應用服務的機器組成,Real Server可以是WEB服務器、MAIL服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個,每個Real Server之間通過高速的LAN或分佈在各地的WAN相連接。在實際的應用中,Director Server也可以同時兼任Real Server的角色。

 

Shared Storage層:是為所有Real Server提供共享儲存空間和內容一致性的儲存區域,在物理上,一般有磁盤陣列設備組成,為了提供內容的一致性,一般可以通過NFS網絡檔案系統共享數 據,但是NFS在繁忙的業務系統中,性能並不是很好,此時可以採用集群檔案系統,例如Red hat的GFS檔案系統,oracle提供的OCFS2檔案系統等。

 

從整個LVS結構可以看出,Director Server是整個LVS的核心,目前,用於Director Server的操作系統只能是Linux和FreeBSD,linux2.6內核不用任何設置就可以支持LVS功能,而FreeBSD作為 Director Server的應用還不是很多,性能也不是很好。對於Real Server,幾乎可以是所有的系統平臺,Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

 

3.4均衡策略

 

LVS預設支持八種負載均衡策略,簡述如下:

 

3.4.1.輪詢調度(Round Robin)

 

調度器通過“輪詢”調度演算法將外部請求按順序輪流分配到集群中的真實服務器上,它均等地對待每一臺服務器,而不管服務器上實際的連接數和系統負載。

 

3.4.2.加權輪詢(Weighted Round Robin)

 

調度器通過“加權輪詢”調度演算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值。

 

3.4.3.最少鏈接(Least Connections)

 

調度器通過“最少連接”調度演算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能,採用“最小連接”調度演算法可以較好地均衡負載。

 

3.4.4.加權最少鏈接(Weighted Least Connections)

 

在集群系統中的服務器性能差異較大的情況下,調度器採用“加權最少鏈接”調度演算法優化負載均衡性能,具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況,並動態地調整其權值。

 

3.4.5.基於區域性性的最少鏈接(Locality-Based Least Connections)

 

“基於區域性性的最少鏈接”調度演算法是針對標的IP地址的負載均衡,目前主要用於Cache集群系統。該演算法根據請求的標的IP地址找出該標的IP地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於一半的工作負載,則用“最少鏈接” 的原則選出一個可用的服務器,將請求發送到該服務器。

 

3.4.6.帶複製的基於區域性性最少鏈接(Locality-Based Least Connections with Replication)

 

“帶複製的基於區域性性最少鏈接”調度演算法也是針對標的IP地址的負載均衡,目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個標的IP地址到一組服務器的映射,而LBLC演算法維護從一個標的IP地址到一臺服務器的映射。該演算法根據請求的標的IP地址找出該標的IP地址對應的服務器組,按“最小連接”原則從服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載,則按“最小連接”原則從這個集群中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服務器從服務器組中刪除,以降低複製的程度。

 

3.4.7.標的地址散列(Destination Hashing)

 

“標的地址散列”調度演算法根據請求的標的IP地址,作為散列鍵(Hash Key)從靜態分配的散串列找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則傳回空。

 

3.4.8.源地址散列(Source Hashing)

 

“源地址散列”調度演算法根據請求的源IP地址,作為散列鍵(Hash Key)從靜態分配的散串列找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則傳回空。

 

除具備以上負載均衡演算法外,還可以自定義均衡策略。

 

3.5場景

 

一般作為入口負載均衡或內部負載均衡,結合反向代理服務器使用。相關架構可參考Ngnix場景架構。

 

四、HaProxy負載均衡

 

HAProxy也是使用較多的一款負載均衡軟體。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理,支持虛擬主機,是免費、快速並且可靠的一種解決方案。特別適用於那些負載特大的web站點。運行樣式使得它可以很簡單安全的整合到當前的架構中,同時可以保護你的web服務器不被暴露到網絡上。

 

4.1.特點

 

  • 支持兩種代理樣式:TCP(四層)和HTTP(七層),支持虛擬主機;
  • 配置簡單,支持url檢測後端服務器狀態;
  • 做負載均衡軟體使用,在高併發情況下,處理速度高於nginx;
  • TCP層多用於Mysql從(讀)服務器負載均衡。 (對Mysql進行負載均衡,對後端的DB節點進行檢測和負載均衡)
  • 能夠補充Nginx的一些缺點比如Session的保持,Cookie引導等工作

4.2.均衡策略

 

支持四種常用演算法:

 

  • 1.roundrobin:輪詢,輪流分配到後端服務器;
  • 2.static-rr:根據後端服務器性能分配;
  • 3.leastconn:最小連接者優先處理;
  • 4.source:根據請求源IP,與Nginx的IP_Hash類似。

 

五、本次分享總結

 

以上是本周的分享,從主要講解了軟體負載均衡的應用背景,Ngnix負載均衡,LVS負載均衡,Haproxy負載均衡。

 

因為時間關係,有些講解的不細緻,大家可以問下度娘/Google,希望本次分享對大家有幫助。

 

來源: http://www.cnblogs.com/itfly8/p/5080743.html

    赞(0)

    分享創造快樂