LVS負載均衡原理

1、LVS基本原理概述

　　LB集羣的實現，LB即負載均衡集羣

　　　　硬件：F5 BIG-IP,Citrix NetScaler,A10,Array,Redware

　　　　軟件：Lvs，nginx，haproxy，ats，perlbal，httpd，varnish

　　　　基於工做的協議層次劃分：

　　　　　　傳輸層：

　　　　　　　　lvs沒有上線，haproxy3萬併發極限（mode-tcp）

　　　　　　應用層

　　　　　　　　haproxy，nginx，ats，perlbal

 

 

　　一、背景

　　　　能夠參考中文官方文檔http://www.linuxvirtualserver.org/zh/lvs1.html

　　　　　　　　英文官方文檔http://www.linuxvirtualserver.org/Documents.html

　　　　　　　　參考駿馬金龍博客http://www.cnblogs.com/f-ck-need-u/p/7576137.html

　　二、簡介

　　　　lvs（linux virtual server），linux虛擬服務器，是一個虛擬的四層交換器集羣系統，根據目標地址和目標端口實現用戶請求轉發，自己不產生流量，只作用戶請求轉發，目前是負載均衡性能最好的集羣系統，那麼負載均衡實現了很好可伸縮性，節點數目能夠增加到幾千，甚至幾萬。後期也由不少用戶參與開發LVS輔助工具和輔助組件，最出名的就是alexandre爲LVS編寫的keepalived，它最初專門用於監控LVS，以後又加入VRRP實現高可用功能。

　　　　負載調度器，真實服務器羣節點一塊兒被稱爲LVS，LVS負載調度器（有時也稱爲負載均衡器），接收服務的全部接入服務集羣的請求，並決定集羣中的哪一個節點應該回復其請求。

　　　　1）、負載調度器（director）：做爲整個集羣的前端，主要將用戶請求分發至真實服務器中進行處理。

　　　　2）、真實服務器池：由多個功能相同的真是服務器組成，爲用戶提供真正的網絡服務，如web服務，郵件服務等。且虛擬服務器集羣做爲一個可伸縮的集羣，可自由添加深處真是服務器而並步影響整個集羣的正常工做。

　　　　3）、共享存儲：做用就是讓每一個用戶訪問的資源都是同樣的，服務器支持寫操做，才建議使用

　　　  LVS集羣的高可用，雖然LVS負載均衡性能很好，可是若是其中節點故障，LVS是沒法感知的，所以產生了LVS周邊的一個輔助工具KeepAlived，用於監控檢查兼容性很是好，若是RS一個節點掛掉，keepalived會將此節點從管理列表中剔出，當節點恢復再拉回管理列表，可是此時的調度器存在單點故障的可能性，因此還必須使用其餘軟件來實現調度器的高可用，好比hearbeat。

　　三、經常使用名詞備註

　　　　VS:virtual server,虛擬服務器，也叫Director

　　　　RS：real server，真正的服務器，集羣中的節點

　　　　CIP：客戶端IP

　　　　VIP：virtual IP，director向外部提供服務的IP

　　　　RIP：realserver集羣節點的服務器網卡IP

　　　　DIP:director與RS通訊的IP

　　四、LVS框架

　　　　在1998年5月，章文嵩成立了Linux Virtual Server的自由軟件項目，進行Linux服務器集羣的開發工做。同時，Linux Virtual Server項目是國內最先出現的自由軟件項目之一。

　　　　Linux Virtual Server項目的目標 ：使用集羣技術和Linux操做系統實現一個高性能、高可用的服務器，它具備很好的可伸縮性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。

　　　　目前，LVS項目已提供了一個實現可伸縮網絡服務的Linux Virtual Server框架，下圖所示。在LVS框架中，提供了含有三種IP負載均衡技術的IP虛擬服務器軟件IPVS、基於內容請求分發的內核Layer-7交 換機KTCPVS和集羣管理軟件。能夠利用LVS框架實現高可伸縮的、高可用的Web、Cache、Mail和Media等網絡服務；在此基礎上，能夠開 發支持龐大用戶數的、高可伸縮的、高可用的電子商務應用。

