一、實驗環境（RHEL 9）

1、NAT模式的實驗環境

在RS1和RS2中下載http，并且在默認發布目錄文件中寫入對應的內容，例如RS1寫入RS1 - 192.168.0.10，RS2寫入RS2 - 192.168.0.20。

[root@RS1 桌面]# dnf install httpd -y
[root@RS1 桌面]# systemctl disable --now firewalld.service 
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
[root@RS1 桌面]# echo RS1 - 192.168.0.10 > /var/www/html/index.html
[root@RS1 桌面]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

[root@RS2 桌面]# dnf install httpd -y
[root@RS2 桌面]# systemctl disable --now firewalld.service 
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".
[root@RS2 桌面]# echo RS2 - 192.168.0.20 > /var/www/html/index.html
[root@RS2 桌面]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

確保lvs可以通過curl訪問RS1和RS2。

2、DR模式的實驗環境

配置回環接口IP地址的示例：

此回環接口IP地址的配置在DR-lvs、RS1、RS2上都要進行配置。

在DR-lvs上的額外配置：

需要在僅主機模式的這個接口上新添加一個192.168.0.220/24的IP地址

二、LVS集群的4種類型

LVS（Linux Virtual Server）是基于 Linux 內核的開源負載均衡解決方案，通過將多個服務器組成一個集群，實現高可用、高性能的服務。LVS 支持四種核心的集群類型（工作模式），它們在數據包轉發方式、架構復雜度和適用場景上有顯著區別：

1. NAT 模式（Virtual Server via Network Address Translation）

核心原理

LVS 負載均衡器作為流量的「雙向網關」，通過修改數據包的 IP 地址實現轉發，具體流程如下：

• 客戶端請求（入站）：
  客戶端向 LVS 的 VIP（虛擬 IP）發送請求，數據包源 IP 為客戶端 IP，目標 IP 為 VIP。
  LVS 接收后，僅修改目標 IP（將 VIP 替換為后端 RS 的私有 IP），源 IP 保持不變（仍為客戶端 IP），然后轉發給選定的 RS。

• RS 響應（出站）：
  RS 處理請求后，生成響應包，目標 IP 為客戶端 IP（因源 IP 未被修改），源 IP 為自身私有 IP。
  由于 RS 的默認網關指向 LVS，響應包會先回傳給 LVS。
  LVS 接收后，修改源 IP（將 RS 的私有 IP 替換為 VIP），再將數據包轉發給客戶端。

架構特點

• 流量路徑：所有入站和出站流量必須經過 LVS，形成「客戶端 → LVS → RS → LVS → 客戶端」的閉環。

• 網絡要求：LVS 與 RS 必須在同一子網（因依賴 LVS 作為網關），RS 的網關必須手動指向 LVS 的 IP。

• VIP 配置：僅 LVS 需配置 VIP，RS 無需綁定 VIP（隱藏在私有子網中）。

優缺點

• 優點：

  • 配置簡單，RS 無需特殊設置（僅需指向 LVS 為網關）。

  • 支持任意 TCP/UDP 服務（如數據庫、FTP 等），兼容性強。

  • 安全性高，RS 隱藏在私有網絡，不直接暴露給客戶端。

• 缺點：

  • LVS 是流量瓶頸（所有數據需經其轉發），性能受限于 LVS 的帶寬和處理能力。

  • 僅適用于小規模集群（通常 RS 數量 ≤ 20 臺）。

適用場景

• 小規模集群（如內部業務系統、低并發服務）。

• 對安全性要求高（需隱藏 RS 真實 IP）。

• 服務類型復雜（如需要雙向交互的協議）。

2. DR 模式（Virtual Server via Direct Routing）

核心原理

LVS 僅處理入站請求，通過修改數據包的?MAC 地址?而非 IP 地址轉發，出站流量由 RS 直接返回客戶端，流程如下：

• 客戶端請求（入站）：
  客戶端向 VIP 發送請求，數據包源 IP 為客戶端 IP，目標 IP 為 VIP，目標 MAC 地址為 LVS 的 MAC。
  LVS 接收后，不修改 IP 地址（源 IP 和目標 IP 保持不變），僅將目標 MAC 地址替換為選定 RS 的 MAC 地址，然后通過二層網絡（交換機）轉發給 RS。

