由兩個問題引發的對GaussDB(DWS)負載均衡的思考


摘要:GaussDB(DWS)的負載均衡通過LVS+keepAlived實現。對於這種方式,需要思考的問題是,CN的返回結果是否會經過LVS,然后再返回給前端應用?如果經過LVS,那么,LVS會不會成為單點瓶頸? 帶着這兩個問題,我們探究一下LVS+KeepAlived的實現原理。

我們知道GaussDB(DWS)為了保證業務的連續性和高可靠性,各個組件都進行了高可用設計。

下圖是應用訪問GaussDB(DWS)的業務流程架構圖,對於業務應用或者用戶來說,他們發生請求給CN,CN解析並生成執行計划,交給DN去執行,執行后再由CN匯總將數據返回給業務用戶或者業務應用。這個過程是容易理解的,本次我們重點關注的是站在CN前面的LVS+KeepAlived。

現在的問題是:

  • CN的返回結果是否會經過LVS,然后再返回給前端應用?
  • 如果經過LVS,那么,LVS會不會成為單點瓶頸?

帶着這兩個問題我們探究一下LVS和KeepAlived的原理。

LVS是什么?

LVS是Linux Virtual Server的簡稱,也就是Linux虛擬服務器, 是一個由章文嵩博士發起的自由軟件項目,它的官方站點是www.linuxvirtualserver.org。現在LVS已經是 Linux標准內核的一部分,在Linux2.4內核以前,使用LVS時必須要重新編譯內核以支持LVS功能模塊,但是從Linux2.4內核以后,已經完全內置了LVS的各個功能模塊,無需給內核打任何補丁,可以直接使用LVS提供的各種功能。

LVS的目的是什么?

LVS主要用於服務器集群的負載均衡,擁有VIP,客戶端將所有請求發送至此VIP,LVS負責將請求分發到不同的RS,客戶不感知RS。其目的是提高服務器的性能,將請求均衡的轉移到不同的服務器上執行,從而將一組服務器構成高性能、高可靠的虛擬服務器。

LVS的體系結構

使用LVS架設的服務器集群系統有三個部分組成:

  (1)最前端的負載均衡層,用Load Balancer表示;

  (2)中間的服務器集群層,用Server Array表示;

  (3)最底端的數據共享存儲層,用Shared Storage表示;

在用戶看來,所有的內部應用都是透明的,用戶只是在使用一個虛擬服務器提供的高性能服務。如圖:

  • Load Balancer層:位於整個集群系統的最前端,有一台或者多台負載調度器(Director Server)組成,LVS模塊就安裝在Director Server上,而Director的主要作用類似於一個路由器,它含有完成LVS功能所設定的路由表,通過這些路由表把用戶的請求分發給Server Array層的應用服務器(Real Server)上。同時,在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord,此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除,恢復時重新加入。
  • Server Array層:由一組實際運行應用服務的機器組成,Real Server可以是WEB服務器、MAIL服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個,每個Real Server之間通過高速的LAN或分布在各地的WAN相連接。在實際的應用中,Director Server也可以同時兼任Real Server的角色。
  • Shared Storage層:是為所有Real Server提供共享存儲空間和內容一致性的存儲區域,在物理上,一般有磁盤陣列設備組成,為了提供內容的一致性,一般可以通過NFS網絡文件系統共享數據,但是NFS在繁忙的業務系統中,性能並不是很好,此時可以采用集群文件系統,例如Red hat的GFS文件系統,oracle提供的OCFS2文件系統等。

從整個LVS結構可以看出,Director Server是整個LVS的核心,目前,用於Director Server的操作系統只能是Linux和FreeBSD,linux2.6內核不用任何設置就可以支持LVS功能,而FreeBSD作為Director Server的應用還不是很多,性能也不是很好。對於Real Server,幾乎可以是所有的系統平台,Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

LVS的程序組成部分

LVS 由2部分程序組成,包括 ipvs 和 ipvsadm。

  1. ipvs(ip virtual server):一段代碼工作在內核空間,叫ipvs,是真正生效實現調度的代碼。
  2. ipvsadm:另外一段是工作在用戶空間,叫ipvsadm,負責為ipvs內核框架編寫規則,定義誰是集群服務,而誰是后端真實的服務器(Real Server)

