一、相關術語
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/selinuxClient: 172.16.1.100Director Server: eth0 - 192.168.1.100 eth1 - 172.16.1.101 (VIP)RealServer01: 192.168.1.101RealServer02: 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.confnet.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 -nIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 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 saveipvsadm: 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 requestsCompleted 200 requestsCompleted 300 requestsCompleted 400 requestsCompleted 500 requestsCompleted 600 requestsCompleted 700 requestsCompleted 800 requestsCompleted 900 requestsCompleted 1000 requestsFinished 1000 requestsServer Software: Apache/2.2.15Server Hostname: 172.16.1.101Server Port: 80Document 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: 0Total transferred: 280840 bytesHTML transferred: 14042 bytesRequests 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 maxConnect: 0 1 0.4 1 3Processing: 1 2 0.6 1 7Waiting: 0 1 0.6 1 4Total: 1 3 0.8 2 7Percentage 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，無法模擬其它動態調度算法的效果，暫時記錄到這裡。
閱讀更多 IT生涯 的文章
