LVS的環(huán)境怎么搭建

LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)，目的在于使用集群技術(shù)和Linux操作系統(tǒng)實(shí)現(xiàn)一個高性能、高可用的服務(wù)器。它具有良好的可靠性，可拓展性和可操作性。從而以低廉的成本實(shí)現(xiàn)最優(yōu)的性能。

一、相關(guān)術(shù)語

1. DS：Director Server。指的是前端負(fù)載均衡器節(jié)點(diǎn)。
2. RS：Real Server。后端真實(shí)的工作服務(wù)器。
3. VIP：向外部直接面向用戶請求，作為用戶請求的目標(biāo)的IP地址。
4. DIP：Director Server IP，主要用于和內(nèi)部主機(jī)通訊的IP地址。
5. RIP：Real Server IP，后端服務(wù)器的IP地址。
6. CIP：Client IP，訪問客戶端的IP地址。

二、三種模式

\1. 直接路由模式（DR）

原理：負(fù)載均衡器和RS都使用同一個IP對外服務(wù)?但只有DR對ARP請求進(jìn)行響應(yīng)，所有RS對本身這個IP的ARP請求保持靜默。也就是說，網(wǎng)關(guān)會把對這個服務(wù)IP的請求全部定向給DR，而DR收到數(shù)據(jù)包后根據(jù)調(diào)度算法，找出對應(yīng)的RS，把目的MAC地址改為RS的MAC（因?yàn)镮P一致）并將請求分發(fā)給這臺RS。這時RS收到這個數(shù)據(jù)包,處理完成之后，由于IP一致，可以直接將數(shù)據(jù)返給客戶，則等于直接從客戶端收到這個數(shù)據(jù)包無異，處理后直接返回給客戶端。由于負(fù)載均衡器要對二層包頭進(jìn)行改換,所以負(fù)載均衡器和RS之間必須在一個廣播域，也可以簡單的理解為在同一臺交換機(jī)上。

優(yōu)點(diǎn)：負(fù)載均衡器只是分發(fā)請求，應(yīng)答包通過單獨(dú)的路由方法返回給客戶端。

缺點(diǎn)：要求負(fù)載均衡器的網(wǎng)卡必須與物理網(wǎng)卡在一個物理段上。

\2. NAT模式（NAT）

原理：就是把客戶端發(fā)來的數(shù)據(jù)包的IP頭的目的地址，在負(fù)載均衡器上換成其中一臺RS的IP地址，并發(fā)至此RS來處理，RS處理完成后把數(shù)據(jù)交給經(jīng)過負(fù)載均衡器，負(fù)載均衡器再把數(shù)據(jù)包的原IP地址改為自己的IP，將目的地址改為客戶端IP地址即可。期間，無論是進(jìn)來的流量,還是出去的流量，都必須經(jīng)過負(fù)載均衡器。

優(yōu)點(diǎn)：集群中的物理服務(wù)器可以使用任何支持TCP/IP操作系統(tǒng)。

缺點(diǎn)：擴(kuò)展性差。當(dāng)服務(wù)器節(jié)點(diǎn)（普通PC服務(wù)器）增長過多時，負(fù)載均衡器將成為整個系統(tǒng)的瓶頸，因?yàn)樗械恼埱蟀蛻?yīng)答包的流向都經(jīng)過負(fù)載均衡器。當(dāng)服務(wù)器節(jié)點(diǎn)過多時，大量的數(shù)據(jù)包都交匯在負(fù)載均衡器處，導(dǎo)致負(fù)載均衡器變慢以至于整個鏈路變慢。

\3. IP隧道模式（TUN）

原理：隧道模式就是，把客戶端發(fā)來的數(shù)據(jù)包，封裝一個新的IP頭標(biāo)記(僅目的IP)發(fā)給RS，RS收到后，先把數(shù)據(jù)包的頭解開，還原數(shù)據(jù)包，處理后直接返回給客戶端，不需要再經(jīng)過負(fù)載均衡器。注意，由于RS需要對負(fù)載均衡器發(fā)過來的數(shù)據(jù)包進(jìn)行還原，所以說必須支持IPTUNNEL協(xié)議。因此，在RS的內(nèi)核中，必須編譯支持IPTUNNEL這個選項(xiàng)。

