ipvsadm及lvs的調度算法

 libnet下載地址： http://search.cpan.org/dist/libnet/

ipvsadm下載地址： http://www.linuxvirtualserver.org/software/ipvs.html#kernel-2.6
從Linux內核版本2.6起，ip_vs code已經被整合進了內核中，所以，只要在編譯內核的時候選擇了ipvs的功能，您的Linux即能支持LVS。Linux 2.4.23之後的內核版本也整合了ip_vs code，但若是是更舊的內核版本，您得本身手動將ip_vs code整合進內核原碼中，並從新編譯內核方可以使用lvs。
1、關於ipvsadm:
ipvsadm是運行於用戶空間、用來與ipvs交互的命令行工具，它的做用表如今：
一、定義在Director上進行dispatching的服務(service)，以及哪此服務器(server)用來提供此服務；
二、爲每臺同時提供某一種服務的服務器定義其權重（即概據服務器性能肯定的其承擔負載的能力）；
注：權重用整數來表示，有時候也能夠將其設置爲atomic_t；其有效表示值範圍爲24bit整數空間，即（2^24-1）；
所以，ipvsadm命令的主要做用表如今如下方面：
一、添加服務（經過設定其權重>0）；
二、關閉服務（經過設定其權重>0）；此應用場景中，已經鏈接的用戶將能夠繼續使用此服務，直到其退出或超時；新的鏈接請求將被拒絕；
三、保存ipvs設置，經過使用「ipvsadm-sav > ipvsadm.sav」命令實現；
四、恢復ipvs設置，經過使用「ipvsadm-sav < ipvsadm.sav」命令實現；
五、顯示ip_vs的版本號，下面的命令顯示ipvs的hash表的大小爲4k；
  # ipvsadm
    IP Virtual Server version 1.2.1 (size=4096)
六、顯示ipvsadm的版本號
  # ipvsadm --version
   ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)

七、查看LVS上當前的全部鏈接
# ipvsadm -Lcn   
或者
#cat /proc/net/ip_vs_conn
八、查看虛擬服務和RealServer上當前的鏈接數、數據包數和字節數的統計值，則可使用下面的命令實現：
# ipvsadm -l --stats
九、查看包傳遞速率的近似精確值，可使用下面的命令：
# ipvsadm -l --rate
2、ipvsadm使用中應注意的問題
默認狀況下，ipvsadm在輸出主機信息時使用其主機名而非IP地址，所以，Director須要使用名稱解析服務。若是沒有設置名稱解析服務、服務不可用或設置錯誤，ipvsadm將會一直等到名稱解析超時後才返回。固然，ipvsadm須要解析的名稱僅限於RealServer，考慮到DNS提供名稱解析服務效率不高的狀況，建議將全部RealServer的名稱解析經過/etc/hosts文件來實現；

3、調度算法
Director在接收到來自於Client的請求時，會基於"schedule"從RealServer中選擇一個響應給Client。ipvs支持如下調度算法：（一、2爲靜態調度算法，三、四、五、六、七、8爲動態調度算法）
一、輪詢（round robin, rr),加權輪詢(Weighted round robin, wrr)——
新的鏈接請求被輪流分配至各RealServer；算法的優勢是其簡潔性，它無需記錄當前全部鏈接的狀態，因此它是一種無狀態調度。輪叫調度算法假設全部服務器處理性能均相同，無論服務器的當前鏈接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的狀況，並且當請求服務時間變化比較大時，輪叫調度算法容易致使服務器間的負載不平衡。

二、目標地址散列調度（Destination Hashing，dh）

算 法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，經過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先 根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。

三、源地址散列調度（Source Hashing，sh）

算 法正好與目標地址散列調度算法相反，它根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然返回空。它採用的散列函數與目標地址散列調度算法 的相同。除了將請求的目標IP地址換成請求的源IP地址外，它的算法流程與目標地址散列調度算法的基本類似。在實際應用中，源地址散列調度和目標地址散列 調度能夠結合使用在防火牆集羣中，它們能夠保證整個系統的惟一出入口。

 

四、最少鏈接(least connected, lc)， 加權最少鏈接(weighted least connection, wlc)——
新的鏈接請求將被分配至當前鏈接數最少的RealServer；最小鏈接調度是一種動態調度算法，它經過服務器當前所活躍的鏈接數來估計服務器的負載狀況。調度器須要記錄各個服務器已創建鏈接的數目，當一個請求被調度到某臺服務器，其鏈接數加1；當鏈接停止或超時，其鏈接數減一。
lc：256*A+I=當前鏈接數  wlc：（256*A+I）/W=當前鏈接數   【A：活動鏈接數  I:非活動鏈接數 W：權重值】
五、基於局部性的最少連接調度（Locality-Based Least Connections Scheduling，lblc）——
針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，由於在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器均可以處理任一請求，算法的設計目標是在服務器的負載基本平衡狀況下，將相同目標IP地址的請求調度到同一臺服務器，來提升各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工做負載，則用「最少連接」的原則選出一個可用的服務器，將請求發送到該服務器。
六、帶複製的基於局部性最少連接調度（Locality-Based 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地址對應的服務器組；按「最小鏈接」原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按「最小鏈接」原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。
七、 最短的指望的延遲（Shortest Expected Delay Scheduling ,sed）
sed: (A+1)/w=當前鏈接數
八、最少隊列調度（Never Queue Scheduling ,nq）
無需隊列。若是有臺realserver的鏈接數＝0就直接分配過去，不須要在進行sed運算
4、關於LVS追蹤標記fwmark：
若是LVS放置於多防火牆的網絡中，而且每一個防火牆都用到了狀態追蹤的機制，那麼在迴應一個針對於LVS的鏈接請求時必須通過此請求鏈接進來時的防火牆，不然，這個響應的數據包將會被丟棄。