• RS 響應（出站）：
  RS 已預先綁定 VIP（需配置在回環接口或禁用 ARP 響應，避免沖突），因此會接收目標 IP 為 VIP 的數據包。
  RS 處理后，直接以客戶端 IP 為目標、VIP 為源 IP 發送響應包，通過自身網絡接口直接返回給客戶端，無需經過 LVS。

架構特點

• 流量分離：入站流量經 LVS，出站流量由 RS 直連客戶端，LVS 負載極大降低。

• VIP 配置：LVS 和所有 RS 必須綁定相同的 VIP（LVS 用于接收請求，RS 用于響應客戶端）。

• 網絡要求：LVS 與 RS 必須在同一物理子網（二層可達），因依賴 MAC 地址轉發。

• ARP 抑制：RS 需配置內核參數（如?arp_ignore=1、arp_announce=2），避免對 VIP 的 ARP 請求做出響應，防止客戶端直接連接 RS。

優缺點

• 優點：

  • 性能極高（LVS 僅處理入站流量，無 IP 修改開銷），支持大規模集群（RS 可達數百臺）。

  • 出站流量不經過 LVS，避免瓶頸。

• 缺點：

  • 網絡拓撲受限（必須同一子網），跨網段部署困難。

  • RS 配置較復雜（需綁定 VIP 并抑制 ARP）。

適用場景

• 高并發 Web 服務（如 HTTP/HTTPS）。

• 大規模集群（如電商平臺、內容分發節點）。

• 對響應速度要求極高的場景（如實時交互服務）。

3. TUN 模式（Virtual Server via IP Tunneling）

核心原理

通過?IP 隧道技術（如 IPIP、GRE）將客戶端請求封裝后轉發給 RS，突破子網限制，流程如下：

• 客戶端請求（入站）：
  客戶端向 VIP 發送請求，LVS 接收后，將原始數據包（源 IP：客戶端 IP，目標 IP：VIP）封裝在新的 IP 隧道中：

  • 外層隧道的源 IP 為 LVS 的 IP，目標 IP 為 RS 的隧道 IP（RS 預先配置的公網或跨網段 IP）。
    LVS 將封裝后的數據包發送給 RS。

• RS 響應（出站）：
  RS 解封裝隧道包，獲取原始請求（目標 IP 為 VIP），因自身已綁定 VIP，可直接處理請求。
  響應包以客戶端 IP 為目標、VIP 為源 IP，通過自身網絡直接返回客戶端，無需經過 LVS。

架構特點

• 跨網絡部署：LVS 與 RS 可位于不同子網、不同機房甚至跨公網（依賴隧道協議）。

• 流量分離：入站流量經隧道轉發，出站流量由 RS 直連客戶端。

• VIP 配置：LVS 和所有 RS 需綁定相同的 VIP（RS 綁定在隧道接口或回環接口）。

優缺點

• 優點：

  • 擴展性極強，支持跨地域集群（如多機房部署）。

  • 性能優于 NAT 模式（出站流量不經過 LVS）。

• 缺點：

  • 隧道封裝增加網絡開銷（約 20-40 字節 / 包），對高頻小數據包影響較明顯。

  • 需配置隧道協議（如 IPIP、GRE），RS 配置較復雜。

適用場景

• 跨地域分布式集群（如 CDN 節點、多區域云服務）。

• 突破子網限制的大規模集群（如跨數據中心負載均衡）。

4. Full-NAT 模式（Virtual Server via Full Network Address Translation）

核心原理

LVS 同時修改數據包的?源 IP 和目標 IP，實現「雙向地址轉換」，流程如下：

• 客戶端請求（入站）：
  客戶端向 VIP 發送請求，源 IP 為客戶端 IP，目標 IP 為 VIP。
  LVS 接收后，同時修改源 IP 和目標 IP：

  • 源 IP：客戶端 IP → LVS 的私有 IP（避免 RS 直接與客戶端通信）。

  • 目標 IP：VIP → RS 的私有 IP。
    然后將修改后的數據包轉發給 RS。

• RS 響應（出站）：
  RS 處理后，生成響應包，源 IP 為自身私有 IP，目標 IP 為 LVS 的私有 IP（因入站時源 IP 已被修改）。
  響應包回傳給 LVS 后，LVS 將源 IP 替換為 VIP，目標 IP 替換為客戶端 IP，再返回給客戶端。

架構特點