　　　　LVS是四層（傳輸層tcp/vdp），七層（應用層）的負載均衡工具，用的最多的是就是四層負載均衡功能的ipvs，七層的內容分發負載ktcpvs（kenrnel tcp virtual server）,基於內容的調度，由於應用層交換處理複雜，但伸縮性有限，目前還不成熟

　　　　　　ipvs是集成在內核中的框架，ipvs是真正生效實現調度的代碼，能夠經過用戶空間的程序ipvadm工具來管理，該工具能夠定義一些規則來管理內核中的ipvs，就像iptables和netfilter的關係同樣。

　　　　　　ipvadmin，工做在用戶空間，負責ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器（Real Server）

 

 　　

　

　　五、LVS集羣的類型，支持的幾種模式

　　　　在LVS集羣中，集羣是一個總體，經過負載均衡調度器（director）做爲外部通訊的中介，所以如何將外部請求轉發到內部真是服務器的方式對LVS集羣分類，LVS四種方式：網絡地址轉換（LVS-NAT），直接路由（LVS-DR）,IP隧道（LVS-TUN）、LVS-FULLNAT，一個負載均衡器上能夠實現多種轉發方式，通常用一種方式便可。

　

 

2、LVS集羣架構圖示

　　

 

　　一、用戶訪問從CIP到達VIP

　　二、負載均衡器DIP到達交換/路由器

　　三、最後到達後端的RIP真實的服務器

 

3、LVS在內核中的過程

 

 

　　

 

 

　　一、當用戶向負載均衡調度器（Director Server）發起請求，調度器將請求發往內核空間。

　　二、PREROUTING鏈收到用戶請求，判斷目標IP肯定是本機IP，將數據包發往INPUT鏈。

　　三、IPVS工做在INPUT鏈上，當用戶請求到達INPUT時，IPVS會將用戶請求和本身已定義好的集羣服務進行對比，若是用戶請求的就是定義的集羣服務，那麼IPVS會強行修改數據包裏的目標IP地址及端口，並將新的數據包發往POSTROUTING鏈。

　　四、POSTROUTING連接收數據包後發現目標IP地址恰好時本身的後端服務器，那麼此時經過選路，將數據包最終發送給後端的服務器。

4、內核空間和用戶空間的交互

　　

　　　　

　　　ipvsadmin定義lvs服務監聽的ip和port，併發送給ipvs，而ipvs是工做在netfilter的input鉤子上的程序，當input鏈中有目標ip屬於lvs服務的請求報文時，ipvs就會修改該報文的鏈路，使其不進入用戶空間而直接轉到postrouting鏈上，並轉發給其中一臺real server。

 5、LVS 4種工做模式介紹

　　

　　一、lvs-nat 網絡地址轉換模式

　　大多數商品化的IP負載均衡硬件都是使用此方法，如Cisco的LocalDirector、F5的Big/ip。詳細介紹4個步驟以下：

　　　　1）客戶端發送請求到達director

　　　　2）director根據負載均衡算法改寫目標地址爲後端的RIP並轉發給該後端主機，和NAT同樣

　　　　3）當後端主機（RS）處理完請求後，將響應數據交給director

　　　　4）Director改寫源地址爲VIP後傳給客戶端

　　　　

　　　關於這種模式

　　　　一、RIP和DIP通常處於同一私有網段中。但並不是必須，RS的網關要指向DIP，這樣能保證將響應數據交給Director

　　　　二、支持端口映射，可修改請求報文的目標端口；

　　　　三、VS/NAT模式的最大缺點使Director負責全部進出數據：不只處理客戶端發起的請求，還負責將響應傳輸給客戶端。而響應數據通常比請求數據大得多，調度器Director容易出現瓶頸。（也就是像7層負載的處理方式同樣，但卻沒有7層負載那麼多功能）

　　　　四、vs必須使linux系統，RS能夠是任何系統

