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

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

1.1 keepalived及LVS概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( 1 ) Load Balancer層

負載均衡層位于整個集群系統(tǒng)的最前端，由一臺或者多臺負載調(diào)度器（ Director Server )組成， LVS模塊就安裝在Director Server的系統(tǒng)上，而Director Server的主要功能類似路由器，其包含了完成LVS 負載轉(zhuǎn)發(fā)功能所設定的路由表， Director利用這些路由表信息把用戶的請求分發(fā)到Sever Array層的物理服務器（ Real Server ）上。此外，為了監(jiān)測各個Real Server服務器的健康狀況，在Director Server上還要安裝監(jiān)控模塊Ldirectord，而當監(jiān)控到某個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提供共享存儲空間和內(nèi)容一致性的存儲區(qū)域，在物理實現(xiàn)上，該層一般由磁盤陣列設備組成。而為了提供一致性的內(nèi)容，通常利用NFS網(wǎng)絡文件系統(tǒng)提供集群的共享數(shù)據(jù)，但是NFS在繁忙的業(yè)務系統(tǒng)中，性能并不是很好，此時可以采用集群文件系統(tǒng)，例如Redhat的GFS文件系統(tǒng)和IBM的GPFS文件系統(tǒng)等。

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

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

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

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

( 2) VSTUN (Virtual Server via IP Tunneling)

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

( 3) VSDR (Virtual Server via Direct Routing)

即直接路由技術(shù)實現(xiàn)的虛擬服務器。這種技術(shù)在調(diào)度連接和管理上與VSNAT和VSTUN 技術(shù)是一樣的，不過它的報文轉(zhuǎn)發(fā)方式與前兩種均不同， VSDR通過改寫請求報文的MAC地址，將請求直接發(fā)送到選中的Real Server ，而Real Server則將響應直接返回給客戶端。因此，這種技術(shù)不僅避免了VSNAT 中的IP地址轉(zhuǎn)換，同時也避免了VS TUN 中的IP隧道開銷，所以VSDR 是三種負載調(diào)度機制中性能最高的實現(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)的主機僅僅知道這命虛擬路由器的IP 地址10 .110.10.1，而并不知道具體的Master路由器的IP地址以及Backup路由器的IP地址。局域網(wǎng)內(nèi)的主機將自己的默認路由下一跳地址設置為該虛擬路由器的IP地址10.110.10.1 之后，網(wǎng)絡內(nèi)的主機就通過這個虛擬的路由器來與其他網(wǎng)絡進行通信。在通信過程中，如果備份組內(nèi)的Master路由器故障，則Backup路由器將會通過選舉機制重新選出一個新的Master路由器，從而繼續(xù)向網(wǎng)絡內(nèi)的主機提供路由服務，最終實現(xiàn)了路由功能的高可用。

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

1.2 KeepAlived工作原理

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

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

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

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

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

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

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

在Keepalived 進程啟動的時候，所有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 ）信息。而當故障Router 重新恢復后，根據(jù)該Router 的優(yōu)先級情況，其可能恢復到Master 狀態(tài)也可能保持為Backup 狀態(tài)。

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

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

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

1.3 KeepAlived的負載均衡算法

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

( 1 ) Round-Robin

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

( 2 ) Weighted Round-Robin

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

( 3 ) Least-Connection

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

( 4 ) Weighted Least-Connections

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

( 5) Destination Hash ScheduIing

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

( 6 ) Source Hash Scheduling

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

( 7 ) Shortest Expected Delay

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

1.4 Keepalived 路由方式

（1） NAT

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

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

對外提供服務的公有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 負責接收請求，并將請求的目的地址替換成LVS Router的NAT Virtual IP地址，再將其轉(zhuǎn)發(fā)到選中的后端服務器上，同時服務器處理后的應答數(shù)據(jù)也通過LVS Router將其地址替換成LVS Router的Public Virtual IP 地址，然后再轉(zhuǎn)發(fā)給Internet客戶端，這個過程也稱為IP偽裝，因為對客戶端而言，服務器的真實IP地址已被隱藏。

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

（2） DR

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

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

1.5 Keepalived 配置與使用

Keepalived高可用負載均衡器的配置主要是編輯Keepalived的配置文件/etc/keepalived/keepalived.conf為了演示Keepalived負載均衡的配置使用，本節(jié)采用兩個獨立服務器來作為前端Keepalived負載均衡器，其中一臺服務器作為主用負載均衡器（LBl )，另一臺服務器作為Standby負載均衡器一備（LB2），后端服務器池由四臺運行HTTP服務的節(jié)點構(gòu)成，后端服務器位于同一個私有網(wǎng)絡中，其真實IP地址段為192.168.1.20-192.168.1.23 ，由Keepalived 控制的VIP 為10 .0 .0.1 。此外，每個負載均衡器配有兩張物理網(wǎng)卡eth0和eth1,其中eth0接入Internet, eth1與后端服務器一起接人私有網(wǎng)絡，此處的負載均衡器采用Round-Robin調(diào)度算法， 由于后端節(jié)點數(shù)量很小， Keepalived的路由方法可以設置為NAT，其架構(gòu)和圖3-4相似，典型二層負載均衡架構(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}}//虛擬服務器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 中的內(nèi)容可以看到， 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出現(xiàn)故障時的郵件通知管理員，讓管理員以郵件形式知道Keepalived的運行情況。通常情況下，郵件通知不是必須的，用戶可以選擇其他監(jiān)控方式來對Keepalived 進行監(jiān)控，如Nagios。需要說明的是，全局配置段對Keepalived來說是可選的，其內(nèi)容并不是Keepalived 配置所必須的。全局配置段的幾個主要配置參數(shù)說明如下：

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

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

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

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

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)絡的VRRP_EXT實例和針對內(nèi)部私有網(wǎng)絡的VRRP_INT 實例。VRRP 配置段中的關(guān)鍵參數(shù)說明如下。

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

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

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

Virtual_Router_id ：虛擬路由標志，同一個VRRP實例使用唯一的標識。即同一個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的負載均衡器， LB2的keepalived.conf 配置文件與LB1類似，其不同之處在于VRRP實例配置段中的的VRRP 實例State和Priority參數(shù)的設置，如LBl 中的State為Master, LB2 中的State為BACKUP ，并且LB2 中VRRP實例的Priority 必須小于LBl 中的優(yōu)先級。

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

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

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

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

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

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

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

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

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

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