1.LVS:(LB集羣的一個實現)
Internet的快速增長使多媒體網絡服務器面對的訪問數量快速增加，服務器需要具備提供大量並法訪問的能力，因此對於大負載的服務器來講，CPU，I/O處理能力很快就會成爲瓶頸。由於單臺服務器的性能總是有限的，簡單的提高硬件性能並不能真正解決這個問題。爲此，必須採用多服務器和負載均衡技術才能滿足大量訪問的需要。Linux虛擬服務器（Linux Virtual Servers，LVS）使用負載均衡技術將多臺服務器組成一個虛擬服務器。它爲適應快速增長的網絡訪問需求提供了一個負載能力易於擴展，而且價格低廉的解決方案。
2.LVS結構框架
LVS由前端的負載均衡器（Load Balancer，LB）和後端的真實服務器（Real Server，RS）羣組成。RS間可以通過局域網或廣域網連接。LVS的這種結構對用是透明的，用戶只能看見一臺作爲LB的虛擬服務器（Virtal Server），而看不到提供服務的RS羣。當用戶的請求發往虛擬服務器，LB根據設定的包轉發策略和負載均衡調度算法將用戶的請求轉發給RS。RS再將用戶請求結果返回給用戶。同請求包一樣，應答包的返回方式也與包轉發策略有關。
3.LVS工作原理：
（1）lvs的控制是由兩部份組成的
ipvs(ip virrual server):一段代碼(工作在內核中的netfilter input鉤子函數上)是真正生效實現調度的代碼
ipvsadm（工作在用戶空間的命令行工具，負責爲ipvs內核框架編寫規則，用於管理集羣服務）
（2）lvs附着於netfiler五個內置的鉤子函數
PREROUTING —> INPUT（流向內部)
PREROUTING----> FORWARD —> POSTROUTING(轉發)‘
OUTPUT—> POSTROUTING(流向外部)
（3）lvs工作於INPUT
PREROUTING ---> INPUT(lvs在此強行改變數據流向)--->POSTROUTING
1.當用戶向負載均衡調度器（Director Server）發起請求，調度器將請求發往至內核空間
2.PREROUTING鏈首先會接收到用戶請求，判斷目標IP確定是本機IP，將數據包發往INPUT鏈
3.IPVS是工作在INPUT鏈上的，當用戶請求到達INPUT時，IPVS會將用戶請求和自己已定義好的集羣服務進行比對，如果用戶請求的就是定義的集羣服務，那麼此時IPVS會強行修改數據包裏的目標IP地址及端口，並將新的數據包發往POSTROUTING鏈
4.POSTROUTING鏈接收數據包後發現目標IP地址剛好是自己的後端服務器，那麼此時通過選路，將數據包最終發送給後端的服務器
4.LVS的包轉發策略：
1.NAT (Network Address Translation)模式。LB收到用戶請求包後，LB將請求包中虛擬服務器的IP地址轉換爲某個選定RS的IP地址，轉發給RS；RS將應答包發給LB，LB將應答包中RS的IP轉爲虛擬服務器的IP地址，回送給用戶。
2.IP隧道 (IP Tunneling)模式。LB收到用戶請求包後，根據IP隧道協議封裝該包，然後傳給某個選定的RS；RS解出請求信息，直接將應答內容傳給用戶。此時要求RS和LB都要支持IP隧道協議。
3.DR(Direct Routing)模式。LB收到請求包後，將請求包中目標MAC地址轉換爲某個選定RS的MAC地址後將包轉發出去，RS收到請求包後,可直接將應答內容傳給用戶。此時要求LB和所有RS都必須在一個物理段內,且LB與RS羣共享一個虛擬IP。
三種負載平衡對比
| 網絡地址轉換（NAT） | 直接路由（DR） | IP隧道（IP TUN） | |
|---|---|---|---|
| 建立難度 | 易 | 有一定難度 | 有一定難度 |
| 可擴展性 | 差 | 好 | 很好 |
| 帶寬 | 小 | 大 | 大 |
| 延遲 | 最大 | 小 | 大 |
| 支持的服務器數量 | 少（10～20） | 多（>100） | 多（>100） |
| IP包修改 | 修改IP地址和端口 | 修改IP包的MAD地址 | 對請求包進行IP包裝 |
| 後臺服務器OS | 任何支持NAT的OS | 多數 | 支持IP Tunnel |
| 網絡連接 | 局域網 | 局域網 | 本地或遠程 |
| 缺省路由 | 負載均衡服務器 | 不限 | |
| 實際服務器限制 | 無 | Lo不響應ARP | Tunl設備不響應ARP |
| 服務端口映射 | 可以 | 不可以 | 不可以 |
5.lvs相關術語
1.DS：Director Server。指的是前端負載均衡器節點。
2.RS：Real Server。後端真實的工作服務器。
3.VIP：向外部直接面向用戶請求，作爲用戶請求的目標的IP地址。
4.DIP：Director Server IP，主要用於和內部主機通訊的IP地址。
5.RIP：Real Server IP，後端服務器的IP地址。
6.CIP：Client IP，訪問客戶端的IP地址。
6.LVS 的負載調度算法
在內核中的連接調度算法上,IPVS 已實現了以下八種調度算法:
一.
輪叫調度(RoundRobin Scheduling )
輪叫調度(Round Robin Scheduling)算法就是以輪叫的方式依次將請求調度不同的服務器,即每次調度執行 i = (i + 1) mod n,並選出第 i 臺服務器。算法的優點是其簡潔性,它無需記錄當前所有連接的狀態,所以它是一種無狀態調度。
二.
加權輪叫調度(Weighted RoundRobin Scheduling )
加權輪叫調度 (Weighted RoundRobin Scheduling)算法可以解決服務器間性能不一的情況,它用相應的權值表示服務器的處理性能,服務器的缺省權值爲 1。假設服務器 A 的權值爲1,B 的 權值爲 2,則表示服務器 B 的處理性能是 A 的兩倍。加權輪叫調度算法是按權值的高低和輪叫方式分配請求到各服務器。權值高的服務器先收到的連接,權值高的服 務器比權值低的服務器處理更多的連接,相同權值的服務器處理相同數目的連接數。
三
最小連接調度(LeastConnection Scheduling )
最小連接調度(Least Connection Scheduling)算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態調度算法,它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目,當一個請求被調度到某臺服務器,其連接數加 1;當連接中止或超時,其連接數減一。
四
加權最小連接調度(Weighted LeastConnection Scheduling)
加權最小連接調 度(Weighted LeastConnection Scheduling)算法是最小連接調度的超集,各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲 1,系統管理員可以動態地設置服務器的權值。加權最小連接調度在調度新連接時儘可能使服務器的已立連接數和其權
值成比例。
五
基於局部性的最少鏈接(LocalityBased Least Connections Scheduling )
基 於局部性的最少鏈接調度(LocalityBased Least Connections Scheduling,以下簡稱爲LBLC)算法是針對請求報文的目標 IP 地址的負載均衡調度,目前主要用於 Cache 集羣系統,因爲在 Cache 集羣中 客戶請求報文的目標 IP 地址是變化的。這裏假設任何後端服務器都可以處理任一請求,算法的設計目標是在服務器的負載基本平衡情況下,將相同目標 IP 地址的 請求調度到同一臺服務器,來提高各臺服務器的訪問局部性和主存 Cache 命中率,從而整個集
羣系統的處理能力。LBLC 調度算法先根據請求的目標 IP 地址 找出該目標 IP 地址最近使用的服務器,若該服務器是可用的且沒有超載,將請求發送到該服務器;若服務器不存在,或者該服務器超載且有服務器處於其一半的工 作負載,則用 “ 最少鏈接 ” 的原則選出一個可用的服務器,將請求發送到該服務器。
六
帶複製的基於局部性最少鏈接(LocalityBased Least Connections with Replication
Scheduling)
帶複製的基於局部性最少鏈接調度(LocalityBased Least Connections with Replication
Scheduling,以下簡稱爲 LBLCR)算法也是針對目標 IP 地址的負載均衡,目前主要用於 Cache集羣系統。它與 LBLC 算法的不同之處是它要 維護從一個目標 IP 地址到一組服務器的映射,而 LBLC 算法維護從一個目標 IP 地址到一臺服務器的映射。對於一個 “ 熱門 ” 站點的服務請求,一臺 Cache 服務器可能會忙不過來處理這些請求。這時,LBLC 調度算法會從所有的Cache 服務器中按 “ 最小連接 ” 原則選出一臺 Cache 服務器,映射該 “ 熱門 ” 站 點到這臺Cache 服務器,很快這臺 Cache 服務器也會超載,就會重複上述過程選出新的 Cache 服務器。這樣,可能會導致該 “ 熱門 ” 站點的映像會出現 在所有的 Cache 服務器上,降低了 Cache 服務器的使用
效率。LBLCR 調度算法將 “ 熱門 ” 站點映射到一組 Cache 服務器(服務器集合),當該 “ 熱門 ” 站點的請求負載增加時,會增加集合裏的 Cache 服務器,來處理不斷增長的負載;當該 “ 熱門 ” 站點的請求負載降低時,會減少集合裏的 Cache 服務器 數目。這樣,該 “ 熱門 ” 站點的映像不太可能出現在所有的 Cache 服務器上,從而提供 Cache 集羣系統的使用效率。
LBLCR 算法先根據請求的目標 IP 地址找出該目標 IP 地址對應的服務器組;按 “ 最小連接 ” 原則從該服務器組中選出一臺服務器,若服務器沒有超載,將請求發送到該服務器;若服務器超載;則按 “ 最小連接 ” 原則從整個集羣中選出一臺服務器,將該服務器加入到服務器組中,將請求發送到該服務器。同時,當該服務器組有一段時間沒有被修改,將最忙的服 務器從服務器組中刪除,以降低複製的程度。
七
目標地址散列調度(Destination Hashing Scheduling )
目標地址散列調度 (Destination Hashing Scheduling)算法也是針對目標 IP 地址的負載均衡,但它是一種靜態映射算法,通過一個散列(Hash)函數將一個目標 IP 地址映射到一臺服務
器。目標地址散列調度算法先根據請求的目標 IP 地址,作爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則
返回空。
八
源地址散列調度(Source Hashing Scheduling)
源地址散列調度(Source Hashing Scheduling)算法正好與目標地址散列調度算法相反,它根據請求的源 IP 地址,作爲散列鍵(Hash Key)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,否則返回空。它採用的散列函數與目標地址散列調度算法 的相同。它的算法流程與目標地址散列調度算法的基本相似,除了將請求的目標 IP 地址換成請求的源 IP 地址,所以這裏不一一敘述。在實際應用中,源地址散列 調度和目標地址散列調度可以結合使用在防火牆集羣中,它們可以保證整個系統的唯一出入口。