1、群集
1.1群集的含義
由多臺主機構成,但對外只表現為一個整體,只提供一個訪問入口(域名與IP地址),相當于一臺大型計算機。
1.2 企業群集分類
負載均衡群集:提高應用系統的響應能力、盡可能處理更多的訪問請求、減少延遲為目標,獲得高并發、高負載(LB)的整體性能。LB的負載分配依賴于主節點的分流算法。
高可用群集:提高應用系統的可靠性、盡可能地減少中斷時間為目標,確保服務的連續性,達到高可用(HA)的容錯效果。HA的工作方式包括雙工和主從兩種模式。
高性能運算群集:提高應用系統的CPU運算速度、擴展硬件資源和分析能力為目標,獲得相當于大型、超級計算機的高性能運算(HPC)能力。高性能依賴于“分布式運算”、“并行計算”,通過專用硬件和軟件將多個服務器的CPU、內存等資源整合在一起,實現只有大型、超級計算機才具備的計算能力。
1.3 負載均衡群集
1.3.1 負載均衡的結構
第一層,負載調度器(Load Balancer或Director) 訪問整個群集系統的唯一入口,對外使用所有服務器共有的VIP地址,也稱為群集IР地址。通常會配置主、備兩臺調度器實現熱備份,當主調度器失效以后能夠平滑替換至備用調度器,確保高可用性。
第二層,服務器池(Server Pool) 群集所提供的應用服務、由服務器池承擔,其中每個節點具有獨立的RIP地址(真實IP),只處理調度器分發過來的客戶機請求。當某個節點暫時失效時,負載調度器的容錯機制會將其隔離,等待錯誤排除以后再重新納入服務器池。
第三層,共享存儲(Share Storage) 為服務器池中的所有節點提供穩定、一致的文件存取服務,確保整個群集的統一性。共享存儲可以使用NAS設備,或者提供NFS共享服務的專用服務器。
1.3.2 負載均衡群集的三種工作模式
NAT模式:Network Address Translation,簡稱NAT模式。類似于防火墻的私有網絡結構,負載調度器作為所有服務器節點的網關,即作為客戶機的訪問入口,也是各節點回應客戶機的訪問出口。 服務器節點使用私有IP地址,與負載調度器位于同一個物理網絡,安全性要優于其他兩種方式。
TUN模式:IP Tunnel,簡稱TUN模式。采用開放式的網絡結構,負載調度器僅作為客戶機的訪問入口,各節點通過各自的Internet連接直接回應客戶機,而不再經過負載調度器。服務器節點分散在互聯網中的不同位置,具有獨立的公網IP地址,通過專用IP隧道與負載調度器相互通信。
DR模式:Direct Routing,簡稱DR模式。采用半開放式的網絡結構,與TUN模式的結構類似,但各節點并不是分散在各地,而是與調度器位于同一個物理網絡。負載調度器與各節點服務器通過本地網絡連接,不需要建立專用的IP隧道。
2、LVS虛擬服務器
Linux Virtual Server:針對Linux內核的負載均衡解決方案。
2.1 LVS的負載均衡算法
輪詢(Round Robin):將收到的訪問請求按照順序輪流分配給群集中的各節點(真實服務器),均等地對待每一臺服務器,而不管服務器實際的連接數和系統負載。
加權輪詢(Weighted Round Robin):根據調度器設置的權重值來分發請求,權重值高的節點優先獲得任務,分配的請求數越多。保證性能強的服務器承擔更多的訪問流量。
最少連接(Least Connections):根據真實服務器已建立的連接數進行分配,將收到的訪問請求優先分配給連接數最少的節點。
加權最少連接(Weighted Least Connections):在服務器節點的性能差異較大時,可以為真實服務器自動調整權重。性能較高的節點將承擔更大比例的活動連接負載。
2.2 LVS-DR工中的ARP問題
(1)在LVS-DR負載均衡集群中,負載均衡器與節點服務器都要配置相同的VIP地址,勢必會造成各服務器ARP通信的紊亂 當ARP廣播發送到LVS-DR集群時,因為負載均衡器和節點服務器都是連接到相同的網絡上,它們都會接收到ARP廣播。 只有前端的負載均衡器進行響應,其他節點服務器不應該響應ARP廣播。arp_ingore=1可以防止網關路由發送ARP廣播時調度器和節點服務器進行響應,導致ARP緩存徐亂 ,不對非本地物理網卡IP的ARP請求進行響應。
(2)arp_annonuce=2:系統不使用響應數據包的源IP地址(VIP)來作為本機進行ARP請求報文的源IP地址,而使用發送報文的物理網卡IP地址作為ARP請求報文的源IP地址,這樣就可以防止網關路由器接受到源IP地址為VIP的ARP請求報文后又更新ARP緩存表,導致外網再發送請求時,數據包到達不了調度器。
2.3 LVS -DR模式工作原理
2.3.1 數據包流向分析
1. 客戶端 → Director(負載均衡器)
???- 客戶端發送請求到VIP(虛擬IP),數據包到達 Director Server內核空間。
2. Director → Real Server(真實服務器)
???- Director 判斷數據包目標IP為VIP,是集群服務請求,修改:
?????- 目標MAC:Real Server MAC
?????- 源MAC:Director Server MAC
???- IP地址保持不變,發送到 Real Server。
3. Real Server 處理請求
???- 接收報文(目標MAC為自身),通過lo接口配置VIP處理請求。
???- 響應報文源IP為 VIP,目標IP為客戶端(CIP),直接發送給客戶端。
4. 客戶端接收響應
???- 響應報文不經過Director Server。
2.3.2 DR模式特點
Director Server 與 Real Server 必須在同一物理網絡。
Real Server 可以使用私有或公網地址。
Director 僅作為請求入口,不作為網關。
所有請求經過 Director,響應直接由 Real Server 發送。
Real Server 的網關不能指向 Director Server。
Real Server 的lo接口配置 VIP。
3、LVS-DR模式部署
3.1 環境規劃
3.1.1 服務器規劃
DR服務器IP:192.168.17.155
Web服務器1 IP:192.168.17.157
Web服務器2 IP:192.168.17.158
vip:192.168.17.100
3.1.2 環境架構
3.2 配置負載調度器(Director Server)
環境部署
DR服務器IP:192.168.17.155
vip:192.168.17.100
(1)系統配置
#關閉防火墻及增強功能
systemctl stop firewalld.service
systemctl stop iptables.service
setenforce 0 modprobe ip_vs #加載LVS內核模塊
yum -y install ipvsadm #安裝ipvsadm 管理工具
(2)配置虛擬IP
cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0
vim ifcfg-ens33:0
# 內容
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.17.100
NETMASK=255.255.255.255ifup ens33:0 #開啟網卡
ifconfig ens33:0 #查看網卡
(3)調整內核參數
vim /etc/sysctl.conf
# 添加
net.ipv4.ip_forward = 0 #禁用IPv4轉發功能
net.ipv4.conf.all.send_redirects = 0 #對所有網卡禁用發送重定向
net.ipv4.conf.default.send_redirects = 0 #對新創建的網卡禁用
net.ipv4.conf.ens33.send_redirects = 0 #專門對ens33網卡禁用
sysctl -p #加載配置并立即生效
(4)配置LVS服務及調度
#如果有報錯文件不存在 需要先添加規則 在保存即可
ipvsadm-save > /etc/sysconfig/ipvsadm #保存 導出ipvsadm-restore < /etc/sysconfig/ipvsadm #恢復 systemctl start ipvsadm
ipvsadm -C #清空現有規則
ipvsadm -A -t 192.168.17.100:80 -s rr #創建LVS虛擬服務(VIP)
-A:添加虛擬服務 -t:指定服務類型為 TCP 協議 192.168.10.180:80: VIP(虛擬 IP)+ 端口
-s:指定 負載均衡調度算法 rr:Round Robin(輪詢)
ipvsadm -a -t 192.168.17.100:80 -r 192.168.17.157:80 -g #添加后端真實服務器(Real Server 1)
-a:給虛擬服務添加真實服務器 -t:關聯的虛擬服務(VIP: 端口) -r:真實服務器的 IP -g:LVS為DR模式
ipvsadm -a -t 192.168.17.100:80 -r 192.168.17.158:80 -g #添加后端真實服務器(Real Server 2)
ipvsadm -ln # 查看節點狀態,Route代表DR模式
ipvsadm-save > /etc/sysconfig/ipvsadm # 保存到配置文件(持久化)
3.3 配置節點服務器(Real Server)
Web服務器1 IP:192.168.17.157
Web服務器2 IP:192.168.17.158
(1)配置VIP到lo接口
cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0
# 內容
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.17.100 #綁定的VIP(與LVS調度器的VIP一致,即客戶端訪問的入口IP)
NETMASK=255.255.255.255 #子網掩碼必須設為255.255.255.255(僅本機可見的主機路由)ifup lo:0
ifconfig lo:0
route add -host 192.168.17.100 dev lo:0 # 為VIP添加一條主機路由,指定通過lo:0接口訪問
(2)ARP參數調整,避免MAC沖突
vim /etc/sysctl.conf
net.ipv4.conf.lo.arp_ignore = 1 禁錮路由
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
sysctl -p
(3)安裝web服務
# 192.168.17.157
echo 'this is 192.168.17.157 web01!' >/usr/local/nginx/html/index.html# 192.168.17.158
echo 'this is 192.168.17.158 web02!' > /usr/local/nginx/html/index.html
3.4 測試LVS群集
在客戶端瀏覽器訪問:http://192.168.17.100/
4、LVS+Keepalived群集
4.1 概念與原理
4.1.1 Keepalived
基于VRRP協議實現高可用(HA)。
初衷是為 LVS負載均衡提供高可用方案,后來支持其他服務(如 Nginx、MySQL 等)。
功能:
??1. LVS 集群管理
??2. 節點健康檢查(Health Check)
?????Keepalive可以通過在自身的Keepalive.conf文件里配置LVS的節點IP和相關參數實現對LVS的直接管理;除此之外,當LVS集群中的某一個甚至是幾個節點服務器同時發生故障無法提供服務時,Keepalive服務會自動將失效的節點服務器從LVS的正常轉發隊列中清除出去,并將請求調度到別的正常節點服務器上,從而保證最終用戶的訪問不受影響;當故障的節點服務器被修復以后,Keepalive服務又會自動地把它們加入到正常轉發隊列中,對客戶提供服務。
??3. 故障自動切換(Failover)
?????Keepalive可以實現任意兩臺主機之間,例如Master和Backup主機之間的故障轉移和自動切換,這個主機可以是普通的不能停機的業務服務器,也可以是LVS負載均衡,Nginx反向代理這樣的服務器。
?????Keepalive高可用功能實現的簡單原理為,兩臺主機同時安裝好Keepalive軟件并啟動服務,開始正常工作時,由角色為Master的主機獲得所有資源并對用戶提供服務,角色為Backup的主機作為Master主機的熱備;當角色為Master的主機失效或出現故障時,角色為Backup的主機將自動接管Master主機的所有工作,包括接管VIP資源及相應資源服務;而當角色為Master的主機故障修復后,又會自動接管回它原來處理的工作,角色為Backup的主機則同時釋放Master主機失效時它接管的工作,此時,兩臺主機將恢復到最初啟動時各自的原始角色及工作狀態。
??4. 高可用 VIP(虛擬 IP)接管
4.1.2 工作原理
① 基于VRRP協議: keepalived通過VRRP(虛擬路由冗余協議)來實現高可用,多臺服務器組成的一個組,主服務器(master)負責對外提供虛擬IP地址(VIP),并且定時發送心跳包,當備服務器(backup)檢測不到心跳時,會按優先級選舉新的master,接管虛擬IP地址,主要就是保證服務不中斷。
? ?② 基于TCP/IP協議:keepalived 在IP層面上(ping),TCP層 (端口檢測)和應用層 (自定義腳本)對服務器健康狀態進行檢測 ,確保服務能正常的運行(可用性)。
? ?③ 選舉策略: keepalived通過優先級和權重來決定主備切換 ?,支持用戶手動配置 或這腳本動態去配置,當主機故障或者新節點 加入的時候,觸發選舉 重新進行分配虛擬IP 實現自動接管。
4.1.3 Keepalived的主要模塊
模塊 | 功能 |
---|---|
core | 核心進程、配置文件加載解析 |
vrrp | VRRP 協議實現,高可用 |
check | 健康檢查,支持 TCP/HTTP/腳本檢查 |
4.2 腦裂問題與防護
4.2.1 腦裂
當網絡出現問題或者配置錯誤時,多個服務器都認為自己是主服務器,結果虛擬IP(VIP)沖突,導致服務器終端或者不穩定。
4.2.2 原因
1. 心跳線故障(斷線、老化)
???高可用服務器對之間心跳線鏈路發生故障,導致無法正常通信。如心跳線壞了(包括斷了,老化)。
2. 網卡/驅動故障
???因網卡及相關驅動壞了,ip配置及沖突問題(網卡直連)。
3. 心跳網絡設備故障
???因心跳線間連接的設備故障(網卡及交換機)。
4. 仲裁機器異常
???因仲裁的機器出問題
5. 防火墻阻擋 VRRP
??高可用服務器上開啟了 iptables防火墻阻擋了心跳消息傳輸。
6. 配置不一致(virtual_router_id、優先級、實例名)
???Keepalive配置里同一 VRRP實例如果 virtual_router_id兩端參數配置不一致也會導致裂腦問題發生。
7. vrrp實例名字不一致、優先級一致。
4.2.3 防護策略
健康檢查、網路檢測(ping)、延遲VIP切換、雙心跳線冗余、腳本監控報警
4.3 部署步驟
4.3.1環境準備
主DR服務器IP:192.168.17.155
備DR服務器IP:192.168.17.156(在LVS-DR模式下新增)
Web服務器1 IP:192.168.17.157
Web服務器2 IP:192.168.17.158
vip:192.168.17.100
4.3.2 DR服務器操作
參考LVS-DR服務器配置
4.3.3 配置Keepalived
文件 /etc/keepalived/keepalived.confglobal_defs {router_id LVS_01 # MASTER 為 LVS_01,BACKUP 為 LVS_02smtp_server 127.0.0.1
}vrrp_instance VI_1 {state MASTER # BACKUP 節點寫 BACKUPinterface ens33 # 網卡名virtual_router_id 10 # BACKUP與BACKUP相同priority 100 # MASTER 高于 BACKUPadvert_int 1authentication {auth_type PASSauth_pass abc123}virtual_ipaddress {192.168.17.100}
}virtual_server 192.168.17.100 80 {delay_loop 6lb_algo rrlb_kind DRpersistence_timeout 50protocol TCPreal_server 192.168.17.157 80 {weight 1TCP_CHECK {connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}real_server 192.168.17.158 80 {weight 1TCP_CHECK {connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}
}
4.3.4 啟動服務
同LVS-DR流程
4.3.5 配置Web節點
同LVS節點服務器配置
4.3.6 測試
客戶端訪問:http://192.168.17.100/
停掉 MASTER Keepalived:systemctl stop keepalived 再次訪問。觀察 BACKUP 節點接管 VIP 是否成功。再啟動 MASTER,觀察 VIP 是否回歸(搶占或非搶占模式)。