深入淺出 LVS 負載均衡(四)實操 DR 模型、Keepalived DR 模型的高可用

語言: CN / TW / HK
  • 深入淺出 LVS 負載均衡(四)實操 DR 模型、Keepalived DR 模型的高可用

    欄目:技術分享

    之前介紹了 LVS 負載均衡 NAT、FULLNAT、DR、TUN 模型的實現原理。本章繼續來動手實踐一下~

    實踐環境

    LVS 目前已經是 Linux 核心中的一部分,在核心中的模組叫做 ipvs,支援 NAT、DR、TUNNEL 模型。使用者不能直接操作 ipvs 模組,需要安裝互動軟體 ipvsadm,使用 ipvsadm 和 ipvs 進行互動。

    使用 4臺 UCloud 雲主機來搭建實驗環境,建立雲主機的時候選擇分時購買,更划算。

    實驗機器及環境

    • 4臺 UCloud 雲主機,CentOS 7.9 64位,1 核 1 G,需要注意⼀下防⽕牆規則,實踐中選擇的是【Web伺服器推薦】,開放 22、3389、80、443 的端⼝號,這個可以⾃⾏配置
    • 兩臺 Real Server:RS01、RS02,⼀臺負載均衡伺服器:LB01
    • RS01:10.23.190.76、RS02:10.23.122.152、LB01:10.23.21.184、LB02:10.23.115.100
    • VIP:10.23.88.247
    • RS01、RS02 安裝 httpd,快速啟動 http 伺服器,且配置不同的請求響應
    • LB01、LB02 安裝pvsadm、keepalived,並啟動       ipvsadm、keepalived

    實驗機器展示

    DR 模式實操

    回顧一下 DR 模式的特點

    • DR 模式僅修改資料包的「目標 MAC 地址」,只有請求資料包需要經過負載均衡器,所以 DR 模式不支援對埠的轉換
    • 真實伺服器和負載均衡器必須在同一個網段,且真實伺服器的預設閘道器不能是負載均衡器
    • 真實伺服器的 lo 介面上需要配置 VIP 的 IP 地址,且真實伺服器需要更改 ARP 協議,“隱藏” lo 介面上的 VIP

    實操開始,前置準備工作和上篇實操中的 NAT 模式的一樣,這裡就不贅述了。

    開始配置 DR 模式:

    RS01、RS02

    • 修改 ARP 協議
    • echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
    • echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
    • echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
    • echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
    • 在 lo 介面上配置 VIP
    • ifconfig lo:0 10.23.21.184 netmask 255.255.255.255
    • 驗證配置 ifconfig

    LB01

    • 配置路由入口規則
    • ipvsadm -A -t 10.23.21.184:80 -s rr
    • 配置路由出口規則
    • ipvsadm -a -t 10.23.21.184:80 -r 10.23.190.76 -g -w 1
    • ipvsadm -a -t 10.23.21.184:80 -r 10.23.122.152 -g -w 1
    • 如果 VIP 和本機地址不一致,要配置 VIP(我這裡就不用了)
    • 配置 VIP
    • ifconfig eth0:0 VIP/24
    • 驗證配置
    • ipvsadm  -ln
    • ifconfig

    配置完成,現在我們來驗證下 DR 模式下的負載均衡。

    發現直接在本地請求 LB01 的外網 IP 地址時,一直處於等待狀態,最終報錯:Operation timed out。

    我們先來看下 LB01 有沒有正確的收到連線請求

    • 檢視 LB01 記錄的連線資訊:ipvsadm -Lnc

    可以看到 LB01 正確的收到了連線請求,並且轉發給了 RS02。接下來我們登陸到 RS02 上,檢查 RS02 是否接收到了資料包。

    • 檢視 RS02 上的 TCP 連線資訊:netstat -natp | grep 10.23.21.184

    RS02 收到了資料包,並且也發出了返回的資料包,返回資料包的 IP 地址和埠號也和發出的一致。所以可以合理地猜測,問題出在由 RS02 直接返回資料包給客戶端的過程中。那麼只有兩種情況,RS02 無法連線到客戶端或者客戶端拒絕接收這個資料包。

    檢查 RS02 是否能正常連線到客戶端

    • ping 106.75.220.2

    RS02 和客戶端可以正常請求訪問。那麼應該是客戶端拒絕接收了這個資料包,抓包來看下,客戶端是否有收到這個資料包。

    再次請求 LB01,並檢視客戶端和 LB01 互動的資料包

    • tcpdump host 106.75.253.112 -nne

    發現只有發出的資料包,而沒有收到的資料包。現在情況是:RS02 發出了資料包,但是客戶端卻沒收到。那只有一種可能,就是雲主機的 EIP 轉發資料包的時候,由於某種條件限制,扔掉了這個資料包。如果是這樣的話,在內網環境中應該是可以正常訪問的。我們再申請一臺在相同網段的雲主機,驗證一下。

    果然是可以正常訪問的,後來和官方交流之後也證實了這一點。(我猜測應該是出於對安全的考慮,所有進出的資料包,IP 地址 和 MAC 地址必須和本機一致,否則資料包會被丟棄。)

    到此實驗配置完成,驗證也隨之完成~

    Keepalived 實現 DR 模型的高可用性實操

    在成功搭建 DR 模型之後,不由得思考這麼一個問題,如果負載均衡伺服器宕機了怎麼辦?負載均衡伺服器承載著客戶端對服務端的所有請求路由,如果一旦宕機,影響的是整個系統不可用。所以需要一些措施來保證負載均衡的高可用性。

    最簡單的辦法就是將單點部署的負載均衡伺服器變成多點部署。如果當前使用的節點出現問題,迅速地切換到另一個節點上,這樣就可以保證系統的整個可用性。那麼,現在負載均衡伺服器單點故障的問題就轉換成多點部署的切換問題。

    先來看看解決多點部署的切換問題,需要什麼條件?首先需要發現問題,即需要不斷地檢查當前節點是否正常,如果當前節點不正常的話,需要快速地切換到其他的節點上。keepalived 就是這樣工作的。

    實際操作開始~

    • RS01、RS02 和 DR 模型實操類似,只不過要重新申請一個VIP:10.23.88.247,繫結在 RS01、RS02 的 lo:0 上 
    • ifconfig lo:0 10.23.88.247 netmask 255.255.255.255 broadcast 10.23.88.247 up  
    • LB01、LB02
      • 安裝 ipvsadm、keepalived
        • yum install ipvsadm keepalived -y
      • 修改 keepalived 配置檔案
        • cp keepalived.conf keepalived.conf.bak

    驗證 keepalived DR 模型

    可以正常訪問到兩臺伺服器,接下來把 LB01 的 keepalived 停掉,繼續訪問 VIP

    還是可以正常訪問,VIP 漂到了 LB02 上。使用 ipvsadm -lnc 檢視具體連線資訊

    實驗完成,差不多斷斷續續的用了 4.5 小時,包括一些額外的排查時間,共計花費不到 5 元錢~

    至此,深入淺出 LVS 負載均衡系列解讀全部完成,感謝您的閱讀與分享。

    *本平臺所釋出文章資訊,版權歸UCloud所有,如需轉載請註明出處!