• 網絡靈活性：LVS 與 RS 無需同一子網，RS 的網關無需指向 LVS（只需能與 LVS 通信即可）。

• 雙向流量經過 LVS：因源 IP 被修改，RS 無法直接響應客戶端，必須經 LVS 轉發。

• 狀態跟蹤：LVS 需維護連接狀態表（記錄客戶端 IP 與 RS 的映射），確保響應包正確轉發。

優缺點

• 優點：

  • 網絡部署靈活，支持復雜拓撲（如 LVS 在公網、RS 在內網不同子網）。

  • 可隱藏客戶端真實 IP（RS 僅能看到 LVS 的私有 IP），安全性高于 DR/TUN 模式。

• 缺點：

  • LVS 處理所有雙向流量，性能低于 DR/TUN 模式，易成為瓶頸。

  • 需內核支持?ip_vs_fullnat?模塊（部分 Linux 發行版默認不啟用）。

適用場景

• 網絡架構復雜（LVS 與 RS 跨子網、跨 VLAN）。

• 需隱藏客戶端 IP（如防止 RS 被直接攻擊）。

• 無法使用 DR/TUN 模式的場景（如 RS 無法綁定 VIP）。

四種模式核心差異對比表

三、LVS中的13種調度算法

LVS（Linux Virtual Server）提供了多種調度算法，用于決定如何將客戶端請求分配給后端服務器（RS）。這些算法可分為靜態調度（不考慮服務器負載）和動態調度（基于服務器實時負載）兩類，共 13 種核心算法。以下是詳細解析：

1、靜態調度算法（不考慮服務器負載）

1.?輪詢（Round Robin, rr）

• 原理：按順序依次將請求分配給 RS，循環往復。

• 優點：實現簡單，適用于各 RS 性能相近的場景。

• 缺點：忽略服務器實際負載和處理能力差異，可能導致性能不均衡。

• 示例：有三臺RS：訪問順序為RS1 → RS2 → RS3 → RS1 → RS2 → RS3 → ...

2.?加權輪詢（Weighted Round Robin, wrr）

• 原理：根據 RS 的性能（如 CPU、內存、帶寬）分配權重，權重高的服務器接收更多請求。

• 公式：請求數分配比例 = 服務器權重 / 總權重。

• 優點：優化資源利用率，適合硬件配置差異較大的集群。

• 示例：根據權重，訪問RS1三次后，訪問RS2兩次，最后再訪問RS31次，然后就是重復以上訪問順序。RS1(3) → RS2(2) → RS3(1) → RS1(3) → RS2(2) → ...

3.?源地址哈希（Source Hashing, sh）

• 原理：根據客戶端 IP 地址計算哈希值，將同一 IP 的請求始終路由到固定 RS。

• 公式：RS = Hash (Client_IP) % 服務器數量。

• 優點：實現會話粘滯（Sticky Session），適合需保持會話狀態的服務（如購物車）。

• 缺點：可能導致負載分布不均（如大量請求來自同一 IP 段）。

4.?目標地址哈希（Destination Hashing, dh）

• 原理：根據請求的目標 IP（如 VIP）或端口計算哈希值，固定路由到同一 RS。

• 適用場景：內容分發網絡（CDN）、反向代理緩存（如緩存服務器集群）。

• 區別：與源地址哈希的方向相反，常用于服務器間負載均衡。

5.?IP 鏈（IP Link, ipip）

• 原理：基于 IP 地址的前綴匹配，將特定 IP 段的請求路由到指定 RS。

• 配置：需手動指定 IP 段與 RS 的映射關系。

• 示例：

  plaintext

  192.168.1.0/24 → RS1  
  192.168.2.0/24 → RS2  
  

6.?通用哈希（Generic Hashing, gh）

• 原理：允許用戶自定義哈希函數，基于任意請求參數（如 URL、HTTP 頭）進行調度。

• 優點：靈活性高，適合特殊業務需求（如按 URL 路徑分流）。

• 實現：需通過內核模塊或自定義代碼擴展。

2、動態調度算法（基于服務器負載）

7.?最小連接（Least Connections, lc）

• 原理：優先將請求分配給當前活躍連接數最少的 RS。

• 公式：選擇?Active_Connections / Weight?值最小的服務器。

• 優點：自動平衡負載，適合長連接服務（如數據庫、SSH）。

• 缺點：對短連接服務（如 HTTP）效果有限。

