http://www.cnblogs.com/bccu/archive/2009/03/11/1408899.html

在調度器的實現技術中，IP負載均衡技術效率最高。在已有的IP負載均衡技術中有通過網絡地址轉換（Network Address Translation）將一組服務器構成一個高性能的、高可用的虛擬服務器，我們稱之為VS/NAT技術（Virtual Server via Network Address Translation），大多數商品化的IP負載均衡調度器產品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。在分析VS/NAT的缺點和網絡服務的非對稱性的基礎上，我們提出通過IP隧道實現虛擬服務器的方法VS/TUN（Virtual Server via IP Tunneling），和通過直接路由實現虛擬服務器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。所以，IPVS軟件實現了這三種IP負載均衡技術，它們的大致原理如下：
Virtual Server via Network Address Translation（VS/NAT）
通過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給后端真實服務器；真實服務器的響應報文通過調度器時，報文源地址被重寫再返回給客戶，完成整個負載調度過程。
下面的基本結構和三層結構其實都是利用NAT這種方式。這種情況的配置比較簡單，但通常在流量比較大的情況下會造成調度器的瓶頸。因為服務數據的返回必須通過調度器出去。
Virtual Server via IP Tunneling（VS/TUN）
采用NAT技術時，由于請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為了解決這個問題，調度器把請求報文通過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，所以調度器只處理請求報文。由于一般網絡服務應答比請求報文大許多，采用VS/TUN技術后，集群系統的最大吞吐量可以提高10倍。
Virtual Server via Direct Routing（VS/DR）
VS/DR通過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地提高集群系統的伸縮性。這種方法沒有IP隧道的開銷，對集群中的真實服務器也沒有必須支持IP隧道協議的要求，但是要求調度器與真實服務器都有一塊網卡連在同一物理網段上。也就是說，在這種結構中，數據從外部到內部真實服務器的訪問會通過調度器進來，但是真實服務器對其的應答不是通過調度器出去。即在大多數情況下，真實服務器可以通過各自的網關或者專用的網關對數據進行外發，從而降低調度器負載。
同時在LVS中提供了八種不同的調度算法以供按照實際需求選擇：
輪叫（Round Robin）
調度器通過"輪叫"調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。
加權輪叫（Weighted Round Robin）
調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。
最少鏈接（Least Connections）
調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用"最小連接"調度算法可以較好地均衡負載。
加權最少鏈接（Weighted Least Connections）
在集群系統中的服務器性能差異較大的情況下，調度器采用"加權最少鏈接"調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。
基于局部性的最少鏈接（Locality-Based Least Connections）
"基于局部性的最少鏈接" 調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務器，將請求發送到該服務器。
帶復制的基于局部性最少鏈接（Locality-Based Least Connections with Replication） "帶復制的基于局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。
目標地址散列（Destination Hashing）
"目標地址散列"調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
源地址散列（Source Hashing）
"源地址散列"調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
上述八種負載均衡調度算法在實施中，節點的權重越高，在集群中使用的頻率就越高。比如說權重為2的節點在每接收兩個訪問請求之后，權重為1的節點才接收一個訪問請求。
LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。
為此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。一般來說，LVS集群采用三層結構，其體系結構如圖1所示，三層主要組成部分為：
負載調度器（load balancer），它是整個集群對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認為服務是來自一個IP地址（我們可稱之為虛擬IP地址）上的。
服務器池（server pool），是一組真正執行客戶請求的服務器，服務有WEB、MAIL、FTP和DNS等。
共享存儲（shared storage），它為服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。
調度器是服務器集群系統的唯一入口點（Single Entry Point），它可以采用IP負載均衡技術、基于內容請求分發技術或者兩者相結合。在IP負載均衡技術中，需要服務器池擁有相同的內容提供相同的服務。當客戶請求到達時，調度器只根據服務器負載情況和設定的調度算法從服務器池中選出一個服務器，將該請求轉發到選出的服務器，并記錄這個調度；當這個請求的其他報文到達，也會被轉發到前面選出的服務器。在基于內容請求分發技術中，服務器可以提供不同的服務，當客戶請求到達時，調度器可根據請求的內容選擇服務器執行請求。因為所有的操作都是在Linux操作系統核心空間中將完成的，它的調度開銷很小，所以它具有很高的吞吐率。
服務器池的結點數目是可變的。當整個系統收到的負載超過目前所有結點的處理能力時，可以在服務器池中增加服務器來滿足不斷增長的請求負載。對大多數網絡服務來說，請求間不存在很強的相關性，請求可在不同的結點上并行執行，所以整個系統的性能基本上可隨著服務器池的結點數目增加而線性增長。
共享存儲通常是數據庫、網絡文件系統或者分布式文件系統。服務器結點需要動態更新的數據一般存儲在數據庫系統中，同時數據庫會保證并發訪問時數據的一致性。靜態的數據可以存儲在網絡文件系統（如NFS/CIFS）中，但網絡文件系統的伸縮能力有限，一般來說，NFS/CIFS服務器只能支持3~6個繁忙的服務器結點。對于規模較大的集群系統，可以考慮用分布式文件系統，如AFS[1]、GFS[2.3]、Coda[4]和Intermezzo[5]等。分布式文件系統可為各服務器提供共享的存儲區，它們訪問分布式文件系統就像訪問本地文件系統一樣，同時分布式文件系統可提供良好的伸縮性和可用性。此外，當不同服務器上的應用程序同時讀寫訪問分布式文件系統上同一資源時，應用程序的訪問沖突需要消解才能使得資源處于一致狀態。這需要一個分布式鎖管理器（Distributed Lock Manager），它可能是分布式文件系統內部提供的，也可能是外部的。開發者在寫應用程序時，可以使用分布式鎖管理器來保證應用程序在不同結點上并發訪問的一致性。
負載調度器、服務器池和共享存儲系統通過高速網絡相連接，如100Mbps交換網絡、Myrinet和Gigabit網絡等。使用高速的網絡，主要為避免當系統規模擴大時互聯網絡成為整個系統的瓶頸。
Graphic Monitor是為系統管理員提供整個集群系統的監視器，它可以監視系統的狀態。Graphic Monitor是基于瀏覽器的，所以無論管理員在本地還是異地都可以監測系統的狀況。為了安全的原因，瀏覽器要通過HTTPS（Secure HTTP）協議和身份認證后，才能進行系統監測，并進行系統的配置和管理。
層次的體系結構可以使得層與層之間相互獨立，每一個層次提供不同的功能，在一個層次可以重用不同的已有軟件。例如，調度器層提供了負載平衡、可伸縮性和高可用性等，在服務器層可以運行不同的網絡服務，如Web、Cache、Mail和Media等，來提供不同的可伸縮網絡服務。明確的功能劃分和清晰的層次結構使得系統容易建設，以后整個系統容易維護，而且系統的性能容易被擴展。
共享存儲如分布式文件系統在這個LVS集群系統是可選項。當網絡服務需要有相同的內容，共享存儲是很好的選擇，否則每臺服務器需要將相同的內容復制到本地硬盤上。當系統存儲的內容越多，這種無共享結構（Shared-nothing Structure）的代價越大，因為每臺服務器需要一樣大的存儲空間，任何的更新需要涉及到每臺服務器，系統的維護代價會非常高。
共享存儲為服務器組提供統一的存儲空間，這使得系統的內容維護工作比較輕松，如Webmaster只需要更新共享存儲中的頁面，對所有的服務器都有效。分布式文件系統提供良好的伸縮性和可用性，當分布式文件系統的存儲空間增加時，所有服務器的存儲空間也隨之增大。對于大多數Internet服務來說，它們都是讀密集型（Read-intensive）的應用，分布式文件系統在每臺服務器使用本地硬盤作Cache（如2Gbytes的空間），可以使得訪問分布式文件系統本地的速度接近于訪問本地硬盤。
此外，存儲硬件技術的發展也促使從無共享的集群向共享存儲的集群遷移。存儲區域網（Storage Area Networks）技術解決了集群的每個結點可以直接連接/共享一個龐大的硬盤陣列，硬件廠商也提供多種硬盤共享技術，如光纖通道（Fiber Channel）、共享SCSI（Shared SCSI）。InfiniBand是一個通用的高性能I/O規范，使得存儲區域網中以更低的延時傳輸I/O消息和集群通訊消息，并且提供很好的伸縮性。InfiniBand得到絕大多數的大廠商的支持，如Compaq、Dell、Hewlett-Packard、IBM、Intel、Microsoft和SUN Microsystems等，它正在成為一個業界的標準。這些技術的發展使得共享存儲變得容易，規模生產也會使得成本逐步降低。
集群系統的特點是它在軟硬件上都有冗余。系統的高可用性可以通過檢測節點或服務進程故障和正確地重置系統來實現，使得系統收到的請求能被存活的結點處理。
通常，我們在調度器上有資源監測進程來時刻監視各個服務器結點的健康狀況。當服務器對ICMP ping不可達時或者探測她的網絡服務在指定的時間沒有響應時，資源監測進程通知操作系統內核將該服務器從調度列表中刪除或者失效。這樣，新的服務請求就不會被調度到壞的結點。資源監測進程能通過電子郵件或傳呼機向管理員報告故障。一旦監測進程到服務器恢復工作，通知調度器將其加入調度列表進行調度。另外，通過系統提供的管理程序，管理員可發命令隨時可以將新機器加入服務來提高系統的處理性能，也可以將已有的服務器切出服務，以便對服務器進行系統維護。
現在前端的調度器有可能成為系統的單一失效點（Single Point of Failure）。一般來說，調度器的可靠性較高，因為調度器上運行的程序較少而且大部分程序早已經遍歷過，但我們不能排除硬件老化、網絡線路或者人為誤操作等主要故障。為了避免調度器失效而導致整個系統不能工作，我們需要設立一個從調度器作為主調度器的備份。兩個心跳（Heartbeat）進程[6]分別在主、從調度器上運行，它們通過串口線和UDP等心跳線來相互定時地匯報各自的健康狀況。當從調度器不能聽得主調度器的心跳時，從調度器通過ARP欺騙（Gratuitous ARP）來接管集群對外的Virtual IP Address，同時接管主調度器的工作來提供負載調度服務。當主調度器恢復時，這里有兩種方法，一是主調度器自動變成從調度器，二是從調度器釋放Virtual IP Address，主調度器收回Virtual IP Address并提供負載調度服務。這里，多條心跳線可以使得因心跳線故障導致誤判（即從調度器認為主調度器已經失效，其實主調度器還在正常工作）的概論降到最低。
通常，當主調度器失效時，主調度器上所有已建立連接的狀態信息將丟失，已有的連接會中斷?？蛻粜枰蛑匦逻B接，從調度器才會將新連接調度到各個服務器上，這對客戶會造成一定的不便。為此，IPVS調度器在Linux 內核中實現一種高效狀態同步機制，將主調度器的狀態信息及時地同步到從調度器。當從調度器接管時，絕大部分已建立的連接會持續下去。
在具體實施過程中，在紅帽企業版Linux上對LVS集群的定義和配置提供了更加詳細的方案：

