一、簡介 LVS是 Linux Virtual Server 的簡稱，也就是Linux虛擬伺服器。這是一個由章文嵩博士發起的一個開源項目，它的官方網址是http://www.linuxvirtualserver.org，現在 LVS 已經是 Linux 內核標準的一部分。使用 LVS 可以達到的技術 ...
一、簡介
LVS是 Linux Virtual Server 的簡稱，也就是Linux虛擬伺服器。這是一個由章文嵩博士發起的一個開源項目，它的官方網址是http://www.linuxvirtualserver.org，現在 LVS 已經是 Linux 內核標準的一部分。使用 LVS 可以達到的技術目標是：通過 LVS 達到的負載均衡技術和 Linux 操作系統實現一個高性能高可用的 Linux 伺服器集群，它具有良好的可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的性能。LVS 是一個實現負載均衡集群的開源軟體項目，LVS架構從邏輯上可分為調度層、Server集群層和共用存儲。
二、相關術語
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地址。
三、三種模式
1. 直接路由模式（DR）
原理：負載均衡器和RS都使用同一個IP對外服務｡但只有DR對ARP請求進行響應，所有RS對本身這個IP的ARP請求保持靜默。也就是說，網關會把對這個服務IP的請求全部定向給DR，而DR收到數據包後根據調度演算法，找出對應的RS，把目的MAC地址改為RS的MAC（因為IP一致）並將請求分發給這台RS。這時RS收到這個數據包,處理完成之後，由於IP一致，可以直接將數據返給客戶，則等於直接從客戶端收到這個數據包無異，處理後直接返回給客戶端。由於負載均衡器要對二層包頭進行改換,所以負載均衡器和RS之間必須在一個廣播域，也可以簡單的理解為在同一臺交換機上。
優點：負載均衡器只是分發請求，應答包通過單獨的路由方法返回給客戶端。
缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。
2. NAT模式（NAT）
原理：就是把客戶端發來的數據包的IP頭的目的地址，在負載均衡器上換成其中一臺RS的IP地址，併發至此RS來處理，RS處理完成後把數據交給經過負載均衡器，負載均衡器再把數據包的原IP地址改為自己的IP，將目的地址改為客戶端IP地址即可。期間，無論是進來的流量,還是出去的流量，都必須經過負載均衡器。
優點：集群中的物理伺服器可以使用任何支持TCP/IP操作系統。
缺點：擴展性差。當伺服器節點（普通PC伺服器）增長過多時，負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器。當伺服器節點過多時，大量的數據包都交匯在負載均衡器處，導致負載均衡器變慢以至於整個鏈路變慢。
3. IP隧道模式（TUN）
原理：隧道模式就是，把客戶端發來的數據包，封裝一個新的IP頭標記(僅目的IP)發給RS，RS收到後，先把數據包的頭解開，還原數據包，處理後直接返回給客戶端，不需要再經過負載均衡器。註意，由於RS需要對負載均衡器發過來的數據包進行還原，所以說必須支持IPTUNNEL協議。因此，在RS的內核中，必須編譯支持IPTUNNEL這個選項。
優點：負載均衡器只負責將請求包分發給後端節點伺服器，而RS將應答包直接發給用戶，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。
缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的伺服器支持“IP Tunneling”(IP Encapsulation)協議，伺服器可能只局限在部分Linux系統上。
四、相關調度演算法
1. LVS負載均衡的調度演算法一（靜態）
輪循調度（rr, Round Robin）
調度器通過“輪循”調度演算法將外部請求按順序輪流分配到集群中的真實機器上，它均等的對待每一臺伺服器，而不管伺服器實際的連接數和系統負載。
加權輪循（wrr, Weighted Round Robin）
調度器通過“加權輪循”調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器能處理更多的訪問流量。調度器可以自動問詢真實伺服器的負載情況，並動態的調整其權值。
目標地址散列（DH, Destination Hashing）
“目標地址散列”調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
源地址散列（SH, Source Hashing）
“源地址散列”調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找到對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。
2. LVS負載均衡的調度演算法二（動態）
最少鏈接（LC, Least Connections）
調度器通過“最少鏈接”調度演算法動態的將網路請求調度到已建立的鏈接數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用“最少連接”調度演算法可以較好的均衡負載。
OL(Over Load)=active * 256 + deactive
加權最少鏈接（WLC, Weighted Least Connections）
在集群系統中的伺服器性能差異較大的情況下，調度器採用“加權最少連接”調度演算法優化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自動問詢真實伺服器的負載情況，並動態的調整其權值。
OL(Over Load)=(active * 256 + deactive) / weighted
最短的期望延遲（SED, Shortest Expected Delay Scheduling）
最少隊列調度（NQ, Never Queue Scheduling）
無需排隊。如果有台Real Server的連接數等於0就直接分配過去，不需要再進行SED運算。
基於局部性的最少鏈接（LBLC, Locality-Based Least Connections）
“基於局部性的最少連接”調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。該演算法根據請求的目標IP地址找出該目標IP最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用“最少連接”的原則選出一個可用的伺服器，將請求發送到該伺服器。
帶複製的基於局部性最少鏈接（LBLCR, Locality-Based Least Connections with Repilcation）
“帶複製的基於局部性最少連接”調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一臺伺服器的映射。該演算法根據請求的目標IP地址找出該目標IP地址對應的伺服器組，按“最少連接”原則從伺服器組中選出一臺伺服器，若伺服器沒有超載，將請求發到該伺服器；若伺服器超載，則按“最少連接”原則從這個集群中選出一臺伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。
五、簡單實驗之LVS-NAT模式
實驗環境：CentOS6.5，關閉iptables/selinux
Client: 172.16.1.100
Director Server:
eth0 - 192.168.1.100
eth1 - 172.16.1.101 (VIP)
RealServer01: 192.168.1.101
RealServer02: 192.168.1.102
1、RS配置：
a. 兩台RS的網卡配置中網關均配置為DS的eth0 IP: 192.168.1.100
b. 因為沒有做共用存儲，只在各自的主頁文件中加入不同信息以示區別：
RealServer01 # echo "RealServer01" > /var/log/index.html
RealServer02 # echo "RealServer02" > /var/log/index.html
2、DS配置：
a) 開啟ipv4轉發
# vi /etc/sysctl.conf net.ipv4.ip_forward = 1
b) 安裝啟動ipvsadm
# yum install ipvsadm -y # service ipvsadm start
c) 增加規則
# ipvsadm -A -t 172.16.1.101:80 -s rr # ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.101 -m -w 1 # ipvsadm -a -t 172.16.1.101:80 -r 192.168.1.102 -m -w 2
d) 查看並保存
[root@director ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.16.1.101:80 rr -> 192.168.1.101:80 Masq 1 0 0 -> 192.168.1.102:80 Masq 2 0 0 [root@director ~]# service ipvsadm save ipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm: [確定]
e) 在Client測試的結果
rr調度演算法結果：
wrr調度演算法結果：
# ipvsadm -E -t 172.16.1.101:80 -s wrr
六、擴展 - 利用apache ab工具來模擬大量requests
ab命令基本參數：
-n 執行的請求數量
-c 併發請求個數
其它參數：
-t 測試所進行的最大秒數 -p 包含了需要POST的數據的文件 -T POST數據所使用的Content-type頭信息 -k 啟用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求，預設時，不啟用KeepAlive功能
測試案例：
# yum -y install httpd-tools # ab -c 10 -n 10000 http://172.16.1.101/index.html
# 測試完成進度 Benchmarking 172.16.1.101 (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Completed 400 requests Completed 500 requests Completed 600 requests Completed 700 requests Completed 800 requests Completed 900 requests Completed 1000 requests Finished 1000 requests Server Software: Apache/2.2.15 Server Hostname: 172.16.1.101 Server Port: 80 Document Path: /index.html # 請求的資源 Document Length: 14 bytes #返回的長度 Concurrency Level: 10 # 併發個數 Time taken for tests: 0.262 seconds # 總請求時間 Complete requests: 1000 # 總請求數 Failed requests: 0 # 失敗的請求數 Write errors: 0 Total transferred: 280840 bytes HTML transferred: 14042 bytes Requests per second: 3816.98 [#/sec] (mean) # 平均每秒的請求數 Time per request: 2.620 [ms] (mean) # 平均每個請求消耗的時間 Time per request: 0.262 [ms] (mean, across all concurrent requests) Transfer rate: 1046.84 [Kbytes/sec] received # 傳輸速率 Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 0.4 1 3 Processing: 1 2 0.6 1 7 Waiting: 0 1 0.6 1 4 Total: 1 3 0.8 2 7 Percentage of the requests served within a certain time (ms) 50% 2 # 50%的requests都在2ms內完成 66% 3 75% 3 80% 3 90% 4 95% 4 98% 4 99% 5 100% 7 (longest request)
說明：由於缺乏實際requests，無法模擬其它動態調度演算法的效果，暫時記錄到這裡。
