一、集群和分布式介紹

1.1、誕生的原因

? ? ? ??單臺設備?“又貴又弱又容易掛”，扛不住現代業務的?“海量訪問、海量數據、復雜計算”；集群 / 分布式讓多臺設備?“抱團干活”，分擔壓力（流量、存儲、計算），還能?“壞了一臺不影響全局”，正好解決互聯網時代?“業務又大又復雜，還得 24 小時不宕機”?的需求。就像以前一個人挑水，現在一群人用 “接力賽” 運水，又快又穩，還不怕有人累倒。

1.2、系統性能擴展方式

????????Scale UP：向上擴展，增強

????????Scale Out：向外擴展，增加設備，調度分配問題，Cluter

1.3、集群Cluter

Cluster: 集群是為了解決某個特定問題將墮胎計算機組合起來形成的單個系統

Cluster常見的三種類型：

LB：LoadBalancing（負載均衡）由多個主機組成，每個主機只承擔一部分訪問

HA：High Availiablity（高可用）SPOF（single Point Of failure）

????????MTBF:Mean Time Between Failure 平均無故障時間，正常時間

????????MTTR:Mean Time To Restoration（ repair）平均恢復前時間，故障時間

????????A=MTBF/（MTBF+MTTR） (0,1)：99%, 99.5%, 99.9%, 99.99%, 99.999%

????????SLA：Service level agreement（服務等級協議）是在一定開銷下為保障服務的性能和可用性，服 務提供商與用戶間定義的一種雙方認可的協定。通常這個開銷是驅動提供服務質量的主要因素。在 常規的領域中，總是設定所謂的三個9，四個9來進行表示，當沒有達到這種水平的時候，就會有一 些列的懲罰措施，而運維，最主要的目標就是達成這種服務水平。

????????停機時間又分為兩種，一種是計劃內停機時間，一種是計劃外停機時間，而運維則主要關注計劃外 停機時間

HPC：High-performance computing（高性能計算，國家戰略資源）

1.4、分布式

分布式存儲:Ceph，GlusterFs，FastDFS，MogileFs

分布式計算:hadoop，Spark

分布式常見應用

????????分布式應用-服務按照功能拆分，使用微服務

????????分布式靜態資源--靜態資源放在不同的存儲集群上

????????分布式數據和存儲--使用key-value緩存系統

????????分布式計算--對特殊業務使用分布式計算，比如Hadoop集群

1.5、集群和分布式

集群：同一個業務系統，部署在多臺服務器上，集群中，每一臺服務器實現的功能沒有差別，數據 和代碼都是一樣的

分布式：一個業務被拆成多個子業務，或者本身就是不同的業務，部署在多臺服務器上。分布式 中，每一臺服務器實現的功能是有差別的，數據和代碼也是不一樣的，分布式每臺服務器功能加起 來，才是完整的業務

分布式是以縮短單個任務的執行時間來提升效率的，而集群則是通過提高單位時間內執行的任務數 來提升效率

對于大型網站，訪問用戶很多，實現一個群集，在前面部署一個負載均衡服務器，后面幾臺服務器 完成同一業務。如果有用戶進行相應業務訪問時，負載均衡器根據后端哪臺服務器的負載情況，決 定由給哪一臺去完成響應，并且臺服務器垮了，其它的服務器可以頂上來。分布式的每一個節點， 都完成不同的業務，如果一個節點垮了，那這個業務可能就會失敗

二、lvs（Linux virtual server）

2.1、lvs簡介

LVS:Linux Virtual Server，負載調度器，內核集成，章文嵩，阿里的四層SLB(Server LoadBalance)是基 于LVS+keepalived實現

LVS 官網: http://www.linuxvirtualserver.org/

LVS 相關術語

????????VS: Virtual Server，負責調度

????????RS:RealServer，負責真正提供服務

2.2、lvs集群體系結構

工作原理：

VS根據請求報文的目標IP和目標協議及端口將其調度轉發至某RS，根據調度算法來挑選RS

2.3、lvs概念

VS：Virtual Server

RS：Real Server

CIP：Client IP

VIP: Virtual serve IP VS外網的IP