8.?加權最小連接（Weighted Least Connections, wlc）

• 原理：在最小連接基礎上，考慮服務器權重（權重高的服務器可承受更多連接）。

• 公式：選擇?Active_Connections / Weight?值最小的服務器。

• 示例：RS1 (權重 5) 當前 50 連接，RS2 (權重 1) 當前 10 連接，則優先分配給 RS2（50/5 > 10/1）。

9.?基于局部性的最小連接（Locality-Based Least Connections, lblc）

• 原理：結合源地址哈希和最小連接算法：

  • 優先將同一 IP 的請求路由到上次處理的 RS（會話粘滯）。

  • 若該 RS 過載（連接數超過閾值），則分配給連接數最少的 RS。

• 適用場景：緩存集群（如 Redis），減少緩存失效。

10.?帶復制的基于局部性的最小連接（Locality-Based Least Connections with Replication, lblcr）

• 原理：在 lblc 基礎上，增加 “復制” 機制：

  • 當請求頻繁訪問某 RS 時，將該 RS 的內容復制到其他服務器（降低單點負載）。

• 適用場景：內容分發網絡（CDN），通過復制熱點內容提升響應速度。

11.?目標地址哈希的最小連接（Destination Hashing with Least Connections, dh-lc）

• 原理：結合目標地址哈希和最小連接算法：

  • 先按目標 IP 哈希選擇候選 RS 列表。

  • 再從候選列表中選擇連接數最少的 RS。

• 適用場景：負載均衡器后端連接多個上游服務器（如反向代理）。

12.?最短預期延遲（Shortest Expected Delay, sed）

• 原理：計算每個 RS 的預期處理延遲，選擇延遲最小的服務器。

• 公式：預期延遲 = (Active_Connections + 1) / Weight。

• 特點：相比 wlc，更傾向于分配請求給輕載服務器（避免重載服務器持續過載）。

13.?最少隊列調度（Never Queue, nq）

• 原理：若有服務器處于空閑狀態（連接數為 0），直接分配；否則使用 sed 算法。

• 優點：避免請求排隊，適合對響應時間敏感的服務。

3、內核 4.15 版本后的新增調度算法

1. 加權故障轉移（Weighted Fail Over, FO）

原理：遍歷虛擬服務關聯的真實服務器（RS）鏈表，優先選擇未過載且權重最高的 RS 進行調度。當 RS 被標記為 “過載”（通過設置IP_VS_DEST_F_OVERLOAD標志）時，調度器會自動跳過該 RS，將請求轉發至其他符合條件的 RS。

優點：

• 支持通過 “過載標記” 主動剔除故障或負載過高的節點，提高集群穩定性。

• 權重機制可優先調度性能更強的 RS（權重高的節點優先處理請求），資源利用率更合理。

• 適合灰度發布場景：可通過調整權重或標記過載，逐步將流量切換到新節點。

缺點：

• 依賴人工或外部監控系統標記 “過載” 狀態，若標記不及時可能導致請求分配不合理。

• 未考慮 RS 實時連接數等動態負載，僅通過權重和過載狀態調度，可能在高負載時不夠靈活。

適用場景：

• 灰度發布、A/B 測試（通過權重控制流量比例）。

• 需要手動干預節點狀態的場景（如臨時下線維護）。

• 對節點故障敏感的服務（快速剔除異常節點）。

2. 溢出連接（Overflow-connection, OVF）

原理：基于 RS 的權重值和當前活動連接數調度，優先選擇權重最高的 RS，直到其活動連接數超過權重值（即 “溢出”），再依次調度下一個權重最高的 RS。判斷條件為：

• RS 未過載（未設置IP_VS_DEST_F_OVERLOAD標志）。

• 活動連接數 < 權重值（權重值不為 0）。

優點：

• 自動根據 RS 的承載能力（權重）分配連接，避免單一節點負載過高（活動連接數不超過權重上限）。

• 權重機制確保性能強的 RS（高權重）能處理更多連接，資源分配更均衡。

• 無需復雜的負載計算，調度邏輯簡單，性能開銷低。

缺點：

• 僅依賴活動連接數和權重，未考慮非活動連接等其他負載指標，對長連接場景的適應性有限。

• 若所有高權重 RS 均 “溢出”，低權重 RS 可能因突然承接大量請求而壓力驟增。

適用場景：

