20?張圖讓你徹底掌握負(fù)載均衡的秘密！

時間：2021-09-10 16:31:49

關(guān)鍵字：負(fù)載均衡

手機看文章

掃描二維碼
隨時隨地手機看文章

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

前言

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

最好大家對網(wǎng)絡(luò)是如何連接的，數(shù)據(jù)包的收發(fā)機制有所了解，這樣會很容易理解本文的知識點，如果對此沒概念，建議大家看看這篇文章，把網(wǎng)絡(luò)是如何連接的給你安排得明明白白

沒看過也沒關(guān)系，本文會對一些必要的知識點做些鋪墊，爭取讓大家都能看懂

負(fù)載均衡器的誕生

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

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

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

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

占用過多公網(wǎng) IP，要知道現(xiàn)在租一個公網(wǎng) IP 可是要好幾千
DNS 緩存可能會引起致命故障

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

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

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

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

對外用公網(wǎng) ip（以下我們簡稱 VIP）承接所有流量，對內(nèi)則與真實的服務(wù)器（即 Real Server，以下簡稱 RS）通信，與 RS 在同一個內(nèi)網(wǎng)里
LB 只負(fù)載轉(zhuǎn)發(fā)請求的工作，實際的處理邏輯交由其背后的 RS，RS 處理完后將響應(yīng)包發(fā)給 LB，然后 LB 再返回給 client

于是網(wǎng)絡(luò)拓?fù)鋱D改進(jìn)如下

NAT

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

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

當(dāng) RS 處理好后，由于這個數(shù)據(jù)包還要經(jīng)過 LB 再轉(zhuǎn)發(fā)給客戶端，所以服務(wù)器的網(wǎng)關(guān)要設(shè)置為 LB 的內(nèi)網(wǎng) IP（即 192.168.0.1）再將數(shù)據(jù)包出去，LB 就能收到所有的響應(yīng)數(shù)據(jù)包了。

此時的數(shù)據(jù)包如下

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

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

修改后的數(shù)據(jù)包

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

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

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

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

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

DR

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

畫外音：紅色虛線為數(shù)據(jù)包的流轉(zhuǎn)流程，可以看到響應(yīng)數(shù)據(jù)包不經(jīng)過 LVS

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

方案有了，那么怎么實現(xiàn)呢？這個設(shè)計方案有兩個注意點

首先 LVS 還是要承載所有的請求流量（接收所有數(shù)據(jù)包），然后再根據(jù)負(fù)載均衡算法轉(zhuǎn)發(fā)給 RS
RS 處理完后是不經(jīng)過 LVS，直接將數(shù)據(jù)包轉(zhuǎn)發(fā)給路由器再發(fā)給客戶端的，意味著 RS 必須要有與 LVS 同樣的 VIP（四元組不能變），另外由以上拓?fù)鋱D可知，它們也必須在同一個子網(wǎng)里（嚴(yán)格地說，應(yīng)該是同一個 ?vlan，因為是通過交換機通信的），這就意味著 LVS 和 RS 都必須要有兩個 IP，一個 VIP，一個子網(wǎng) IP

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

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

物理網(wǎng)卡：可以插網(wǎng)線的網(wǎng)卡，如果有多個網(wǎng)卡，我們一般將其命名為 eth0，eth1。。。，如果一個網(wǎng)卡對應(yīng)多個 IP，以 eth0 為例，一般將其命名為 eth0，eth0:0，eth0:1。。。eth0:x，比如一臺機器只有一個網(wǎng)卡，但其對應(yīng)兩個 IP 192.168.1.2, 192.168.1.3，那么其綁定的網(wǎng)卡名稱分別為 eth0,eth0:0
虛擬網(wǎng)卡：虛擬網(wǎng)卡通常被稱為 loopback，一般命名為 lo，是一個特殊的網(wǎng)絡(luò)接口，主要用于本機中各個應(yīng)用之間的網(wǎng)絡(luò)交互（哪怕網(wǎng)線拔了，本機各個應(yīng)用之間通過 lo 也是能通信的），需要注意的是虛擬網(wǎng)卡和物理網(wǎng)卡一樣，也可以綁定任意 IP 地址，如果在虛擬網(wǎng)卡配置了任何的 IP 地址，只要有物理網(wǎng)卡，就能到收到并處理目的 IP 為虛擬網(wǎng)卡上 IP 的數(shù)據(jù)包，lo 默認(rèn)綁定了 127.0.0.1 這個本地 IP ，如果要綁定其他的 IP，對應(yīng)的網(wǎng)卡命名一般為 lo:0，lo:1。。。

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

理解了以上知識點，我們可以將拓?fù)鋱D完善如下

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

1. arp_ignore=1

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

所以當(dāng)客戶端請求 VIP 后，請求到達(dá)了上圖中的路由器，路由器要轉(zhuǎn)發(fā)給此 IP 對應(yīng)的機器，于是它首先發(fā)起了一個 arp 請求希望拿到 VIP 對應(yīng)的 mac 地址。

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

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

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

當(dāng)然一般服務(wù)器默認(rèn)都會響應(yīng)所有 IP 的 arp 響應(yīng)，所以需要對 RS 做額外配置，即

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

設(shè)置的 arp_ignore=1 表示的含義如下

1?-?reply?only?if?the?target?IP?address?is?local?address
configured?on?the?incoming?interface

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

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

route?add?-host?115.205.4.214?dev?lo:0
#?添加一條路由，目標(biāo)?IP?為?VIP?的數(shù)據(jù)包使用?lo?接口發(fā)送，這樣響應(yīng)報文的源?IP?就會為?VIP

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

2. arp_announce=2

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

但這里有一個點需要注意，通過 arp 獲取網(wǎng)關(guān)的 mac 時，網(wǎng)卡會發(fā)送一個包含「源IP」，「目標(biāo) IP」,「源 mac」的 arp 廣播包

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

我們知道目標(biāo) IP 是網(wǎng)關(guān) IP，所以網(wǎng)關(guān)會響應(yīng)這個 arp 請求，但同時網(wǎng)關(guān)在收到這個 arp 響應(yīng)后也會在本地的 arp 表更新：源 IP => 源 mac 這一項，這里的源 mac 為 RS2 的 mac，還記得上文中路由器的 arp 緩存表已經(jīng)保存了 LVS 的 VIP 與 LVS 的 mac 的對應(yīng)關(guān)系了嗎，也就是說從 RS2 發(fā)出的 arp ，源 IP 如果是數(shù)據(jù)包的源 IP（即 VIP），網(wǎng)關(guān)收到 arp 后會在路由表更新 VIP 的 mac 地址為 RS2 的 mac 的地址！這樣下一次客戶端請求路由器就會直接把數(shù)據(jù)包轉(zhuǎn)發(fā)給 RS2 而不會經(jīng)過 LVS！所以 RS2 要發(fā) arp 獲取網(wǎng)關(guān)的 mac 時使用的源 IP 應(yīng)該為其物理網(wǎng)卡（eth0）對應(yīng)的 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 數(shù)據(jù)包的源 IP 地址，選擇該發(fā)送網(wǎng)卡上最合適的本地地址作為 arp 請求的源 IP 地址

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

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

FullNAT

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

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

FullNAT

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

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

上圖就是是 TCP Header，client_ip 就是放在 tcp option 字段中的，然后 RS 上只要安裝了 TOA 模塊就能從中讀取 client_ip，TCP 的這個 option 的字段也提醒我們在做技術(shù)方案設(shè)計的時候適當(dāng)?shù)脑黾右恍┤哂嘧侄文茏屇愕某绦蚩蓴U展性更好。

總結(jié)

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

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

- EOF -