DIP: Director IP VS內網的IP

RIP: Real server IP

訪問流程：CIP VIP == DIP RIP

2.4、lvs集群的類型

lvs-nat： 修改請求報文的目標IP,多目標IP的DNAT

lvs-dr： 操縱封裝新的MAC地址

lvs-tun： 在原請求IP報文之外新加一個IP首部

lvs-fullnat： 修改請求報文的源和目標IP

2.4.1、nat模式

Ivs-nat:

本質是多目標IP的DNAT，通過將請求報文中的目標地址和目標端口修改為某挑出的RS的RIP和 PORT實現轉發

RIP和DIP應在同一個IP網絡，且應使用私網地址;RS的網關要指向DIP

請求報文和響應報文都必須經由Director轉發，Director易于成為系統瓶頸

支持端口映射，可修改請求報文的目標PORT

VS必須是Linux系統，RS可以是任意OS系統

2.4.2、nat模式數據邏輯

1、客戶端發送訪問請求，請求數據包中含有請求來源（cip），訪問目標地址（VIP）訪問目標端口 （9000port）

2、VS服務器接收到訪問請求做DNAT把請求數據包中的目的地由VIP換成RS的RIP和相應端口

3、RS1相應請求，發送響應數據包，包中的相應保溫為數據來源（RIP1）響應目標（CIP）相應端口 （9000port）

4、VS服務器接收到響應數據包，改變包中的數據來源（RIP1-->VIP）,響應目標端口（9000-->80）

5、VS服務器把修改過報文的響應數據包回傳給客戶端

6、lvs的NAT模式接收和返回客戶端數據包時都要經過lvs的調度機，所以lvs的調度機容易阻塞

客戶請求到達vip后進入PREROUTING,在沒有ipvs的時候因該進入本機INPUT,當IPVS存在后訪問請求在通 過PREROUTING后被ipvs結果并作nat轉發

因為ipvs的作用點是在PREROUTING和INPUT鏈之間，所以如果在prerouting中設定規則會干擾ipvs的工 作。所以在做lvs時要把iptables的火墻策略全清理掉。

2.4.3、DR模式

DR：Direct Routing，直接路由，LVS默認模式,應用最廣泛,通過為請求報文重新封裝一個MAC首部進行 轉發，源MAC是DIP所在的接口的MAC，目標MAC是某挑選出的RS的RIP所在接口的MAC地址；源 IP/PORT，以及目標IP/PORT均保持不變

2.4.4、DR模式數據邏輯

在DR模式中，RS接收到訪問請求后不需要回傳給VS調度器，直接把回傳數據發送給client，所以RS和vs 上都要有vip

2.4.5、DR模式數據傳輸過程

1、客戶端發送數據幀給vs調度主機幀中內容為客戶端IP+客戶端的MAC+VIP+VIP的MAC

2、VS調度主機接收到數據幀后把幀中的VIP的MAC該為RS1的MAC，此時幀中的數據為客戶端IP+客戶端 的MAC+VIP+RS1的MAC

3、RS1得到2中的數據包做出響應回傳數據包，數據包中的內容為VIP+RS1的MAC+客戶端IP+客戶端IP的 MAC

2.4.6、DR模式的特點

1、Director和各RS都配置有VIP

2、確保前端路由器將目標IP為VIP的請求報文發往Director

3、在前端網關做靜態綁定VIP和Director的MAC地址

在RS上使用arptables工具

arptables -A IN -d $VIP -j DROP 
arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP

在RS上修改內核參數以限制arp通告及應答級別

/proc/sys/net/ipv4/conf/all/arp_ignore 
/proc/sys/net/ipv4/conf/all/arp_announce

4、RS的RIP可以使用私網地址，也可以是公網地址；RIP與DIP在同一IP網絡；

5、RIP的網關不能指向DIP，以確保響應報文不會經由Director

6、RS和Director要在同一個物理網絡

7、請求報文要經由Director，但響應報文不經由Director，而由RS直接發往Client

8、不支持端口映射（端口不能修敗）

9、RS可使用大多數OS系統

2.4.7、TUN模式

