負載均衡器的誕生和工作機制

前言

今天我們來深度揭秘一下負載均衡器 LVS 的秘密，相信大家看了你管這破玩意兒叫負載均衡?這篇文章后，還是有不少疑問，比如 LVS 看起來只有類似路由器的轉發功能，為啥說它是四層（傳輸層）負載均衡器呢，今天我們就來逐漸揭開 LVS 的迷霧，本文將會用圖解的方式淺入深地探討 LVS 的工作機制

負載均衡器的誕生

在很長一段時間內小章公司的 DAU（日活）不超過 10，所以他只部署了一臺機器，畢竟多一臺機器要加錢，而且就算掛了也影響不了幾個用戶

但無意間小章的業務踩中了風口，業務量暴漲，dau 達到了好幾萬，眼看就要突破十萬，小章慌了，趕緊全面升級了這臺機器的內存，CPU 等配置，暫時扛過去了，但小章明白，單機性能無論怎么升都會遇到瓶頸，所以小章想了個辦法，多部署幾臺機器，將流量平均分配到這幾臺機器上

怎么分配呢，最簡單的方式，當然是用 DNS 負載均衡，在域名解析服務器上設置負載均衡策略，讓流量隨機打到其中某臺機器上

但這個方案有以下兩個明顯的問題：

占用過多公網 IP，要知道現在租一個公網 IP 可是要好幾千

DNS 緩存可能會引起致命故障

第一個問題加錢就能解決，但第二個問題可不是加錢就能解決的了，因為眾所周知 DNS 解析是迭代或遞歸查詢，需要經過 根 DNS 服務器 ->頂級DNS服務器->權威DNS服務器這三步查找才能解析到域名對應的 ip，可想可知這個解析是有多么耗時，所以一般會有 DNS 緩存，DNS 緩存主要有「瀏覽器緩存」,「操作系統緩存」,「路由器緩存」,「ISP 緩存」四種

每次發起一個域名解析請求，都會依次在以上四個緩存里查找，如果命中緩存，則直接返回此域名對應的 IP，其中像 Chrome 緩存 1 分鐘， ISP 緩存可能高達 1~2 個小時，于是問題就來了，如果某臺機器宕機，但由于以上四個緩存中依然可能會有此域名的 IP 緩存，對請求方而言，是感知不到的，那么只要緩存未過期請求方就會持續地將將流量打到這臺掛掉的機器，引起線上故障，這當然是不能容忍的。

那該怎么辦呢，小章突然想起了計算機界的一個經典名言：「沒有什么是加一層解決不了的問題，如果有，那就再多加一層」，何不在 DNS 與 server 間多加一層，負載均衡的工作讓這個中間層來做，小章想了下腦海中浮現出了以下架構圖

可以看到這個負載均衡器（以下簡稱 LB）有以下特點

對外用公網 ip（以下我們簡稱 VIP） 承接所有流量，對內則與真實的服務器（即 Real Server，以下簡稱 RS）通信，與 RS 在同一個內網里

LB 只負載轉發請求的工作，實際的處理邏輯交由其背后的 RS，RS 處理完后將響應包發給 LB，然后 LB 再返回給 client

于是網絡拓撲圖改進如下

NAT

接下來的重點就是 LB 是如何工作的了，首先要明白，當我們說收到一個請求時，實際上收到的是一個數據包，那么這個數據包長啥樣呢

源IP,目的IP，源端口，目的端口，簡稱 TCP 四元組，四元組唯一確定一條鏈接，在傳輸過程中四元組是不會變的，現在 LB 收到這個數據包之后，想將其轉發給其背后的服務器，就要把目的 IP 改成服務器的 IP（假設為第二臺機器，其 IP 地址為 192.168.0.3），那么修改后的數據包如下

當 RS 處理好后，由于這個數據包還要經過 LB 再轉發給客戶端，所以服務器的網關要設置為 LB 的內網 IP（即 192.168.0.1）再將數據包出去，LB 就能收到所有的響應數據包了。

此時的數據包如下

為什么 RS 的響應包要經過 LB 呢，因為為了保證四元組不變，LB 收到數據包后要將源 IP 改為 VIP，客戶端才會識別到這是對之前請求的正確響應

畫外音:客戶端請求與響應包的四元組不能變

修改后的數據包

所以總結一下 LB 的主要工作機制：主要是修改了進出數據包的 IP，首先修改目的 IP 為其 RS 的 IP，將包傳給 RS 處理，RS 處理完后再將包發給網關（LB），LB 再修改源 IP 為其出口的 VIP，只要四元組不變，那么客戶端就能正常地收到其請求的響應，為了讓大家更直觀地感受負載均衡的對 IP 的修改，我做了一張動圖，相信大家看了理解會更深刻

