keepalived及LVS概述,KeepAlived工作原理

負載均衡器（Load Balancer, LB ）是一組能夠將IP數據流以負載均衡形式轉發到多臺物理服務器的集成軟件。有硬件負載均衡器和軟件負載均衡器之分，硬件負載均衡器主要是在訪問網絡和服務器之間配置物理負載均衡設備，客戶端對物理服務器的訪問請求首先會抵達負載均衡設備，然后再由負載均衡設備根據一定的負載算法轉發到后端服務器。相比而言，軟件負載均衡器不需要特定的物理設備，只需在相應的操作系統上部署具有負載均衡功能的軟件即可。

在Opens tack高可用集群部署中，服務的負載均衡和高可用主要有兩種主流的實現方案，即 HAProxy+ Keepalived和Pacemaker+HAProxy方案。由于OpenStack服務組件多樣，不同服務均需要進行特定的高可用設計，并且從集群資源統一調度和集群穩定性的角度考慮，后一種方案是多數OpenStack廠商的高可用部署方案首選，但是選用后一方案并不意味著Keepalived在OpenStack高可用集群部署中不被使用。由于Keepalived 的主要作用之一是進行虛擬路由的故障切換，其在Neutron 的L3 高可用設計與實現中起著舉足輕重的作用。

1.1 keepalived及LVS概述

Keepalived的項目實現的主要目標是簡化LVS項目的配置并增強其穩定性，即Keepalived是對LVS項目的擴展增強。

Keepalived為Linux系統和基于Linux 的架構提供了負載均衡和高可用能力，其負載均衡功能主要源自集成在Linux內核中的LVS項目模塊IPVS( IP Virtual Server ），基于IPVS提供的4 層TCP/IP協議負載均衡， Keepalived也具備負載均衡的功能，此外， Keepalived還實現了基于多層TCP/IP 協議（ 3 層、4 層、5/7 層）的健康檢查機制，因此， Keepalived在LVS 負載均衡功能的基礎上，還提供了LVS 集群物理服務器池健康檢查和故障節點隔離的功能。

除了擴展LVS的負載均衡服務器健康檢查能力， Keepalived 還基于虛擬路由冗余協議（ Virtual Route Redundancy Protocol, VRRP )實現了LVS 負載均衡服務器的故障切換轉移，即Keepalived還實現了LVS負載均衡器的高可用性。Keepalived 就是為LVS 集群節點提供健康檢查和為LVS 負載均衡服務器提供故障切換的用戶空間進程。

圖3-1為Keepalived的原理架構圖，從圖中可以看到， Keepalived的多數核心功能模塊均位于用戶空間，而僅有IPVS和NETLINK模塊位于內核空間，但是這兩個內核模塊正是Keepalived 實現負載均衡和路由高可用的核心模塊，其中的NETLINK主要用于提供高級路由及其相關的網絡功能。Keepalived的大部分功能模塊位于用戶空間，其中幾個核心功能模塊的介紹如下。

圖3-1 Keepalived的原理架構圖

WatchDog ：其主要負責監控Checkers和VRRP子進程的運行狀況。

Checkers ：此功能模塊主要負責真實服務器的健康檢查（ HealthChecking )，是Keepalived最主要的功能之一，因為HealthChecking是負載均衡功能穩定運行的基礎， LVS集群節點的故障隔離和重新加入均依賴于HealthChecking的結果。

VRRPStack ：此功能模塊主要負責負載均衡器之間的故障切換，如果集群架構中僅使用一個LVS負載均衡器，由于本身不具備故障切換的條件，則VRRPStack不是必須的。

IPVS Wrapper ：此模塊主要用來發送設定的規則到內核IPVS代碼。Keepalived的設計目標是構建高可用的LVS 負載均衡群集， Keepalived在運行中將會通過IPVSWrapper模塊調用IPVSAdmin工具來創建虛擬服務器，檢查和管理LVS集群物理服務器池。

Netlink Reflector ：此功能模塊主要用來設定VRRP的VIP地址并提供相關的網絡功能，該模塊通過與內核中的NETLINK模塊交互，從而為Keepalived 提供路由高可用功能。

從Keepalived 的實現原理和功能來看， Keepalived是開源負載均衡項目LVS的增強和虛擬路由協議VRRP實現的集合，即Keepalived通過整合和增強LVS與VRRP來提供高可用的負載均衡系統架構。

1.linux虛擬服務器---lvs

