萬字長文帶你從 0 學習 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 項目架構的伺服器集群系統中，通常包含三個功能層次：最前端的負載均衡層（ 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 設計的具有二層拓撲的負載均衡架構
在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如下。
從Keepalived 配置文件/etc/keepali ved/keepali ved. conf 中的內容可以看到， Keepalived的配置主要分為三個模塊， 即全局配置段、VRRP 定義段、虛擬伺服器LVS 配置段。
1. 全局配置段
全局配置段（ global_defs ）的主要作用之一就是Keepalived出現故障時的郵件通知管理員，讓管理員以郵件形式知道Keepalived的運行情況。通常情況下，郵件通知不是必須的，用戶可以選擇其他監控方式來對Keepalived 進行監控，如Nagios。需要說明的是，全局配置段對Keepalived來說是可選的，其內容並不是Keepalived 配置所必須的。全局配置段的幾個主要配置參數說明如下：
Notification_email ：用於配置接收郵件的負載均衡器的管理員群組郵箱。
Notification_email_from ：自定義發出郵件的郵箱地址，即管理員郵件顯示的發件人。
SMTP ：指定簡單郵件參數協議伺服器地址，一般為本機。
LVS_ID: LVS 負載均衡器標誌，同一網路中其值唯一。
2. VRRP 配置段
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 ）配置段主要定義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的負載均衡功能。
●編號564，輸入編號直達本文
●輸入m獲取文章目錄
推薦↓↓↓
運維
更多推薦：《18個技術類微信公眾號》
涵蓋：程序人生、演算法與數據結構、黑客技術與網路安全、大數據技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
TAG:Web開發 |