一、什麼是LVS？前端
首先簡單介紹一下LVS (Linux Virtual Server)究竟是什麼東西，其實它是一種集羣(Cluster)技術，採用IP負載均衡技術和基於內容請求分發技術。調度器具備很好的吞吐率，將請求均衡地轉移到不一樣的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集羣的結構對客戶是透明的，並且無需修改客戶端和服務器端的程序。算法
爲此，在設計時須要考慮系統的透明性、可伸縮性、高可用性和易管理性。通常來講，LVS集後端
羣採用三層結構，其體系結構如圖所示：
服務器
LVS集羣的體系結構網絡
2、LVS主要組成部分爲：負載均衡
負載調度器（load balancer/ Director），它是整個集羣對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認爲服務是來自一個IP地址（咱們可稱之爲虛擬IP地址）上的。函數
服務器池（server pool/ Realserver），是一組真正執行客戶請求的服務器，執行的服務通常有WEB、MAIL、FTP和DNS等。性能
共享存儲（shared storage），它爲服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。測試
3、LVS負載均衡方式:spa
◆Virtual Server via Network Address Translation NAT（VS/NAT）
VS/NAT是一種最簡單的方式，全部的RealServer只須要將本身的網關指向Director便可。客戶端能夠是任意操做系統，但此方式下，一個Director可以帶動的RealServer比較有限。在VS/NAT的方式下，Director也能夠兼爲一臺RealServer。VS/NAT的體系結構如圖所示。
VS/NAT的體系結構
◆Virtual Server via IP Tunneling(VS/TUN)
IP隧道（IP tunneling）是將一個IP報文封裝在另外一個IP報文的技術，這可使得目標爲一個IP地址的數據報文能被封裝和轉發到另外一個IP地址。IP隧道技術亦稱爲IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態創建的，隧道一端有一個IP地址，另外一端也有惟一的IP地址。
它的鏈接調度和管理與VS/NAT中的同樣，只是它的報文轉發方法不一樣。調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，將請求報文封裝在另外一個IP報文中，再將封裝後的IP報文轉發給選出的服務器；服務器收到報文後，先將報文解封得到原來目標地址爲 VIP 的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，因此就處理這個請求，而後根據路由表將響應報文直接返回給客戶。
VS/TUN的體系結構
VS/TUN的工做流程：
◆Virtual Server via Direct Routing(VS/DR)
VS/DR方式是經過改寫請求報文中的MAC地址部分來實現的。Director和RealServer必需在物理上有一個網卡經過不間斷的局域網相連。 RealServer上綁定的VIP配置在各自Non-ARP的網絡設備上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址便可以是內部地址，也能夠是真實地址。
VS/DR的體系結構
VS/DR的工做流程
VS/DR的工做流程如圖所示：它的鏈接調度和管理與VS/NAT和VS/TUN中的同樣，它的報文轉發方法又有不一樣，將報文直接路由給目標服務器。在VS/DR中，調度器根據各個服務器的負載狀況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改成選出服務器的MAC地址，再將修改後的數據幀在與服務器組的局域網上發送。由於數據幀的MAC地址是選出的服務器，因此服務器確定能夠收到這個數據幀，從中能夠得到該IP報文。當服務器發現報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，而後根據路由表將響應報文直接返回給客戶。
VS/DR的工做流程
四、三種負載均衡方式比較：
◆Virtual Server via NAT
VS/NAT 的優勢是服務器能夠運行任何支持TCP/IP的操做系統，它只須要一個IP地址配置在調度器上，服務器組能夠用私有的IP地址。缺點是它的伸縮能力有限，當服務器結點數目升到20時，調度器自己有可能成爲系統的新瓶頸，由於在VS/NAT中請求和響應報文都須要經過負載調度器。咱們在Pentium166 處理器的主機上測得重寫報文的平均延時爲60us，性能更高的處理器上延時會短一些。假設TCP報文的平均長度爲536 Bytes，則調度器的最大吞吐量爲8.93 MBytes/s. 咱們再假設每臺服務器的吞吐量爲800KBytes/s，這樣一個調度器能夠帶動10臺服務器。（注：這是很早之前測得的數據）
基於 VS/NAT的的集羣系統能夠適合許多服務器的性能要求。若是負載調度器成爲系統新的瓶頸，能夠有三種方法解決這個問題：混合方法、VS/TUN和 VS/DR。在DNS混合集羣系統中，有若干個VS/NAT負調度器，每一個負載調度器帶本身的服務器集羣，同時這些負載調度器又經過RR-DNS組成簡單的域名。
但VS/TUN和VS/DR是提升系統吞吐量的更好方法。
對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，須要編寫相應的應用模塊來轉換報文數據中的IP地址或者端口號。這會帶來實現的工做量，同時應用模塊檢查報文的開銷會下降系統的吞吐率。
◆Virtual Server via IP Tunneling
在VS/TUN 的集羣系統中，負載調度器只將請求調度到不一樣的後端服務器，後端服務器將應答的數據直接返回給用戶。這樣，負載調度器就能夠處理大量的請求，它甚至能夠調度百臺以上的服務器（同等規模的服務器），而它不會成爲系統的瓶頸。即便負載調度器只有100Mbps的全雙工網卡，整個系統的最大吞吐量可超過 1Gbps。因此，VS/TUN能夠極大地增長負載調度器調度的服務器數量。VS/TUN調度器能夠調度上百臺服務器，而它自己不會成爲系統的瓶頸，能夠用來構建高性能的超級服務器。VS/TUN技術對服務器有要求，即全部的服務器必須支持「IP Tunneling」或者「IP Encapsulation」協議。目前，VS/TUN的後端服務器主要運行Linux操做系統，咱們沒對其餘操做系統進行測試。由於「IP Tunneling」正成爲各個操做系統的標準協議，因此VS/TUN應該會適用運行其餘操做系統的後端服務器。
◆Virtual Server via Direct Routing
跟VS/TUN方法同樣，VS/DR調度器只處理客戶到服務器端的鏈接，響應數據能夠直接從獨立的網絡路由返回給客戶。這能夠極大地提升LVS集羣系統的伸縮性。跟VS/TUN相比，這種方法沒有IP隧道的開銷，可是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，服務器網絡設備（或者設備別名）不做ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上。
三種LVS負載均衡技術的優缺點概括如下表：
|
VS/NAT
|
VS/TUN |
VS/DR |
服務器操做系統 |
任意 |
支持隧道 |
多數（支持Non-arp） |
服務器網絡 |
私有網絡 |
局域網/廣域網 |
局域網 |
服務器數目（100M網絡） |
10~20 |
100 |
大於100 |
服務器網關 |
負載均衡器 |
本身的路由 |
本身的路由 |
| 效率 |
通常
|
高 |
最高 |
注：以上三種方法所能支持最大服務器數目的估計是假設調度器使用100M網卡，調度器的硬件配置與後端服務器的硬件配置相同，並且是對通常Web服務。使 用更高的硬件配置（如千兆網卡和更快的處理器）做爲調度器，調度器所能調度的服務器數量會相應增長。當應用不一樣時，服務器的數目也會相應地改變。因此，以上數據估計主要是爲三種方法的伸縮性進行量化比較。
五、lvs的負載調度算法 在內核中的鏈接調度算法上，IPVS已實現瞭如下八種調度算法：
◆一 輪叫調度（Round­Robin Schedul ing ）
輪叫調度（Round Robin Scheduling）算法就是以輪叫的方式依次將請求調度不一樣的服務器，即每次調度執行i=(i+1)mod n，並選出第i臺服務器。算法的優勢是其簡潔性，它無需記錄當前全部鏈接的狀態，因此它是一種無狀態調度。
◆二 加權輪叫調度（Weighted Round­Robin Scheduling ）
加權輪叫調度 （Weighted Round­Robin Scheduling）算法能夠解決服務器間性能不一的狀況，它用相應的權值表示服務器的處理性能，服務器的缺省權值爲1。假設服務器A的權值爲1，B的權值爲2，則表示服務器B的處理性能是A的兩倍。加權輪叫調度算法是按權值的高 低和輪叫方式分配請求到各服務器。權值高的服務器先收到的鏈接，權值高的服 務器比權值低的服務器處理更多的鏈接，相同權值的服務器處理相同數目的鏈接數。
◆三 最小鏈接調度（Least­Connect ion Schedul ing ）
最小鏈接調度（Least­ Connect ion Scheduling）算法是把新的鏈接請求分配到當前鏈接數最小的服務器。最小鏈接調度是一種動態調度算法，它經過服務器當前所活躍的鏈接數來估計服務器的負載狀況。調度器須要記錄各個服務器已創建鏈接的數目，當一個請求被調度到某臺服務器，其鏈接數加1；當鏈接停止或超時，其鏈接數減一。
◆四 加權最小鏈接調度（Weighted Least­Connectio n Scheduling）
加權最小鏈接調 度（Weighted Least­Connectio n Scheduling）算法是最小鏈接調度的超集，各個服務器用相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員能夠動態地設置服務器的權值。加權最小鏈接調度在調度新鏈接時儘量使服務器的已創建鏈接數和其權值成比例。
◆五 基於局部性的最少連接（Locality­Based Least Connections Schedulin g ）
基於局部性的最少連接調度（Locality­Based Least Connections Scheduling，如下簡稱爲LBLC）算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，由於在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求，算法的設計目標是在服務器的負載基本平衡狀況下，將相同目標IP地址的請求調度到同一臺服務器，來提升各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP 地址 找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工 做負載，則用「最少連接」的原則選出一個可用的服務器，將請求發送到該服務器。
◆六 帶複製的基於局部性最少連接（Locality­Based Least Connectio ns with Replication Scheduling）
帶複製的基於局部性最少連接調度（Locality­Based Least Connectio ns 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地址對應的服務器組；按「最小鏈接」原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按「最小鏈接」原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服 務器從服務器組中刪除，以下降複製的程度。
◆七 目標地址散列調度（Destinat ion Hashing Scheduling ）
目標地址散列調度 （Destinat ion Hashing Scheduling）算法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，經過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。
◆八 源地址散列調度（Source Hashing Scheduling）
源地址散列調度（Source Hashing Scheduling）算法正好與目標地址散列調度算法相反，它根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。它採用的散列函數與目標地址散列調度算法 的相同。它的算法流程與目標地址散列調度算法的基本類似，除了將請求的目標IP地址換成請求的源IP 地址，因此這裏不一一敘述。在實際應用中，源地址散列 調度和目標地址散列調度能夠結合使用在防火牆集羣中，它們能夠保證整個系統的惟一出入口。
--leeypp@gmail.com