優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而RS將應(yīng)答包直接發(fā)給用戶，減少了負(fù)載均衡器的大量數(shù)據(jù)流動，負(fù)載均衡器不再是系統(tǒng)的瓶頸，就能處理很巨大的請求量，這種方式，一臺負(fù)載均衡器能夠?yàn)楹芏郣S進(jìn)行分發(fā)。而且跑在公網(wǎng)上就能進(jìn)行不同地域的分發(fā)。

缺點(diǎn)：隧道模式的RS節(jié)點(diǎn)需要合法IP，這種方式需要所有的服務(wù)器支持“IP Tunneling”(IP Encapsulation)協(xié)議，服務(wù)器可能只局限在部分Linux系統(tǒng)上。

三、相關(guān)調(diào)度算法

\1. LVS負(fù)載均衡的調(diào)度算法一（靜態(tài)）

輪循調(diào)度（rr, Round Robin） 調(diào)度器通過“輪循”調(diào)度算法將外部請求按順序輪流分配到集群中的真實(shí)機(jī)器上，它均等的對待每一臺服務(wù)器，而不管服務(wù)器實(shí)際的連接數(shù)和系統(tǒng)負(fù)載。

加權(quán)輪循（wrr, Weighted Round Robin） 調(diào)度器通過“加權(quán)輪循”調(diào)度算法根據(jù)真實(shí)服務(wù)器的不同處理能力來調(diào)度訪問請求。這樣可以保證處理能力強(qiáng)的服務(wù)器能處理更多的訪問流量。調(diào)度器可以自動問詢真實(shí)服務(wù)器的負(fù)載情況，并動態(tài)的調(diào)整其權(quán)值。

目標(biāo)地址散列（DH, Destination Hashing） “目標(biāo)地址散列”調(diào)度算法根據(jù)請求的目標(biāo)IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。

源地址散列（SH, Source Hashing） “源地址散列”調(diào)度算法根據(jù)請求的源IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找到對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。

\2. LVS負(fù)載均衡的調(diào)度算法二（動態(tài)）

最少鏈接（LC, Least Connections） 調(diào)度器通過“最少鏈接”調(diào)度算法動態(tài)的將網(wǎng)絡(luò)請求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上。如果集群系統(tǒng)的真實(shí)服務(wù)器具有相近的系統(tǒng)性能，采用“最少連接”調(diào)度算法可以較好的均衡負(fù)載。 OL(Over Load)=active * 256 + deactive

加權(quán)最少鏈接（WLC, Weighted Least Connections） 在集群系統(tǒng)中的服務(wù)器性能差異較大的情況下，調(diào)度器采用“加權(quán)最少連接”調(diào)度算法優(yōu)化負(fù)載均衡性能，具有較高權(quán)值的服務(wù)器將承受較大比例的活動連接負(fù)載。調(diào)度器可以自動問詢真實(shí)服務(wù)器的負(fù)載情況，并動態(tài)的調(diào)整其權(quán)值。 OL(Over Load)=(active * 256 + deactive) / weighted

最短的期望延遲（SED, Shortest Expected Delay Scheduling）

最少隊(duì)列調(diào)度（NQ, Never Queue Scheduling） 無需排隊(duì)。如果有臺Real Server的連接數(shù)等于0就直接分配過去，不需要再進(jìn)行SED運(yùn)算。

基于局部性的最少鏈接（LBLC, Locality-Based Least Connections） “基于局部性的最少連接”調(diào)度算法是針對目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)。該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP最近使用的服務(wù)器，若該服務(wù)器是可用的且沒有超載，將請求發(fā)送到該服務(wù)器；若服務(wù)器不存在，或者該服務(wù)器超載且有服務(wù)器處于一半的工作負(fù)載，則用“最少連接”的原則選出一個可用的服務(wù)器，將請求發(fā)送到該服務(wù)器。

