摘要：GaussDB(DWS)的負載均衡經過LVS+keepAlived實現。對於這種方式，須要思考的問題是，CN的返回結果是否會通過LVS，而後再返回給前端應用？若是通過LVS，那麼，LVS會不會成爲單點瓶頸？ 帶着這兩個問題，咱們探究一下LVS+KeepAlived的實現原理。
咱們知道GaussDB(DWS)爲了保證業務的連續性和高可靠性，各個組件都進行了高可用設計。前端
下圖是應用訪問GaussDB(DWS)的業務流程架構圖，對於業務應用或者用戶來講，他們發生請求給CN，CN解析並生成執行計劃，交給DN去執行，執行後再由CN彙總將數據返回給業務用戶或者業務應用。這個過程是容易理解的，本次咱們重點關注的是站在CN前面的LVS+KeepAlived。linux
如今的問題是：windows
- 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表示；oracle
（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的負載均衡機制
一、 LVS是四層負載均衡，也就是說創建在OSI模型的第四層——傳輸層之上，傳輸層上有咱們熟悉的TCP/UDP，LVS支持TCP/UDP的負載均衡。由於LVS是四層負載均衡，所以它相對於其它高層負載均衡的解決辦法，好比DNS域名輪流解析、應用層負載的調度、客戶端的調度等，它的效率是很是高的。
二、 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的關係
一、keepalived 是 lvs 的擴展項目，是對LVS項目的擴展加強，所以它們之間具有良好的兼容性。
二、對LVS應用服務層的應用服務器集羣進行狀態監控：若應用服務器不可用，則keepalived將其從集羣中摘除，若應用服務器恢復，則keepalived將其從新加入集羣中。
三、檢查LVS主備節點的健康狀態，經過IP漂移，實現主備冗餘的服務高可用，服務器集羣共享一個虛擬IP，同一時間只有一個服務器佔有虛擬IP並對外提供服務，若該服務器不可用，則虛擬IP漂移至另外一臺服務器並對外提供服務，解決LVS自己單點故障問題。
至此，咱們能夠回答第二個問題：
- 若是通過LVS，那麼，LVS會不會成爲單點瓶頸或者出現單獨故障？
答：返回結果不會通過LVS，不會由於返回的數據量太大形成單獨瓶頸的問題。對應請求， LVS只須要將用戶請求轉發給CN便可，負載很低，也不會出現單獨瓶頸的問題。另外，LVS經過keepAlived實現了主備冗餘，避免了單獨故障。
本文分享自華爲雲社區《由兩個問題引起的對GaussDB(DWS)負載均衡的思考》，原文做者：Sprother 。