LVS是Linux Virtual Server的簡稱，即Linux虛擬服務器。目前，LVS項目已經被集成到Linux內核中。LVS具有良好的可靠性、可擴展性和可操作性，加上其實現最優的集群服務性能所需的低廉成本， LVS的負載均衡功能經常被用于高性能、高可用的服務器群集中。

基于LVS技術可以實現很多高伸縮、高可用的網絡服務，例如Web服務、Cache服務、DNS服務FTP服務、MAIL服務、視頻／音頻點播服務等， LVS的功能也在發展過程中得到了很多用戶的實踐驗證，例如很多著名網站和組織都在使用基于LVS架構的集群系統，包括Linux門戶網站（ www.linux.com ）向RealPlayer 提供音頻視頻服務的Real公司（ www.real.com ） 、全球最大的開源網站( sourceforge.net ）等都是LVS項目的使用者。

在基于LVS 項目架構的服務器集群系統中，通常包含三個功能層次：最前端的負載均衡層（ Load Balancer ）、中間的物理服務器群組層（ Server Array ）以及最底端的數據共享存儲層（ Shared Storage ），典型的LVS 集群架構如圖3-2 所示。在LVS負載均衡集群架構中，盡管整個集群內部有多個物理節點在處理用戶發出的請求，但是在用戶看來，所有的內部應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務，這也是Linux虛擬服務器項目，即LVS項目的主要名稱來源，如下是對LVS 集群架構中各個層次的功能描述。

圖3-2 LVS 集群架構

( 1 ) Load Balancer層

負載均衡層位于整個集群系統的最前端，由一臺或者多臺負載調度器（ Director Server )組成， LVS模塊就安裝在Director Server的系統上，而Director Server的主要功能類似路由器，其包含了完成LVS 負載轉發功能所設定的路由表， Director利用這些路由表信息把用戶的請求分發到Sever Array層的物理服務器（ Real Server ）上。此外，為了監測各個Real Server服務器的健康狀況，在Director Server上還要安裝監控模塊Ldirectord，而當監控到某個Real Server不可用時，該服務器會被從LVS 路由表中剔除，恢復時又會重新加入。

( 2 ) Server Array 層

服務器陣列或服務器池由一組實際運行應用服務的物理機器組成，Real Server可以是Web服務器、Mail 服務器、FTP服務器、DNS服務器以及視頻服務器中的一個或者多個的組合。每個Real Server之間通過高速的LAN或分布在各地的WAN 相連接。在實際應用中，為了減少資源浪費， Director Server也可以同時兼任Real Server的角色，即在Real Server同時部署LVS模塊。

( 3) Shared Storage 層

存儲層是為所有Real Server提供共享存儲空間和內容一致性的存儲區域，在物理實現上，該層一般由磁盤陣列設備組成。而為了提供一致性的內容，通常利用NFS網絡文件系統提供集群的共享數據，但是NFS在繁忙的業務系統中，性能并不是很好，此時可以采用集群文件系統，例如Redhat的GFS文件系統和IBM的GPFS文件系統等。