LVS集群的結構：基本結構和三層結構
基本結構圖示如下：
在這種結構中有兩臺雙網卡的Linux服務器被配置為LVS Router，又稱為調度器。LVS的主要作用是虛擬出一個公共連接的IP地址和一個專用連接的IP地址（這兩個地址不是手工配置生成，而是在服務啟動的時候形成），稱之為浮動地址。
在同一個時間，只有一個LVS Server處于工作狀態，外部用戶要訪問內部的真實服務器實際上所做的操作是直接訪問LVS Server的外部網絡浮動地址，在這個例子中是eth0:1。這個公共網絡浮動地址就是外部用戶要訪問的虛擬服務器。只不過是虛擬服務器能夠將來自外部的訪問按照負載均衡算法發送到內部的真實服務器上面。這種算法通常帶有輪詢性質。
而內部真實服務器在上面的結構中會將網關指向LVS Server的內部浮動地址，這個結構中是eth1:1。真實服務器在接收到由虛擬服務器轉發的服務請求之后會將結果通過eth1:1返回。
盡管eth0:1是虛擬服務器IP地址，但是如果在同一個結構中要支持多個不同虛擬地址的服務，比如說HTTP在1.1.1.10，FTP在1.1.1.20……這種情況下完全可以建立多個不同的虛擬網卡。不過仍然要注意，這個虛擬網絡是在服務啟動狀態下自動生成的而不是手動建立和配置的。
為了保證所有的真實服務器都提供同樣的服務內容，通常也會指定一些特定的方式，比如利用rsync或者借助下面的三層結構的共享存儲來維護多臺真實服務器的數據一致性。
在任何時候只有一臺LVS服務器處于工作狀態中，而另外一臺處于備份狀態。他們之間通過心跳頻道來相互探知對方的狀態。探知的方式是借助一些特定的腳本通過心跳頻道相互發送信號。在這個結構中主心跳頻道是LVS服務器的公共網絡，而備用心跳頻道是LVS服務器的內部網絡。
當然在上面的圖中，并不是一定需要兩個LVS Router，只有一臺LVS Router的情況下也可以做，只不過少了一些保證而已。


