1 構建高可用集群
1.1 什么是高可用集群
高可用集群(High Availability Cluster，簡稱HA Cluster)，是指以減少服務中斷時間為目的得服務器集群技術，它通過保護用戶得業務程式對外部間斷提供的服務，把因為軟體，硬體，認為造成的故障對 業務得影響降低到最小程度，總而言之就是保證公司業務7*24小時不宕機，
1.2 高可用衡量標準
衡量集群的可用性(HA)高低，可以從MTTF(平均無故障時間)和MTTR(平均故障維修時間)進行考 量，公式為:HA=MTTF/(MTTF+MTTR)*100%，具體衡量標準可以參考下表
1.3 高可用保障
對集群中的服務器進行負載均衡、健康監測，并在服務器出現故障時能進行故障轉移，自動切換到正常服務器是高可用保障的必要手段，
1.3.1 負載均衡
常見的負載均衡手段如下:
硬體負載均衡，如F5 軟體負載均衡，如nginx、haproxy、lvs 幾種軟體負載均衡技術比較
1.3.2 健康監測和自動切換
常見的健康監測和自動切換軟體有keepAlived和heartBeat，其二者對比如下:
Keepalived使用更簡單:從安裝、配置、使用、維護等角度上對比，Keepalived都比Heartbeat要簡單;
Heartbeat功能更強大:Heartbeat雖然復雜，但功能更強大，配套工具更全，適合做大型集群管理，而Keepalived主要用于集群倒換，基本沒有管理功能，
1.4 高可用拓撲圖
2 軟體負載均衡技術LVS
2.1 LVS簡介
2.1.1 什么是lvs
LVS是Linux Virtual Server的簡寫，在1998年5月由章文嵩博士成立， 作業在OSI模型的四層，基于IP進行負載均衡， 在linux2.2內核時，IPVS就已經以內核補丁的形式出現， 從2.4版本以后，IPVS已經成為linux官方標準內核的一部分，
2.1.2 LVS官方資料鏈接
- lvs專案介紹 [http://www.linuxvirtualserver.org/zh/lvs1.html]
- lvs集群的體系結構 [http://www.linuxvirtualserver.org/zh/lvs2.html]
- lvs集群中的IP負載均衡技術 [http://www.linuxvirtualserver.org/zh/lvs3.html]
- lvs集群的負載調度 [http://www.linuxvirtualserver.org/zh/lvs4.html]
- lvs中文站點 [http://zh.linuxvirtualserver.org]
2.2 LVS場景術語
LVS服務器(DS)
集群中節點服務器(RS)
虛擬IP地址(VIP)，用于向客戶端提供服務的IP地址(配置于負載均衡器上)
真實服務器的IP地址(RIP)， 集群中節點服務器的IP地址
負載均衡器IP地址(DIP)，負載均衡器的IP地址，物理網卡上的IP
客戶端主機IP地址(CIP)，終端請求用戶的主機IP地址
2.3 作業原理
LVS負載均衡調度技術是在linux內核中實作的，使用配置LVS時，不是直接配置內核中的IPVS，而是通 過IPVS的管理工具IPVSADM來管理配置，LVS集群負載均衡器接受所有入站客戶端的請求，并根據演算法 來決定由哪個集群的節點來處理請求，
2.4 LVS的四種作業模式
2.4.1 NAT模式
NAT(Network Address Translation)模式是基于NAT技術實作的，在此模式中，LVS服務器既要處理請求的接入，又要處理請求的回應，因此存在較大的性能瓶頸，
- 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP(客戶端IP),后面統稱為CIP)，目標地址為VIP(負載均衡器前端地址，后面統稱為VIP)，
- 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的目標地址改為了后端服務器的RIP地址并將報文根據演算法發送出去，
- 報文送到Real Server后，由于報文的目標地址是自己，所以會回應該請求，并將回應報文返還給LVS，
- 然后lvs將此報文的源地址修改為本機并發送給客戶端，
注意：在NAT模式中，Real Server的網關必須指向LVS，否則報文無法送達客戶端，
NAT模式缺點：
擴展性有限，當服務器節點（普通PC服務器）增長過多時,負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器，當服務器節點過多時，大量的資料包都交匯在負載均衡器那，速度就會變慢！
2.4.2 DR模式
DR(Direct Routing)模式是LVS的默認作業模式，也叫直接路由模式，只處理請求的接入，不處理請求的回應，因此性能高，瓶頸小，
- 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP，
- 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為了RIP的MAC地址，并將此包發送給RS，
- RS發現請求報文中的目的MAC是自己，就會將次報文接收下來，處理完請求報文后，將回應報文通過lo介面送給eth0網卡直接發送給客戶端，
注意：需要設定lo介面的VIP不能回應本地網路內的arp請求，
優點：
負載均衡器也只是分發請求，應答包通過單獨的路由方法回傳給客戶端，因此DR模式的效率很高，但是配置稍微復雜一點，因此對于訪問量不是特別大的公司可以用Haproxy/Nginx取代，日1000-2000W PV或者并發請求1萬一下都可以考慮用Haproxy/Nginx，
缺點：所有節點和調度器只能在一個局域網里面，
2.4.3 TUN模式（隧道模式）
- 客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP，
- 負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP，目標地址改為RIP,并將此包發送給RS，
- RS收到請求報文后，會首先拆開第一層封裝,然后發現里面還有一層IP首部的目標地址是自己lo介面上的VIP，所以會處理次請求報文，并將回應報文通過lo介面送給eth0網卡直接發送給客戶端，
注意：需要設定lo介面的VIP不能在共網上出現，
總結：
- TUN模式必須在所有的 realserver 機器上面系結 VIP 的 IP 地址
- TUN模式的 vip ------>realserver 的包通信通過 TUNNEL 模式，不管是內網和外網都能通信，所以不需要 lvs vip 跟 realserver 在同一個網段內
- TUN模式 realserver 會把 packet 直接發給 client 不會給 lvs 了
- TUN模式走的隧道模式，所以運維起來比較難，所以一般不用，
優點：
負載均衡器只負責將請求包分發給后端節點服務器，而RS將應答包直接發給用戶，所以，減少了負載均衡器的大量資料流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發，而且跑在公網上就能進行不同地域的分發，
缺點：
隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持”IP Tunneling”(IP Encapsulation)協議，服務器可能只局限在部分Linux系統上，
2.4.4 FULLNAT模式
淘寶定制化的技術，linux內核不支持，
無論是 DR 還是 NAT 模式，不可避免的都有一個問題：LVS 和 RS 必須在同一個 VLAN 下，否則 LVS 無法作為 RS 的網關，
這引發的兩個問題是：
- 同一個 VLAN 的限制導致運維不方便，跨 VLAN 的 RS 無法接入，
- LVS 的水平擴展受到制約，當RS水平擴容時，總有一天其上的單點 LVS 會成為瓶頸，
Full-NAT 由此而生，解決的是LVS和RS跨VLAN的問題，而跨VLAN問題解決后，LVS和RS不再存在VLAN上的從屬關系，可以做到多個LVS對應多個RS，解決水平擴容的問題，
在包從 LVS 轉到 RS 的程序中，源地址從客戶端 IP 被替換成了 LVS 的內網 IP，內網 IP 之間可以通過多個交換機跨 VLAN 通信，當 RS 處理完接受到的包，回傳時，會將這個包回傳給 LVS 的內網 IP，這一步也不受限于 VLAN，LVS 收到包后，在 NAT 模式修改源地址的基礎上，再把 RS 發來的包中的目標地址從 LVS 內網 IP 改為客戶端的 IP，
Full-NAT 主要的思想是把網關和其下機器的通信，改為了普通的網路通信，從而解決了跨 VLAN 的問題，采用這種方式，LVS 和 RS 的部署在 VLAN 上將不再有任何限制，大大提高了運維部署的便利性，
2.5 LVS 調度演算法
2.5.1 靜態調度演算法
- RR：Round Robin 輪詢調度
- WRR：Weighted RR 加權輪詢調度
- SH：Source Hashing源地址哈希調度
- DH：Destination Hashing目標地址哈希調度
2.5.2 動態調度演算法
- LC：Least Connections最小連接數調度
- WLC：Weighted LC加權最小連接數調度 (默認)
- SED：Shortest Expection Delay初始連接高權重優先
- NQ：Nerver Queue 第一輪平均分配，后續SED
- LBLC：Locality-Based LC 動態的DH演算法
- LBLCR：LBLC with Replication 帶復制功能的LBLC
- FO: Weighted Fail Over，linux內核4.15后新增的調度演算法
- OVF：Overflow-connection，linux內核4.15后新增的調度演算法
2.5.3 LVS 基本命令
對于lvs的操作，主要是通過ipvsadm軟體實作，Linux內核已集成lvs，常用的lvs操作命令如下：
- 集群服務管理：
# 此命令用來添加一個lvs策略，IP指VIP，調度演算法是12種調度演算法 的一種
ipvsadm -A -t IP -s 調度演算法
# 此命令用來清除一個lvs策略
ipvsadm -C
# 此命令用來保存一個lvs策略
ipvsadm -S
# 此命令用來加載一個lvs策略
ipvsadm -R
# 此命令用來查看策略
ipvsadm -L
- 集群RS管理
# 添加一臺RS，
# IP1指VIP
# IP2指RIP
# -m|g|i中m是NAT
# g是 DR，
ipvsadm -a -t IP1 -r IP2 - m|g|i
# 此命令用來洗掉一臺RS，IP1指VIP，IP2指RIP
ipvsadm -d -t IP1 -r IP2
2.6 LVS 實戰（DR模式）
ARP(Address Resolution Protocol)地址決議協議，是根據IP地址獲取物理地址 (MAC)的一個 TCP/IP協議，主機發送資訊時將包含目標IP地址的ARP請求廣播到局域網路上的 所有主機，并接收返 回訊息，以此確定目標的物理地址;收到回傳訊息后將該IP地址和物理地址 存入本機ARP快取中并 保留一定時間，下次請求時直接查詢ARP快取以節約資源，
2.6.1 DR模式服務器拓撲圖
服務器準備：
- LVS（Q110）：CentOS7 DIP：192.168.88.110 VIP：192.168.88.88
- RS1（Q111）： CentOS7 RIP：192.168.88.111 VIP：192.168.88.88
- RS2（Q112）： CentOS7 RIP：192.168.88.112 VIP：192.168.88.88
2.6.2 DR模式實作
通過拓撲圖可以發現，需要讓LVS和RS在同一個網段，并且在兩個RS服務器上也需要系結VIP，操作步驟如下：
- 在兩臺RS服務器Q111和Q112上進行如下ARP抑制操作，并配置VIP到lo網卡上，如下:
# arp抑制，修改內核
echo 1 > /proc/sys/net/ipv4/conf/ens33/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/ens33/arp_announce
# 安裝ifconfig,centos7沒有ifconfig
yum install net-tools.x86_64 -y
# 配置VIP到lo網卡 這里的子網掩碼需要4個255，
ifconfig lo:8 192.168.88.88 netmask 255.255.255.255
# 查看IP
ifconfig
查看網關是否生效
[root@q111 ~]# route -n
- 在兩臺RS服務器Q111和Q112上都安裝httpd服務器（測驗使用）：
# 下載安裝httpd服務，命令如下
yum install -y httpd
# 設定首頁內容(RS2把內容改為this is RS2)
echo this is RS01 > /var/www/html/index.html
# 啟動httpd
systemctl start httpd
通過單獨訪問192.168.88.111和192.168.88.112可以正常訪問，
- 在LVS服務器Q110上安裝ipvsadm，系結VIP192.168.88.88：
# 1）安裝ipvsadm
yum install -y ipvsadm
# 2）在lvs的ens33網卡上系結VIP192.168.88.100
ifconfig ens33:8 192.168.88.88/24
# 查看ip
ifconfig
4. LVS服務器上設定DR策略和負載規則
# 設定規則
ipvsadm -A -t 192.168.88.88:80 -s rr
# 添加RS
ipvsadm -a -t 192.168.88.88:80 -r 192.168.88.111 -g -w 1
ipvsadm -a -t 192.168.88.88:80 -r 192.168.88.112 -g -w 1
#查看策略
ipvsadm -Ln
- 驗證
客戶端測驗：192.168.88.88，可以使用瀏覽器或者curl命令
LVS上查看調度情況
[root@q110 ~]# ipvsadm -Lnc
FIN_WAIT：正常情況
2.6.3 小結
以上以DR模型搭建了一套簡單的負載均衡環境，但是存在幾個問題：
- 如果LVS服務器掛了會出現什么問題?
- 如何進行故障轉移、自動切換?
- 如果后端某臺RS服務器掛了會出現什么問題?
- 如何獲知RS服務器狀態?
解決方案：通過使用LVS+KeepAlived實作高可用架構，
3 KeepAlived
3.1 keepAlived簡介
Keepalived的作用是檢測服務器狀態，如果有一臺web服務器宕機，或作業出現故障，Keepalived將檢測到，并將有故障的服務器從系統中剔除，同時使用其他服務器代替該服務器的作業，當服務器作業正常后Keepalived自動將服務器加入到服務器群中，
3.2 keepAlived特點
3.2.1 健康檢測
tcp_check：
作業在第4層，keepalived向后端服務器發起一個tcp連接請求，如果后端服務器 沒有回應或超時，那么這個后端將從服務器池中移除，
http_get：
作業在第5層，向指定的URL執行http請求，將得到的結果用md5加密并與指定的 md5值比較看是否匹配，不匹配則從服務器池中移除;此外還可以指定http回傳 碼來判斷檢測是否成功，HTTP_GET可以指定多個URL用于檢測，這個一臺服務器有多個虛擬主機的情況下比較好用，
misc_check：
用腳本來檢測，腳本如果帶有引數，需將腳本和引數放入雙引號內，
ssl_get：
和http_get相似，不同的只是用SSL連接，
smtp_check：
主要用于郵件系統SMTP協議的檢測
3.2.2 故障遷移
VRRP協議
在現實的網路環境中，主機之間的通信都是通過配置靜態路由或者(默認網關)來完成的，而主機之間的 路由器一旦發生故障，通信就會失效，因此這種通信模式當中，路由器就成了一個單點瓶頸，為了解決 這個問題，就引入了VRRP協議，
VRRP協議是一種容錯的主備模式的協議，保證當主機的下一跳路由出現故障時，由另一臺路由器來代 替出現故障的路由器進行作業，通過VRRP可以在網路發生故障時透明的進行設備切換而不影響主機之 間的資料通信，
故障遷移原理
在 Keepalived 服務正常作業時，主 Master 節點會不斷地向備節點發送(多播的方式)心跳訊息，用以告訴備 Backup 節點自己還活著，當主 Master 節點發生故障時，就無法發送心跳訊息，備節點也就 因此無法繼續檢測到來自主 Master 節點的心跳了，于是呼叫自身的接管程式，接管主 Master 節點的 IP 資源及服務，而當主 Master 節點恢復時，備 Backup 節點又會釋放主節點故障時自身接管的 IP 資源 及服務，恢復到原來的備用角色，
3.3 keepAlived原理
Keepalived作業在TCP/IP參考模型的三層、四層、五層，其原理如下：
網路層
Keepalived通過ICMP協議向服務器集群中的每一個節點發送一個ICMP資料包(有點類似與 Ping的功能)，如果某個節點沒有回傳回應資料包，那么認為該節點發生了故障， Keepalived將報告這個節點失效，并從服務器集群中剔除故障節點，
傳輸層
Keepalived在傳輸層里利用了TCP協議的埠連接和掃描技術來判斷集群節點的埠是否 正常， 比如對于常見的WEB服務器80埠，或者SSH服務22埠，Keepalived一旦在傳輸 層探測到這些埠號沒有資料回應和資料回傳，就認為這些埠發生例外，然后強制將這些 埠所對應的節點從服務器集群中剔除掉，
應用層
Keepalived的運行方式更加全面化和復雜化，用戶可以通過自定義Keepalived作業方式， 例如:可以通過撰寫程式或者腳本來運行Keepalived，而Keepalived將根據用戶的設定參 數檢測各種程式或者服務是否正常，如果Keepalived的檢測結果和用戶設定的不一致時， Keepalived將把對應的服務器從服務器集群中剔除，
3.4 分布式選舉策略
3.4.1 僅設定priority
在一個一主多備的Keepalived集群中，priority值最大的將成為集群中的MASTER節點，而其他都是 BACKUP節點，在MASTER節點發生故障后，BACKUP節點之間將進行“民主選舉”，通過對節點優先級值 priority和weight的計算，選出新的MASTER節點接管集群服務，
3.4.2 設定priority和weight
weight值為正數時
在vrrp_script中指定的腳本如果檢測成功，那么MASTER節點的權值將是weight值與priority值之和;如 果腳本檢測失效，那么MASTER節點的權值保持為priority值
MASTER 節點vrrp_script腳本檢測失敗時，如果MASTER節點priority值小于BACKUP節點weight值與 priority值之和，將發生主、備切換，
MASTER節點vrrp_script腳本檢測成功時，如果MASTER節點weight值與priority值之和大于BACKUP節 點weight值與priority值之和，主節點依然為主節點，不發生切換，
weight值為負數時
在vrrp_script中指定的腳本如果檢測成功，那么MASTER節點的權值仍為priority值，當腳本檢測失敗時，MASTER節點的權值將是priority值與weight值之差 MASTER節點vrrp_script腳本檢測失敗時，如果MASTER節點priority值與weight值之差小于BACKUP節點priority值，將發生主、備切換， MASTER節點vrrp_scrip腳本檢測成功時，如果MASTER節點priority值大于BACKUP節點priority值時，主節點依然為主節點，不發生切換，
對于weight值的設定，有一個簡單的標準，即weight值的絕對值要大于MASTER和BACKUP節點priority 值之差，由此可見，對于weight值的設定要非常謹慎，如果設定不好，主節點發生故障時將導致集群角 色選舉失敗，使集群陷于癱瘓狀態，
4 LVS+keepAlived
4.1 網路拓撲圖
為了測驗lvs的高可用，這里需要增加一臺lvs服務器，需在此服務器上安裝ipvsadm，RS1 和 RS2保持不變，
4.2 keepAlived安裝和配置
4.2.1 安裝keepAlived
在兩臺lvs服務器上都需要安裝keepAlived，安裝命令如下:
yum install -y keepalived
keepAlived安裝完成后，在/etc/keepalived目錄下有一個keepalived.conf原組態檔，內容如下:
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
#上面的配置無需關注，重點關注和修改下面的配置
vrrp_instance VI_1 {
#標識當前lvs是主，根據實際lvs服務器規劃確定，可選值
state MASTER
MASTER和BACKUP
#lvs服務器提供服務器的網卡，根據實際服務器網卡進行修改
interface eth0
#lvs提供的服務所屬ID，目前無需修改
virtual_router_id 51
#lvs服務器的優先級，主服務器最高，備份服務器要低于主服務器
priority 100
# VRRP Multicast 廣播周期秒數
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.88.88/24 dev ens33 label ens33:8
}
}
#virtual_ipaddress用于配置VIP和LVS服務器的網卡系結關系，一般需要修改
#示例: 192.168.25.100/24 dev ens33 label ens33:9
virtual_ipaddress {
192.168.200.16
192.168.200.17
192.168.200.18
} }
#配置lvs服務策略，相當于ipvsadm -A -t 192.168.25.100:80 -s rr，一般需要修改
virtual_server 192.168.200.100 443 {
delay_loop 6
#配置lvs調度演算法，默認輪詢
lb_algo rr
#配置lvs作業模式，可以改為DR
lb_kind NAT
#用于指定同一個client在多久內，只去請求第一次提供服務的RS，為查看輪詢效果，這里需要改為0
persistence_timeout 50
#TCP協議
protocol TCP
#配置RS資訊，相當于ipvsadm -a -t 192.168.25.100:80 -r 192.168.25.112 -g
real_server 192.168.201.100 443 {
#當前RS的權重
weight 1
#SSL_GET健康檢查，一般改為HTTP_GET
SSL_GET {
#兩個url可以洗掉一個，url內的內容改為path /和status_code 200，digest洗掉
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
#下面的配置實際是兩組lvs服務的配置，含義和上面的lvs服務配置一致，如果用不到，下面的配置可以全部 洗掉
virtual_server 10.10.10.2 1358 {
delay_loop 6
lb_algo rr
lb_kind NAT
persistence_timeout 50
protocol TCP
sorry_server 192.168.200.200 1358
real_server 192.168.200.2 1358 {
weight 1
HTTP_GET {
url {
....
4.2.2 配置keepAlived
基于上述組態檔和實戰拓撲圖及服務器規劃，對兩臺lvs服務器分別修改keepalived.conf配置如下:
LVS主服務器（Q110）
! Configuration File for keepalived
global_defs {
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
#主服務器
state MASTER
interface ens33
virtual_router_id 51
#優先級高
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.88.88/24 dev ens33 label ens33:8
}
}
virtual_server 192.168.88.88 80 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 0
protocol TCP
real_server 192.168.88.111 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 192.168.88.112 80 {
weight 1
HTTP_GET {
url {
path /
status_code 200
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
LVS備用服務器
# 拷貝主服務器配置到備用服務器并覆寫
scp /etc/keepalived/keepalived.conf [email protected]:`pwd`
# 進入備用服務器修改配置
vi /etc/keepalived/keepalived.conf
# 調整內容1：vrrp_instance VI_1 中state 改為 BACKUP，權重priority 50
注意：組態檔中的key和大括號之間一定要有空格
4.2.3 啟動keepAlived
在兩臺lvs服務器上分別啟動keepAlived，命令如下:
systemctl start keepalived
4.3 高可用測驗
4.3.1 測驗環境檢查
上述步驟執行完畢后，可以在lvs主服務器和備份服務器分別執行ifconfig命令，可以查看到VIP被系結到 了主服務器，如下:
4.3.2 測驗負載均衡
在客戶端發起請求，測驗負載均衡，如下:
# qin @ QinMac in ~ [8:54:24]
$ curl 192.168.88.88
this is RS02
# qin @ QinMac in ~ [8:56:05]
$ curl 192.168.88.88
this is RS01
# qin @ QinMac in ~ [8:56:15]
$ curl 192.168.88.88
this is RS02
# qin @ QinMac in ~ [8:56:16]
$ curl 192.168.88.88
this is RS01
4.3.3 測驗RS高可用
關閉一臺RS1后(這里可以使用systemctl stop httpd)，客戶端繼續發起請求，查看是 否可以正常訪問，
# qin @ QinMac in ~ [8:56:19]
$ curl 192.168.88.88
this is RS02
# qin @ QinMac in ~ [9:01:21]
$ curl 192.168.88.88
this is RS02
# qin @ QinMac in ~ [9:01:23]
$ curl 192.168.88.88
this is RS02
會發現，此時客戶端可以正常訪問，但只有RS2在提供服務，這說明，keepAlived檢測到了RS1服務器例外，將其剔除了，
此時再啟動RS1服務器，客戶端繼續訪問，會發現回應結果如下，keepAlived檢測到RS1服務器恢復正 常，又將其加入服務串列了
4.3.4 測驗LVS高可用
測驗lvs主服務宕機
使用ifconfig 網卡名 down命令，關閉主服務器網卡，此時主服務器不能提供服務，觀察備份服務器是否將VIP系結到自己，以及客戶端是否可以繼續正常訪問，如下: 關閉主服務器網卡
[root@q110 keepalived]# ifconfig ens33 down
觀察備份服務器，會發現VIP已經系結過來了，這里實際是keepAlived檢測到了主服務器的例外，而做 出的故障轉移和自動切換，
觀察客戶端是否可以繼續正常訪問
# qin @ QinMac in ~ [9:02:32]
$ curl 192.168.88.88
this is RS01
# qin @ QinMac in ~ [9:04:24]
$ curl 192.168.88.88
this is RS02
測驗lvs主服務器恢復 上述測驗通過后，可以開啟主服務器網卡，讓其能夠提供服務，然后觀察VIP是否會回到主服務器， 開啟主服務器網卡
ifconfig ens33 up
查看主服務器和備份服務器
主服務器
備服務器
會發現，VIP重新系結到了主服務器，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/433292.html
標籤：其他
上一篇：認識 LLVM
下一篇：leecode刷題1