• 短連接服務（如 Web 服務），活動連接數能較好反映負載狀態。

• 對調度效率要求高、節點性能差異明顯的集群。

• 需要限制單節點最大連接數的場景（通過權重控制上限）。

四、ipvsadm命令

ipvsadm的操作類型參數

用于指定要執行的操作（必選）：

ipvsadm的服務類型參數

用于指定虛擬服務的協議類型（配合?-A、-D、-L?等使用）：

ipvsadm的負載均衡算法參數

通過?-s?指定調度算法（添加虛擬服務時使用）：

ipvsadm的工作模式參數

通過?-m、-g、-i?指定后端服務器的工作模式（添加 Real Server 時使用）：

ipvsadm的其他常用參數

核心功能:

? ? ? ? 1、集群服務管理：增、刪、改。????????對應下面的定義虛擬服務（Virtual Service）--- 即管理集群服務。

? ? ? ? 2、集群服務的RS管理：增、刪、改。? ? ? ? 對應下面的添加 / 刪除后端服務器（Real Server）--- 即管理集群服務中的Real Server服務器。

? ? ? ? 3、查看配置

1、負載均衡配置

1. 定義虛擬服務（Virtual Service）

創建對外提供服務的虛擬 IP（VIP）和端口，并指定負載均衡算法：

# 添加 TCP 虛擬服務（VIP:192.168.1.100，端口:80，輪詢算法）
ipvsadm -A -t 192.168.1.100:80 -s rr# 添加 UDP 虛擬服務（如 DNS 負載均衡）
ipvsadm -A -u 192.168.1.100:53 -s wrr  # 加權輪詢

2. 添加 / 刪除后端服務器（Real Server）

將實際提供服務的服務器加入或移出負載均衡池：

# 添加后端服務器（-m: NAT 模式；-g: DR 模式；-i: TUN 模式）
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.101:80 -m -w 1  # 權重為 1# 刪除后端服務器
ipvsadm -d -t 192.168.1.100:80 -r 192.168.1.101:80

2、負載均衡算法及其適用場景

通過?-s?參數指定調度算法，支持多種策略：

3、工作模式配置

通過?-m、-g、-i?參數指定工作模式：

4、查看與管理

1. 顯示當前配置

ipvsadm -L -n  # 查看所有虛擬服務和后端服務器（數字形式顯示 IP:Port）
ipvsadm -L -n -c  # 查看當前連接和統計信息
ipvsadm -L -t 192.168.1.100:80  # 查看特定虛擬服務的配置

2. 清空統計信息

ipvsadm -Z  # 重置所有服務和服務器的連接計數器和流量統計

3. 持久化配置

ipvsadm-save > /etc/sysconfig/ipvsadm  # 保存當前配置到文件
ipvsadm-restore < /etc/sysconfig/ipvsadm  # 從文件恢復配置

5、高級功能

1. 會話保持（Persistence）

讓同一客戶端的請求始終被轉發到同一服務器：

# 設置 3600 秒的會話保持時間
ipvsadm -A -t 192.168.1.100:80 -s rr -p 3600

2. 健康檢查

結合外部監控工具（如 keepalived）自動檢測服務器狀態，失效時自動移除：

# 配置 keepalived 監控 RS 狀態（示例片段）
real_server 192.168.1.101 80 {weight 1SSL_GET {url { path /healthcheck }url { path / }connect_timeout 3retry 3delay_before_retry 3}
}

五、部署NAT模式的LVS集群示例?

LVS NAT 模式

• 工作層級：第 3 層（網絡層）

• 原因：
  NAT 模式中，負載均衡器需要對數據包的?源 IP 和目標 IP 進行修改（網絡層操作）。

  • 客戶端請求到達負載均衡器時，目標 IP 被修改為后端服務器的私有 IP；

  • 后端服務器響應時，源 IP 被修改為負載均衡器的公網 IP，再返回給客戶端。
    整個過程僅涉及 IP 地址的轉換，不處理端口（傳輸層）或應用層數據，因此工作在網絡層。

注意：如果有類似下圖的錯誤，可能是防火墻沒有關閉，可以使用 systemctl disable --now firewalld.service 這條命令關閉防火墻后再試。

1、在lvs調度機中開啟內核路由功能

2、在lvs調度機中安裝ipvsadm