從客戶端的角度來看，它以為其與 LB 背后的 RS 通信，但實際上它只是與 LB 通信，LB 只是起到了一個虛擬服務器的作用，所以我們給它命名為 LVS（Linux Virtual Server），LVS 只是起到了修改 IP 地址并且轉發數據包的功能而已，由于它在數據包的進出過程中都修改了 IP 地址，我們稱這模式為 NAT（Network Address Translation，網絡地址轉換） 模式，可以看到這種工作模式下，網絡請求包和網絡響應包都要經過 LVS

看到這問題似乎已經完美解決了，但是我們忽略了一個問題：每個網絡數據包都是有大小限制的。如下圖示，在每個數據包中，每個 payload（一般為應用層數據）大小一般不能超過 1460 byte

也就是說如果在客戶端的請求數據（比如 HTTP 請求過大）超過了 1460 個字節，就要分包傳，服務端收到所有分包后再組裝成完整的應用層數據，那么顯然，LVS 應該把同一個請求（即四元組相同）的分包轉發給同一個 RS，不然把分包傳給不同的 RS，數據就不完整了。所以 LVS 要根據四元組來記錄包應該轉發給哪一個 RS，四元組一樣的數據包都轉發給同一個 RS。

四元組的 IP 是在 IP Header 中，而端口號在 TCP Header 中，這意味著 LVS 需要卸下 TCP Header 拿到端口號，然后根據四元組是否相同再決定是否轉發到同一臺 RS 上，四元組對應一個 TCP 連接，也就是說 LVS 具有記錄連接的功能，而連接是傳輸層的概念。至此相信你明白開頭的一個問題：「LVS 起到了轉發包的功能，為什么說它是四層負載均衡」

DR

經過這樣的設計，由于 LVS 負載均衡的作用，輕松解決了單機瓶頸，小章的公司順利度過了 C10K（并發連接 1 萬），C20K，。。。。的問題，度過了瓶頸期，但隨著并發數越來越高，小章發現了一個大問題，LVS 逐漸扛不住了，因為所有數據包的進出都要經過它，這讓它成為了很大的瓶頸，隨著 RS 水平擴展數量越來越多， LVS 遲早要掛掉。能否讓 LVS 只負責轉發請求包，但響應的數據包直接經由 RS 返回給客戶端呢，類似下面這樣

畫外音：紅色虛線為數據包的流轉流程，可以看到響應數據包不經過 LVS

這樣的話響應包就不用經過 LVS 了，LVS 的負載壓力自然釋放了，我們把這種模式稱為 DR（Direct Router，直接路由）模式

方案有了，那么怎么實現呢？這個設計方案有兩個注意點

首先 LVS 還是要承載所有的請求流量（接收所有數據包），然后再根據負載均衡算法轉發給 RS

RS 處理完后是不經過 LVS，直接將數據包轉發給路由器再發給客戶端的，意味著 RS 必須要有與 LVS 同樣的 VIP（四元組不能變），另外由以上拓撲圖可知，它們也必須在同一個子網里（嚴格地說，應該是同一個 vlan，因為是通過交換機通信的），這就意味著 LVS 和 RS 都必須要有兩個 IP，一個 VIP，一個子網 IP

那么一臺主機如何才能有兩個 IP 呢？

我們知道計算機要上網，首先要把網線插入網卡，一個網卡其實就對應著一個 IP，所以一臺主機配兩個網卡就有兩個 IP ，但多數人不知道的是一個網卡是可以配置多個 IP 的，另外網卡一般分兩種，一種是物理網卡，一種是虛擬網卡

物理網卡：可以插網線的網卡，如果有多個網卡，我們一般將其命名為 eth0，eth1。。。，如果一個網卡對應多個 IP，以 eth0 為例，一般將其命名為 eth0，eth0:0，eth0:1。。。eth0:x，比如一臺機器只有一個網卡，但其對應兩個 IP 192.168.1.2, 192.168.1.3，那么其綁定的網卡名稱分別為 eth0,eth0:0

虛擬網卡：虛擬網卡通常被稱為 loopback，一般命名為 lo，是一個特殊的網絡接口，主要用于本機中各個應用之間的網絡交互（哪怕網線拔了，本機各個應用之間通過 lo 也是能通信的），需要注意的是虛擬網卡和物理網卡一樣，也可以綁定任意 IP 地址，如果在虛擬網卡配置了任何的 IP 地址，只要有物理網卡，就能到收到并處理目的 IP 為虛擬網卡上 IP 的數據包，lo 默認綁定了 127.0.0.1 這個本地 IP ，如果要綁定其他的 IP，對應的網卡命名一般為 lo:0，lo:1。。。