轉發方式：不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而在原IP報文之外再封裝一個IP首部 （源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RS；RS直接響應給客戶端（源IP是VIP，目標IP 是CIP）

2.4.8、TUN模式數據傳輸過程

1、客戶端發送請求數據包，包內有源IP+vip+dport

2、到達vs調度器后對客戶端發送過來的數據包重新封裝添加IP報文頭，新添加的IP報文頭中包含 TUNSRCIP(DIP)+TUNDESTIP(RSIP1)并發送到RS1

3、RS收到VS調度器發送過來的數據包做出響應，生成的響應報文中包含SRCIP(VIP)+DSTIP（CIP） +port，響應數據包通過網絡直接回傳給client

2.4.9、TUN模式特點

1、DIP, VIP, RIP都應該是公網地址

2、RS的網關一般不能指向DIP

3、請求報文要經由Director，但響應不能經由Director

4、不支持端口映射

5、RS的OS須支持隧道功能

2.4.10、fullnet模式

fullnat：通過同時修改請求報文的源IP地址和目標IP地址進行轉發

CIP --> DIP

VIP --> RIP

1、VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會指向DIP

2、RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但Director還要將其發往Client

3、請求和響應報文都經由Director 4.支持端口映射

2.4.11、LVS工作模式總結

lvs-nat與lvs-fullnat：請求和響應報文都經由Director

lvs-nat：RIP的網關要指向DIP

lvs-fullnat：RIP和DIP未必在同一IP網絡，但要能通信

lvs-dr與lvs-tun：請求報文要經由Director，但響應報文由RS直接發往Client

lvs-dr：通過封裝新的MAC首部實現，通過MAC網絡轉發

lvs-tun：通過在原IP報文外封裝新IP頭實現轉發，支持遠距離通信

2.5、lvs的調度算法

2.5.1、lvs調度算法類型

ipvs scheduler：根據其調度時是否考慮各RS當前的負載狀態被分為兩種：靜態方法和動態方法

靜態方法：僅根據算法本身進行調度，不考慮RS的負載情況

動態方法：主要根據每RS當前的負載狀態及調度算法進行調度Overhead=value較小的RS將被調度

2.5.2、lvs靜態調度算法

1、RR：roundrobin 輪詢 RS分別被調度，當RS配置有差別時不推薦

2、WRR：Weighted RR，加權輪詢根據RS的配置進行加權調度，性能差的RS被調度的次數少

3、SH：Source Hashing，實現session sticky，源IP地址hash；將來自于同一個IP地址的請求始終發往 第一次挑中的RS，從而實現會話綁定

4、DH：Destination Hashing；目標地址哈希，第一次輪詢調度至RS，后續將發往同一個目標地址的請 求始終轉發至第一次挑中的RS，典型使用場景是正向代理緩存場景中的負載均衡，如：寬帶運營商

補充：LVS靜態調度算法中的WRR中的加權的意思是依舊是執行RR輪詢的規則，只不過有權重的在分配的時候根據權重大小來決定分配的事務的數量。

2.5.3、lvs動態調度算法

主要根據RS當前的負載狀態及調度算法進行調度Overhead=value較小的RS會被調度

1、LC：least connections（最少鏈接發） 適用于長連接應用Overhead（負載值）=activeconns（活動鏈接數） x 256+inactiveconns（非活 動鏈接數）

2、WLC：Weighted LC（權重最少鏈接） 默認調度方法Overhead=(activeconns x 256+inactiveconns)/weight

3、SED：Shortest Expection Delay, 初始連接高權重優先Overhead=(activeconns+1+inactiveconns) x 256/weight 但是，當node1的權重為1，node2的權重為10，經過運算前幾次的調度都會被node2承接

4、NQ：Never Queue，第一輪均勻分配，后續SED

5、LBLC：Locality-Based LC，動態的DH算法，使用場景：根據負載狀態實現正向代理

6、LBLCR：LBLC with Replication，帶復制功能的LBLC，解決LBLC負載不均衡問題，從負載重的復制 到負載輕的RS

3.5.4、在4.15版本內核以后新增調度算法

1.FO(Weighted Fai Over)調度算法：常用作灰度發布

