Linux之虛擬服務器LVS搭建

時間 2019-11-20

原文原文鏈接

導讀	LVS是 Linux Virtual Server 的簡稱，也就是Linux虛擬服務器。這是一個由章文嵩博士發起的一個開源項目，它的官方網址是http://www.linuxvirtualserver.org，如今 LVS 已是 Linux 內核標準的一部分。使用 LVS 能夠達到的技術目標是：經過 LVS 達到的負載均衡技術和 Linux 操做系統實現一個高性能高可用的 Linux 服務器集羣，它具備良好的可靠性、可擴展性和可操做性。從而以低廉的成本實現最優的性能。LVS 是一個實現負載均衡集羣的開源軟件項目，LVS架構從邏輯上可分爲調度層、Server集羣層和共享存儲

1、相關術語html

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地址。

2、三種模式前端

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

原理：負載均衡器和RS都使用同一個IP對外服務｡但只有DR對ARP請求進行響應，全部RS對自己這個IP的ARP請求保持靜默。也就是說，網關會把對這個服務IP的請求所有定向給DR，而DR收到數據包後根據調度算法，找出對應的RS，把目的MAC地址改成RS的MAC（由於IP一致）並將請求分發給這臺RS。這時RS收到這個數據包,處理完成以後，因爲IP一致，能夠直接將數據返給客戶，則等於直接從客戶端收到這個數據包無異，處理後直接返回給客戶端。因爲負載均衡器要對二層包頭進行改換,因此負載均衡器和RS之間必須在一個廣播域，也能夠簡單的理解爲在同一臺交換機上。算法

優勢：負載均衡器只是分發請求，應答包經過單獨的路由方法返回給客戶端。apache

缺點：要求負載均衡器的網卡必須與物理網卡在一個物理段上。後端

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系統上。

3、相關調度算法

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地址對應的服務器組，按「最少鏈接」原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發到該服務器；若服務器超載，則按「最少鏈接」原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程度。

4、簡單實驗之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

一、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

二、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

5、擴展 - 利用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，沒法模擬其它動態調度算法的效果，暫時記錄到這裏。