LVS的核心功能是為集群服務提供軟件負載均衡，而負載均衡技術有很多實現方案，如基于DNS 域名輪流解析方案、基于客戶端調度訪問方案、基于應用層系統負載的調度方案，以及基于IP地址的調度方案。在上述列舉的負載調度算法中，執行效率最高的是IP負載均衡技術，LVS 的IP 負載均衡技術是通過IPVS模塊來實現的， IPVS是LVS 集群系統的核心軟件，其主要安裝在集群的Director Server上，并在Director Server上虛擬出一個服務IP地址，用戶對服務的訪問只能通過該虛擬IP地址實現。這個虛擬IP通常稱為LVS的VIP( Virtual IP ），用戶的訪問請求首先經過VIP到達負載調度器，然后由負載調度器從Real Server列表中按照一定的負載均衡算法選取一個服務節點響應用戶的請求。在這個過程中，當用戶的請求到達Director Server后， Director Server如何將請求轉發到提供服務的Real Server節點，而Real Server節點又如何將數據返回給用戶， 這是IPVS實現負載均衡的核心技術。IPVS 實現數據路由轉發的機制有三種，分別是NAT 、TUN 和DR技術。

（1） VSNAT (Virtual Server via Network Address Translation)

即通過網絡地址轉換的虛擬服務器技術。在這種負載轉發方案中，當用戶的請求到達調度器時，調度器自動將請求報文的目標IP地址（ VIP ）替換成LVS選中的后端Real Server地址，同時報文的目標端口也替換為選中的Real Server對應端口， 最后將報文請求發送給選中的Real Server進行處理。當Real Server處理完請求并將結果數據返回給用戶時，需要再次經過負載調度器，此時調度器進行相反的地址替換操作，即將報文的源地址和源端口改成VIP地址和相應端口，然后把數據發送給用戶，完成整個負載調度過程?？梢钥闯?，在這種方式下，用戶請求和響應報文都必須經過Director Server 進行地址轉換，請求時進行目的地址轉換（ Destination Network Address Translation, DNAT ），響應時進行源地址轉換（ Source Network Address Translation, SNAT ）。在這種情況下，如果用

戶請求越來越多，調度器的處理能力就會成為集群服務快速響應的瓶頸。

( 2) VSTUN (Virtual Server via IP Tunneling)

即IP隧道技術實現的虛擬服務器。VS TUN與VSNAT技術的報文轉發方法不同，在VS TUN方式中，調度器采用IP隧道技術將用戶請求轉發到某個選中的Real Server上，而這個Real Server將直接響應用戶的請求，不再經過前端調度器。此外， IP TUN技術對RealServer的地域位置沒有要求，其既可以與Director Server位于同一個網段，也可位于獨立網絡中。因此，在VS TUN方式中，調度器將只處理用戶的報文請求，而無需進行轉發， 故集群系統的響應速率相對而言得到極大提高。

( 3) VSDR (Virtual Server via Direct Routing)

即直接路由技術實現的虛擬服務器。這種技術在調度連接和管理上與VSNAT和VSTUN 技術是一樣的，不過它的報文轉發方式與前兩種均不同， VSDR通過改寫請求報文的MAC地址，將請求直接發送到選中的Real Server ，而Real Server則將響應直接返回給客戶端。因此，這種技術不僅避免了VSNAT 中的IP地址轉換，同時也避免了VS TUN 中的IP隧道開銷，所以VSDR 是三種負載調度機制中性能最高的實現方案。但是，在這種方案下， Director Server與Real Sever必須在同一物理網段上存在互聯。

2 . 虛擬路由冗余協議一VRRP

虛擬路由冗余協議（ Virtual Router Redundancy Protocol, VRRP ）是一種容錯協議，其主要目的是解決路由單點故障的問題。VRRP協議將局域網內的一組路由器虛擬為單個路由，通常將其稱為一個路由備份組， 而這組路由器內包括一個Master路由（ 即活動路由器）和若干個Backup 路由（即備份路由器）， VRRP虛擬路由示意圖如圖3-3所示。在圖3-3中RouterA 、RouterB 和RouterC屬于同一個VRRP組，組成一個虛擬路由器，而由VRRP協議虛擬出來的路由器擁有自己的IP地址10.110.10.1 ，而備份組內的路由器也有自己的IP 地址（如Master的IP地址為10.110.10.5, Backup 的IP地址為10.110.10.6和10.110.10.7）。

圖3-3 VRRP虛擬路由示意圖

在實際使用中，局域網內的主機僅僅知道這命虛擬路由器的IP 地址10 .110.10.1，而并不知道具體的Master路由器的IP地址以及Backup路由器的IP地址。局域網內的主機將自己的默認路由下一跳地址設置為該虛擬路由器的IP地址10.110.10.1 之后，網絡內的主機就通過這個虛擬的路由器來與其他網絡進行通信。在通信過程中，如果備份組內的Master路由器故障，則Backup路由器將會通過選舉機制重新選出一個新的Master路由器，從而繼續向網絡內的主機提供路由服務，最終實現了路由功能的高可用。

路由器開啟VRRP功能后，會根據設定的優先級確定自己在備份組中的角色。優先級高的路由器成為Master路由器，優先級低的成為Backup路由器，并且Master路由器定期發送VRRP通告報文，通知備份組內的其他Backup路由器自己工作正常， 而備用路由器則啟動定時器等待通告報文的到來。（如何判斷Master路由器是否正常工作？）如果Backup路由器的定時器超時后仍未收到Master路由器發送來的VRRP通告報文， 則認為Master 路由器已經故障，此時Backup路由器會認為自己是主用路由器（備份組內的路由器會根據優先級選舉出新的Master路由器），并對外發送VRRP通告報文。此外， VRRP在提高路由可靠性的同時，還簡化了主機的路由配置， 在具有多播或廣播能力的局域網中，借助VRRP能在某臺路由器出現故障時仍然提供高可靠的默認鏈路，有效避免單一鏈路發生故障后網絡中斷的問題，并且無需修改主機動態路由協議、路由發現協議等配置信息。

1.2 KeepAlived工作原理

Keepalived 本質上是提供數據流轉發與服務器健康檢查并具備故障切換的高可用路由，而數據轉發與健康檢查是對LVS功能的擴展和增強，因此也可以認為Keepalived是運行在用戶空間的LVS 路由（LVS Router) 進程。在實際應用中， Keepalived通常部署在兩臺主備或一主多備的服務器上，即Keepalived進程既運行在Active/Master狀態的LVS Router中，也運行在Passive/Slave狀態的LVS Router中，而所有運行Keepalived進程的LVS Router都遵循虛擬路由冗余協議VRRP。在VRRP的協議框架下，作為Master的Router將會處理兩個主要任務，即轉發客戶端訪問請求到后端物理服務器以進行負載均衡和周期性的發送VRRP協議報文，而作為Slave的Routers則負責接收VRRP報文，如果某一時刻作為Slave 的Routers 接收VRRP報文失敗，則認為Master Router故障， 并從Slave Routers中重新選舉產生一個新的Master Router 。

