負(fù)載均衡器（Load Balancer, LB ）是一組能夠?qū)P數(shù)據(jù)流以負(fù)載均衡形式轉(zhuǎn)發(fā)到多臺物理服務(wù)器的集成軟件。有硬件負(fù)載均衡器和軟件負(fù)載均衡器之分，硬件負(fù)載均衡器主要是在訪問網(wǎng)絡(luò)和服務(wù)器之間配置物理負(fù)載均衡設(shè)備，客戶端對物理服務(wù)器的訪問請求首先會抵達(dá)負(fù)載均衡設(shè)備，然后再由負(fù)載均衡設(shè)備根據(jù)一定的負(fù)載算法轉(zhuǎn)發(fā)到后端服務(wù)器。相比而言，軟件負(fù)載均衡器不需要特定的物理設(shè)備，只需在相應(yīng)的操作系統(tǒng)上部署具有負(fù)載均衡功能的軟件即可。

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

1.1 keepalived及LVS概述

Keepalived的項目實現(xiàn)的主要目標(biāo)是簡化LVS項目的配置并增強其穩(wěn)定性，即Keepalived是對LVS項目的擴(kuò)展增強。

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

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

圖3-1為Keepalived的原理架構(gòu)圖，從圖中可以看到， Keepalived的多數(shù)核心功能模塊均位于用戶空間，而僅有IPVS和NETLINK模塊位于內(nèi)核空間，但是這兩個內(nèi)核模塊正是Keepalived 實現(xiàn)負(fù)載均衡和路由高可用的核心模塊，其中的NETLINK主要用于提供高級路由及其相關(guān)的網(wǎng)絡(luò)功能。Keepalived的大部分功能模塊位于用戶空間，其中幾個核心功能模塊的介紹如下。

圖3-1 Keepalived的原理架構(gòu)圖

WatchDog ：其主要負(fù)責(zé)監(jiān)控Checkers和VRRP子進(jìn)程的運行狀況。

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

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

IPVS Wrapper ：此模塊主要用來發(fā)送設(shè)定的規(guī)則到內(nèi)核IPVS代碼。Keepalived的設(shè)計目標(biāo)是構(gòu)建高可用的LVS 負(fù)載均衡群集， Keepalived在運行中將會通過IPVSWrapper模塊調(diào)用IPVSAdmin工具來創(chuàng)建虛擬服務(wù)器，檢查和管理LVS集群物理服務(wù)器池。

Netlink Reflector ：此功能模塊主要用來設(shè)定VRRP的VIP地址并提供相關(guān)的網(wǎng)絡(luò)功能，該模塊通過與內(nèi)核中的NETLINK模塊交互，從而為Keepalived 提供路由高可用功能。

從Keepalived 的實現(xiàn)原理和功能來看， Keepalived是開源負(fù)載均衡項目LVS的增強和虛擬路由協(xié)議VRRP實現(xiàn)的集合，即Keepalived通過整合和增強LVS與VRRP來提供高可用的負(fù)載均衡系統(tǒng)架構(gòu)。

1.linux虛擬服務(wù)器---lvs

LVS是Linux Virtual Server的簡稱，即Linux虛擬服務(wù)器。目前，LVS項目已經(jīng)被集成到Linux內(nèi)核中。LVS具有良好的可靠性、可擴(kuò)展性和可操作性，加上其實現(xiàn)最優(yōu)的集群服務(wù)性能所需的低廉成本， LVS的負(fù)載均衡功能經(jīng)常被用于高性能、高可用的服務(wù)器群集中。

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

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

圖3-2 LVS 集群架構(gòu)

( 1 ) Load Balancer層

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

( 2 ) Server Array 層

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

( 3) Shared Storage 層

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

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

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

即通過網(wǎng)絡(luò)地址轉(zhuǎn)換的虛擬服務(wù)器技術(shù)。在這種負(fù)載轉(zhuǎn)發(fā)方案中，當(dāng)用戶的請求到達(dá)調(diào)度器時，調(diào)度器自動將請求報文的目標(biāo)IP地址（ VIP ）替換成LVS選中的后端Real Server地址，同時報文的目標(biāo)端口也替換為選中的Real Server對應(yīng)端口， 最后將報文請求發(fā)送給選中的Real Server進(jìn)行處理。當(dāng)Real Server處理完請求并將結(jié)果數(shù)據(jù)返回給用戶時，需要再次經(jīng)過負(fù)載調(diào)度器，此時調(diào)度器進(jìn)行相反的地址替換操作，即將報文的源地址和源端口改成VIP地址和相應(yīng)端口，然后把數(shù)據(jù)發(fā)送給用戶，完成整個負(fù)載調(diào)度過程。可以看出，在這種方式下，用戶請求和響應(yīng)報文都必須經(jīng)過Director Server 進(jìn)行地址轉(zhuǎn)換，請求時進(jìn)行目的地址轉(zhuǎn)換（ Destination Network Address Translation, DNAT ），響應(yīng)時進(jìn)行源地址轉(zhuǎn)換（ Source Network Address Translation, SNAT ）。在這種情況下，如果用

戶請求越來越多，調(diào)度器的處理能力就會成為集群服務(wù)快速響應(yīng)的瓶頸。

( 2) VSTUN (Virtual Server via IP Tunneling)

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

( 3) VSDR (Virtual Server via Direct Routing)

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

2 . 虛擬路由冗余協(xié)議一VRRP

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

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

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

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

1.2 KeepAlived工作原理

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

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

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

圖3-4 基于Keepalived 設(shè)計的具有二層拓?fù)涞呢?fù)載均衡架構(gòu)

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

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

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

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

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

