IPVS簡介

ipvs是工作在Linux內核態的4層負載均衡；和用戶態的負載均衡軟件(如nginx、haproxy)功能類似：作為客戶端訪問的統一入口并將訪問請求根據調度算法轉給后端真實的服務器。相比于用戶態負載均衡，ipvs為Linux內核子模塊性能更強，但ipvs僅工作在4層無法處理7層數據(比如SSL證書、修改HTTP請求頭)。

IPVS調度算法

IPVS是如何決策應該把請求調度到哪個后端RS(Real Server)上的呢？這是由負載均衡調度算法決定的。IPVS常用的調度算法有：

輪詢（Round Robin）：IPVS認為集群內每臺RS都是相同的，會輪流進行調度分發。從數據統計上看，RR模式是調度最均衡的。

加權輪詢（Weighted Round Robin）：IPVS會根據RS上配置的權重，將消息按權重比分發到不同的RS上。可以給性能更好的RS節點配置更高的權重，提升集群整體的性能。

最小連接數（Least Connections）：IPVS會根據集群內每臺RS的連接數統計情況，將消息調度到連接數最少的RS節點上。在長連接業務場景下，LC算法對于系統整體負載均衡的情況較好；但是在短連接業務場景下，由于連接會迅速釋放，可能會導致消息每次都調度到同一個RS節點，造成嚴重的負載不均衡。

加權最小連接數（Weighted Least Connections）：最小連接數算法的加權版~

地址哈希（Address Hash）：LB上會保存一張哈希表，通過哈希映射將客戶端和RS節點關聯起來。

IPVS轉發模式

根據調度算法選擇一個合適的后端RS節點，IPVS怎么將數據轉發給后端RS呢？
IPVS支持三種轉發模式：

DR模式（Direct Routing）

NAT模式（Network Address Translation)

IP隧道（IP tunneling）

三種轉發模式性能從高到低：DR > NAT > IP隧道

DR模式

DR模式下，客戶端的請求包到達負載均衡器的虛擬服務IP端口后，負載均衡器不會改寫請求包的IP和端口，但是會改寫請求包的MAC地址為后端RS的MAC地址，然后將數據包轉發；真實服務器處理請求后，響應包直接回給客戶端，不再經過負載均衡器。所以DR模式的轉發效率是最高的。

DR模式的特點：

數據包在LB轉發過程中，源/目的IP端口都不會變化。LB只是將數據包的MAC地址改寫為RS的MAC地址，然后轉發給相應的RS。所以LB必須和后端RS節點在同一個子網

每臺RS上都必須在環回網卡(lo)上綁定VIP。因為LB轉發時并不會改寫數據包的目的IP，所以RS收到的數據包的目的IP仍是VIP，為了保證RS能夠正確處理該數據包，而不是丟棄，必須在RS的環回網卡上綁定VIP。這樣RS會認為這個虛擬服務IP是自己的IP，自己是能夠處理這個數據包的，否則RS會直接丟棄該數據包。

RS上的業務進程必須監聽在環回網卡的VIP上，且端口必須和LB上的虛擬服務端口一致。因為LB不會改寫數據包的目的端口，所以RS服務的監聽端口必須和LB上虛擬服務端口一致，否則RS會直接拒絕該數據包。

RS處理完請求后，響應直接回給客戶端，不再經過LB。因為RS收到的請求數據包的源IP是客戶端的IP，所以理所當然RS的響應會直接回給客戶端，而不會再經過LB。這時候要求RS和客戶端之間的網絡是可達的。

NAT模式

NAT模式下請求包和響應包都需要經過LB處理。當客戶端的請求到達LB后，LB會對請求包做目的地址轉換（DNAT），將請求包的目的IP改寫為RS的IP。RS處理請求后將響應返回給LB，當LB收到RS的響應后，LB會對響應包做源地址轉換（SNAT），將響應包的源IP改寫為LB的VIP。

NAT模式的特點：

LB會修改數據包的地址。對于請求包，會進行DNAT；對于響應包，會進行SNAT。

LB會透傳客戶端IP到RS（DR模式也會透傳）。雖然LB在轉發過程中做了NAT轉換，但是因為只是做了部分地址轉發，所以RS收到的請求包里是能看到客戶端IP的。

需要將RS的默認網關地址配置為LB的浮動IP地址。因為RS收到的請求包源IP是客戶端的IP，為了保證響應包在返回時能走到LB上面，所以需要將RS的默認網關地址配置為LB的虛擬服務IP地址。當然，如果客戶端的IP是固定的，也可以在RS上添加明細路由指向LB的虛擬服務IP，不用改默認網關。

LB和RS須位于同一個子網，并且客戶端不能和LB/RS位于同一子網。因為需要將RS的默認網關配置為LB的虛擬服務IP地址，所以需要保證LB和RS位于同一子網。又因為需要保證RS的響應包能走回到LB上，則客戶端不能和RS位于同一子網。否則RS直接就能獲取到客戶端的MAC，響應包就直接回給客戶端了，也就走不到LB上面了。這時候由于沒有LB做SNAT，客戶端收到的響應包源IP是RS的IP，而客戶端的請求包目的IP是LB的虛擬服務IP，這時候客戶端無法識別響應包，會直接丟棄。

IP隧道模式

隧道模式下LB將原始請求報文封裝在另一個IP報文中，再將封裝好的IP報文轉發給后端RS；后端RS服務器收到報文后，先將報文解封獲得原報文中目標地址為VIP的報文，服務器發現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然后根據路由表將響應報文直接返回給客戶。

隧道模式的特點：

LB和RS節點不用處于同一子網；解除了NAT模式和DR模式的限制。

LB和RS節點必須都支持隧道技術，且RS節點也需要在TUN網卡上配置VIP地址；因為LB通過隧道發送報文，RS節點必須支持隧道才能解封裝，解封裝后拿到原始報文的目的地址為VIP，如果RS節點上沒有配置VIP，則會丟棄報文。

RS節點必須能訪問互聯網；因為RS節點是直接將響應報文返回給客戶端，所以必須能訪問外網。

命令演示

IPVS為內核子模塊，需要用ipvsadm命令添加虛擬服務規則；IPVS與ipvsadm的關系就和netfilter與iptables一樣。
ipvsadm命令參數展示

?

?

Commands:
  --add-service     -A         增加一個虛擬服務
  --edit-service     -E        修改一個虛擬服務
  --delete-service   -D         刪除一個虛擬服務
  --clear           -C       清理所有虛擬服務
  --restore         -R        從標準輸入獲取ipvsadm命令。一般結合下邊的-S使用。
  --save            -S       從標準輸出輸出虛擬服務器的規則。可以將虛擬服務器的規則保存，在以后通過-R直接讀入，以實現自動化配置。
  --add-server      -a        為虛擬服務添加一個real server（RS）
  --edit-server     -e        修改虛擬服務中的RS
  --delete-server   -d         刪除虛擬服務中的RS
  --list            -L|-l    列出虛擬服務表中的所有虛擬服務。可以指定地址。添加-c顯示連接表。
  --help            -h        顯示幫助信息


Options:
  --tcp-service  -t service-address   指定虛擬服務為tcp服務。service-address要是host[:port]的形式。
  --udp-service  -u service-address   指定虛擬服務為udp服務。service-address要是host[:port]的形式。
  --scheduler    -s scheduler      指定調度算法。調度算法可以指定以下10種：rr（輪詢），wrr（權重），lc（最后連接），wlc（權重），lblc（本地最后連接），lblcr（帶復制的本地最后連接），dh（目的地址哈希），sh（源地址哈希），sed（最小期望延遲），nq（永不排隊）。默認調度算法為wlc。
  --real-server  -r server-address    為虛擬服務指定數據可以轉發到的真實服務器的地址。可以添加端口號。如果沒有指定端口號，則等效于使用虛擬地址的端口號。
  --gatewaying   -g                  指定轉發模式為DR(direct routing) (default)
  --ipip         -i                指定轉發模式為ip隧道(tunneling)
  --masquerading -m                  指定轉發模式為NAT模式(NAT)
  --connection   -c                 列出當前的IPVS連接。

?

環境準備；VM1/VM2/VM3都是在client上的VMware虛擬機。VMware網絡模式為NAT。

確保LB節點上開啟contrack和forward功能

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
echo "net.ipv4.vs.conntrack=1" >> /etc/sysctl.conf
sysctl -p

在虛擬機VM1(LB)上安裝ipvsadm命令

yum install ipvsadm

在虛擬機VM1(LB)上為網卡添加一個VIP

[root@vm1 ~]# ip addr add 192.168.81.100/24 dev eth0
[root@vm1 ~]# ip a s eth0
2: eth0:  mtu 1500 qdisc mq state UP group default qlen 1000
link/ether fa:16:3e:68:5a:12 brd ffffff:ff
inet 192.168.81.128/24 brd 172.16.2.255 scope global noprefixroute dynamic eth0
   valid_lft 102241123sec preferred_lft 102241123sec
inet 192.168.81.100/24 scope global secondary eth0
   valid_lft forever preferred_lft forever
inet6 fe80:3eff5a12/64 scope link 
   valid_lft forever preferred_lft forever

在虛擬機VM1(LB)上添加ipvs虛擬配置，并指定調度算法為輪詢

ipvsadm -At 192.168.81.100:80 -s rr

在虛擬機VM1(LB)上添加RS節點

ipvsadm -at 192.168.81.100:80 -r 192.168.81.129:80 -m
ipvsadm -at 192.168.81.100:80 -r 192.168.81.130:80 -m

在虛擬機VM1(LB)上查看虛擬配置

[root@test ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.81.100:80 rr
  -> 192.168.81.129:80              Masq    1      0          0         
  -> 192.168.81.130:80              Masq    1      0          0

為了使client能訪問vip，確保client機器上有訪問vip的路由，192.168.81.1為VMware的虛擬網卡VMnet8的ip

由于本次環境的LB/RS都是通過VMware虛擬出來的，虛擬機和client互通，為了使RS節點將響應報文返回給LB，需要在兩個RS節點上添加路由，使響應報文經過LB從而把響應報文的源地址換回vip

#目的地址為什么不是客戶端ip？因為VMware用的nat模式，client的請求到達LB時，VMware會把數據包源ip改為VMnet8網卡的地址`192.168.81.1`，也就是會做SNAT
ip route add 192.168.81.1 via 192.168.81.128 dev eth0

訪問測試，LB將請求輪詢轉發給后端RS節點

審核編輯：黃飛

?