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。
一、關於ipvsadm:
ipvsadm是運行於用戶空間、用來與ipvs交互的命令行工具，它的作用表現在：
1、定義在Director上進行dispatching的服務(service)，以及哪此服務器(server)用來提供此服務；
2、爲每臺同時提供某一種服務的服務器定義其權重（即概據服務器性能確定的其承擔負載的能力）；
注：權重用整數來表示，有時候也可以將其設置爲atomic_t；其有效表示值範圍爲24bit整數空間，即（2^24-1）；
因此，ipvsadm命令的主要作用表現在以下方面：
1、添加服務（通過設定其權重>0）；
2、關閉服務（通過設定其權重>0）；此應用場景中，已經連接的用戶將可以繼續使用此服務，直到其退出或超時；新的連接請求將被拒絕；
3、保存ipvs設置，通過使用“ipvsadm-sav > ipvsadm.sav”命令實現；
4、恢復ipvs設置，通過使用“ipvsadm-sav < ipvsadm.sav”命令實現；
5、顯示ip_vs的版本號，下面的命令顯示ipvs的hash表的大小爲4k；
# ipvsadm
IP Virtual Server version 1.2.1 (size=4096)
6、顯示ipvsadm的版本號
# ipvsadm --version
ipvsadm v1.24 2003/06/07 (compiled with popt and IPVS v1.2.0)
7、查看LVS上當前的所有連接
# ipvsadm -Lcn
或者
#cat /proc/net/ip_vs_conn
8、查看虛擬服務和RealServer上當前的連接數、數據包數和字節數的統計值，則可以使用下面的命令實現：
# ipvsadm -l --stats
9、查看包傳遞速率的近似精確值，可以使用下面的命令：
# ipvsadm -l --rate
二、ipvsadm使用中應注意的問題
默認情況下，ipvsadm在輸出主機信息時使用其主機名而非IP地址，因此，Director需要使用名稱解析服務。如果沒有設置名稱解析服務、服務不可用或設置錯誤，ipvsadm將會一直等到名稱解析超時後才返回。當然，ipvsadm需要解析的名稱僅限於RealServer，考慮到DNS提供名稱解析服務效率不高的情況，建議將所有RealServer的名稱解析通過/etc/hosts文件來實現；
三、調度算法
Director在接收到來自於Client的請求時，會基於"schedule"從RealServer中選擇一個響應給Client。ipvs支持以下調度算法：（1、2爲靜態調度算法，3、4、5、6、7、8爲動態調度算法）
1、輪詢（round robin, rr),加權輪詢(Weighted round robin, wrr)——
新的連接請求被輪流分配至各RealServer；算法的優點是其簡潔性，它無需記錄當前所有連接的狀態，所以它是一種無狀態調度。輪叫調度算法假設所有服務器處理性能均相同，不管服務器的當前連接數和響應速度。該算法相對簡單，不適用於服務器組中處理性能不一的情況，而且當請求服務時間變化比較大時，輪叫調度算法容易導致服務器間的負載不平衡。
2、目標地址散列調度（Destination Hashing，dh）
算 法也是針對目標IP地址的負載均衡，但它是一種靜態映射算法，通過一個散列（Hash）函數將一個目標IP地址映射到一臺服務器。目標地址散列調度算法先 根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。
3、源地址散列調度（Source Hashing，sh）
算 法正好與目標地址散列調度算法相反，它根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法 的相同。除了將請求的目標IP地址換成請求的源IP地址外，它的算法流程與目標地址散列調度算法的基本相似。在實際應用中，源地址散列調度和目標地址散列 調度可以結合使用在防火牆集羣中，它們可以保證整個系統的唯一出入口。
4、最少連接(least connected, lc)， 加權最少連接(weighted least connection, wlc)——
新的連接請求將被分配至當前連接數最少的RealServer；最小連接調度是一種動態調度算法，它通過服務器當前所活躍的連接數來估計服務器的負載情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中止或超時，其連接數減一。
lc：256*A+I=當前連接數 wlc：（256*A+I）/W=當前連接數 【A：活動連接數 I:非活動連接數 W：權重值】
5、基於局部性的最少鏈接調度（Locality-Based Least Connections Scheduling，lblc）——
針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣中客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和主存Cache命中率，從而整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於其一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務器。
6、帶複製的基於局部性最少鏈接調度（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地址對應的服務器組；按“最小連接”原則從該服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載；則按“最小連接”原則從整個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。
7、 最短的期望的延遲（Shortest Expected Delay Scheduling ,sed）
sed: (A+1)/w=當前連接數
8、最少隊列調度（Never Queue Scheduling ,nq）
無需隊列。如果有臺realserver的連接數＝0就直接分配過去，不需要在進行sed運算
四、關於LVS追蹤標記fwmark：
如果LVS放置於多防火牆的網絡中，並且每個防火牆都用到了狀態追蹤的機制，那麼在迴應一個針對於LVS的連接請求時必須經過此請求連接進來時的防火牆，否則，這個響應的數據包將會被丟棄。