Keepalived是一個與LVS Router相關的控制進程，在RHEL7 /Centos7 系統中，Keepalived 由Systemctl 命令通過讀取/etc/keepalived/keepalived.conf配置文件來啟動。在遵循VRRP協議的Master Router 中， Keepalived進程會啟動內核中的LVS服務以創建虛擬服務器，并根據配置拓撲對服務運行狀況進行監控。此外，Master Router還會向Slave Routers 發送周期性的VRRP廣播報文，而Master Router運行狀態的正常與否是由Slave Routers上的VRRP 實例決定的。如果在用戶預置的時間段內Slave Router不能接收到VRRP 報文，則Keepalived認為Master Router故障，同時觸發LVS Router 的Failover操作。

在Failover 的過程中， Keepalived 創建的虛擬服務器會被清除，新的Master Router將接管VIP 發送ARP信息、設置IPVS Table記錄條目（Virtual Server）以及物理服務器的健康檢查和發送VRRP 廣播報文。Keepalived的Failover操作針對的是四層TCP/ IP 協議，即傳輸層，因為TCP在傳輸層上進行的是基于鏈路連接的數據傳輸。所以，當服務器在響應TCP請求時，如果出現設置時間段的Timeout，則Keepalived的健康檢查機制將會監測到該情況并認為該服務器故障，然后將其從服務器池中移除（故障服務器隔離） 。圖3-4 是基于Keepalived 設計的具有二層拓撲的負載均衡架構，該架構分為兩個層次。第一層為負載均衡層，由一個Active 和多個Backup的LVS Routers組成，其中，每個LVS Router 都配置有兩個網絡接口，一個接入Internet 網絡，另一個接入內部私有網絡， Active的LVS Router 在這兩個網絡接口間進行數據轉發。在圖3-4 的負載均衡架構中，位于第一層的LVS Routers和第二層的物理服務器通過私網接口接人相同的局域網中， Active的LVSRouter通過NAT 技術將Internet數據流轉發到私網物理服務器上，而這些位于第二層的物理服務器運行著最終響應請求的服務。

圖3-4 基于Keepalived 設計的具有二層拓撲的負載均衡架構

位于二層私網中的服務器在與Internet交互時必須經過主LVS Router的NAT轉發， 并且對于外部網絡中的客戶端而言，訪問二層私網中的物理服務器就如訪問同處Internet網絡中的服務，因為從客戶端的角度來看，訪問請求的目的地址正是位于主LVS Router上的VIP地址，而該VIP與客戶端地址處于相同網絡中， VIP 還可以是管理員指定的互聯網域名，如www.example.com 。VIP在Keepalived的配置中通常被指定到一個或者多個虛擬服務器上，而虛擬服務器的主要任務便是監昕VIP及相應端口上的請求，當主LVS Router進行Failover操作的時候， VIP會從一個LVS Router轉移到另一個LVS（因此VIP 也稱為浮動IP)。

在Keepalived負載均衡架構的VIP 配置中，每個將LVS Router連接到Internet的物理網卡接口均可配置多個VIP ，并且每個VIP對應著不同的Virtual Server ，即多個VirtualServers 可以同時監聽相同物理網卡上的不同VIP ，其中每個VIP都對應著不同的服務。例如， Linux 系統中的接口eth0將LVS Router連接到Internet中，則可以在eth0上配置一個地址為192.168.115.100 的VIP以用于響應HTTP服務請求，同時還可以在eth0上配置另一個地址為192.168.115.200 的VIP 以用于響應FTP 服務請求。在這里， HTTP 服務和FTP服務均對應著監聽不同VIP 的Virtual Server 。在由一個Active Router和一個Backup Router組成的Keepalived 負載均衡架構中， Active Router的主要任務就是將VIP 上的請求轉發到選中的某個后端服務器上，具體服務器的選舉機制則由Keepalived 所支持的負載均衡算法來決定。