畫外音：一般服務器包括 LVS 是以雙網卡的形式存在的，一來每個網卡帶寬都是有限的，雙網卡相當于提升了一倍的帶寬，二來兩個網卡也起到了熱備的作用，如果一個網卡壞了，另外一個可以頂上。

理解了以上知識點，我們可以將拓撲圖完善如下

你可能注意到了 RS 的 VIP 是綁定在 lo:0 虛擬網卡上而不是物理網卡上，這是為什么呢，主要是為了保證請求都打到 LVS 上。

1. arp_ignore=1

首先我們知道 LVS 和 RS 都位于同一個子網，我們需要了解一下子網的工作機制：子網一般稱為以太網，主要用 mac 地址來通信，位于 ISO 模型的二層，一開始內網的機器互相不知道彼此的 mac 地址，需要通過 arp 機制來根據 IP 獲取其對應的 mac，獲取之后首先會在本地的 arp 表記錄此 IP 對應的 mac（下次就直接在本地緩存查找 mac），然后會在包頭上附上 IP 對應的 mac，再將包傳輸出去，交換機就會找到對應的機器了

所以當客戶端請求 VIP 后，請求到達了上圖中的路由器，路由器要轉發給此 IP 對應的機器，于是它首先發起了一個 arp 請求希望拿到 VIP 對應的 mac 地址。

那么現在問題來了，由于三臺機器的 IP 都為相同的 VIP，如果都響應了 arp 請求，就相當于一個 IP 對應了三個 mac，路由器該用誰的 mac 地址呢？

解決方案很簡單：由于請求都要經過 LVS，所以只讓 LVS 響應 arp，抑制住另外兩臺 RS 對 VIP 的 arp 響應即可，不過請求到達 LVS 后，LVS 還要將包轉發給 RS（假設為 RS2 吧），此時也要用到 arp 來獲取 RS 的 mac 地址，但是注意從 LVS 發起的 arp 請求目的 IP 變成了 RS2 的內網 IP：115.205.4.217（綁定在物理網卡 eth0 上）。

綜上所述， RS 不能響應目的 IP 為虛擬網卡綁定的 VIP 的 arp 請求，但能響應目的 IP 為物理網卡綁定的 IP 的 arp 請求，這就是為什么 RS 需要把 VIP 綁定在虛擬網卡上，而把內網 IP 綁定在物理網卡上的真實原因，就是為了 arp 響應的需要

當然一般服務器默認都會響應所有 IP 的 arp 響應，所以需要對 RS 做額外配置，即

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.lo.arp_ignore=1

設置的 arp_ignore=1 表示的含義如下

1-replyonlyifthetargetIPaddressislocaladdress
configuredontheincominginterface

即我們上述所說的，只響應目的 IP 為接收網卡（即物理網卡）上的 IP 的 arp 請求（會忽略目的 IP 為虛擬網卡 上 VIP 的 arp 請求）

作了以上的設置后由于針對 VIP 的 arp 請求只有 LVS 會響應（路由器收到 LVS 的 arp 響應后會在 arp 緩存表里記錄 VIP 的 mac 地址為 LVS 的mac），所以可以保證所有請求都會打到 LVS 上，然后 LVS 也順利地將數據包發給了 RS2，RS2 處理好后就準備把數據包從網卡發出了，但這里需要注意，RS2 可不能直接把數據包通過物理網卡 eth0 傳出去的，這樣會導致數據包的源 IP 被修改為 eth0 的 IP（即 115.205.4.217），會導致四元組發生變化（別問為什么，問就是協議棧的關系），所以我們需要額外配置一下，讓數據包使用 lo 接口發送，如下

routeadd-host115.205.4.214devlo:0
#添加一條路由，目標IP為VIP的數據包使用lo接口發送，這樣響應報文的源IP就會為VIP

然后再通過 eth0 發出去，這樣可保證四元組不會發生變化。

2. arp_announce=2

接下來還有一個問題，RS2 怎么將數據包傳給它的網關（即路由器）呢，由于它們還是在同一個子網，所以也是通過 arp 的方式先獲取到網關的 mac，然后在以太網包頭上裝上網關的 mac 傳給網關的。

但這里有一個點需要注意，通過 arp 獲取網關的 mac 時，網卡會發送一個包含「源IP」，「目標 IP」,「源 mac」的 arp 廣播包

通常情況下源 IP 可以選擇為數據包的源 IP，也可以選擇為物理網卡上的 IP，但在 DR 模式下這里的源 IP 只能選擇為物理網卡上 IP，這是為什么呢