LVS的負載均衡機制

1、 LVS是四層負載均衡,也就是說建立在OSI模型的第四層——傳輸層之上,傳輸層上有我們熟悉的TCP/UDP,LVS支持TCP/UDP的負載均衡。因為LVS是四層負載均衡,因此它相對於其它高層負載均衡的解決辦法,比如DNS域名輪流解析、應用層負載的調度、客戶端的調度等,它的效率是非常高的。

2、 LVS的轉發主要通過修改IP地址(NAT模式,分為源地址修改SNAT和目標地址修改DNAT)、修改目標MAC(DR模式)來實現。

GaussDB(DWS)目前主要采用的是DR(Direct Routing)模式,所以,我們主要聊一聊DR模式。

下圖是DR模式的一個示意圖:

DR模式下需要LVS和RS集群綁定同一個VIP(RS通過將VIP綁定在loopback實現),請求由LVS接受,由真實提供服務的服務器(RealServer, RS)直接返回給用戶,返回的時候不經過LVS。詳細來看,一個請求過來時,LVS只需要將網絡幀的MAC地址修改為某一台RS的MAC,該包就會被轉發到相應的RS處理,注意此時的源IP和目標IP都沒變,LVS只是做了一下移花接木。RS收到LVS轉發來的包時,鏈路層發現MAC是自己的,到上面的網絡層,發現IP也是自己的,於是這個包被合法地接受,RS感知不到前面有LVS的存在。而當RS返回響應時,只要直接向源IP(即用戶的IP)返回即可,不再經過LVS。

至此,回答了我們第一個問題:

  • CN的返回結果是否會經過LVS,然后再返回給前端應用?

答:GaussDB(DWS)采用的是LVS的DR模式,返回時不再經過LVS。

接下來,我們看看keepAlived。

什么是keepAlived?

Keepalived顧名思義,保持存活,在網絡里面就是保持在線了,也就是所謂的高可用或熱備,用來防止單點故障(單點故障是指一旦某一點出現故障就會導致整個系統架構的不可用)的發生。

keepAlived的原理

Keepalived的實現基於VRRP(Virtual Router Redundancy Protocol,虛擬路由器冗余協議),而VRRP是為了解決靜態路由的高可用。虛擬路由器由多個VRRP路由器組成,每個VRRP路由器都有各自的IP和共同的VRID(0-255),其中一個VRRP路由器通過競選成為MASTER,占有VIP,對外提供路由服務,其他成為BACKUP,MASTER以IP組播(組播地址:224.0.0.18)形式發送VRRP協議包,與BACKUP保持心跳連接,若MASTER不可用(或BACKUP接收不到VRRP協議包),則BACKUP通過競選產生新的MASTER並繼續對外提供路由服務,從而實現高可用。

KeepAlived與LVS的關系

1、keepalived 是 lvs 的擴展項目,是對LVS項目的擴展增強,因此它們之間具備良好的兼容性。

2、對LVS應用服務層的應用服務器集群進行狀態監控:若應用服務器不可用,則keepalived將其從集群中摘除,若應用服務器恢復,則keepalived將其重新加入集群中。

3、檢查LVS主備節點的健康狀態,通過IP漂移,實現主備冗余的服務高可用,服務器集群共享一個虛擬IP,同一時間只有一個服務器占有虛擬IP並對外提供服務,若該服務器不可用,則虛擬IP漂移至另一台服務器並對外提供服務,解決LVS本身單點故障問題。

至此,我們可以回答第二個問題:

  • 如果經過LVS,那么,LVS會不會成為單點瓶頸或者出現單獨故障?

答:返回結果不會經過LVS,不會因為返回的數據量太大造成單獨瓶頸的問題。對應請求, LVS只需要將用戶請求轉發給CN即可,負載很低,也不會出現單獨瓶頸的問題。另外,LVS通過keepAlived實現了主備冗余,避免了單獨故障。

本文分享自華為雲社區《由兩個問題引發的對GaussDB(DWS)負載均衡的思考》,原文作者:Sprother 。

 

點擊關注,第一時間了解華為雲新鮮技術~


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM