叢集,lvs負載均衡的四種工作模式

吻如雪上霜發表於2021-05-04

叢集

叢集的三種分類以及用途

  • 負載均衡: 分配流量(排程器),提升速度
  • 高可用: 關鍵性業務
  • 高效能: 開發演算法,天氣預報,國家安全

負載均衡的叢集

  • lvs(適用於大規模)
  • haproxy(適用於中型)
  • nginx(適用於中小型)
  • slb(雲主機) 內網免費,公網收費
  • F5硬體裝置 (金融公司,政府機構)

LVS

lvs:Linux Virtual Server (linux虛擬伺服器)

lv4:四層交換,四層路由
根據請求報文的目標IP個PORT(埠)將其轉發至後端主機叢集的其中一臺主機(根據挑選演算法)

netfilter:

  • PREROUTING --> INPUT
  • PREROUTING --> FORWARD --> POSTROUTING
  • OUTPUT --> PREROUTING

ipvsadm/ipvs

  • ipvsadm: 使用者空間的命令列工具,用於管理叢集服務
  • ipvs: 工作與核心中netfilter INPUT鉤子上

支援 TCP,UDP,AH,EST,AH_EST,SCTP等協議

//檢視系統對ipvs的支援情況,包括演算法
grep -i -A 2 'ipvs' /boot/config-2.6.32-504.el6.x86_ 64

lvs arch

排程器:director,dispatcher,balancer
RS:Real Server:(真實伺服器:真正處理服務的伺服器)

Client IP:CIP -- (發起服務請求主機的IP)
Director Virutal IP:VIP -- (對外IP)
Director IP:DIP -- (對內IP)
Real Server IP:RIP -- (真實伺服器的IP)

lvs的四種模式

  • nat
  • dr
  • tun
  • fullnat

lvs-nat

lvs-nat模式工作原理:
①.客戶端將請求發往排程器,請求報文源地址是CIP(客戶端IP,後面統稱為CIP),目標地址為VIP(排程器前端地址,後面統稱為VIP)。

②.排程器收到報文後,發現請求的是在規則裡面存在的地址,那麼它將客戶端請求報文的目標地址改為了RS(後端伺服器)的RIP地址並通過自己的DIP傳送出去。

③.報文送到RS後,由於報文的目標地址是自己,所以會響應該請求,並將響應報文返還給LVS的DIP地址。

④.然後lvs將此報文的源地址修改為本機並通過自己的VIP傳送給客戶端。

注意:

在NAT模式中,Real Server的閘道器必須指向LVS,否則報文無法送達客戶端

特點:

  • RS和DIP應該使用私網地址,且RS的閘道器要指向DIP
  • 請求和響應報文都要經由director轉發,所以配置時需要將director的轉發功能開啟,極高負載的場景中,director可能會成為系統效能瓶頸
  • 支援埠對映
  • RS可以使用任意OS
  • RS的RIP和Director的DIP必須在同一IP網路

優點:

叢集中的物理伺服器可以使用任何支援TCP/IP作業系統,只有負載均衡器需要一個合法的IP地址。

缺點:

擴充套件性有限。當伺服器節點(普通PC伺服器)增長過多時,負載均衡器將成為整個系統的瓶頸,因為所有的請求包和應答包的流向都經過負載均衡器。當伺服器節點過多時,大量的資料包都交匯在負載均衡器那,速度就會變慢!

lvs-dr

lvs的預設模式,gateway
lvs-dr模式通過修改請求報文的目標MAC地址進行轉發
Director:排程器需要配置VIP,DIP
RSs: 所有的RS都需要配置RIP,VIP

lvs-dr的工作原理:
①.客戶端將請求發往前端的負載均衡器,請求報文源地址是CIP,目標地址為VIP。

②.負載均衡器收到報文後,發現請求的是在規則裡面存在的地址,那麼它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址,目標MAC改為了RIP的MAC地址,並將此包傳送給RS。

③.RS發現請求報文中的目的MAC是自己,就會將報文接收下來,處理完請求報文後,將響應報文通過lo介面送給eth0網路卡直接傳送給客戶端。

