大型網站架構系列:負載均衡詳解(4)

五柳-先生發表於2016-02-28

本文是負載均衡詳解的第四篇,主要介紹了LVS的三種請求轉發模式和八種負載均衡演算法,以及Haproxy的特點和負載均衡演算法。具體參考文章,詳見最後的連結。

 

三、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.1LVS/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.2LVS/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.3LVS/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場景架構。

4、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,希望本次分享對大家有幫助。

 

參考資料:

Nginx負載均衡實現原理圖解 http://www.server110.com/nginx/201403/7225.html

Nginx架構及其web服務搭建優化配置詳解

http://linux.it.net.cn/e/server/nginx/2015/0102/11183.html

Ngnix雙主場景:http://network.51cto.com/art/201109/288597.htm

用LVS構架負載均衡Linux叢集系統 linux lvs

http://blog.chinaunix.net/uid-45094-id-3012037.html

LVS基本介紹

http://os.51cto.com/art/201202/317108.htm

 

下次分享時間:下下週12月9日 晚7點30~~8點30見。《大型網站架構系列:分散式訊息佇列技術》

分享是快樂的,也是個人成長的過程。文章一般是自己的學習總結,工作經驗,不足之處在所難免,請大家指正,共同進步。建立了一個以架構為中心的KK群466097527 ,歡迎大家加入。專注大型分散式網站架構,大資料,架構模式,設計模式。

轉載:http://www.cnblogs.com/itfly8/p/5080988.html

相關文章