ipvsadm?是 Linux 系統中用于管理?IP 虛擬服務器（IP Virtual Server，IPVS）?的工具，它是 LVS（Linux Virtual Server）項目的核心組件。IPVS 是 Linux 內核的一部分，提供高性能的負載均衡功能，常用于構建大規模、高可用的服務器集群。

3、在lvs調度機中添加調度策略

4、查看添加的調度策略

[root@lvs 桌面]# watch -n1 ipvsadm -Ln  #可以使用這條命令監視調度策略的改動

5、測試：使用client主機循環訪問lvs調度機六次之后，再查看調度策略中連接數的改變

6、保存調度策略

7、刪除所有調度策略

8、重新加載調度策略

9、以上操作均為臨時的重新加載調度策略的操作，如果想要讓ipvsadm開機啟動時自動加載策略

需要設置此服務開機自啟動，而且需要/etc/sysconfig/ipvsadm?文件存在。

因為在大多數 Linux 發行版中，ipvsadm?服務的默認配置通常會加載?/etc/sysconfig/ipvsadm（或類似路徑）中的規則。例如：

CentOS/RHEL 系統：
ipvsadm?服務腳本默認讀取?/etc/sysconfig/ipvsadm?文件：

# 服務腳本片段（通常位于 /usr/lib/systemd/system/ipvsadm.service）
ExecStart=/sbin/ipvsadm-restore < /etc/sysconfig/ipvsadm

Ubuntu/Debian 系統：
可能使用不同的路徑（如?/etc/ipvsadm.rules），需檢查服務配置。

測試：

重啟后發現調度策略仍然存在，說明設置成功

10、再次測試：修改為權重調用算法后，修改real server的權重，然后再次測試

因為我們上面的示例用的就是權重調用算法，所以可以不需要修改策略的算法，只需要修改real server的權重來進行測試。

修改權重后進行測試：

此結果說明權重調用算法和real server的權重修改成功。

六、部署DR模式的LVS集群示例

?LVS DR 模式

• 工作層級：第 2 層（數據鏈路層）

• 原因：
  DR 模式中，負載均衡器僅修改數據包的?目標 MAC 地址（數據鏈路層操作），不改變 IP 地址。

  • 客戶端請求的目標 IP 始終是 VIP（負載均衡器和后端服務器共享的虛擬 IP）；

  • 負載均衡器通過修改 MAC 地址，將數據包轉發到選定的后端服務器；

  • 后端服務器直接使用 VIP 作為源 IP 響應客戶端，無需經過負載均衡器。
    由于核心操作是 MAC 地址的替換，因此工作在數據鏈路層。

1、配置好網絡環境，確保主機能互通（具體配置看第一大點的實驗環境）

2、在router主機中的防火墻中啟用 IP 偽裝（Masquerading）功能，實現網絡地址轉換（NAT）。

3、DR模式中需要在LVS集群的各主機上均需要配置VIP，所以我們需要解決地址沖突。

在 LVS 的 DR 模式（Direct Routing）中，VIP（虛擬 IP）需要同時配置在?負載均衡器（Director）?和?所有后端服務器（Real Server）?上，但為了避免 ARP 地址沖突（多個設備響應同一個 VIP 的 ARP 請求），需要通過特殊配置確保：

1. 只有負載均衡器響應 VIP 的 ARP 請求。

2. 后端服務器靜默處理 VIP，不響應 ARP 請求。

解決方案：ARP 抑制配置

參數作用詳解

通過調整內核參數?arp_ignore?和?arp_announce?來控制 ARP 響應行為：

1. 后端服務器配置（關鍵！）

在每個?后端服務器（Real Server）?上添加以下配置：

# 永久生效，直接寫入文件
echo net.ipv4.conf.all.arp_ignore = 1 >> /etc/sysctl.conf
echo net.ipv4.conf.all.arp_announce = 2 >> /etc/sysctl.conf
echo net.ipv4.conf.lo.arp_ignore = 1 >> /etc/sysctl.conf
echo net.ipv4.conf.lo.arp_announce = 2 >> /etc/sysctl.conf# 應用配置
sysctl -p 

為什么需要同時配置?all?和?lo？

all 的作用范圍是所有網絡接口。

lo 的作用范圍是僅針對回環接口?lo。

在 LVS DR 模式中：

1. VIP 配置在后端服務器的?lo?接口，但流量實際通過?eth0?收發。

2. all?配置：防止所有接口（包括?eth0）響應 VIP 的 ARP 請求。