注意:

  • 需要設定lo介面的VIP不能響應本地網路內的arp請求
  • 保證客戶端CIP傳送的請求只能被排程器的VIP響應
    • 靜態繫結
    • arptables (arp防火牆)
    • 修改RS主機核心的兩個引數
      arp_announce:是否接收並記錄別人的通告以及是否通告自己的MAC地址給別人
      0(預設值)-- 允許使用任一網路介面配置的IP地址(即任一本地地址),通常就是待傳送的IP資料包的源IP地址。
      1 -- 儘量避免使用不屬於該網路介面(即傳送資料包的網路介面)子網的本地地址作為傳送方IP地址。根據我對官方原文的理解,就是說如果主機包含多個子網,而IP資料包的源IP地址屬於其中一個子網,雖然該IP地址不屬於本網口的子網,但是也可以作為ARP請求資料包的傳送方IP地址,否則就會按照取值為2的方式選擇傳送方IP地址。
      2 -- 忽略IP資料包的源IP地址,總是選擇網口所配置的最合適的IP地址作為ARP請求資料包的傳送方IP地址(一個網口可能會配置多個IP地址)。

總結:

1、通過在排程器 LB 上修改資料包的目的 MAC 地址實現轉發。注意源地址仍然是 CIP,目的地址仍然是 VIP 地址。

2、請求的報文經過排程器,而 RS 響應處理後的報文無需經過排程器 LB,因此併發訪問量大時使用效率很高(和 NAT 模式比)

3、因為 DR 模式是通過 MAC 地址改寫機制實現轉發,因此所有 RS 節點和排程器 LB 只能在一個區域網裡面

4、RS 主機需要繫結 VIP 地址在 LO 介面(掩碼32 位)上,並且需要配置 ARP 抑制。

5、RS 節點的預設閘道器不需要配置成 LB,而是直接配置為上級路由的閘道器,能讓 RS 直接出網就可以。

6、由於 DR 模式的排程器僅做 MAC 地址的改寫,所以排程器 LB 就不能改寫目標埠,那麼 RS 伺服器就得使用和 VIP 相同的埠提供服務。

7、直接對外的業務比如WEB等,RS 的IP最好是使用公網IP。對外的服務,比如資料庫等最好使用內網IP。

優點:

和TUN(隧道模式)一樣,負載均衡器也只是分發請求,應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比,VS-DR這種實現方式不需要隧道結構,因此可以使用大多數作業系統做為物理伺服器。

DR模式的效率很高,但是配置稍微複雜一點,因此對於訪問量不是特別大的公司可以用haproxy/nginx取代。日1000-2000W PV或者併發請求1萬一下都可以考慮用haproxy/nginx。

缺點:

所有 RS 節點和排程器 LB 只能在一個區域網裡面

lvs-tun

①.客戶端將請求發往前端的負載均衡器,請求報文源地址是CIP,目標地址為VIP。

②.負載均衡器收到報文後,發現請求的是在規則裡面存在的地址,那麼它將在客戶端請求報文的首部再封裝一層IP報文,將源地址改為DIP,目標地址改為RIP,並將此包傳送給RS。

③.RS收到請求報文後,會首先拆開第一層封裝,然後發現裡面還有一層IP首部的目標地址是自己lo介面上的VIP,所以會處理次請求報文,並將響應報文通過lo介面送給eth0網路卡直接傳送給客戶端。

注意:

需要設定lo介面的VIP不能在共網上出現。

總結:

1.TUNNEL 模式必須在所有的 realserver 機器上面繫結 VIP 的 IP 地址

2.TUNNEL 模式的 vip ------>realserver 的包通訊通過 TUNNEL 模式,不管是內網和外網都能通訊,所以不需要 lvs vip 跟 realserver 在同一個網段內

3.TUNNEL 模式 realserver 會把 packet 直接發給 client 不會給 lvs 了

4.TUNNEL 模式走的隧道模式,所以運維起來比較難,所以一般不用。

優點:

負載均衡器只負責將請求包分發給後端節點伺服器,而RS將應答包直接發給使用者。所以,減少了負載均衡器的大量資料流動,負載均衡器不再是系統的瓶頸,就能處理很巨大的請求量,這種方式,一臺負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。

缺點:

