lvs(1) - 基礎概念

一、集羣

系統擴展方式有兩種, 一種是向上擴展(scale up), 通過提升CPU規格、磁盤空間、內存空間等方式來提高性能; 第二種就是通過橫向擴展(scale out), 通過將一組相互獨立、通過高速網絡互連的計算機(這些計算機都提供相同的服務)組成一個組, 並以單一系統模式進行管理. 當客戶端與集羣通信時, 對客戶端來說集羣就想一個獨立的服務器.

1.1 集羣類型

集羣有三種類型:

• LB(Load Banlancing): 負載均衡, 根據算法將請求分攤後端多個服務器上進行處理, 從而提高服務的併發性能和可用性.
• HA(High availability): 高可用, 相同的兩個及以上運行相同服務的主機, 在一個發生故障時可以及時切換到其他健康的主機上, 避免業務因故障而中斷.
• HP(High Performancing): 高性能集羣,

1.2 LB集羣的實現

類型	名稱
硬件	BIGIP(F5), NetScaler(Citrix), A10(A10), Array, Redware
軟件	lvs, haproxy, nginx, ats(Apache Traffic Server), Perbal
傳輸層	lvs, haproxy(mode tcp)
應用層	haproxy, nginx, ats, perbal

二、lvs

lvs(Linux Virual Server)是軟件LB的實現, 工作在傳輸層, 根據請求報文的目標IP和PORT將其轉發至後端主機集羣中的某一臺主機(根據挑選算法). lvs的實現是ipvs, 命令行工具是ipvsadm.

ipvs支持TCP、UDP、AH、EST、AH_EST、SCTP等諸多協議. 一個ipvs主機可以同時定義多個cluster service; 一個cluster service上至少應該有一個RealServer(定義時需要指明lvs-type和lvs scheduler).

ipvs工作在內核空間, 附着在netfilter的INPUT鏈上, 當一個請求進入之後通過PREROUTING鏈到達INPUT鏈之後, 會在INPUT鏈上強制修改請求從POSTROUTING鏈出主機到達後端的RealServer之上.

詳細流程請看下圖:

查看內核是否支持ipvs:

$ grep -i -A 10 'IPVS' /boot/config-VERSION.x86_64

2.1 lvs術語

• 調度器: director, dispatcher, balancer
• DIP: Director IP
• VIP: Director Virtual IP
• CIP: Client IP
• RIP: Realserver IP

2.2 lvs類型

2.2.1 lvs-nat

多目標的DNAT(iptables), 它通過修改請求報文的目標IP地址(同時可能修改目標端口)至挑選出某RS的RIP實現地址轉發.

請求報文流程圖:

• 用戶對director發起請求, 這時在三層的首部中, 源地址是CIP, 目標地址是VIP;
• 報文從director的配置了VIP這種網卡進入被PREROUTING鏈捕獲, 本應該交由FORWARD鏈, 但此時IPVS強行修改路徑將數據包從PREROUTING鏈轉發至INPUT鏈上; 並且將目標地址改爲RIP, 將報文交由POSTROUTING鏈;
• 然後從配置了DIP這張網卡出去, 交給後端的RealServer(通過挑選算法.)

響應報文流程圖:

• RealServer收到請求後, 將響應報文封裝, 此時數據包的目標地址是CIP, 源地址是RIP;
• 數據包被髮送至Director, 從配置了DIP的網卡進入, 交由PREROUTING鏈, 然後轉發至INPUT鏈, 這時數據包的目標地址不變, 仍然是CIP, 而源地址被修改爲VIP;
• 然後交由POSTROUTING鏈, 從配置了VIP的網卡出去, 通過路由器發送給互聯網的Client.

配置lvs-nat的注意事項:

• RS和DIP應該使用私網地址, 且RS的網關要指向DIP.
• 請求和響應報文都要經由director轉發; 極高負載的場景中, director可能會成爲系統瓶頸.
• 支持端口映射.
• RS可以使用任意OS.
• RS的RIP和director的DIP必須在同一IP的網絡.

2.2.2 lvs-dr(Direct Routing)

它通過修改報文的目標MAC地址進行轉發.

請求報文流程圖:

