Keepalived介紹（鏈接）

1、Keepalived是什麼（what）

（一）概述

       Keepalived[保持在線] 是一個基於VRRP協議來實現的LVS服務高可用方案，能夠利用其來避免單點故障。一個LVS服務會有2臺服務器運行Keepalived，一臺爲主服務器（MASTER），一臺爲備份服務器（BACKUP），可是對外表現爲一個虛擬IP，主服務器會發送特定的消息給備份服務器，當備份服務器收不到這個消息的時候，即主服務器宕機的時候， 備份服務器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。   

       Keepalived的做用是檢測服務器的狀態，若是有一臺web服務器死機，或工做出現故障，Keepalived將檢測到，並將有故障的服務器從系統中剔除，同時使用其餘服務器代替該服務器的工做，當服務器工做正常後Keepalived自動將服務器加入到服務器羣中。

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

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

Keepalived工做原理

    Keepalived軟件起初是專爲LVS負載均衡軟件設計的，用來管理並監控LVS集羣系統中各個服務節點的狀態，後來又加入了能夠實現高可用的VRRP功能。所以，Keepalived除了可以管理LVS軟件外，還能夠做爲其餘服務（例如：Nginx、Haproxy、MySQL等）的高可用解決方案軟件。

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

      Keepalived (的做用)就是爲LVS 集羣節點提供健康檢查和爲LVS 負載均衡服務器提供故障切換的用戶空間進程。

Keepalived採用是模塊化設計，不一樣模塊實現不一樣的功能；

keepalived主要有三個模塊，分別是core、check和vrrp。 

 

core：是keepalived的核心，負責主進程的啓動和維護，全局配置文件的加載解析等 

check： 負責healthchecker(健康檢查)，包括了各類健康檢查方式，以及對應的配置的解析包括LVS的配置解析；可基於腳本檢查對IPVS後端服務器健康情況進行檢查。 

vrrp：VRRPD子進程，VRRPD子進程就是來實現VRRP協議的

 

keepalived配置文件：

Keepalived配置文件爲：keepalived.conf；

主要有三個配置區域，分別是：全局配置(Global Configuration)、VRRPD配置、LVS配置 

全局配置又包括兩個子配置： 全局定義(global definition) 靜態IP地址/路由配置(static ipaddress/routes)

Keepalived服務VRRP的工做原理：

    Keepalived高可用對之間是經過 VRRP進行通訊的， VRRP是經過競選機制來肯定主備的，主的優先級高於備，所以，工做時主會優先得到全部的資源，備節點處於等待狀態，當主宕機的時候，備節點就會接管主節點的資源，而後頂替主節點對外提供服務。

在 Keepalived服務對之間，只有做爲主的服務器會一直髮送 VRRP廣播包,告訴備它還活着，此時備不會槍佔主，當主不可用時，即備監聽不到主發送的廣播包時，就會啓動相關服務接管資源，保證業務的連續性.接管速度最快；

 

出現腦裂的緣由：

 

1. 高可用服務器對之間心跳線鏈路發生故障，致使沒法正常通訊。

2. 因心跳線壞了（包括斷了，老化）。

3. 因網卡及相關驅動壞了，ip配置及衝突問題（網卡直連）

4. 因心跳線間鏈接的設備故障（網卡及交換機）

5. 因仲裁的機器出問題（採用仲裁的方案）

6. 高可用服務器上開啓了 iptables防火牆阻擋了心跳消息傳輸。

7. 高可用服務器上心跳網卡地址等信息配置不正確，致使發送心跳失敗

8. 其餘服務配置不當等緣由，如心跳方式不一樣，心跳廣插衝突、軟件Bug等。

 

如何解決腦裂：

 

① 同時使用串行電纜和以太網電纜鏈接，同時用兩條心跳線路，這樣一條線路壞了，另外一個仍是好的，依然能傳送心跳消息。

② 當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊設備支持，如Stonith、feyce）。至關於備節點接收不到心跳消患，經過單獨的線路發送關機命令關閉主節點的電源。

③ 作好對裂腦的監控報警（如郵件及手機短信等或值班）.在問題發生時人爲第一時間介入仲裁，下降損失。

管理員能夠經過手機回覆對應數字或簡單的字符串操做返回給服務器.讓服務器根據指令自動處理相應故障這樣解決故障的時間更短。

 

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的大部分功能模塊位於用戶空間，其中幾個核心功能模塊的介紹以下。

• 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 集羣架構中各個層次的功能描述。

( 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文件系統等。

1.          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）。

         在實際使用中，局域網內的主機僅僅知道這命虛擬路由器的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數據流轉發到私網物理服務器上，而這些位於第二層的物理服務器運行着最終響應請求的服務。

        位於二層私網中的服務器在與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再經過網絡形式訪問可共享的數據源。

       對於數據請求比較繁忙的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通訊的默認路由。

       對外提供服務的公有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 。

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.com
smtp_server 127.0 . 0.1
smtp_connect_timeout 60
router_id LVS DEVEL
}
/ /VRRP配置段
vrrp_sync_group VG1 {
group {
VRRP EXT
VRRP INT
}
/ /VRRP 實例VRRP_EXT配置段
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
10.0.0.1
}
}
// VRRP 實例VRRP_ INT 配置段
vrrp_instance VRRP_ENT {
state MASTER
interface eth1
virtual_router_id 2
priority 100
advert_int 1
authentication{
auth_type PASS
auth_pass passwordl23
}
virtual_ipaddress {
192 .168 .1.1
}
}
//虛擬服務器LVS 配置段
virtual_server 10 .0.0 .180 {
delay_loop 6
lb_algo rr
lb_kind NAT  //NAT路由方式
protocol tcp
//後端服務器1
real_server 192.168.1.20 80 {
TCP_CHECK {
connect timeout 10
}
}
//後端服務器2
real_server 192 .168 .1.21 80 {
TCP_CHECK {
connect timeout 10
}
}
//後端服務器3
real_server 192.168.1.22 80 {
TCP_CHECK {
connect timeout 10
}
}
//後端服務器4
real_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.com
smtp_server 127 0 . 0.1
smtp_connect_timeout 60
router 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 EXT
VRRP INT
}
vrrp_instance VRRP_EXT {
state MASTER
interface eth0
virtual_router_id 50
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass password123
}
virtual_ipaddress {
10.0.0.1
}
}
vrrp_instance VRRP_ INT {
state MASTER
interface eth1
virtual_router_id  
priority 100
advert_int 1
authentication {
auth_type PASS
auth__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 6
lb_algo rr
lb_kind NAT
protocol tcp
real_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

 

 

 

鏈接 ：

Keepliaved介紹 ：https://blog.csdn.net/huwh_/article/details/77113410