在此FO算法中，遍歷虛擬服務所關聯的真實服務器鏈表，找到還未過載(未設置IP_VS_DEST_F OVERLOAD標志)的且權重最高的真實服務器，進行調度

當服務器承接大量鏈接，我們可以對此服務器進行過載標記（IP_VS_DEST_F OVERLOAD），那么vs調度 器就不會把鏈接調度到有過載標記的主機中。

2.OVF(Overflow-connection)調度算法

基于真實服務器的活動連接數量和權重值實現。將新連接調度到權重值最高的真實服務器，直到其活動 連接數量超過權重值，之后調度到下一個權重值最高的真實服務器,在此OVF算法中，遍歷虛擬服務相關 聯的真實服務器鏈表，找到權重值最高的可用真實服務器。一個可用的真實服務器需要同時滿足以下條件:

未過載(未設置IP_VS_DEST_F OVERLOAD標志)

真實服務器當前的活動連接數量小于其權重值

其權重值不為零

三、lvs軟件介紹

3.1、lvs軟件相關信息

程序包：ipvsadm

Unit File: ipvsadm.service

主程序：/usr/sbin/ipvsadm

規則保存工具：/usr/sbin/ipvsadm-save

規則重載工具：/usr/sbin/ipvsadm-restore

配置文件：/etc/sysconfig/ipvsadm-config

ipvs調度規則文件：/etc/sysconfig/ipvsadm

3.2、ipvsadm命令

核心功能:

集群服務管理:增、刪、改

集群服務的RS管理:增、刪、改

查看

命令參數

管理集群服務
ipvsadm -A|E -t（tcp）|u（udp）|f（防護墻標簽） \
service-address(集群地址) \
[-s scheduler(調度算法)] \
[-p [timeout]] \
[-M netmask] \
[--pepersistence_engine] \
[-b sched-flags]
ipvsadm -D -t|u|f service-address 刪除
ipvsadm –C 清空
ipvsadm –R 重載
ipvsadm -S [-n] 保存
管理集群中的real server
ipvsadm -a|e -t|u|f service-address -r server-address [-g | -i| -m](工作模式) [-w
weight](權重)
ipvsadm -d -t|u|f service-address -r server-address 刪除RS
ipvsadm -L|l [options] 查看rs
ipvsadm -Z [-t|u|f service-address] 清楚計數器

命令實際運用的示例：