　　　缺點：在整個過程當中，全部輸入輸出的流量都要通過LVS調度器，調度器網絡I/O壓力就會很是大，所以很容易稱爲瓶頸，特別使對請求流量很小，而響應流量很大的web類應用來講更爲如此；

　　　優勢：NAT模式配置管理簡單，因爲使用了NAT技術，LVS調度器及應用服務器能夠在不一樣網段中，網絡架構靈活，應用服務器只須要進行簡單的網絡設定便可加入集羣。

 

　　二、lvs-dr 直接路由模式

 　　　　1）、客戶端發送請求到達director，也就是CIP:VIP ；

　　　　 2）、director將請求報文從新封裝一個mac地址首部dip-mac：rip-mac,因此DIP和RIP須要相同的物理網絡實現arp通訊,源IP地址和目標IP地址不變，只是修改源mac地址爲DIP的mac地址，目標mac地址改成RIP的mac地址；而後發送給RS；

　　　　 3）、RS發現目標地址是本身的MAC地址處理報文，而且RS本地會還接口Lo配置爲VIP，響應報文從Lo的VIP發送給eth0網卡，因此響應報文首部cip-mac:Lo-mac，最後響應報文直接發送給客戶端，此時源ip地址爲VIP，目標地址爲CIP;

　　　　　　注意：RS，director都有VIP，因此要確保請求報文只發送到director，常見的方法修改RS的內核參數arp_ignore、arp_announce設置爲1，使RS不影響其餘主機的ARP通訊。

　　　　　　補充：兩個內核參數設定說明

　　　　　　　　echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

　　　　　　　　echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

　　　　　　　　echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

　　　　　　　　echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce　　

　　　　　　　　arp_ignore 定義是否相應

　　　　　　　　　　0，默認，收到請求我只要有這個地址就響應

　　　　　　　　　　一、請求報文從哪一個地址進來的，就只能這個接口地址響應

　　　　 　　　　arp_announce 是否介紹通告，是否通知別人

　　　　　　　　　　0，默認的，所有通告

　　　　　　　　　　1，儘可能避免，不通告不一樣網段的

　　　　　　　　　　2，不通告不一樣網段的

　　　　　關於這種模式：

　　　　　　1）確保前端路由器將目標ip爲vip的請求報文發往director

　　　　　　　　a、在前端網關作靜態綁定；

　　　　　　　　b、在RS上使用arptables；

　　　　　　　　c、在RS上修改內核參數以限制arp通告即應答級別；

　　　　　　　　　　arp_announce

　　　　　　　　　　arp_ignore

　　　　　　2）、RS的RIP可使用私網或公網地址；

　　　　　　3）、RS跟director在同一物理網絡；

　　　　　　4）、請求報文經由director，響應報文直接發往client；

　　　　　　5）、此模式不支持端口映射；

　　　　　　6）、RS支持大多數的OS；

　　　　　　7）、RIP的網關不能指向DIP，以確保響應報文不經由director；

　　　　　　

　　　　　缺點：LVS調度器及應用服務器在同一個網段中，所以不能實現集羣的跨網段應用。

　　　　　優勢：直接路由轉發，經過修改請求報文的目標mac地址進行轉發，效率提高明顯

 

   　三、lvs-tun IP隧道模式

 　　　　1）、客戶端將請求發送前端的負載均衡器，請求報文源地址是CIP，目標地址爲VIP。

　　　　 2）、負載均衡器收到報文後，發現請求的在規則裏面存在的地址，它將請求報文的首部再封裝一層IP報文，將源地址改成DIP，目標地址改成RIP，並將此包發送給RS;

　　　　 3）、RS收到請求報文後，會首先拆開第一層封裝，而後發現裏面還有一層IP首部的目標地址是本身Lo接口上的VIP，因此會再次處理請求報文（這種2次分裝解封裝的過程，就稱爲隧道模式）並將響應報文經過Lo接口送給eht0網卡而後直接發給客戶端，這種模式也是須要設置Lo接口爲VIP，而且不能在公網上

　　　　

 　　　　關於這種模式：

　　　　　　1）、DIP、VIP、RIP、都應該是公網地址；

