前言

話說(shuō)之前大學(xué)放暑假的時(shí)候，我到一個(gè)餐廳打工兩個(gè)月，Title 是初級(jí)傳菜員。正是這次打工經(jīng)驗(yàn)，為我?guī)?lái)了一波潛藏已久的素材，請(qǐng)聽聽我的故事吧~

本文主要內(nèi)容如下：

一、餐廳角色

在餐廳主要有這幾種角色：

• 服務(wù)員：負(fù)責(zé)記錄客戶已點(diǎn)哪些菜、上菜時(shí)間、上菜、劃掉菜。可以將多個(gè)服務(wù)員都當(dāng)做客戶端，相對(duì)于傳菜員來(lái)說(shuō)。
• 傳菜員：負(fù)責(zé)通知廚房走菜、劃菜、傳菜。可以將傳菜員當(dāng)作 Keepalived 組件。
• 廚師：烹飪、裝盤。可以將廚師當(dāng)作后臺(tái)真實(shí)服務(wù)器。

為什么需要傳菜員這個(gè)角色？有了傳菜員這個(gè)角色后，發(fā)生了什么呢？

• 服務(wù)員需要服務(wù)顧客，不需要離開包間去廚房拿菜。（單一職責(zé)）
• 服務(wù)員不需要定期到廚房詢問(wèn)菜是否好了。（解耦）

流程圖如下：

① 客戶點(diǎn)菜下單。

② 服務(wù)員記錄菜名、上菜時(shí)間。這里的上菜時(shí)間是指客戶要求的上菜時(shí)間，因?yàn)橛行┛蛻艨赡芟氲扰笥岩黄饋?lái)了再吃。

③ 服務(wù)員將一份訂單交給傳菜員，另外一份訂單留在包間。

④ 傳菜員大聲通知多位廚師有哪些菜要做，什么時(shí)候開始上菜。

⑤ 廚師準(zhǔn)備食材和烹飪。如果缺少食材，廚師還會(huì)告訴傳菜員，由傳菜員轉(zhuǎn)告服務(wù)員說(shuō)這道菜不能做。

⑥ 廚師做好后將菜裝在盤子里，然后遞給傳菜員。

⑦ 傳菜員將訂單上對(duì)應(yīng)的菜劃掉，表示已經(jīng)做了。

⑧ 傳菜員將菜端給服務(wù)員。

⑨ 服務(wù)員將菜從訂單上劃掉。

⑩ 服務(wù)員將菜端上餐桌。

這個(gè)流程簡(jiǎn)單來(lái)說(shuō)就是客戶下單->服務(wù)員傳單->傳菜員通知->廚師烹飪->傳菜員傳菜->服務(wù)員上菜。

上面的流程不正是服務(wù)員請(qǐng)求數(shù)據(jù)，將請(qǐng)求都發(fā)給了傳菜員，傳菜員將請(qǐng)求轉(zhuǎn)發(fā)給了廚師，廚師處理完后返回結(jié)果。妙?。。?/p>

二、初探 Keepalived 的路由方案

2.1 為什么需要路由方案

上篇我們講到 Keepalived 的負(fù)載均衡調(diào)度算法，通過(guò)這個(gè)算法選出某臺(tái)真實(shí)服務(wù)來(lái)處理本次客戶端請(qǐng)求。

就好比傳菜員要將要做的菜，告訴其中一個(gè)廚師（一般是告訴大廚）。

而如何告訴廚師呢？是用??喇叭??喊，還是??傳呼機(jī)??，還是走到他旁邊告訴他？

服務(wù)員與廚師對(duì)話的方式

對(duì)于 Keepalived 來(lái)說(shuō)，選擇了一個(gè)真實(shí)服務(wù)器后，后續(xù)還有兩個(gè)流程需要梳理下：

• Keepalived 如何將請(qǐng)求轉(zhuǎn)發(fā)給這個(gè)服務(wù)呢？
• 服務(wù)處理完這個(gè)請(qǐng)求后，如何將處理結(jié)果返回給客戶端？

上面兩個(gè)流程就是 Keepalived 的路由方案要做的事。

Keepalived 有三種路由方案：NAT、TUN、DR。

2.2 配置在哪

具體的配置哪種路由方案在 keepalived.conf 配置文件中，其中有一個(gè) lb_kind 配置，可以配置成 NAT、DR、TUN 三種。目前配置的是 DR 模式。

還有一個(gè)配置 lb_algo，這個(gè)是配置調(diào)度算法的，比如這里配置的 wrr 加權(quán)輪詢調(diào)度算法。

2.3 LVS 的結(jié)構(gòu)

上篇我們說(shuō)到 Keepalived 是利用了 LVS 模塊的功能來(lái)實(shí)現(xiàn)負(fù)載均衡的。那么 LVS 的結(jié)構(gòu)是怎么樣的呢？

