暑假打工 2 個 月，讓我明白了 Keepalived 高可用的三種路由方案
這是悟空的第 158 篇原創文章
原文鏈接：首發悟空聊架構
官網：www.passjava.cn
你好，我是悟空。
前言
上篇我們講了Keepalived 底層原理上篇，中篇還是得繼續呀，但是發現中篇內容還是很多，一篇講不完，所以先講 Keepalived 的路由原理。
在寫的過程中，發現路由原理其實挺枯燥的，我想把這個主題用通俗易懂、且有趣的方式講解出來，但是一直找不到合適的切入點，一次偶然的對話讓我的靈感迸發。
話說之前大學放暑假的時候，我到一個餐廳打工兩個月，Title 是初級傳菜員。正是這次打工經驗，爲我帶來了一波潛藏已久的素材，請聽聽我的故事吧~
本文主要內容如下：
一、餐廳角色
在餐廳主要有這幾種角色：
- 服務員：負責記錄客戶已點哪些菜、上菜時間、上菜、劃掉菜。可以將多個服務員都當做客戶端，相對於傳菜員來說。
- 傳菜員：負責通知廚房走菜、劃菜、傳菜。可以將傳菜員當作 Keepalived 組件。
- 廚師：烹飪、裝盤。可以將廚師當作後臺真實服務器。
爲什麼需要傳菜員這個角色？有了傳菜員這個角色後，發生了什麼呢？
- 服務員需要服務顧客，不需要離開包間去廚房拿菜。（單一職責）
- 服務員不需要定期到廚房詢問菜是否好了。（解耦）
流程圖如下：
① 客戶點菜下單。
② 服務員記錄菜名、上菜時間。這裏的上菜時間是指客戶要求的上菜時間，因爲有些客戶可能想等朋友一起來了再喫。
③ 服務員將一份訂單交給傳菜員，另外一份訂單留在包間。
④ 傳菜員大聲通知多位廚師有哪些菜要做，什麼時候開始上菜。
⑤ 廚師準備食材和烹飪。如果缺少食材，廚師還會告訴傳菜員，由傳菜員轉告服務員說這道菜不能做。
⑥ 廚師做好後將菜裝在盤子裏，然後遞給傳菜員。
⑦ 傳菜員將訂單上對應的菜劃掉，表示已經做了。
⑧ 傳菜員將菜端給服務員。
⑨ 服務員將菜從訂單上劃掉。
⑩ 服務員將菜端上餐桌。
這個流程簡單來說就是客戶下單->服務員傳單->傳菜員通知->廚師烹飪->傳菜員傳菜->服務員上菜。
上面的流程不正是服務員請求數據，將請求都發給了傳菜員，傳菜員將請求轉發給了廚師，廚師處理完後返回結果。妙啊！！
二、初探 Keepalived 的路由方案
2.1 爲什麼需要路由方案
上篇我們講到 Keepalived 的負載均衡調度算法，通過這個算法選出某臺真實服務來處理本次客戶端請求。
就好比傳菜員要將要做的菜，告訴其中一個廚師（一般是告訴大廚）。
而如何告訴廚師呢？是用
喇叭喊，還是傳呼機，還是走到他旁邊告訴他？
服務員與廚師對話的方式
對於 Keepalived 來說，選擇了一個真實服務器後，後續還有兩個流程需要梳理下：
- Keepalived 如何將請求轉發給這個服務呢？
- 服務處理完這個請求後，如何將處理結果返回給客戶端？
上面兩個流程就是 Keepalived 的路由方案要做的事。
Keepalived 有三種路由方案：NAT、TUN、DR。
2.2 配置在哪
具體的配置哪種路由方案在 keepalived.conf 配置文件中，其中有一個 lb_kind 配置，可以配置成 NAT、DR、TUN 三種。目前配置的是 DR 模式。
還有一個配置 lb_algo，這個是配置調度算法的，比如這裏配置的 wrr 加權輪詢調度算法。
2.3 LVS 的結構
上篇我們說到 Keepalived 是利用了 LVS 模塊的功能來實現負載均衡的。那麼 LVS 的結構是怎麼樣的呢？
分爲兩個模塊：前端的負載均衡器（Load Balance，簡稱 LB），後端的多臺真實服務器（Real Server, 簡稱 RS）組成。LB 負責流量轉發，RS 負責處理請求，然後將請求返回。
三、深入理解 Keepalived 的路由方案
3.1 NAT 路由方案
NAT 的全稱是 Network Address Translation，網絡地址轉換。它有兩個功能：
- 使企業內部的私有 IP 可以訪問外網，
- 使外部用戶可以訪問位於公司內部的私有 IP 主機。
對於 Keepalived 來說，這種模式就好比餐廳的標準下單上菜模式：多個服務員將訂單數據轉給傳菜員，傳菜員通知廚師進行烹飪，廚師把菜做好後轉給傳菜員，傳菜員負責把菜傳遞給服務員。
如下圖所示，LVS 負載調度器有兩塊網卡，配置了不同的 IP 地址，網卡 eth0 設置爲公網 VIP 與外部網絡連通，網卡 eth1 設置爲私有 VIP 與內部網絡通過交換設備相互連接，
示例如下：
eth0 網卡 -> 公網 VIP -> 外部網絡
eth1 網卡 -> 私有 VIP -> 交換設備 > 內網網絡
原理圖如下所示：
① 比如現在 eth0 網卡配置了一個公有 VIP 如 10.1.2.88，客戶端發送的請求都是到這個 Public VIP（目標地址）。
② 主 LVS Router 負責接收請求，將請求的目的地址（Public VIP）替換成 NAT VIP（192.168.56.88）。
③ 這個 NAT VIP 和後端服務器同屬一個局域網，可以相互訪問，請求經過負載均衡調度選擇一個真實服務器。
④ LVS 修改數據包中的目標地址和目標端口爲真實服務器的。
⑤ 真實服務器處理完請求後，將應答數據返回給 LVS Router。
⑥ LVS Router 將應答數據的源 IP 地址 NAT VIP 和端口轉換成 Public VIP 和 LVS 的端口，然後轉發給外部網絡的客戶端。
對於客戶端而言，它只和 Public VIP 打交道，並不知道 NAT VIP，更不知道真實服務器的 IP 地址，這個過程也稱爲 IP 僞裝。
對於服務員💁🏻來說，她只和傳菜員打交道，並不知道廚師👩🏻🍳 。
1.2 LVS-TUN 路由方案
1.2.1 NAT 方案的瓶頸
如果餐廳的生意非常火爆，一個傳菜員會非常忙，有可能廚師已經把菜做好了，但是傳菜員沒有時間傳給服務員，那麼餐廳的瓶頸就是傳菜員了。
如下所示，一個傳菜員對應三個廚師，而且做的菜很多，都需要傳菜員將菜端給包間外的服務員。
NAT 的路由方案存在瓶頸，由於所有的數據請求及響應的數據包都需要經過 LVS 調度器轉發，如果後端服務數量很多，客戶端訪問流量也很大的話，那麼調度器會忙於調度轉發和地址替換等操作。
爲了解決 NAT 的性能問題，TUN 路由方案是個比較好的選擇。TUN 方案中，真實服務器處理完結果後，直接返回給客戶端。但是這就要求真實服務器能夠與外部網絡連接。
也就是說廚師做好菜後，廚師直接把菜遞給服務員，不需要經過傳菜員。廚師是對外可見的。
1.2.2 TUN 詳解
TUN 其實是 tunneling（隧道）的縮寫，而 TUN 路由方案就是基於 IP 隧道的一種技術。
我們熟知的 VPN 技術就是 IP 隧道技術。
IP 隧道其實是一種封裝技術，將一個 IP 報文封裝在另一個 IP 報文中。分爲如下兩步：
- ① 先將原始數據包進行封裝。
- ② 然後添加新的源地址+端口、新的目標地址+端口。
它可以將原始數據包封裝並添加新的包頭（內容包括新的源地址及端口、目標地址及端口），從而實現將一個目標爲調度器VIP地址的數據包封裝，通過隧道轉發給後端的真實服務器（Real Server），通過將客戶端發往調度器的原始數據包封裝，並在其基礎上添加新的數據包頭（修改目標地址爲調度器選擇出來的真實服務器的IP地址及對應端口），LVS（TUN）模式要求真實服務器可以直接與外部網絡連接，真實服務器在收到請求數據包後直接給客戶端主機響應數據。
原理圖如下所示：
TUN 模式的缺點：
隧道模式的RS節點需要合法 IP，這種方式需要所有的服務器支持 IP Tunneling 協議。
1.3 LVS-DR 模式
那麼 LVS 的 TUN 路由模式有沒有什麼問題呢？
因爲 TUN 的方式必須在 LVS 調度器和真實的服務器之間有一個隧道連接，這個創建隧道的過程會對服務器增加負擔。
在餐廳這種場景中，TUN 模式中，廚師是對外可見的，菜好了後直接和服務員對接；而 DR 模式中，廚師不可見，統一被看成是傳菜員。
DR 模式和 TUN 模式的相同之處：
- 模式中，用戶的請求被調度器負載均衡到真實服務器上，然後真實服務器把響應結果返回給客戶端。
- 客戶端的請求數據包中目標 IP 爲 LVS 的 VIP，源 IP 爲客戶端 IP。
DR 模式和 TUN 模式不同之處：
- DR 模式要求調度器與後端服務器必須在一個局域網內。
- DR 模式不需要創建 IP 隧道。
- DR 模式中，VIP 需要在 LVS 調度器與後端所有的服務器間共享。
- DR 模式中，真實服務器處理完結果後，返回數據包時，設置源 IP 爲 VIP 地址，目標 IP 爲客戶端 IP。
- DR 模式中，LVS 調度器和真實服務器在同一物理網段上。同一網段機器數量有限，限制了其應用範圍。
更細節的內容
負載均衡器和RS都使用同一個IP對外服務但只有 DR（Director Server，可以理解爲 LVS 的核心） 對 ARP 請求進行響應，所以 RS （Real Server，真實服務器）對本身這個 IP 的 ARP 請求保持靜默。
也就是說，網關會把對這個服務IP的請求全部定向給 DR。而 DR 收到數據包後根據調度算法,找出對應的 RS，把目的 MAC 地址改爲 RS 的 MAC（因爲 IP 一致）並將請求分發給這臺 RS 這時 RS 收到這個數據包，處理後直接返回給客戶端。由於負載均衡器要對二層包頭進行改換,所以負載均衡器和RS之間必須在一個廣播域，也可以簡單的理解爲在同一臺交換機上。
四、三種模式對比
推薦 DR 模式。
彩蛋一
有位讀者朋友對上篇提出一個疑問：Keepalived 高可用上篇
主向備機發送的到底是 VRRP 還是 ARP 廣播報文？
更正和解答上篇的內容：
（1）主向備機發送的 VRRP 協議的廣播報文，傳遞了優先級字段。從源碼這裏可以看出。
1.發送 VRRP 廣播的方法，傳入了一個 vrrp 實體和 prio 優先級。
vrrp.c
vrrp_send_adv(vrrp_t * vrrp, uint8_t prio)
2.這個方法 vrrp_send_adv 是在下面這個地方調用的，prio 是 vrrp 的屬性字段 effective_priority 傳進去的。
（2）主向局域網內廣播 ARP 請求分組，告訴局域網自己的 IP 地址和 MAC 地址。客戶端就知道了主的 IP 地址和 MAC 地址。
（3）假如發生了主備切換，雖然 IP 沒變，還是 VIP，但是 MAC 地址已經變了。客戶端發送 IP 數據報時，從自己的 ARP 高速緩存中找到 VIP 對應的 MAC 地址，把 MAC 地址寫入 MAC 幀，然後通過局域網把該 MAC 幀發往此硬件地址。
- END -
關於我
8 年互聯網開發經驗，擅長微服務、分佈式、架構設計。目前在一家大型上市公司從事基礎架構和性能優化工作。
InfoQ 簽約作者、藍橋簽約作者、阿里雲專家博主、51CTO 紅人。
歡迎加我好友 passjava，提供技術解答、簡歷修改、500人技術交流羣。
參考資料
https://weread.qq.com/web/reader/fae32ef072021a44fae8fe6k9a132c802349a1158154a83
https://weread.qq.com/web/reader/0e732d007260a7490e70173ke2e329c0261e2ef524fbf75
https://weread.qq.com/web/reader/36732010719ecf6b3676799kc8f3245027cc8ffe9a588b8
https://weread.qq.com/web/reader/634329b05930c06341b7d10k98f3284021498f137082c2e