• Clint對director發起請求, 這時在三層的首部中, 源地址是CIP, 目標地址是VIP; 在二層的首部中源mac是CIP-MAC, 目標mac是VIP-MAC;
• VIP配置在網卡ens33的別名上(ens33:0); 數據包從ens33:0進入, 在到達INPUT鏈後;
• 此時源IP和目標IP均未修改, IPVS只是修改了源MAC爲DIP-MAC, 目標MAC爲RIP-MAC;
• 由於DIP和RIP處於同一個網絡中, 所以是通過二層傳輸; POSTROUTING鏈檢查目標MAC爲RIP-MAC, 便將數據包交由配置了DIP的網卡ens33發送至後端的RealServer上(通過挑選算法).
• 數據包從RIP進入RealServer, 然後被交給綁定了VIP的lo:0(lo的別名), lo:0將數據包解包後將請求報文交給用戶空間的應用獲取Client請求的資源.

響應報文流程圖:

• lo:0獲取請求報文後, 此時目標地址爲CIP, 源地址爲VIP; 目標MAC被修改CIP-MAC, 源MAC被修改爲VIP-MAC;
• lo:0將數據包發送給配置了RIP的網卡(ens33), 此時數據包將被通過互聯網路由發回給Client.

配置lvs-dr的注意事項:

• 保證前端路由器將目標IP爲VIP的請求報文發送給director:
  • 靜態綁定
  • arptables
  • 修改RS主機內核參數
• RS的RIP可以使用私有地址, 也可以使用公網地址;
• RS跟Director必須在同一物理網絡中;
• 請求報文經由Director調度, 但響應報文一定不能經由Director;
• 不支持端口映射;
• RS可以是大多數OS;
• RS的網關不能指向DIP.

2.2.3 lvs-tun

不修改請求報文的IP首部, 而是通過在原有IP首部(cip <--> vip)之外, 在封裝一個首部(dip <--> rip).

請求報文流程圖:

• 當用戶請求到達Director時, 請求的數據報文會被綁定了vip的網卡交由PREROUTING鏈後轉交給INPUT鏈, 此時源IP爲CIP, 目標IP爲VIP;
• 此時IPVS會在原來的數據報文的首部在封裝一層IP報文, 封裝源IP爲DIP, 目標IP爲RIP, 並且將重新封裝後的數據包交由POSTROUTING鏈, 然後在從綁定了DIP的網卡發送給後端的RS.
• RS接受到數據包, 解包後發現裏面還有一層IP首部, 而且目標IP是迴環接口的VIP(lo:0), 就將數據包轉發給迴環接口, 迴環接口接到數據包並解包, 將請求報文發給用戶空間的APP獲取相應的資源.

響應報文流程圖:

• 迴環接口獲取響應報文後, 將報文封裝通過本機的物理網卡發送出去, 此時數據包首部的源IP爲VIP, 目標IP爲CIP;
• 數據包經過重重路由後發送至Client.

lvs-tun模型的注意事項:

• RIP, DIP, VIP全得是公網地址;
• RS的網關不能指向DIP
• 請求報文必須經由director調度, 但響應報文必須不能經由director;
• 不支持端口映射;
• RS的OS必須支持隧道功能.

2.2.4 lvs-fullnat

director通過同時修改請求報文的目標地址和源地址進行轉發.

流程圖參考lvs-nat模型.

lvs-fullnat模型的注意事項:

• vip是公網地址, RIP和DIP是私網地址, 二者無須在同一網絡中;
• RS接收到的請求報文的源地址爲DIP, 因此要響應給DIP;
• 請求報文和響應報文都必須經由director;
• 支持端口映射機制;
• RS可以是任意OS.

三、lvs scheduler

調度方法有總的來說分爲靜態方法和動態方法:

• 靜態方法: 僅根據算法本身進行調度
  • RR: Round Robin, 輪詢
  • WRR: Weight Round Robin, 加權輪詢
  • SH: Source Hash, 源地址IP hash, 實現會話保持的機制, 將來自同一個IP的請求始終調度至同一個RS
  • DH: Destination Hash, 目標地址IP hash, 將對同一目標的請求始終發往同一個RS
• 動態方法: 根據算法及各RS的當前負載狀態進行調度, 根據overhead來計算
  • LC: Least Connection, 最少連接數量, 如果所有RS的連接數爲0, 則從RS列表中至上而下開始調度; overhead=Active*256+Inactive
  • WLC: Weighted Least Connection, 加權的最少連接數; Overhead=(Active*256+Inactive)/Weight
  • SED: Shortest Expection Delay, 最短期望延遲; Overhead=(Active+1)*256/weight
  • NQ: Never Queue, SED算法的改進
  • LBLC: Locality-Based Least Connection, 即爲動態的DH算法, 正向代理情形下的cache server調度
  • LBLCR: Locality-Based Least Connection with Replication, 帶複製的LBLC算法