我們知道目標 IP 是網關 IP，所以網關會響應這個 arp 請求，但同時網關在收到這個 arp 響應后也會在本地的 arp 表更新：源 IP => 源 mac 這一項，這里的源 mac 為 RS2 的 mac，還記得上文中路由器的 arp 緩存表已經保存了 LVS 的 VIP 與 LVS 的 mac 的對應關系了嗎，也就是說從 RS2 發出的 arp ，源 IP 如果是數據包的源 IP（即 VIP），網關收到 arp 后會在路由表更新 VIP 的 mac 地址為 RS2 的 mac 的地址！這樣下一次客戶端請求路由器就會直接把數據包轉發給 RS2 而不會經過 LVS！所以 RS2 要發 arp 獲取網關的 mac 時使用的源 IP 應該為其物理網卡（eth0）對應的 IP（即 115.205.4.217），這樣就避免了上述問題，與 arp_ignore=1 一樣，這一項也需要我們手動配置

net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.lo.arp_announce=2

arp_announce=2 表示的是忽略 IP 數據包的源 IP 地址，選擇該發送網卡上最合適的本地地址作為 arp 請求的源 IP 地址

上面這段有點繞，大家可以多讀幾遍好好體會一下，其實主要目的就是為了避免路由器的 ARP 緩存表誤更新 VIP 的 mac 為 RS 的 mac

從上面的介紹可以看出 DR 模式是比較復雜的，需要在 RS 上做額外的配置，所以線上一般使用 NAT 模式

FullNAT

但問題又來了，該怎么解決 NAT 模式下 LVS 的單點問題呢，畢竟所有進出流量都出入同一臺 LVS（因為 RS 的網關只有有一個），在 RS 不斷擴容下，單點 LVS 很可能成為巨大的隱患，而且 LVS 要作為所有 RS 的網關，意味著他們要在同一個網段下。

如果在阿里云這些公有云平臺上部署肯定不現實，因為在公有云上，很可能 RS 是分布在各地的，這就意味著要跨 vlan 來通信，而 NAT 顯然不符合要求，于是在 NAT 的基礎上又衍生出了 FullNAT，FullNAT 其實就是為了公有云而生的

FullNAT

NAT 模式下，LVS 只將數據包的目標 IP 改成了 RS 的 IP，而在 FullNAT 模式下，LVS 還會將源 IP 地址也改為 LVS 的內網 IP（修改 IP 主要由 LVS 的內核模塊 ip_vs 來操作），注意上圖 LVS 內網 IP 和 RS 的 IP 是可以在不同網段下的，通常在公有云平臺上，它們是部署在 intranet 即企業內網中的，這樣的話 LVS 就可以跨網段和 RS 通信了，也避免了 LVS 的單點瓶頸，多臺 LVS 都可以將請求轉發給 RS

如圖示，部署了兩臺 LVS，它們內網與 RS 的不在同一個網段，照樣能通信，部分讀者可能會注意到一個問題：LVS 轉發給 RS 的數據包源 IP（即客戶端 IP，client_ip）被替換成了內網 IP，這就意味著 RS 收到的數據包是不含有 client_ip 的，有時候 client_ip 對我們分析數據有很重要的作用（比如分析下單在不同地域分布情況就需要 client_ip），針對這種情況，LVS 會在收到請求包后在數據包的 TCP Header 中插入 client_ip

上圖就是是 TCP Header，client_ip 就是放在 tcp option 字段中的，然后 RS 上只要安裝了 TOA 模塊就能從中讀取 client_ip，TCP 的這個 option 的字段也提醒我們在做技術方案設計的時候適當的增加一些冗余字段能讓你的程序可擴展性更好。

總結

至此，相信大家已經明白了 LVS 的 NAT，DR ，FullNAT 的工作機制了，實際上 LVS 還有個 TUNNEL 隧道模式，只是生產上不怎么用，所以不做介紹，另外每個 LVS 一般會做雙機熱備，如下,備機通過定時發送心跳包能感受到 LVS 主機的存活，另外注意虛線部分，備機還可以感知到服務器的存活，如果服務器掛了， LVS 會將其剔除，保證 LVS 轉發的流量不會打到宕掉的機器上。

文中的小章就是章文嵩博士，1998 年他主導了 LVS 項目的開發，一開始只有 NAT,DR，TUNNEL 三種模式，但后來隨著阿里云云上服務的崛起，這三種模式都無法滿足實際的部署需要，所以他又指導其手下基于 NAT 來做改造誕生了 FullNAT，值得一提的是 LVS 是少數幾個國人開發并得到 Linux 官方認可的開源軟件，已集成進 Linux 內核，可見這一項目的巨大價值與貢獻

審核編輯：湯梓紅