目錄
一、核心組件與作用
1. LVS（Linux Virtual Server）
2. Keepalived
二、DR 模式下的 LVS + Keepalived 工作原理
1. 整體架構
2. 數據包流向（DR 模式）
三、部署步驟（DR 模式）
3.1 環境規劃
3.2 主 / 備 LVS 節點配置（以主節點為例）
（1）基礎環境準備
（2）配置 VIP（主 / 備節點均需配置）
（3）配置 Keepalived（主節點）
（4）優化內核參數（主 / 備節點均需配置）
（5）啟動服務
3.3 后端 RS 配置（RS1 和 RS2 均需配置）
（1）綁定 VIP 到 lo 接口
（2）優化 ARP 策略（避免 MAC 沖突）
（3）部署 Web 服務
四、測試與驗證
五、核心優勢與注意事項
優勢
注意事項
六、與其他方案對比（LVS+Keepalived vs Nginx/HAProxy）
三種模式的選擇依據
一、核心組件與作用
1. LVS（Linux Virtual Server）
- 定位：內核級四層負載均衡器，通過虛擬 IP（VIP）將客戶端請求分發到后端真實服務器（Real Server，RS）。
- 核心功能：
- 基于不同模式（DR/NAT/TUN）實現流量轉發，其中?DR 模式因高性能成為主流選擇。
- 支持多種調度算法（如輪詢 rr、加權輪詢 wrr 等），實現請求的均衡分發。
- 優勢：工作在內核態，轉發效率極高，適合高并發場景（百萬級并發支撐）。
2. Keepalived
- 定位：基于 VRRP 協議的高可用工具，為 LVS 提供故障轉移和健康檢查能力。
- 核心功能：
- VIP 漂移：監控 LVS 主節點狀態，故障時自動將 VIP 切換到備用節點，避免單點故障。
- 健康檢查：檢測后端 RS 狀態，自動剔除故障節點，確保請求僅分發到正常服務。
- 集群管理：直接集成 LVS 配置，統一管理負載均衡規則。
二、DR 模式下的 LVS + Keepalived 工作原理
1. 整體架構
- 角色分工：
- 主 LVS 節點（MASTER）：承載 VIP，處理并分發客戶端請求，發送 VRRP 心跳給備節點。
- 備 LVS 節點（BACKUP）：監聽主節點心跳，主節點故障時接管 VIP，繼續提供負載均衡。
- 后端 RS：部署 Web 等服務，通過 lo 接口綁定 VIP，直接響應客戶端（不經過 LVS）。
- VIP 流轉：正常時 VIP 在主 LVS 節點，主節點故障后 VIP 自動漂移到備節點。
2. 數據包流向（DR 模式）
- 客戶端 → 主 LVS 節點：客戶端請求發送到 VIP，數據包到達主 LVS 內核空間。
- LVS → 后端 RS：LVS 僅修改數據包的目標 MAC 地址（改為目標 RS 的 MAC），IP 地址不變（源 CIP，目標 VIP），通過二層網絡發送到 RS。
- RS → 客戶端：RS 通過 lo 接口的 VIP 處理請求，響應數據包直接發送給客戶端（源 VIP，目標 CIP），不經過 LVS。
三、部署步驟（DR 模式）
3.1 環境規劃
| 角色 | IP 地址 | 核心配置 |
|---|---|---|
| 主 LVS（MASTER） | 192.168.10.80 | 綁定 VIP 192.168.10.180 |
| 備 LVS（BACKUP） | 192.168.10.23 | 備用節點，主節點故障時接管 VIP |
| 后端 RS1 | 192.168.10.16 | 部署 Web 服務，lo 接口綁定 VIP |
| 后端 RS2 | 192.168.10.17 | 部署 Web 服務，lo 接口綁定 VIP |
| 客戶端 | 192.168.10.100 | 訪問 VIP 192.168.10.180 |
3.2 主 / 備 LVS 節點配置（以主節點為例）
（1）基礎環境準備
# 關閉防火墻和 SELinux
systemctl stop firewalld && systemctl disable firewalld
setenforce 0 && sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config# 安裝工具
yum -y install ipvsadm keepalived
modprobe ip_vs # 加載 LVS 內核模塊
（2）配置 VIP（主 / 備節點均需配置）
# 創建虛擬網卡配置文件
cd /etc/sysconfig/network-scripts/
cp ifcfg-ens33 ifcfg-ens33:0# 編輯配置（子網掩碼必須為 255.255.255.255）
vim ifcfg-ens33:0
DEVICE=ens33:0
ONBOOT=yes
IPADDR=192.168.10.180
NETMASK=255.255.255.255
IPV6INIT=no# 啟動虛擬網卡
ifup ens33:0
（3）配置 Keepalived（主節點）
vim /etc/keepalived/keepalived.conf
global_defs {router_id LVS_01 # 主節點標識，備節點改為 LVS_02
}# VRRP 實例（控制 VIP 漂移）
vrrp_instance VI_1 {state MASTER # 備節點改為 BACKUPinterface ens33 # 綁定 VIP 的物理網卡virtual_router_id 10 # 主備節點需一致priority 100 # 主節點優先級高于備節點（備節點設為 90）advert_int 1 # 心跳間隔 1 秒authentication {auth_type PASSauth_pass abc123 # 主備節點認證密碼需一致}virtual_ipaddress {192.168.10.180 # VIP 地址}
}# LVS 負載均衡配置
virtual_server 192.168.10.180 80 {delay_loop 6 # 健康檢查間隔 6 秒lb_algo rr # 調度算法：輪詢lb_kind DR # 模式：DRpersistence_timeout 50 # 會話保持超時 50 秒（同一客戶端 50 秒內固定訪問同一 RS）protocol TCP# 后端 RS1 配置real_server 192.168.10.16 80 {weight 1 # 權重（越高分配越多請求）TCP_CHECK { # TCP 健康檢查connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}# 后端 RS2 配置real_server 192.168.10.17 80 {weight 1TCP_CHECK {connect_port 80connect_timeout 3nb_get_retry 3delay_before_retry 3}}
}
（4）優化內核參數（主 / 備節點均需配置）
send_redirects：控制當前服務器是否發送 ICMP 重定向報文。
- 取值?
1（默認）：允許發送 ICMP 重定向報文。 - 取值?
0：禁止發送 ICMP 重定向報文。
關閉 ICMP 重定向的核心目的是?避免客戶端繞開負載均衡器直接訪問后端服務器，具體原因如下：
-
DR 模式的特殊網絡路徑：
- 負載均衡器（Director）通過修改 MAC 地址將請求轉發給后端服務器。
- 后端服務器處理后，直接通過自己的物理網卡向客戶端發送響應（源 IP 是 VIP）。
此時，服務器（后端或 Director）可能會認為 “客戶端到 VIP 的最優路徑是直接訪問后端服務器”，從而發送 ICMP 重定向報文給客戶端，導致客戶端后續請求直接發給后端服務器（繞過 Director），破壞負載均衡策略。
-
防止路由混亂：
LVS 集群中，VIP 同時存在于 Director 和后端服務器（DR 模式），網絡拓撲相對特殊。ICMP 重定向可能會讓客戶端或中間設備（如交換機）學習到錯誤的路由規則，導致請求分發異常。
vim /etc/sysctl.conf
net.ipv4.conf.all.send_redirects = 0 控制 ICMP 重定向
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.ens33.send_redirects = 0
sysctl -p # 生效配置
（5）啟動服務
ip_vs?是 Linux 內核中實現 LVS（Linux Virtual Server，Linux 虛擬服務器）的核心模塊，全稱為?IP Virtual Server。它是由章文嵩博士主導開發的內核級負載均衡組件，通過在 Linux 內核中直接處理網絡數據包，實現了高性能、高可用的 Layer 4（傳輸層）負載均衡。
ip_vs 的核心作用
?ip_vs?運行在 Linux 內核的網絡協議棧中，主要負責：
- 接收客戶端請求：監聽虛擬 IP（VIP）上的服務端口（如 80、443）。
- 負載均衡調度：根據配置的算法（如輪詢、權重、IP 哈希等），從后端真實服務器（Real Server）池中選擇合適的節點。
- 轉發數據包：根據 LVS 的工作模式（NAT/DR/TUN），對數據包進行地址轉換、MAC 地址修改或隧道封裝，將請求轉發到選定的后端服務器。
- 維護連接狀態：跟蹤客戶端與后端服務器的連接，確保同一客戶端的請求能被正確轉發（如 IP 哈希算法）。
ip_vs 的工作原理
- 內核態處理：
ip_vs?直接在內核態工作，避免了用戶態與內核態之間的數據拷貝，因此性能遠高于基于用戶態的負載均衡工具（如 Nginx 作為四層負載均衡時）。 - 依賴 IPVS 管理工具：
ip_vs?本身是內核模塊，需要通過用戶態工具（如?ipvsadm?或?keepalived）進行配置（如定義 VIP、后端服務器、負載策略等）。 - 支持多種轉發模式：如前文提到的 NAT、DR、TUN 三種模式，通過不同的數據包處理方式適配不同的網絡場景。
ip_vs 與 LVS 的關系
- LVS 是整體架構：包含內核中的?
ip_vs?模塊（負責實際轉發）和用戶態管理工具（如?ipvsadm，負責配置規則）。 - ip_vs 是 LVS 的核心：沒有?
ip_vs?模塊，LVS 就無法實現負載均衡功能；用戶態工具僅用于配置和管理?ip_vs?的規則。
使用場景
ip_vs?適用于需要高性能四層負載均衡的場景，例如：
- 大規模 Web 服務集群的入口流量分發。
- 數據庫讀寫分離的連接轉發。
- 高并發 TCP/UDP 服務的負載均衡（如游戲服務器、視頻流服務）。
systemctl start keepalived
systemctl enable keepalivedipvsadm -ln # 驗證 LVS 規則（顯示 RR 算法和 DR 模式）
#清除規則
ipvsadm -C
#添加虛擬服務器（VIP），使用輪詢算法（rr）
ipvsadm -A -t 192.168.10.180:80 -s rr
#添加后端真實服務器（DR 模式）
ipvsadm -a -t 192.168.10.180:80 -r 192.168.10.16:80 -g
ipvsadm -a -t 192.168.10.180:80 -r 192.168.10.17:80 -g
#保存規則到配置文件
ipvsadm-save > /etc/sysconfig/ipvsadm
systemctl start ipvsadm3.3 后端 RS 配置（RS1 和 RS2 均需配置）
（1）綁定 VIP 到 lo 接口
cd /etc/sysconfig/network-scripts/
cp ifcfg-lo ifcfg-lo:0vim ifcfg-lo:0
DEVICE=lo:0
ONBOOT=yes
IPADDR=192.168.10.180 # 與 LVS 的 VIP 一致
NETMASK=255.255.255.255
IPV6INIT=no# 啟動接口并添加路由
ifup lo:0
route add -host 192.168.10.180 dev lo:0 # 確保 VIP 路由指向 lo 接口
（2）優化 ARP 策略（避免 MAC 沖突）
各參數含義
1.?arp_ignore：控制是否響應 ARP 請求
- 作用：決定當服務器收到一個 ARP 請求（詢問某個 IP 對應的 MAC 地址）時，是否返回自己的 MAC 地址。
- 取值含義：
0（默認）：只要本地配置了該 IP，就響應 ARP 請求（返回自己的 MAC）。1：僅當 ARP 請求的目標 IP 配置在接收請求的網絡接口上時，才響應；如果 IP 配置在非接收接口（如 lo 回環接口），則不響應。
2.?arp_announce：控制發送 ARP 通告時的源 IP 選擇
- 作用：當服務器主動發送 ARP 通告（告知網絡中其他設備 “我擁有某個 IP”）時，決定使用哪個 IP 作為源 IP。
- 取值含義：
0（默認）：允許使用任意網絡接口上的 IP 作為源 IP 發送 ARP 通告。1：盡量使用與目標 IP 同網段的本地 IP 作為源 IP。2：強制使用發送接口上的 IP 作為源 IP，不允許使用其他接口（如 lo）上的 IP。
vim /etc/sysctl.conf
# 禁止 RS 響應非本地物理 IP 的 ARP 請求
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 服務
yum -y install httpd
systemctl start httpd && systemctl enable httpd# RS1 頁面內容
echo 'this is kgc web!' > /var/www/html/index.html
# RS2 頁面內容
echo 'this is benet web!' > /var/www/html/index.html
四、測試與驗證
- 負載均衡測試：客戶端訪問?
http://192.168.10.180，刷新頁面（間隔超過 50 秒），應輪詢顯示 RS1 和 RS2 的頁面。 - 高可用測試：
- 停止主 LVS 節點的 Keepalived：
systemctl stop keepalived。 - 在備節點執行?
ip addr，確認 VIP 已漂移到備節點。 - 客戶端繼續訪問 VIP，服務正常（由備節點分發請求）。
- 重啟主節點 Keepalived，VIP 自動回歸（默認搶占模式）。
- 停止主 LVS 節點的 Keepalived：
五、核心優勢與注意事項
優勢
- 高性能：DR 模式下 LVS 僅修改 MAC 地址，轉發效率極高，適合高并發。
- 高可用：Keepalived 實現 VIP 漂移，避免 LVS 節點單點故障。
- 靈活性：支持多種調度算法，可根據 RS 性能調整權重。
注意事項
- 網絡要求：LVS 節點與 RS 必須在同一物理網段（DR 模式限制）。
- ARP 策略：RS 必須配置?
arp_ignore?和?arp_announce，否則會導致 VIP 沖突。 - 會話保持：
persistence_timeout?需根據業務場景調整（如靜態頁面可設為 0）。 - 腦裂防護：通過雙心跳線、仲裁 IP（如網關）避免主備節點同時爭搶 VIP。
六、與其他方案對比（LVS+Keepalived vs Nginx/HAProxy）
| 特性 | LVS + Keepalived | Nginx | HAProxy |
|---|---|---|---|
| 工作層級 | 四層（內核態） | 四層 + 七層（應用態） | 四層 + 七層（應用態） |
| 性能 | 最高（百萬級并發） | 高（十萬級并發） | 高（接近 Nginx） |
| 健康檢查 | 依賴 Keepalived 腳本 / TCP 檢查 | 簡單 HTTP/TCP 檢查 | 強大（支持多種協議） |
| 適用場景 | 超大規模集群、高并發 | 中小型集群、需七層轉發（如 URL 路由） | 高可用集群、復雜健康檢查需求 |
三種模式的選擇依據
| 模式 | 核心適用場景 | 與 Keepalived 結合的優勢 | 典型業務場景 |
|---|---|---|---|
| DR | 同網段、高并發、高性能要求 | 性能最優，適合大規模集群，Keepalived 保障 VIP 高可用 | 電商、門戶等高流量網站 |
| NAT | 跨網段、小規模集群、需隱藏后端 IP | 部署靈活，適合簡單網絡，Keepalived 簡化故障轉移 | 小型應用、內部服務 |
| TUN | 跨地域、分布式部署，需避免 NAT 瓶頸 | 支持廣域網負載均衡，Keepalived 確保隧道節點高可用 | 跨數據中心集群、分布式服務 |
通過 LVS + Keepalived 的組合，可構建兼具高性能和高可用性的負載均衡架構，是企業級核心服務的理想選擇。
` 、`max()`、 `clamp()`)
問題詳解)
![[Windows] PDF 專業壓縮工具 v3.0](http://pic.xiahunao.cn/[Windows] PDF 專業壓縮工具 v3.0)