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 模式。
