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

我們知道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。

ipvs(ip virtual server)：一段代碼工作在內核空間，叫ipvs，是真正生效實現調度的代碼。

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實現了主備冗余，避免了單獨故障。

EI企業智能 云社區 Gauss AP

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。