　　　　　　2）、RS的網關不能指向DIP；

　　　　　　3）、請求報文要經由Director，響應報文不經由director；

　　　　　　4）、不知道端口映射

　　　　　　5）、RS的操做系統須要支持隧道功能

　　　　缺點：須要租用大量IP，特別是後端服務器使用較多的狀況下

　　　　優勢：LVS調度器將TCP/IP請求從新封裝發給後端服務器，後端應用服務器之間經過IP隧道來進行轉發，能夠存在於不一樣的網段中

　　四、lvs-fullnat 

　　　　1）、客戶端對VIP發起請求；

　　　　2）、director接收請求，發現是請求後端集羣，對請求報文作full nat，源IP改成DIP，目標IP轉換爲任意後端RS的RIP，而後發日後端；

　　　　3）、RS收到請求後，進行響應，源IP爲RIP，目標IP爲DIP，內部路由到director；

　　　　4）、director收到響應報文後，進行full nat，源地址改成VIP，目標地址改成CIP；

 

 

 

 　　　　關於這種模式：

　　　　　　1）、VIP是公網地址，RIP和DIP是死亡地址，且一般不在同一網絡，所以RIP的網關通常不會指向DIP；

　　　　　　2）、RS收到的請求報文地址是DIP，所以只需響應給DIP，但director還要將其發往client；

　　　　　　3）、請求和響應報文都經由director；

　　　　　　4）、支持端口映射；

　　　　這種模式就像DNAT，它經過同時修改請求報文的源IP地址和目標IP地址進行轉發，另外此模式還不是正式版本，須要在官方網站下週源碼，編譯系統內核才能使用。

6、三種類型比較

 

7、LVS的調度方法scheduler

　　負載均衡器可用於作出該決定的調度方法分紅兩個基本的類別，靜態調度和動態調度

　　一、靜態調度，根據算法自己進行調度

　　　　1）RR:round robin，輪詢

　　　　經過輪詢的調度算法，就會分配的比較多，不管後端端真實服務器負載狀態如何都會平均輪詢調度。

　　　　2）WRR:weightd round robin,帶權重的輪詢

　　　　帶權重的輪詢

　　　　3）SH：source hashing源地址hash

　　　　未來自同一個ip的請求始終調度至同一RS

　　　　4）DH：destination hashing目標地址hash

　　　　將同一個目標的請求始終發往同一個RS

　　二、動態調度，根據算法及各RS的當前負載狀態進行調度

　　　　1）、LC：least connection，最少鏈接

　　　　經過監控後端RS的鏈接數，根據TCP協議種的某些計算器來判斷，將請求調度已創建的鏈接數最少後端的真實服務器上。

　　　　計算方法：overhead=active*256+lnactive，overhead越小，表示負載越低

　　　　2）、WLC：weight lc，加權的lc

　　　　計算方法：overhead=（active*256+lnactive）/weight

　　　　3）、SED：shortest expertion delay，最短時間望延遲

　　　　計算方法:overhead=(active+1)*256/加權，數目最小，介紹下次請求。

　　　　4）、NQ：never queue，永不排隊

　　　　無需排隊，若是有臺realserver的鏈接數=0就直接分配過去，不須要在進行sed運算，保證不會有一個主機很空閒。

　　　　5）、LBLC：locality-based least connection，基於本地的最小鏈接，爲動態的DH算法

　　　　該算法根據請求的目標IP地址找出該目標IP 地址最近使用的real server，若該服務器是可用的且沒有超載，就會使用「最少鏈接來挑選一臺可用的服務器，將請求發送到該服務器。

　　　　6）、LBLCR：replicated lblc，帶複製功能的lblc，是dh算法的一種改進

 　　　　該算法根據請求的目標IP地址對應的服務器組，按「最小鏈接」原則從服務器組種選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接」原則從這個集羣種選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器，同時，當該服務器組有一段時間沒被修改，將最忙的服務器從服務器組中刪除，以下降複製的成都。

 

 

轉載請註明出處：http://www.javashuo.com/article/p-nphhatwo-n.html