暑假打工 2 個月,讓我明白了 Keepalived 高可用的三種路由方案

語言: CN / TW / HK

這是悟空的第  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 偽裝。

對於服務員:information_desk_person|type_1_2:來說,她只和傳菜員打交道,並不知道廚師:woman|type_1_2:‍:egg: 。

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 幀發往此硬體地址。

彩蛋二

放點餐廳打工的照片吧。

餐廳打工第一天,腿都要廢了。終於熬完了 2 個月的暑假,還拿到了兩個月的工資,然後購買了當時最酷炫的諾基亞 5230,爽yy(暴露年齡了)。

問:你是否也曾兼職打過工?

- END -

關於我

8 年網際網路開發經驗,擅長微服務、分散式、架構設計。目前在一家大型上市公司從事基礎架構和效能優化工作。

InfoQ 簽約作者、藍橋簽約作者、阿里雲專家博主、51CTO 紅人。

歡迎加我好友,提供技術解答、簡歷修改、500人技術交流群。

悟空的多個技術專題:

33 篇 SpringCloud 實戰,回覆 PDF 獲取。

8 篇分散式演算法文章,回覆 分散式 獲取。

7 篇JVM 專項訓練,回覆 JVM 獲取。

Elasticsearch 筋斗雲版藍皮書1.0,回覆 ES 獲取

面試必備資料,關注即可獲取。↓↓

我是悟空,努力變強,變身超級賽亞人!