此外， Active Router還負責動態監控后端服務器上特定服務的健康狀況，監控方式主要是Keepalived自帶的三種健康檢測機制，即簡單TCP連接、HTTP和HTTPS。就簡單TCP連接檢測方式， Active Router會周期性地對服務器上某個特定端口進行TCP連接，如果TCP 連接超時或者中斷則認為服務不可用，而對于HTTP和HTTPS檢測方式， ActiveRouter通過周期性地抓?。?Fetch ）請求URL并驗證其內容來判斷服務的可用性。與此同時， Backup Router一直處于Standby狀態， LVS router的Failover由VRRP來處理。

在Keepalived 進程啟動的時候，所有LVS Routers會加人一個用來接收和發送VRRP廣播的多播組， 由于VRRP是一種基于優先級的協議，因此在啟動之初優先級高的LVS Router會被選舉為Master Router ，而Master Router將會周期性地向多播組中的成員發送VRRP廣播。如果多播組中的Backup Routers在一定時間內接收VRRP廣播失敗，則重新選舉新的Master Router ，新的Master Router將會接管VIP并廣播地址解析協議（ Address ResolutionProtocol, ARP ）信息。而當故障Router 重新恢復后，根據該Router 的優先級情況，其可能恢復到Master 狀態也可能保持為Backup 狀態。

圖3-4中的兩層負載均衡架構是最常見的部署環境，主要用于很多數據源變化不是很頻繁的數據請求服務中，如靜態Web頁面站點，因為后端獨立服務器（Real Severs ）之間不會自動進行數據同步。圖3-5為基于Keepalived的三層負載均衡架構，在三層負載均衡架構中，前端的LVS Router負責將訪問請求轉發到物理服務器（ Real Servers ）中，然后Real Server再通過網絡形式訪問可共享的數據源。

圖3-5 基于Keepalived的三層負載均衡架構

對于數據請求比較繁忙的FTP站點，三層架構是最為理想的負載均衡架構，在這種架構下，可供訪問的數據源集中存儲在高可用的集群服務器上， Real Servers通過NFS共享目錄或者Samba文件共享等網絡文件系統形式來訪問數據。此外，類似的三層負載均衡架構在需要提供中心化及數據庫事務處理高可用的Web站點中也被普遍使用，如果將Keepalived負載均衡器配置為Active/Active 雙活模式，則還可以將三層負載均衡架構同時用于提供FTP和Web數據庫服務。

1.3 KeepAlived的負載均衡算法

Keepalived所使用的負載均調度機制由集成到內核中的IPVS模塊提供， IPVS是LVS項目的核心功能模塊，其設計的主要目的之一就是解決單IP多服務器的工作環境，IPVS模塊使得基于TCP/IP傳輸層（ 第4 層）的數據交換成為可能。在實際使用中， IPVS會在內核中創建一個名為IPVS Table的表，該表記錄了后端服務器的地址及服務運行狀態，通過IPVS Table, Keepalived便可跟蹤并將請求路由到后端物理服務器中， 即LVS Router利用此表將來自Keepalived 虛擬服務器地址的請求轉發到后端服務器池中，同時將后端服務器的處理結果轉發給客戶端。此外， IPVS table的表結構主要取決于管理員對指定的虛擬服務器所設置的負載均衡算法， Keepalived支持以下幾種負載均衡算法。

( 1 ) Round-Robin

即所謂的輪詢負載均衡，在這種算法中，服務請求會被依次轉發到服務器池中的每一個服務器上，而不去評估服務器的當前負載或者處理能力，服務器池中的每一個服務器都被平等對待。如果使用Round-Robin負載均衡算法，每臺后端服務器會輪詢依次處理服務請求。

( 2 ) Weighted Round-Robin

即加權Round-Robin 算法，是對Round-Robin 算法的一種擴展。在這種算法中，請求被依次轉發到每一臺服務器上，但是當前負載較輕或者計算能力較大的服務器會被轉發更多的請求，服務器的處理能力通過用戶指定的權重因子來決定，權重因子可以根據負載信息動態上調或者下調。如果服務器的配置差別較大，導致不同服務器的處理能力相差較大，則加權的Round-Robin 算法會是不錯的選擇，但是如果請求負載頻繁變動，則權重較大的服務器可能會超負荷工作。