分為兩個(gè)模塊：前端的負(fù)載均衡器（Load Balance，簡(jiǎn)稱 LB），后端的多臺(tái)真實(shí)服務(wù)器（Real Server, 簡(jiǎn)稱 RS）組成。LB 負(fù)責(zé)流量轉(zhuǎn)發(fā)，RS 負(fù)責(zé)處理請(qǐng)求，然后將請(qǐng)求返回。

三、深入理解 Keepalived 的路由方案

3.1 NAT 路由方案

NAT 的全稱是 Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換。它有兩個(gè)功能：

• 使企業(yè)內(nèi)部的私有 IP 可以訪問(wèn)外網(wǎng)，
• 使外部用戶可以訪問(wèn)位于公司內(nèi)部的私有 IP 主機(jī)。

對(duì)于 Keepalived 來(lái)說(shuō)，這種模式就好比餐廳的標(biāo)準(zhǔn)下單上菜模式：多個(gè)服務(wù)員將訂單數(shù)據(jù)轉(zhuǎn)給傳菜員，傳菜員通知廚師進(jìn)行烹飪，廚師把菜做好后轉(zhuǎn)給傳菜員，傳菜員負(fù)責(zé)把菜傳遞給服務(wù)員。

如下圖所示，LVS 負(fù)載調(diào)度器有兩塊網(wǎng)卡，配置了不同的 IP 地址，網(wǎng)卡 eth0 設(shè)置為公網(wǎng) VIP 與外部網(wǎng)絡(luò)連通，網(wǎng)卡 eth1 設(shè)置為私有 VIP 與內(nèi)部網(wǎng)絡(luò)通過(guò)交換設(shè)備相互連接，

示例如下：

eth0 網(wǎng)卡 -> 公網(wǎng) VIP -> 外部網(wǎng)絡(luò)
eth1 網(wǎng)卡 -> 私有 VIP -> 交換設(shè)備 > 內(nèi)網(wǎng)網(wǎng)絡(luò)

原理圖如下所示：

① 比如現(xiàn)在 eth0 網(wǎng)卡配置了一個(gè)公有 VIP 如 10.1.2.88，客戶端發(fā)送的請(qǐng)求都是到這個(gè) Public VIP（目標(biāo)地址）。

② 主 LVS Router 負(fù)責(zé)接收請(qǐng)求，將請(qǐng)求的目的地址（Public VIP）替換成 NAT VIP（192.168.56.88）。

③ 這個(gè) NAT VIP 和后端服務(wù)器同屬一個(gè)局域網(wǎng)，可以相互訪問(wèn)，請(qǐng)求經(jīng)過(guò)負(fù)載均衡調(diào)度選擇一個(gè)真實(shí)服務(wù)器。

④ LVS 修改數(shù)據(jù)包中的目標(biāo)地址和目標(biāo)端口為真實(shí)服務(wù)器的。

⑤ 真實(shí)服務(wù)器處理完請(qǐng)求后，將應(yīng)答數(shù)據(jù)返回給 LVS Router。

⑥ LVS Router 將應(yīng)答數(shù)據(jù)的源 IP 地址 NAT VIP 和端口轉(zhuǎn)換成 Public VIP 和 LVS 的端口，然后轉(zhuǎn)發(fā)給外部網(wǎng)絡(luò)的客戶端。

對(duì)于客戶端而言，它只和 Public VIP 打交道，并不知道 NAT VIP，更不知道真實(shí)服務(wù)器的 IP 地址，這個(gè)過(guò)程也稱為 IP 偽裝。

對(duì)于服務(wù)員????來(lái)說(shuō)，她只和傳菜員打交道，并不知道廚師??????? 。

1.2 LVS-TUN 路由方案

1.2.1 NAT 方案的瓶頸

如果餐廳的生意非?；鸨?，一個(gè)傳菜員會(huì)非常忙，有可能廚師已經(jīng)把菜做好了，但是傳菜員沒有時(shí)間傳給服務(wù)員，那么餐廳的瓶頸就是傳菜員了。

如下所示，一個(gè)傳菜員對(duì)應(yīng)三個(gè)廚師，而且做的菜很多，都需要傳菜員將菜端給包間外的服務(wù)員。

NAT 的路由方案存在瓶頸，由于所有的數(shù)據(jù)請(qǐng)求及響應(yīng)的數(shù)據(jù)包都需要經(jīng)過(guò) LVS 調(diào)度器轉(zhuǎn)發(fā)，如果后端服務(wù)數(shù)量很多，客戶端訪問(wèn)流量也很大的話，那么調(diào)度器會(huì)忙于調(diào)度轉(zhuǎn)發(fā)和地址替換等操作。

為了解決 NAT 的性能問(wèn)題，TUN 路由方案是個(gè)比較好的選擇。TUN 方案中，真實(shí)服務(wù)器處理完結(jié)果后，直接返回給客戶端。但是這就要求真實(shí)服務(wù)器能夠與外部網(wǎng)絡(luò)連接。

也就是說(shuō)廚師做好菜后，廚師直接把菜遞給服務(wù)員，不需要經(jīng)過(guò)傳菜員。廚師是對(duì)外可見的。

1.2.2 TUN 詳解