#添加
[root@DR-server ~]# ipvsadm -a -t 172.25.254.100:80 -r 192.168.0.30 -m
[root@DR-server ~]# ipvsadm -a -t 172.25.254.100:80 -r 192.168.0.40 -m -w 2#更改
[root@DR-server ~]# ipvsadm -e -t 172.25.254.100:80 -r 192.168.0.30 -m -w 1
[root@DR-server ~]# ipvsadm -e -t 172.25.254.100:80 -r 192.168.0.30 -i -w 1#刪除
[root@DR-server ~]# ipvsadm -d -t 172.25.254.100:80 -r 192.168.0.30#查看
[root@DR-server ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 172.25.254.100:80 0 0 0 0 0
-> 192.168.0.30:80 0 0 0 0 0
-> 192.168.0.40:80 0 0 0 0 0#清空
[root@DR-server ~]# ipvsadm -C

四、LVS實戰案例

4.1、部署NAT模式集群

4.1.1、實驗環境?

192.168.212.0（nat），192.168.159.0（only host）

4.1.2、實驗步驟

1、在RS1、RS2和client中下載httpd服務用來進行模擬訪問web的測試

yum install httpd -y  # 下載apache模擬web頁面
systemctl start httpd  # 開啟httpd服務
systemctl enable --now httpd  #開啟開機自啟動
echo （自定義網頁內容） > /var/www/html/index.html  # 這里注意只需要對RS1和RS2進行網頁內容寫入
# 舉個例子    echo RS1 - 192.168.159.221 > /var/www/html/index.html
curl RS1/RS2的ip進行測試
# 舉個例子    curl 192.168.159.221

從這里可以看到RS2其實也是可以（也是應該）curl到RS1中web內容的，畢竟集群的目的是分擔訪問網頁的壓力，如果兩個web網頁完全獨立，那么集群的存在也沒有意義了。

所以，這里建議把所以的實驗機器的防火墻關閉并且關閉selinux或者設置selinux為permissive。

systemctl stop firewalld  # 關閉防火墻
systemctl disable --now firewalld  # 關閉開機自啟動
getenforce  # 查看你目前的selinux的狀態
setenforce 0  # 設置selinux的狀態為permissive

所以的機器的這兩個服務像這樣即可，當然關閉服務更好。

以上就是NAT模式集群的基本環境配置

2、配置client向后端的網絡通信

由于lvs中是有兩個不同網段的網卡的，所以這里需要開啟內核路由功能

sysctl -a | grep ip_forward  # 查看參數 net.ipv4.ip_forawrd=0
vim /etc/sysctl.conf  # 寫入net.ipv4.ip_forawrd=1
sysctl -p  # net.ipv4.ip_forawrd=1

此時client應該可以訪問到RS1和RS2，但是RS1和RS2是找不到client的，因為lvs、RS1和RS2中的網卡有僅主機模式的，此時是沒有網關信息的。

這時候我們就需要給RS1和RS2加上網關，地址為lvs中僅主機模式的ip地址。

此時RS1和RS2除了ping不到client，其他的都是可以正常通信的。

3、在lvs上添加調度策略

#下載調度策略的軟件ipvsadm
yum install ipvsadm -y  
# 不用開啟服務就可以直接使用：管理內核模塊IPVS，通過與IPVS交互從而實現效果ipvsadm -A -t 192.168.212.200:80 -s rr  # 添加一個虛擬機服務器并指定ip端口，以及類型為輪詢
# 向已經存在的虛擬機服務器添加后端真實的服務器，并指定ip端口以及網絡模式
ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.221:80 -m  
ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.222:80 -m
# 查看部署的調度策略
ipvsadm -Ln

4、測試

4.2、部署DR模式集群

4.2.1、實驗環境? ?

192.168.212.0（nat），192.168.159.0（only host）

4.2.2、實驗步驟

1、配置DR實驗的基礎環境

在DR模式的lvs集群實驗中我們使用nginx來搭建web網頁。

yum install nginx -y
systemctl start nginx  # 這里需要確保apache的服務是關閉的
systemctl stop httpd  # 開啟的才需要關閉，本來就是關閉的就不用管echo （自定義內容） > /usr/share/nginx/html/index.html
curl RS的ip  # 查看網頁部署的效果

2、配置全網通

此時client是可以正向進行通信的。

但是RS1和RS2是無法對client進行網絡通信的，因為沒有配置網關和內核路由轉換。

但是此時還是不夠，眼細的會發現這樣的配置跟nat模式集群一樣，怎么可能可以實現RS1訪問client呢？

確實不行，所以此時我們需要對route進行一個網絡偽裝。

所以，此時需要對RS1、RS2和lvs進行網關配置，指向route的僅主機網卡的網絡ip，就可以訪問到route。

網絡偽裝

# 在route上進行配置
systemctl start firewalld
firewall-cmd  --add-masquerade

此時，就發現已經全網通了。

3、添加vip并抑制arp

在lvs、RS1和RS2中添加vip，添加的vip是可以和lvs的物理網卡ip一致的，但是不建議，每個ip有每個ip的職責，使用同一個可能會出現網絡管理和功能拓展上的問題。

lvs和rs配置相同的vip的原因：

讓 RS 能接收并處理目標為 VIP 的數據包（來自 Director 的轉發）；

讓 RS 能以 VIP 為源 IP 向客戶端發送響應（符合 TCP/IP 協議的雙向一致性）；

配合 ARP 參數限制，避免多節點 VIP 的 IP 沖突，同時保證客戶端請求能正確路由到 Director 并轉發給 RS。

# 在lvs和rs中執行
# vip放到lo中，是為了避免vip在物理網絡中arp沖突，因為lo的IP地址僅本機可見，不會發送arp包。
ip addr add dev lo 192.168.159.123/32
# 查看
IP a

此時的client是單獨curl到RS的，但是無法通過vip進行訪問，因為有arp沖突。

抑制arp

在兩個rs中設置lo不對外響應

[root@RS1 ~l# cat /etc/sysctl.conf
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.lo.arp_ignore=1
net.ipv4.conf.lo.arp_announce=2
[root@RS2 system-connections]# sysctl -p
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2

此時的client就可以訪問到vip了，但是發現只有RS2，因為沒有配置ipvsadm的策略。

4、配置ipvsadm策略并驗證

這里注意，lvs調度器的虛擬服務器的ip地址需要指定成client可以訪問到的那個網段并且作為網絡轉換的ip地址。DR和nat的區別可以通過查看RS的類型來進行分辨。

[root@lvs ~]# ipvsadm -A -t 192.168.212.200:80 -s rr
[root@lvs ~]# ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.221:80 -g
[root@lvs ~]# ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.222:80 -g
[root@lvs ~]# ipvsadm -Ln

4.3、防火墻標簽解決輪詢錯誤

4.3.1、使用防火墻標簽的原因

????????以http和https為例，當我們在RS中同時開放80和443端口，那么默認控制是分開輪詢的，這樣我們就出 現了一個輪詢錯亂的問題 當我第一次訪問80被輪詢到RS1后下次訪問443仍然可能會被輪詢到RS1上

4.3.2、實驗環境

有一個lvs集群即可，模式隨意，這里我使用的nat模式。

4.3.3、實驗步驟

1、在RS上安裝mod_ssl

yum install mod_ssl -y
systemctl restart httpd  # 如果啟動不了，檢查一下自己有沒有httpd服務，沒有就下載
yum install httpd -y
systemc    restart httpd
netstat -lntp | grep httpd

當你看到你的httpd有80和443端口的時候就說明環境你已經完成搭建。

2、配置ipvsadm策略并查看效果

ipvsadm -A -t 192.168.212.200:80 -s rr
ipvsadm -A -t 192.168.212.200:443 -s rr
ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.221:80 -m
ipvsadm -a -t 192.168.212.200:80 -r 192.168.159.222:80 -m
ipvsadm -a -t 192.168.212.200:443 -r 192.168.159.221:443 -m
ipvsadm -a -t 192.168.212.200:443 -r 192.168.159.222:443 -m
ipvsadm -Ln

這里注意一下，后面跟著的后端RS的類型也很重要-g一般是DR模式的，看你使用的是哪一個lvs集群模式就需要指定相對應的RS類型，不然會RS的回包會出現錯誤。

?這里可以發現80和443端口使用的兩種不同的輪詢規則，這在訪問頁面的時候是不合適的。當你把商品添加到購物車后點擊支付跳轉到另一個頁面的時候購物車里面的內容就會沒有。

3、配置防火墻標簽解決問題

在lvs中設置端口標簽，人為指定80和443是一個整體

iptables -t mangle -A PREROUTING -d 192.168.212.200 -p tcp -m multiport --dports
80,443 -j MARK --set-mark [自定義]

4、測試一下

4.4、lvs持久鏈接

4.4.1、持久鏈接的原因

????????在我們客戶上網過程中有很多情況下需要和服務器進行交互，客戶需要提交響應信息給服務器，如果單 純的進行調度會導致客戶填寫的表單丟失，為了解決這個問題我們可以用sh算法，但是sh算法比較簡單 粗暴，可能會導致調度失衡

4.4.2、解決方法

在進行調度時，不管用什么算法，只要相同源過來的數據包我們就把他的訪問記錄在內存中，也就是把 這個源的主機調度到了那個RS上

如果在短期（默認360S）內同源再來訪問我仍然按照內存中記錄的調度信息，把這個源的訪問還調度到 同一臺RS上。

如果過了比較長的時間（默認最長時間360s）同源訪問再次來訪，那么就會被調度到其他的RS上

此時是未在lvs中配置記錄信息和等待時長，可以看到會進行輪詢。

ipvsadm -E -f 123 -s rr -p 10

此時可以看到在規則旁邊多了一個persistent，這就是等待時長。

測試：可以看到此時，同一個源訪問就是調度到之前訪問的RS