( 3 ) Least-Connection

即最少連接算法，在這種算法中，請求被轉發到活動連接較少的服務器上。在Keepalived的實際使用中， LVS Router一直在利用內核中的IPVS Table來記錄后端服務器的活動連接，從而動態跟蹤每個服務器的活動連接數。最少連接數算法是一種動態決策算法，它比較適合服務器池中每個成員的處理能力都大致相當，同時負載請求又頻繁變化的場景， 如果不同服務器有不同的處理能力，則下面的加權最少連接數算法較為合適。

( 4 ) Weighted Least-Connections

即加權最少連接數算法，在這種算法中，路由會根據服務器的權重，轉發更多的請求到連接數較少的服務器上。服務器的處理能力通過用戶指定的權重因子來決定，權重因子可以根據負載信息動態上調或者下調。一般來說，服務器加權算法主要用于集群存在不同類型服務器，而服務器配置和處理能力相差較大的場景中。

( 5) Destination Hash ScheduIing

即目標地址哈希算法，通過在靜態Hash表中查詢目的IP地址來確定請求要轉發的服務器，這類算法主要用于緩存代理服務器集群中。

( 6 ) Source Hash Scheduling

即源地址哈希算法，通過在靜態Hash表中查詢源IP地址來確定請求要轉發的服務器，這類算法主要應用于存在多防火墻的LVS Router中。

( 7 ) Shortest Expected Delay

即最小延時算法，在這種算法中，請求被轉發到具有最小連接響應延時的服務器上。

1.4 Keepalived 路由方式

（1） NAT

圖3-6 為基于NAT 路由實現的Keepalived 負載均衡器，在NAT 機制下，每個LVS Router 需要兩個網絡接口。假設eth0為接人Internet 的網絡接口，則eth0上配置有一個真實的IP 地址，同時還配置了一個浮動IP地址（Floating IP ）假設eth1為接入后端私有網絡的接口， 則eth1上也配置有一個真實IP地址和一個浮動IP地址。在出現故障切換Failover的時候， 接人Internet 的虛擬接口和接入私有網絡的虛擬接口會同時切換到Backup的LVSRouter 上，而為了不影響對Internet 客戶端的請求響應，位于私有網絡中的后端服務器均使用NAT路由的浮動IP作為與主LVS Router通信的默認路由。

圖3-6 NAT 路由實現的Keepalived負載均衡