TUN 其實(shí)是 tunneling（隧道）的縮寫，而 TUN 路由方案就是基于 IP 隧道的一種技術(shù)。

我們熟知的 VPN 技術(shù)就是 IP 隧道技術(shù)。

IP 隧道其實(shí)是一種封裝技術(shù)，將一個(gè) IP 報(bào)文封裝在另一個(gè) IP 報(bào)文中。分為如下兩步：

• ① 先將原始數(shù)據(jù)包進(jìn)行封裝。
• ② 然后添加新的源地址+端口、新的目標(biāo)地址+端口。

它可以將原始數(shù)據(jù)包封裝并添加新的包頭（內(nèi)容包括新的源地址及端口、目標(biāo)地址及端口），從而實(shí)現(xiàn)將一個(gè)目標(biāo)為調(diào)度器VIP地址的數(shù)據(jù)包封裝，通過(guò)隧道轉(zhuǎn)發(fā)給后端的真實(shí)服務(wù)器（Real Server），通過(guò)將客戶端發(fā)往調(diào)度器的原始數(shù)據(jù)包封裝，并在其基礎(chǔ)上添加新的數(shù)據(jù)包頭（修改目標(biāo)地址為調(diào)度器選擇出來(lái)的真實(shí)服務(wù)器的IP地址及對(duì)應(yīng)端口），LVS（TUN）模式要求真實(shí)服務(wù)器可以直接與外部網(wǎng)絡(luò)連接，真實(shí)服務(wù)器在收到請(qǐng)求數(shù)據(jù)包后直接給客戶端主機(jī)響應(yīng)數(shù)據(jù)。

原理圖如下所示：

TUN 模式的缺點(diǎn)：

隧道模式的RS節(jié)點(diǎn)需要合法 IP，這種方式需要所有的服務(wù)器支持 IP Tunneling 協(xié)議。

1.3 LVS-DR 模式

那么 LVS 的 TUN 路由模式有沒有什么問(wèn)題呢？

因?yàn)?TUN 的方式必須在 LVS 調(diào)度器和真實(shí)的服務(wù)器之間有一個(gè)隧道連接，這個(gè)創(chuàng)建隧道的過(guò)程會(huì)對(duì)服務(wù)器增加負(fù)擔(dān)。

在餐廳這種場(chǎng)景中，TUN 模式中，廚師是對(duì)外可見的，菜好了后直接和服務(wù)員對(duì)接；而 DR 模式中，廚師不可見，統(tǒng)一被看成是傳菜員。

DR 模式和 TUN 模式的相同之處：

• 模式中，用戶的請(qǐng)求被調(diào)度器負(fù)載均衡到真實(shí)服務(wù)器上，然后真實(shí)服務(wù)器把響應(yīng)結(jié)果返回給客戶端。
• 客戶端的請(qǐng)求數(shù)據(jù)包中目標(biāo) IP 為 LVS 的 VIP，源 IP 為客戶端 IP。

DR 模式和 TUN 模式不同之處：

• DR 模式要求調(diào)度器與后端服務(wù)器必須在一個(gè)局域網(wǎng)內(nèi)。
• DR 模式不需要?jiǎng)?chuàng)建 IP 隧道。
• DR 模式中，VIP 需要在 LVS 調(diào)度器與后端所有的服務(wù)器間共享。
• DR 模式中，真實(shí)服務(wù)器處理完結(jié)果后，返回?cái)?shù)據(jù)包時(shí)，設(shè)置源 IP 為 VIP 地址，目標(biāo) IP 為客戶端 IP。
• DR 模式中，LVS 調(diào)度器和真實(shí)服務(wù)器在同一物理網(wǎng)段上。同一網(wǎng)段機(jī)器數(shù)量有限，限制了其應(yīng)用范圍。

更細(xì)節(jié)的內(nèi)容

負(fù)載均衡器和RS都使用同一個(gè)IP對(duì)外服務(wù)但只有 DR（Director Server，可以理解為 LVS 的核心） 對(duì) ARP 請(qǐng)求進(jìn)行響應(yīng)，所以 RS （Real Server，真實(shí)服務(wù)器）對(duì)本身這個(gè) IP 的 ARP 請(qǐng)求保持靜默。

也就是說(shuō)，網(wǎng)關(guān)會(huì)把對(duì)這個(gè)服務(wù)IP的請(qǐng)求全部定向給 DR。而 DR 收到數(shù)據(jù)包后根據(jù)調(diào)度算法,找出對(duì)應(yīng)的 RS，把目的 MAC 地址改為 RS 的 MAC（因?yàn)?IP 一致）并將請(qǐng)求分發(fā)給這臺(tái) RS 這時(shí) RS 收到這個(gè)數(shù)據(jù)包，處理后直接返回給客戶端。由于負(fù)載均衡器要對(duì)二層包頭進(jìn)行改換,所以負(fù)載均衡器和RS之間必須在一個(gè)廣播域，也可以簡(jiǎn)單的理解為在同一臺(tái)交換機(jī)上。

四、三種模式對(duì)比

推薦 DR 模式。