圖3-5 基于Keepalived的三層負(fù)載均衡架構(gòu)

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

1.3 KeepAlived的負(fù)載均衡算法

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

( 1 ) Round-Robin

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

( 2 ) Weighted Round-Robin

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

( 3 ) Least-Connection

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

( 4 ) Weighted Least-Connections

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

( 5) Destination Hash ScheduIing

即目標(biāo)地址哈希算法，通過在靜態(tài)Hash表中查詢目的IP地址來確定請求要轉(zhuǎn)發(fā)的服務(wù)器，這類算法主要用于緩存代理服務(wù)器集群中。

( 6 ) Source Hash Scheduling

即源地址哈希算法，通過在靜態(tài)Hash表中查詢源IP地址來確定請求要轉(zhuǎn)發(fā)的服務(wù)器，這類算法主要應(yīng)用于存在多防火墻的LVS Router中。

( 7 ) Shortest Expected Delay

即最小延時算法，在這種算法中，請求被轉(zhuǎn)發(fā)到具有最小連接響應(yīng)延時的服務(wù)器上。

1.4 Keepalived 路由方式

（1） NAT

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

圖3-6 NAT 路由實現(xiàn)的Keepalived負(fù)載均衡

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

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

（2） DR

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

圖3-7 DR 路由實現(xiàn)的Keepalived負(fù)載均衡

1.5 Keepalived 配置與使用

Keepalived高可用負(fù)載均衡器的配置主要是編輯Keepalived的配置文件/etc/keepalived/keepalived.conf為了演示Keepalived負(fù)載均衡的配置使用，本節(jié)采用兩個獨立服務(wù)器來作為前端Keepalived負(fù)載均衡器，其中一臺服務(wù)器作為主用負(fù)載均衡器（LBl )，另一臺服務(wù)器作為Standby負(fù)載均衡器一備（LB2），后端服務(wù)器池由四臺運行HTTP服務(wù)的節(jié)點構(gòu)成，后端服務(wù)器位于同一個私有網(wǎng)絡(luò)中，其真實IP地址段為192.168.1.20-192.168.1.23 ，由Keepalived 控制的VIP 為10 .0 .0.1 。此外，每個負(fù)載均衡器配有兩張物理網(wǎng)卡eth0和eth1,其中eth0接入Internet, eth1與后端服務(wù)器一起接人私有網(wǎng)絡(luò)，此處的負(fù)載均衡器采用Round-Robin調(diào)度算法， 由于后端節(jié)點數(shù)量很小， Keepalived的路由方法可以設(shè)置為NAT，其架構(gòu)和圖3-4相似，典型二層負(fù)載均衡架構(gòu)。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}}//虛擬服務(wù)器LVS 配置段virtual_server 10 .0.0 .180 {delay_loop 6lb_algo rrlb_kind NAT //NAT路由方式protocol tcp//后端服務(wù)器1real_server 192.168.1.20 80 {TCP_CHECK {connect timeout 10}}//后端服務(wù)器2real_server 192 .168 .1.21 80 {TCP_CHECK {connect timeout 10}}//后端服務(wù)器3real_server 192.168.1.22 80 {TCP_CHECK {connect timeout 10}}//后端服務(wù)器4real_server 192.168.1.23 80 {TCP_CHECK {connect timeout 10}}

從Keepalived 配置文件/etc/keepali ved/keepali ved. conf 中的內(nèi)容可以看到， Keepalived的配置主要分為三個模塊， 即全局配置段、VRRP 定義段、虛擬服務(wù)器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出現(xiàn)故障時的郵件通知管理員，讓管理員以郵件形式知道Keepalived的運行情況。通常情況下，郵件通知不是必須的，用戶可以選擇其他監(jiān)控方式來對Keepalived 進(jìn)行監(jiān)控，如Nagios。需要說明的是，全局配置段對Keepalived來說是可選的，其內(nèi)容并不是Keepalived 配置所必須的。全局配置段的幾個主要配置參數(shù)說明如下：

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

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

SMTP ：指定簡單郵件參數(shù)協(xié)議服務(wù)器地址，一般為本機(jī)。

LVS_ID: LVS 負(fù)載均衡器標(biāo)志，同一網(wǎng)絡(luò)中其值唯一。

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發(fā)生任何狀態(tài)

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

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

vrrp_instance: VRRP實例，用于配置一個VRRP服務(wù)進(jìn)程實例，其中的State設(shè)定了當(dāng)前節(jié)點VRRP實例的主備狀態(tài)，在主LVS Router中，該值應(yīng)該為MASTER,在備LVS Router中，其值為BACKUP 。正常情況下只有Master的LVS Router在工作， Backup的LVS Router處于Standby狀態(tài)。

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

Virtual_Router_id ：虛擬路由標(biāo)志，同一個VRRP實例使用唯一的標(biāo)識。即同一個VRRP實例中， MASTER和BACKUP狀態(tài)的VRRP實例中， virtual_router_id 值是相同的，同時在全部VRRP 組內(nèi)是唯一的。

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

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

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

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

3. 虛擬服務(wù)器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}}

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

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

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

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

Protocol ：轉(zhuǎn)發(fā)協(xié)議，一般有TCP 和UDP兩種。

TCP CHECK ：表示采用TCP連接對Real Servers 進(jìn)行健康檢查。

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

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

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

//啟動Keepalived服務(wù)systemctl start keepalived . service//將Keepalived服務(wù)設(shè)置為開機(jī)啟動systemctl enable keepalived . service