隧道模式的RS節點需要合法IP,這種方式需要所有的伺服器支援”IP Tunneling”(IP Encapsulation)協議,伺服器可能只侷限在部分Linux系統上。

FULLNAT模式

無論是 DR 還是 NAT 模式,不可避免的都有一個問題:LVS 和 RS 必須在同一個 VLAN 下,否則 LVS 無法作為 RS 的閘道器。

這引發的兩個問題是:

1、同一個 VLAN 的限制導致運維不方便,跨 VLAN 的 RS 無法接入。

2、LVS 的水平擴充套件受到制約。當 RS 水平擴容時,總有一天其上的單點 LVS 會成為瓶頸。

Full-NAT 由此而生,解決的是 LVS 和 RS 跨 VLAN 的問題,而跨 VLAN 問題解決後,LVS 和 RS 不再存在 VLAN 上的從屬關係,可以做到多個 LVS 對應多個 RS,解決水平擴容的問題。

Full-NAT 相比 NAT 的主要改進是,在 SNAT/DNAT 的基礎上,加上另一種轉換,轉換過程如下

在包從 LVS 轉到 RS 的過程中,源地址從客戶端 IP 被替換成了 LVS 的內網 IP。

內網 IP 之間可以通過多個交換機跨 VLAN 通訊。

當 RS 處理完接受到的包,返回時,會將這個包返回給 LVS 的內網 IP,這一步也不受限於 VLAN。

LVS 收到包後,在 NAT 模式修改源地址的基礎上,再把 RS 發來的包中的目標地址從 LVS 內網 IP 改為客戶端的 IP。

Full-NAT 主要的思想是把閘道器和其下機器的通訊,改為了普通的網路通訊,從而解決了跨 VLAN 的問題。採用這種方式,LVS 和 RS 的部署在 VLAN 上將不再有任何限制,大大提高了運維部署的便利性。

總結

1.FULL NAT 模式也不需要 LBIP 和 realserver ip 在同一個網段; full nat 跟 nat 相比的優點是:保證 RS 回包一定能夠回到 LVS;因為源地址就是 LVS--> 不確定

2.full nat 因為要更新 sorce ip 所以效能正常比 nat 模式下降 10%

三種工作模式比較

LVS排程演算法

(1). 輪循排程 rr
均等地對待每一臺伺服器,不管伺服器上的實際連線數和系統負載

(2). 加權輪調 wrr
排程器可以自動問詢真實伺服器的負載情況,並動態調整權值

(3). 最少連結 lc
動態地將網路請求排程到已建立的連線數最少的伺服器上
如果叢集真實的伺服器具有相近的系統效能,採用該演算法可以較好的實現負載均衡

(4). 加權最少連結 wlc
排程器可以自動問詢真實伺服器的負載情況,並動態調整權值
帶權重的誰不幹活就給誰分配,機器配置好的權重高

(5). 基於區域性性的最少連線排程演算法 lblc
這個演算法是請求資料包的目標 IP 地址的一種排程演算法,該演算法先根據請求的目標 IP 地址尋找最近的該目標 IP 地址所有使用的伺服器,如果這臺伺服器依然可用,並且有能力處理該請求,排程器會盡量選擇相同的伺服器,否則會繼續選擇其它可行的伺服器

(6). 複雜的基於區域性性最少的連線演算法 lblcr
記錄的不是要給目標 IP 與一臺伺服器之間的連線記錄,它會維護一個目標 IP 到一組伺服器之間的對映關係,防止單點伺服器負載過高。

(7). 目標地址雜湊排程演算法 dh
該演算法是根據目標 IP 地址通過雜湊函式將目標 IP 與伺服器建立對映關係,出現伺服器不可用或負載過高的情況下,發往該目標 IP 的請求會固定發給該伺服器。

(8). 源地址雜湊排程演算法 sh
與目標地址雜湊排程演算法類似,但它是根據源地址雜湊演算法進行靜態分配固定的伺服器資源。

(9). 最少期望延遲 sed
不考慮非活動連結,誰的權重大,優先選擇權重大的伺服器來接收請求,但權重大的機器會比較忙

(10). 永不排隊 nq
無需佇列,如果有realserver的連線數為0就直接分配過去

相關文章