3. lo?配置：進一步強化對回環接口的控制，確保 VIP 的 ARP 響應只由負載均衡器發出。

這里在兩個后端服務器RS1和RS2上都要進行配置?

2. 負載均衡器配置

在?負載均衡器（Director）?上，通常只需將 VIP 配置在物理網卡（如?eth0）上，無需特殊 ARP 參數。但若 VIP 也配置在回環接口（lo），則需確保：

net.ipv4.conf.lo.arp_ignore = 0  # 允許回環接口響應 VIP 的 ARP
net.ipv4.conf.lo.arp_announce = 0  # 允許使用物理網卡的 MAC 響應

4、在負載均衡器上進行lvs調度策略的編寫

5、測試：

七、TUN模式的LVS集群（只做了解）

LVS（Linux Virtual Server）的?TUN 模式（IP Tunneling）?是一種高性能的負載均衡實現方式，通過 IP 隧道技術將負載均衡器和后端服務器連接起來。

1、核心原理：

1. 工作機制：

   • 負載均衡器（Director）接收客戶端請求后，不修改原數據包，而是將其封裝在一個新的 IP 包中（外層 IP 為 Director 和 Real Server 的 IP），通過隧道發送給后端服務器。

   • 后端服務器（Real Server）解封裝后處理請求，并直接將響應返回給客戶端（無需經過 Director）。

2. 關鍵特點：

   • 網絡層封裝：使用 IPIP 協議（IP 協議號 4）或 GRE（Generic Routing Encapsulation）進行數據包封裝。

   • 跨地域部署：Director 和 Real Server 可以位于不同網絡，只需路由可達。

   • 高性能：請求和響應路徑分離，Director 僅處理入站流量，避免成為瓶頸。

2、優缺點與適用場景

優點：

• 高性能：Director 僅處理請求，響應直接返回客戶端，吞吐量高。

• 跨地域部署：支持將后端服務器分布在不同地理位置。

• 擴展性強：可輕松添加或移除后端服務器，不影響服務。

缺點：

• 配置復雜：需在所有服務器上配置隧道，維護成本高。

• 依賴 IPIP 協議：部分網絡環境可能封禁 IPIP 協議（IP 協議號 4）。

• 故障排查困難：隧道封裝可能導致數據包追蹤復雜。

適用場景：

• 大規模負載均衡集群（如電商平臺、CDN）。

• 跨數據中心部署的高可用服務。

• 需卸載 Director 壓力的高并發場景。

八、FullNAT模式的LVS集群（只做了解）

FullNAT 是 LVS 的一種特殊負載均衡模式，由華為對 Linux 內核進行擴展實現（最早在 2.6.32 內核中引入）。它通過同時修改請求的源 IP 和目標 IP，突破了傳統 DR 模式的網絡限制，允許后端服務器（Real Server）部署在任意網絡中。

1、核心原理：

1. 工作機制

• 請求路徑：
  客戶端 → Director（修改源 IP 為 Director 的內網 IP，目標 IP 為 RS 的內網 IP）→ RS

• 響應路徑：
  RS → Director（修改源 IP 為 VIP，目標 IP 為客戶端 IP）→ 客戶端

2. 關鍵特性

• 雙向 NAT：同時修改請求和響應的源 / 目標 IP，實現跨網段負載均衡。

• 對稱路徑：請求和響應必須經過 Director，保證連接跟蹤一致性。

• 解除網絡限制：RS 可以部署在任意網絡（如私有云、公有云），只需與 Director 路由可達。

2、優缺點與適用場景

優點

• 網絡靈活性：突破 DR 模式的同網段限制，支持混合云部署。

• 部署簡單：RS 無需配置 VIP 和復雜的 ARP 參數。

• 故障隔離：Director 可作為網絡邊界，增強安全性。

缺點

• Director 負載較高：需處理雙向流量，吞吐量低于 DR/TUN 模式。

• 內核依賴：非標準內核模塊，需特殊編譯或使用華為內核。

• 連接跟蹤限制：依賴內核連接跟蹤表，大規模集群需優化內存。

適用場景

• 混合云架構：后端服務器分布在公有云與私有云。

• 數據中心互聯：跨地域數據中心的負載均衡。

• 網絡架構復雜：無法滿足 DR 模式同網段要求的場景。

九、添加防火墻標簽解決輪詢錯誤的問題