帶復(fù)制的基于局部性最少鏈接（LBLCR, Locality-Based Least Connections with Repilcation） “帶復(fù)制的基于局部性最少連接”調(diào)度算法也是針對目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)。它與LBLC算法的不同之處是它要維護(hù)從一個目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個目標(biāo)IP地址到一臺服務(wù)器的映射。該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址對應(yīng)的服務(wù)器組，按“最少連接”原則從服務(wù)器組中選出一臺服務(wù)器，若服務(wù)器沒有超載，將請求發(fā)到該服務(wù)器；若服務(wù)器超載，則按“最少連接”原則從這個集群中選出一臺服務(wù)器，將該服務(wù)器加入到服務(wù)器組中，將請求發(fā)送到該服務(wù)器。同時，當(dāng)該服務(wù)器組有一段時間沒有被修改，將最忙的服務(wù)器從服務(wù)器組中刪除，以降低復(fù)制的程度。

四、簡單實(shí)驗(yàn)之LVS-NAT模式

實(shí)驗(yàn)環(huán)境：CentOS6.5，關(guān)閉iptables/selinux

Client: 172.16.1.100
Director Server:
  eth0 - 192.168.1.100
  eth2 - 172.16.1.101 (VIP)
RealServer01: 192.168.1.101
RealServer02: 192.168.1.102

1、RS配置：

  a. 兩臺RS的網(wǎng)卡配置中網(wǎng)關(guān)均配置為DS的eth0 IP: 192.168.1.100

  b. 因?yàn)闆]有做共享存儲，只在各自的主頁文件中加入不同信息以示區(qū)別：

    RealServer01 # echo "RealServer01" > /var/log/index.html    RealServer02 # echo "RealServer02" > /var/log/index.html

2、DS配置：

a) 開啟ipv4轉(zhuǎn)發(fā)

# vi /etc/sysctl.confnet.ipv4.ip_forward = 1
  b) 安裝啟動ipvsadm# yum install ipvsadm -y# service ipvsadm start

c) 增加規(guī)則

# 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 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 saveipvsadm: Saving IPVS table to /etc/sysconfig/ipvsadm:      [確定]

e) 在Client測試的結(jié)果 rr調(diào)度算法結(jié)果：

wrr調(diào)度算法結(jié)果：

# ipvsadm -E -t 172.16.1.101:80 -s wrr

五、擴(kuò)展 – 利用apache ab工具來模擬大量requests

ab命令基本參數(shù)：

-n 執(zhí)行的請求數(shù)量
-c 并發(fā)請求個數(shù)
其它參數(shù)：

-t 測試所進(jìn)行的最大秒數(shù)
-p 包含了需要POST的數(shù)據(jù)的文件
-T POST數(shù)據(jù)所使用的Content-type頭信息
-k 啟用HTTP KeepAlive功能，即在一個HTTP會話中執(zhí)行多個請求，默認(rèn)時，不啟用KeepAlive功能

測試案例：

# yum -y install httpd-tools # ab -c 10 -n 10000 

# 測試完成進(jìn)度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         # 并發(fā)個數(shù)Time taken for tests:   0.262 seconds     # 總請求時間Complete requests:      1000     # 總請求數(shù)Failed requests:        0         # 失敗的請求數(shù)Write errors:           0
Total transferred:      280840 bytes
HTML transferred:       14042 bytes
Requests per second:    3816.98 [#/sec] (mean)     # 平均每秒的請求數(shù)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內(nèi)完成 66%      3
 75%      3
 80%      3
 90%      4
 95%      4
 98%      4
 99%      5
100%      7 (longest request)

說明：由于缺乏實(shí)際requests，無法模擬其它動態(tài)調(diào)度算法的效果，暫時記錄到這里。