LVS 之 初識LVS

0x00 概述

LVS : Linux Virtual Server

lvs 工作在 IOS 第四層(tcp), 所以又稱 l4: 四層交換,四層路由
LVS 由 ipvs、ipvsadm 兩部分組成
ipvs 工作于 input 鏈上

lvs 與 nginx 工作模式上的區別：

lvs 工作于 IOS 的4 層，僅作請求分發用，沒有流量。(根據請求報文的目標IP和目標協議 及PORT 將其調度轉發至某 后端主機集群(RealServer) 的某一臺主機，根據調度算法來挑選RS；)

nginx工作在網絡的第7層，所以它可以針對http–來做分流策略，比如針對域名、目錄結構等，相比之下lvs并不具備這樣的功能

0x01 LVS拓撲結構圖：

ipvs 工作于內核空間的netfilter的 INPUT 鉤子上的框架， 通過 ipvsadm 命令來管理。

lvs集群類型中的術語 :

VS：Virtual Server, Director, Dispatcher, Balancer (調度器)
RS：Real Server, upstream server, backend server
CIP：Client IP,
VIP: Virtual serve IP,
DIP: Director IP,
RIP: Real server IP,

0x02 lvs-type

有 lvs-nat , dr , tun , fullnat 四種

lvs-nat

修改請求報文的目標IP 和 端口. ? ( masquerade )

• lvs-nat 拓撲結構

• 特性要點：
  1. DIP 和 RIP 在同一IP 網絡，且使用私有地址。 RIP 的網關要指向DIP
  2. 請求報文和響應報文都必須經由Director轉發；極高負載的場景中，Director易于成為系統瓶頸；
  3. 支持端口映射，可修改請求報文的目標PORT；
  4. vs必須是Linux系統，rs可以是任意系統；

lvs-dr

保留原IP 首部，為新的幀首部的目標MAC 定義 為選定的RS MAC; （即：封裝幀首部完成轉發）? ( gateway )

• lvs-dr 拓撲結構

• lvs-dr 請求過程

  1. 請求報文到達前端路由器，ARP 廣播，得到vip 的 MAC地址, 將報文送達 VIP
  2. director 由于工作于 dr 模型，只拆封 MAC 封閉， 根據調度算法得到 RS
  3. DIP 進行 ARP 廣播， 獲得RS 中的 RIP 所在網卡的MAC 地址; 重新封裝MAC首部( S_mac:DIP, D_mac:RIP )，發往 RS
  4. RIP 所在網卡得到報文, 解封裝，得到 源IP(CIP),目標IP(VIP)。

  若目標IP 不是自己，則拒收。所以各主機上均需要配置VIP，但是，前端路由進行ARP 廣播時，RS 的VIP 都能響應, 產生地址沖突。

  • 解決地址沖突的方式有三種：
    (1) 在前端網關做靜態綁定；
    (2) 在各RS使用arptables；
    (3) 在各RS修改內核參數，來限制arp響應(arp_ignore)和通告(arp_announce)的級別；

    • 限制響應級別：arp_ignore:
      0：默認值，表示可使用本地任意接口上配置的任意地址進行響應；
      1: 僅在請求的目標IP配置在本地主機的接收到請求報文接口上時，才給予響應；

    • 限制通告級別：arp_announce:
      0：默認值，把本機上的所有接口的所有信息向每個接口上的網絡進行通告；
      1：盡量避免向非直接連接網絡進行通告；
      2：必須避免向非本網絡通告；

• 特性要點

  1. 保證前端路由將目標IP 為VIP 的請求報文發送給director
     a) 靜態綁定 ( 前端路由 )
     b) arptables （RS）
     c) 修改RS 主機內核的參數

  2. DIP, RIP 可以是私網地址,也可以使用公網地址，因為它們不作為跟客戶端通信的地址，僅用于本地間 主機網絡通信

  3. RS 跟Director 必須在同一物理網絡中
  4. 請求報文經由Director 調度, 但響應報文一定不能經由Director
  5. 不支持端口映射
  6. RS 可以是大多數的OS
  7. RS 的網關不能指向DIP

nat 與 dr 都不支持遠距離轉發, 要想實現遠距離轉發，則采用隧道模式進行轉發

lvs-tun

保留原IP 首部，在原請求IP報文之外新加一個IP 首部; ? ( ip-ip )

• lvs-tun 拓撲結構

• 轉發方式：
  不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而是在原IP報文之外再封裝一個IP首部（源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RS；RS直接響應給客戶端（源IP是VIP，目標IP是CIP）；

• 特性要點

  1. DIP, VIP, RIP都應該是公網地址；
  2. RS的網關不能，也不可能指向DIP；
  3. 請求報文要經由Director，但響應不能經由Director；
  4. 不支持端口映射；
  5. RS的OS得支持隧道功能；

lvs-fullnat :

修改請求報文的目標IP 和 端口， 以及源IP地址。

• lvs-dr 拓撲結構

• 特性要點
  1. VIP是公網地址，RIP和DIP是私網地址，且通常不在同一IP網絡；因此，RIP的網關一般不會指向DIP；
  2. RS收到的請求報文源地址是DIP，因此，只需響應給DIP；但Director還要將其發往Client；
  3. 請求和響應報文都經由Director；
  4. 支持端口映射；
  5. RS 可以使用任意OS;

0x03 調度算法（scheduler）

根據其調度時是否考慮各RS當前的負載狀態，分為 靜態( static) , 動態( dynamic) 兩類
static: RR/WRR, SH, DH (請求時間差不多的情形)
dynamic: LC/WLC, SED, NQ, LBLC, LBLCR (請求時間不一的情形)

靜態方法：僅根據算法本身進行調度；
RR : Round Robin, 輪詢

WRR：Weighted RR, 加權輪詢

SH : Source Hashing, 實現session sticy，源IP地址hash；將來自于同一個IP地址的請求始終發往第一次挑中的RS，從而實現會話綁定

DH：Destination Hashing；目標地址哈希，將發往同一個目標地址的請求始終轉發至第一次挑中的RS，典型使用場景是正向代理, web cache 中的負載均衡

動態方法：主要根據每RS當前的負載狀態及調度算法進行調度；

Overhead=

LC: Least Connections （挑選出連接最少的用做 RS）

WLC: Weighted LC,
Overhead=(activeconns*256+inactiveconns)/weight

SED：Shortest Expection Delay (最短期望延遲)
Overhead=(activeconns+1)*256/weight

NQ：Never Queue， 按權重由大到小的順序，每個RS 分配一個請求，余下的再以SED 算法進行調度。

LBLC：Locality-Based LC，動態的DH算法；
正向代理情形下的 cache server 調度

LBLCR：LBLC with Replication，帶復制功能的LBLC；