注：此實驗的實驗環境為上面DR模式的實驗環境。

1、輪詢規則中可能會遇到的錯誤

以?HTTP?和?HTTPS?為例，當我們在RS中同時開放80和443端口，那么默認控制是分開輪詢的，這樣我們就出現了一個輪詢錯亂的問題。

當我第一次訪問80被輪詢到RS1后下次訪問443仍然可能會被輪詢到RS1上。

在RS1和RS2中安裝mod_ssl并重啟apache。

添加如下的LVS策略：

測試發現兩次訪問都輪詢到了同一個real server。

未做標記時：兩個獨立虛擬服務的 RR 可能 “同步”

關鍵點在于：

• 每個虛擬服務（80 和 443）獨立維護自己的 RR 計數器。

• 若客戶端的 80 和 443 請求幾乎同時到達，兩個虛擬服務的 RR 計數器可能恰好處于相同狀態（例如都指向 RS1）。

例如：

1. 客戶端首次訪問 80 端口時，VS1 的 RR 計數器指向 RS1，請求被轉發到 RS1。

2. 緊接著客戶端訪問 443 端口，此時 VS2 的 RR 計數器也指向 RS1（因初始狀態相同），請求也被轉發到 RS1。

這種 “巧合” 會讓您誤以為 “同一客戶端的請求總被分到同一 RS”，但實際上只是 RR 計數器同步的結果。若兩個請求的時間間隔較長，或中間有其他客戶端的請求插入，RR 計數器可能錯開，導致同一客戶端的請求被分到不同 RS。

2、使用防火墻標記來解決輪詢調度問題

FWM:FireWall Mark。

MARK target 可用于給特定的報文打標記, --set-mark value。

其中:value 可為0xffff格式，表示十六進制數字借助于防火墻標記來分類報文，而后基于標記定義集群服 務:可將多個不同的應用使用同一個集群服務進行調度。

如何實現防火墻標記：

命令：iptables -t mangle -A PREROUTING -d $vip -p $proto -m multiport --dports
$portl,$port2,..-j MARK --set-mark NUMBER#它的作用是：對發往特定 VIP（虛擬 IP）和端口的流量打標記（MARK），以便后續基于標記進行路由或調度。關鍵參數說明
-t mangle：使用 mangle 表，該表專門用于修改數據包元數據（如 TOS、MARK）。
-A PREROUTING：將規則添加到 PREROUTING 鏈，該鏈在路由決策前處理數據包。
-d $vip：目標地址為變量 $vip（通常是 LVS 的虛擬 IP）。
-p $proto：協議類型（如 tcp 或 udp）。
-m multiport --dports $port1,$port2,...：匹配多個目標端口（如 80,443）。
-j MARK --set-mark NUMBER：給匹配的數據包打標記（NUMBER 是 0-4294967295 之間的整數）。

命令：ipvsadm -A -f NUMBER [options] 這是 LVS (Linux Virtual Server) 中用于創建基于防火墻標記 (firewall mark) 的虛擬服務器的命令。
這種方式允許您根據 iptables 標記的流量來調度請求，而不是傳統的 IP 地址和端口。關鍵參數說明
除了 -f NUMBER，常用的選項包括：
-s scheduler      # 指定調度算法 (rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq)
-p [timeout]      # 持久連接的超時時間 (秒)
-M netmask        # 持久連接的子網掩碼

命令：ipvsadm-A|E -t|u|f service-address[-s scheduler] [-p [timeout]]默認360秒參數分組：操作類型：-A：添加新的虛擬服務（Add）-E：編輯已存在的虛擬服務（Edit）服務類型：-t：TCP 服務（如 HTTP、HTTPS）-u：UDP 服務（如 DNS、NTP）-f：基于防火墻標記（Firewall Mark）的服務（您之前配置的就是這種）服務地址：對于 -t 和 -u：格式為 IP:Port（如 192.168.0.220:80）對于 -f：格式為標記值（如 6666）調度算法：-s scheduler：指定負載均衡算法（默認是 wlc，即加權最小連接數）常用值：rr（輪詢）、wrr（加權輪詢）、lc（最小連接數）、sh（源地址哈希）等持久連接：-p [timeout]：啟用會話保持（默認超時時間 360 秒，即 6 分鐘）若省略 timeout，則默認使用 360 秒

LVS工作模式的總結對比