對外提供服務的公有VIP(Public Virtual IP Address ）和私有NAT VIP(NAT Virtual IP Address）均被配置在物理網卡上而最佳的配置方式是將兩個VIP 各自配置到不同的物理網卡上，即在這種配置下，每個LVS Router節點最多只需兩個物理網卡。在NAT 路由轉發中，主LVS Router 負責接收請求，并將請求的目的地址替換成LVS Router的NAT Virtual IP地址，再將其轉發到選中的后端服務器上，同時服務器處理后的應答數據也通過LVS Router將其地址替換成LVS Router的Public Virtual IP 地址，然后再轉發給Internet客戶端，這個過程也稱為IP偽裝，因為對客戶端而言，服務器的真實IP地址已被隱藏。

在NAT路由實現的負載均衡中，后端服務器上可以運行各種操作系統，即后端服務器上的操作系統類型并不影響LVS Router 的NAT 路由功能，但是，使用NAT 路由方式存在的一個缺點是， LVS Router在大規模集群部署中可能會是一個瓶頸，因為LVS Router要同時負責進出雙向數據流的IP地址替換。

（2） DR

相對于其他的負載均衡網絡拓撲， DR(Direct Routing）路由方式為基于Keepalived 的負載均衡系統提供了更高的網絡性能， DR路由方式允許后端服務器直接將處理后的應答數據返回給客戶端，而無需經過LVS Router的處理操作，DR路由方案極大降低了LVS Router 造成網絡瓶頸的可能性。如圖3-7所示。在基于Keepalived的負載均衡架構中， Keepalived的最佳路由方式是DR 路由，即在配置Keepalived的路由方式時，優先將其設置為DR 。

圖3-7 DR 路由實現的Keepalived負載均衡

1.5 Keepalived 配置與使用

Keepalived高可用負載均衡器的配置主要是編輯Keepalived的配置文件/etc/keepalived/keepalived.conf為了演示Keepalived負載均衡的配置使用，本節采用兩個獨立服務器來作為前端Keepalived負載均衡器，其中一臺服務器作為主用負載均衡器（LBl )，另一臺服務器作為Standby負載均衡器一備（LB2），后端服務器池由四臺運行HTTP服務的節點構成，后端服務器位于同一個私有網絡中，其真實IP地址段為192.168.1.20-192.168.1.23 ，由Keepalived 控制的VIP 為10 .0 .0.1 。此外，每個負載均衡器配有兩張物理網卡eth0和eth1,其中eth0接入Internet, eth1與后端服務器一起接人私有網絡，此處的負載均衡器采用Round-Robin調度算法， 由于后端節點數量很小， Keepalived的路由方法可以設置為NAT，其架構和圖3-4相似，典型二層負載均衡架構。LB1的配置文件／etc/keepalived/keepalived.conf如下。

//全局配置段global_defs {notification_email{admin@example . com}notification_email from noreply@example.comsmtp_server 127.0 . 0.1smtp_connect_timeout 60router_id LVS DEVEL}/ /VRRP配置段vrrp_sync_group VG1 {group {VRRP EXTVRRP INT}/ /VRRP 實例VRRP_EXT配置段vrrp_instance VRRP_EXT {state MASTERinterface eth0virtual_router_id 50priority 100advert_int 1authentication {auth_type PASSauth_pass passwordl23}virtual_ipaddress {10.0.0.1}}// VRRP 實例VRRP_ INT 配置段vrrp_instance VRRP_ENT {state MASTERinterface eth1virtual_router_id 2priority 100advert_int 1authentication{auth_type PASSauth_pass passwordl23}virtual_ipaddress {192 .168 .1.1}}//虛擬服務器LVS 配置段virtual_server 10 .0.0 .180 {delay_loop 6lb_algo rrlb_kind NAT //NAT路由方式protocol tcp//后端服務器1real_server 192.168.1.20 80 {TCP_CHECK {connect timeout 10}}//后端服務器2real_server 192 .168 .1.21 80 {TCP_CHECK {connect timeout 10}}//后端服務器3real_server 192.168.1.22 80 {TCP_CHECK {connect timeout 10}}//后端服務器4real_server 192.168.1.23 80 {TCP_CHECK {connect timeout 10}}

從Keepalived 配置文件/etc/keepali ved/keepali ved. conf 中的內容可以看到， Keepalived的配置主要分為三個模塊， 即全局配置段、VRRP 定義段、虛擬服務器LVS 配置段。

1. 全局配置段

global_defs {notification_email {admin@example.com}notification_ email_from noreply@example.comsmtp_server 127 0 . 0.1smtp_connect_timeout 60router id LVS DEVEL}

全局配置段（ global_defs ）的主要作用之一就是Keepalived出現故障時的郵件通知管理員，讓管理員以郵件形式知道Keepalived的運行情況。通常情況下，郵件通知不是必須的，用戶可以選擇其他監控方式來對Keepalived 進行監控，如Nagios。需要說明的是，全局配置段對Keepalived來說是可選的，其內容并不是Keepalived 配置所必須的。全局配置段的幾個主要配置參數說明如下：

Notification_email ：用于配置接收郵件的負載均衡器的管理員群組郵箱。

Notification_email_from ：自定義發出郵件的郵箱地址，即管理員郵件顯示的發件人。

SMTP ：指定簡單郵件參數協議服務器地址，一般為本機。

LVS_ID: LVS 負載均衡器標志，同一網絡中其值唯一。

2. VRRP 配置段

vrrp_sync_group VGl (group {VRRP EXTVRRP INT}vrrp_instance VRRP_EXT {state MASTERinterface eth0virtual_router_id 50priority 100advert_int 1authentication {auth_type PASSauth_pass password123}virtual_ipaddress {10.0.0.1}}vrrp_instance VRRP_ INT {state MASTERinterface eth1virtual_router_id priority 100advert_int 1authentication {auth_type PASSauth__pass password123}virtual_ipaddress {192.168 .1.1}}

VRRP配置段（ vrrp sync group ）主要用于定義VRRP組，在Keepalived發生任何狀態

變化時，被定義在VR即組中的VRRP實例作為邏輯整體一致行動，如在發生LVS Router故障切換Failover的過程中， VRRP組中的實例會作為一致整體同時切換。在本節的演示配置中，同一個VRRP組內配置了兩個VRRP實例，分別是針對外部網絡的VRRP_EXT實例和針對內部私有網絡的VRRP_INT 實例。VRRP 配置段中的關鍵參數說明如下。

vrrp_sync_group : VRRP實例一致組，用于定義VRRP一致組中的成員，組內的VRRP實例行為是一致的，如在Failover的時候， 一致組內的VRRP實例將同時遷移。在本機示例中，當LBl出現故障時， VRRP INT和VRRP EXT實例將同時切換到LB2上。

vrrp_instance: VRRP實例，用于配置一個VRRP服務進程實例，其中的State設定了當前節點VRRP實例的主備狀態，在主LVS Router中，該值應該為MASTER,在備LVS Router中，其值為BACKUP 。正常情況下只有Master的LVS Router在工作， Backup的LVS Router處于Standby狀態。

interface ：對外提供服務的網絡接口，如eth0和eth1，選擇服務接口時，一定要核實清楚，LV Router 的VIP將會配置到這個物理接口上。

Virtual_Router_id ：虛擬路由標志，同一個VRRP實例使用唯一的標識。即同一個VRRP實例中， MASTER和BACKUP狀態的VRRP實例中， virtual_router_id 值是相同的，同時在全部VRRP 組內是唯一的。

Priority ：此參數指明了該VRRP實例的優先級，數字越大說明優先級越高，取值范圍為0-255 ，在同一個VRRP實例里， MASTER的優先級高于BACKUP。若MASTER的Priority值為100 ，那BACKUP 的Priority只能是90或更小的數值。

Advert_ int: Master路由發送VRRP廣播的時間間隔，單位為秒。

Authentication ：包含驗證類型和驗證密碼，類型主要有PASS 和AH兩種，通常使用的類型為PASS 驗證密碼為明文，同一VRRP實例MASTER與BACKUP使用相同的密碼才能正常通信。

Virtual_ipaddress ：虛擬IP地址，即VIP，可以有多個虛擬IP 、地址，每個地址占一行，不需要指定子網掩碼。作為Standby的負載均衡器， LB2的keepalived.conf 配置文件與LB1類似，其不同之處在于VRRP實例配置段中的的VRRP 實例State和Priority參數的設置，如LBl 中的State為Master, LB2 中的State為BACKUP ，并且LB2 中VRRP實例的Priority 必須小于LBl 中的優先級。

3. 虛擬服務器LVS 配置段

virtual_server 10.0.0.1 80 {delay_loop 6lb_algo rrlb_kind NATprotocol tcpreal_server 192 .16 8.1.20 80 {TCP_CHECK {connect timeout 10}real_server 192 .16 8.1.21 80 {TCP_CHECK {connect timeout 10}real_server 192 .16 8.1.22 80 {TCP_CHECK {connect timeout 10}real_server 192 .16 8.1.23 80 {TCP_CHECK {connect timeout 10}}

虛擬服務器（ Virtual Server ）配置段主要定義LVS的監昕虛擬IP地址和對應的后端服務器及其健康檢測機制，虛擬服務器的定義段是Keepalived框架最重要的部分，也是其配置文件keepalived.conf 中必不可少的部分。此部分的定義主要分為一個Virtual Server的定義和多個Real Servers的定義， Virtual Server由VRRP中定義的VIP 加上端口號構成，而Real Server由后端服務器節點IP和端口號構成，相關的配置參數說明如下。

Delay_Loop ：健康檢查的時間間隔，單位為秒。

LB_Algo ：選用的負載均衡算法，示例中的rr表示Round-Robin算法。

LB_Kind ：采用的路由方法，示例中采用的是NAT路由，還可以采用DR和TUN路由。

Protocol ：轉發協議，一般有TCP 和UDP兩種。

TCP CHECK ：表示采用TCP連接對Real Servers 進行健康檢查。

Connect timeout : TCP連接允許中斷的時間，單位為秒，超過此值認為TCP連接Timeout ，即后端服務器不可用。

上述示例中Keepalived的配置采用的是NAT路由方式，而在大規模負載均衡集群中，NAT 路由通常造成網絡性能瓶頸， 因此建議采用DR路由方式。DR路由方式的配置與NAT 方式類似，，為了使用DR路由，將LB_Kind參數配置為DR。

在LBJ 和LB2 上配置完keepalived.conf 后，分別在兩個節點上啟動Keepalived服務，即可正常使用Keepalived的負載均衡功能。

//啟動Keepalived服務systemctl start keepalived . service//將Keepalived服務設置為開機啟動systemctl enable keepalived . service