LVS1.PNG
(6.77 KB) 2008-7-28 23:48




三層結構圖示如下：
從下面的圖可以看出，三層結構相對于基本結構需要更多的設備，配置方面也比較復雜。僅僅是后臺的集群系統已經需要足夠的時間去折騰。但這種結構對于大數據訪問量的FTP服務器、Samba等應用來說是比較理想的。在這個結構中的后面是HA集群，通常HA集群會以服務的形式提供Samba，NFS以及FTP等服務，而真實服務器會通過掛載的方式獲得HA上提供出來的數據。
另外在紅帽的LVS中還有一個比較關鍵的東西是LVS的組件：
LVS的組件中服務包括pulse，lvs，ipvsadm以及nany；另外還包括配置文件/etc/sysconfig/ha/lvs.cf，配置工具piranha configuration tooly以及服務IP進行浮動之前arp欺騙手段中的send_arp。
pulse是LVS的控制進程，該進程用于啟動和控制所有的其他LVS相關的守護進程。該進程的配置文件是/etc/sysconfig/ha/lvs.cf。在主router上pulse用于啟動LVS守護進程，在備份router上pulse通過定期收發心跳信號監控主router的狀態。如果一旦主router失效，在備份router上的pulse進程將關閉所有主router上的LVS服務，并且開啟send_arp程序來重新指派浮動IP到備份router的MAC上。
lvs進程運行在主router上，主要讀取/etc/sysconfig/ha/lvs.cf文件，調用lvsadm工具來建立與維護ipvs路由表并對每一個LVS服務指派nanny進程。如果nanny報告一個真實服務器失效，lvs進程將調用ipvsadm工具將失效真實服務器從IPVS路由表中刪除。
ipvsadm用于升級kernel中的IPVS路由表，該進程主要用于更改、添加、刪除IPVS路由表的條目。
nanny監控的進程運行在主LVS Router上，主LVS Router會通過他來監控每一個真實服務器的狀況。
另外piranha configuration tool提供了一個圖形接口用于修改/etc/sysconfig/ha/lvs.cf文件，而send_arp會在浮動IP向不同的LVS router進行切換時發送arp廣播。


LVS2.PNG
(7.5 KB) 2008-7-28 23:52

基于LVS的Linux負載均衡技術實現（第一篇：基本原理）