前提概要
在大規模互聯網應用中,負載均衡設備是必不可少的組成部分,源于互聯網應用的高并發和大流量的沖擊壓力場景下,通常會在服務端部署多個無狀態的應用服務器和若干有狀態的存儲服務器(數據庫、緩存等等)實現高可用特點和機制。LVS的介紹說明
- 官方站點:http://www.linuxvirtualserver.org;
- 用過LVS的朋友,其實大家的目的性很明確,就是需要通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能,高可用的服務器群集;
- 并且這個集群具有良好的可靠性、可擴展性和可操作性,從而以低廉的成本實現最優的服務性能,這也是大多數中小型公司青睞的架構;
負載均衡層(Load Balancer)
- 處于集群最前端,一臺或多臺構成負載調度,俗稱負載調度器(Director Server);
- 分發請求給服務器集群組層的應用服務器(Real Server);
- 監控應用服務器健康狀況,動態從LVS路由表中剔除、添加;
- 也可以兼職Real Server的身份;
- 負載均衡設備的任務就是作為應用服務器流量的入口,挑選最合適的一臺服務器,將客戶端的請求轉發給它處理,實現客戶端到真實服務端的透明轉發
- 云計算以及分布式架構,本質上也是將后端服務器作為計算資源、存儲資源,由某臺管理服務器封裝成一個服務對外提供,客戶端不需要關心真正提供服務的是哪臺機器,在它看來,就好像它面對的是一臺擁有近乎無限能力的服務器,而本質上,真正提供服務的,是后端的集群支撐的計算能力。
負載均衡的類型
- 負載均衡可以采用硬件設備,也可以采用軟件負載。商用硬件負載設備成本通常較高(一臺幾十萬上百萬很正常)一般有F5和A10硬件負載均衡
- 所以在條件允許的情冴下我們會采用軟負載,軟負載解決的兩個核心問題是:選誰、轉發,其中最著名的是 LVS(Linux Virtual Server)、Nginx、HAproxy等
LVS 是四層負載均衡,是我們國家著名技術專家:章文嵩博士研發的,也就是說建立在 OSI 模型的第四層——傳輸層之上,傳輸層上有我們熟悉的TCP/UDP,LVS支持TCP/UDP的負載均衡。
LVS的轉發主要通過修改IP地址(NAT模式,分為源地址修改SNAT和目標地址修改DNAT)、修改目標mac(DR 模式)來實現。LVS是在第四層做負載均衡
- 首先,LVS不像HAProxy等七層軟負載面向的是HTTP包,所以七層負載可以做的URL解析等工作,LVS無法完成。
- 其次,用戶訪問是與服務端建立連接后交換數據包實現的,如果在第三層網絡層做負載均衡,那么將失去「連接」的語義
- 軟負載面向的對象應該是一個已經建立連接的用戶,而不是一個孤零零的 IP 包后面會看到,實際上 LVS 的機器代替真實的服務器的用戶通過TCP三次握手建立了連接所以 LVS 是需要關心「連接」級別的狀態的
- 一臺或多臺實際運行的應用服務器構成;
- 每個Real Server關聯時通過有效網絡互連;
提供共享存儲空間和內容一致性的存儲區域;例如:數據庫、OSS存儲、FS文件服務器等。
LVS相關術語
- DS:Director Server。指的是前端負載均衡器節點。
- RS:Real Server。后端真實的工作服務器。
- VIP:向外部直接面向用戶請求,作為用戶請求的目標的IP地址。
- DIP:Director Server IP,主要用于和內部主機通訊的IP地址。
- RIP:Real Server IP,后端服務器的IP地址。
- CIP:Client IP,訪問客戶端的IP地址。
- DR
- NAT
- TUNNEL
- Full-NAT
- TUN
返里挑選常用的 DR、NAT、Full-NAT、TUN 來簡單介紹一下。
DR(Dynamic Route 動態路由)
通過為請求報文重新封裝一個MAC首部進行轉發,源MAC是DIP所在的接口的MAC,目標MAC是某挑選出的RS的RIP所在接口的MAC地址;源IP/PORT,以及目標IP/PORT均保持不變;
請求由LVS接受,由真實提供服務的服務器(RealServer, RS)直接返回給用戶,返回的時
候不經過 LVS。
流程分析
DR 模式下需要LVS和綁定同一個 VIP(RS 通過將 VIP綁定在 loopback 實現),此時報文的源IP為CIP,目標IP為VIP;
源地址
目的地址
CIP
VIP
源MAC地址
目的MAC地址
CIP-MAC
VIP-MAC
- 當用戶請求到達DS后,LVS只需要將網絡幀的MAC地址修改為某一臺RS的 MAC,該包就會被轉發到相應的RS處理,注意此時的源IP和目標IP都沒變,LVS 只是做了一下移花接木
IPVS比對數據包請求的服務是否為集群服務,若是,將請求報文中的源MAC地址修改為DIP的MAC地址,將目標MAC地址修改RIP的MAC地址, 此時的源IP和目的IP均未修改,僅修改了源MAC地址為DIP的MAC地址,目標MAC地址為RIP的MAC地址;
源地址
目的地址
CIP
VIP
源MAC地址
目的MAC地址
DIP-MAC
RIP-MAC
- 由于DS和RS在同一個網絡中,所以是通過二層來傳輸。目標MAC地址為RIP的MAC地址,那么此時數據包將會發至RS。
- RS 收到 LVS 轉發來的包,鏈路層發現 MAC 是自己的,到上面的網絡層,發現 IP 也是自己的,于是返個包被合法地接受,RS 感知不到前面有 LVS 的存在。處理完成之后,將響應報文通過lo接口傳送給eth0網卡然后向外發出,此時的源IP地址為VIP,目標IP為CIP;
源地址
目的地址
VIP
CIP
- 響應報文最終送達至客戶端,而當 RS 返回響應時,只要直接向源 IP(即用戶的 IP)返回即可,不再經過 LVS。DR 模式是性能最好的一種模式
這種模式下,有幾個要點:
主要是這種模式在于,通過LVS只是在請求階段做轉發,而且修改的也不是IP地址,而是MAC地址,針對于修改后的MAC地址會自動轉發到對應網段內MAC主機的服務器上面,之后因為IP都沒有改變,之后實際RS可以直接發送給目標Client服務器,這種性能最好,但是對網絡層面要求比較高,對網絡擴展角度而言控制力度略低。NAT?.NETwork Address Translation 網絡地址準換)
- NAT是一種外網和內網地址映射的技術
- NAT模式下,網絡報的進出都要經過LVS的處理
多目標IP的DNAT,通過將請求報文中的目標地址和目標端口修改為選出來的RS的RIP和PORT實現轉發。
流程分析
- LVS需要作為RS的網關,當包到達LVS 時LVS 做目標地址轉換(DNAT)。此時報文的源IP為CIP,目標IP為VIP;
源地址
目的地址
CIP
VIP
- IPVS比對數據包請求的服務是否為集群服務,若是,修改數據包的目標IP地址為后端服務器IP, 此時報文的源IP為CIP,目標IP為RIP;RS接收到包以后,仿佛是客戶端直接發給它的一樣。
源地址
目的地址
CIP
RIP
- RS比對發現目標為自己的IP,將請求處理完,返回響應時,此時報文的源IP為RIP,目標IP為CIP;
源地址
目的地址
RIP
CIP
- 返回時RS的包通過網關(LVS)中轉,LVS 會做源地址轉換(SNAT),將包的源地址改為VIP,這樣,這個包對客戶端看起來就仿佛是LVS直接返回給它的。此時會將源IP地址修改為自己的VIP地址,然后響應給客戶端,此時報文的源IP為VIP,目標IP為CIP;
客戶端無法感知到后端RS 的存在
源地址
目的地址
VIP
CIP
要點
客戶端是不知道真是RS地址的,但是RS服務器卻是可以知道ClientIP的(因為數據包中會包含了ClientIP),但是由于中介LVS的原因,使得發送的時候發給VIP(LVS),返回的時候,由LVS把源地址修改為VIP,所以對于客戶端不能來講是不知道目標地址的RS的存在。這就是反向代理的概念,客戶端是不知道真正服務器的存在,知道的只有門面VIP的存在。
特性
- 要求DS具備雙網卡,VIP應對公網,而DIP必須和RIP在同一個網段內;
- RIP、DIP應該使用私網地址,同在一個網段中,且RS的網關要指向DIP;
- 請求和響應報文都要經由DS轉發,極高負載中,DS可能會成為系統瓶頸;
- RS可以使用任意OS;
在原有的IP報文外再次封裝多一層IP首部,內部IP首部(源地址為CIP,目標IIP為VIP),外層IP首部(源地址為DIP,目標IP為RIP)。
流程分析
- 當用戶請求到達DS后,此時請求的數據報文會先到內核空間的PREROUTING鏈,此時報文的源IP為CIP,目標IP為VIP;
源地址
目的地址
CIP
VIP
- PREROUTING檢查發現數據包的目標IP是本機,將數據包送至INPUT鏈;
- IPVS比對數據包請求的服務是否為集群服務,若是,在請求報文的首部再次封裝一層IP報文,封裝源IP為為DIP,目標IP為RIP。然后發至POSTROUTING鏈。 此時源IP為DIP,目標IP為RIP;
IP首部源地址
IP首部目的地址
源地址
目的地址
DIP
RIP
CIP
VIP
- POSTROUTING鏈根據最新封裝的IP報文,將數據包發至RS(因為在外層封裝多了一層IP首部,所以可以理解為此時通過隧道傳輸),此時源IP為DIP,目標IP為RIP;
- RS接收到報文后發現是自己的IP地址,就將報文接收下來,拆除掉最外層的IP后,會發現里面還有一層IP首部,而且目標是自己的tun0接口VIP,那么此時RS開始處理此請求,處理完成之后,通過tun0接口送出去向外傳遞,此時的源IP地址為VIP,目標IP為CIP;
源地址
目的地址
VIP
CIP
- 響應報文最終送達至客戶端;
1、DIP、VIP、RIP都應該是公網地址;
2、RS的網關不能,也不可能指向DIP;
3、RS必須支持IP隧道;
Full-NAT
無論是 DR 還是 NAT 模式,不可避免的都有一個問題:LVS 和 RS 必須在同一個 vlan 下, 否則 LVS 無法作為 RS 的網關。
這引發的兩個問題是:
- 同一個VLAN的限制導致運維不方便,跨VLAN的RS無法接入
- 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 上將不再有任何限制,大大提高了運維部署的便利性。
上面其實是把內網ip和內網ip之間通過交換機進行轉換捆綁,從而可以跨vlan進行服務請求代理。Session
客戶端與服務端的通信,一次請求可能包含多個TCP 包,LVS 必須保證同一連接的TCP包,必須被轉發到同一臺RS,否則就亂套了。為了確保返一點,LVS 內部維護著一個 Session的 Hash 表,通過客戶端的某些信息可以找到應該轉發到哪一臺 RS 上。LVS 集群化
采用 Full-NAT 模式后,可以搭建 LVS 的集群,拓撲結構如下圖:
容災
容災分為 RS 的容災和 LVS 的容災。
RS 的容災可以通過 LVS 定期健康檢測實現,如果某臺 RS 失去心跳,則認為其已經下線, 不會在轉發到該 RS 上。
LVS 的容災可以通過主備+心跳的方式實現。主 LVS 失去心跳后,備 LVS 可以作為熱備立 即替換。
容災主要是靠 KeepAlived 來做的。(心跳以及下線剔除或者替換工作主要通過keepalived進行控制)