高可用之KeepAlived(一)：基本概念和配置文件分析

時間  2019-11-06
標籤 用之 keepalived 基本概念 配置文件 分析 欄目 負載均衡 简体版
原文   原文鏈接

KeepAlived系列文章：http://www.cnblogs.com/f-ck-need-u/p/7576137.htmlhtml

1.概述

KeepAlived主要有兩個功能：web

  • (1).可以對RealServer進行健康情況檢查，支持4層、5層和7層協議進行健康檢查；
  • (2).對負載均衡調度器實現高可用，防止Director單點故障。

在keepalived設計之初，它只是LVS周邊的一個輔助工具，用於LVS的監控情況檢查，所以它和LVS的兼容性很是好。若是某一個realserver節點宕了，keepalived會將此節點從管理列表中踢出去，當此節點恢復後又將此節點加回管理列表，這樣可以就讓realserver負載均衡變的智能化。可是，此時的調度器存在單點故障的可能性，所以有必要對其實現高可用。算法

實現LVS高可用可使用多種軟件來實現，如heartbeat，可是heartbeat自己不能實現ipvs的健康情況檢查，須要搭配Ldirectord(安裝完heartbeat就有了)來進行健康檢查。所幸的是keepalived後來也加入了高可用的功能，並且配置起來也至關簡單。相比於heartbeat+Ldirectord，keepalived的檢查速度極快，故障轉移也極快，佈置也簡單的多。因此通常來講，要管理ipvs，都會選擇使用keepalived。下圖列出了構建LVS高可用的幾種工具：後端

keepalived實現故障轉移的功能是經過VRRP(virtual router redundancy protocol虛擬路由器冗餘協議)協議來實現的。 在keepalived正常工做的時候，主節點(master)會不斷的發送心跳信息給備節點(backup)，當備節點不能在必定時間內收到主節點的心跳信息時，備節點會認爲主節點宕了，而後會接管主節點上的資源，並繼續向外提供服務保證其可用性。當主節點恢復的時候，備節點會自動讓出資源並再次自動成爲備節點。bash

注意，使用keepalived監控、高可用LVS集羣時(即常說的keepalived+lvs)，並不須要在Director上使用ipvsadm等管理工具額外配置ipvs規則。由於keepalived中集合了管理ipvs規則的組件(即稍後模型圖中的ipvs wrapper)，能夠直接在keepalived的配置文件中配置ipvs相關規則，在解析配置文件時會經過特定的組件將規則發送到內核中的ipvs模塊。服務器

2. VRRP協議

VRRP協議的出現是爲了解決靜態路由的單點故障，它是經過一種競選機制來將路由任務交給某個vrrp路由器的。架構

在VRRP物理結構中，有多個物理的VRRP路由器，其中有一臺稱爲"master"即主節點路由器，其餘的都是"backup"備節點路由器，誰是master誰是backup，這是經過他們的優先級來定義競選的。app

在VRRP虛擬結構中，虛擬路由器是經過"MAC+VRID"的形式來標識的，如"00-00-5E-00-01-{VRID}"。在VRRP虛擬結構中，不論是master仍是backup，VRID必須一致。它們對外都是相同的VIP，客戶端並不須要由於master的切換而修改本身的路由配置。負載均衡

VRRP結構中路由器之間的通訊是經過IP多播的方式實現的(也能夠配置爲其它通訊方式)。可是，只有master節點纔會發送VRRP廣告包(vrrp advertisement message)。當master節點宕掉的時候，backup中優先級最高的VRRP設備會搶佔並升級爲master。dom

3.keepalived架構模型

Keepalived服務啓動的時候，將產生三個相關進程，一個父進程和兩個子進程。

PID    111     Keepalived  <-- Parent process fork and monitor children
       112     \_ Keepalived   <-- VRRP child
       113     \_ Keepalived   <-- Healthchecking child

父進程負責fork和監控子進程，所以父進程也稱爲WatchDog。兩個子進程都會開啓本地套接字Unix Domain Socket。當keepalived服務啓動後，父進程會經過unxi domain socket每隔5秒發送一個"Hello"消息給子進程，若是父進程沒法發送消息給子進程，將認爲子進程出現問題，因而會重啓子進程。

下圖是keepalived設計架構圖：

其中：

  • Checkers組件：負責RealServer的健康情況檢查，並在LVS的拓撲中移除、添加RealServer。它支持layer4/5/7層的協議檢查。該組件使用獨立的子進程負責，但被父進程監控。
  • VRRP組件：提供Director的故障轉移功能從而實現Director的高可用。該組件可獨立提供功能，無需LVS的支持。該組件使用獨立的子進程負責，但被父進程監控。
  • System Call組件：提供讀取自定義腳本的功能。該組件在使用時，將臨時產生一個子進程來執行任務。
  • IPVS wrapper組件：負責將配置文件中IPVS相關規則發送到內核的ipvs模塊。
  • Netlink Reflector：用來設定、監控vrrp的vip地址。

4.安裝keepalived

使用keepalived，徹底能夠yum安裝。本文僅給出編譯安裝的方法，後文的全部配置都使用yum安裝的keepalived。

官方各版本源碼下載地址：http://www.keepalived.org/download.html。如下是編譯安裝keepalived-1.2.19版本的過程。

yum -y install openssl-devel tar xf keepalived-1.2.19.tar.gz cd keepalived-1.2.19 ./configure --prefix=/usr/local/keepalived-1.2.19 make && make install

其中./configure的·--with-kernel-dir·是在管理LVS時須要使用的，若是不用配合LVS，則能夠不用此選項。

再作一下編譯安裝的規範行爲。

ln -s /usr/local/keepalived-1.2.19 /usr/local/keepalived
echo "MANPATH /usr/local/keepalived/share/man" >>/etc/man.config
echo "export PATH=/usr/local/keepalived/sbin:$PATH" > /etc/profile.d/keepalived.sh
chmod +x /etc/profile.d/keepalived.sh
. /etc/profile.d/keepalived.sh

編譯安裝後，在安裝目錄下生成如下一些目錄，其中keepalived程序在sbin目錄下。

[root@xuexi ~]# cd /usr/local/keepalived
[root@xuexi keepalived]# ls
bin  etc  lib  sbin  share

在etc目錄下，有配置文件、SysV管理腳本和大量配置文件示例。

[root@xuexi keepalived]# ls etc
keepalived  rc.d  sysconfig
[root@xuexi keepalived]# ls etc/keepalived/
keepalived.conf  samples
[root@xuexi keepalived]# ls etc/rc.d/init.d/
keepalived

但須要注意的是，這裏提供的SysV服務管理腳本是錯誤的，緣由是腳本中的keepalived命令路徑錯誤。因此修改該文件。

#原文
start() {
    echo -n $"Starting $prog: "
    daemon keepalived ${KEEPALIVED_OPTIONS}
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
}
#修改後
start() {
    echo -n $"Starting $prog: "
    daemon /usr/local/keepalived/sbin/keepalived ${KEEPALIVED_OPTIONS}
    RETVAL=$?
    echo
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
}

5.配置keepalived的日誌

默認keeepalived的日誌會記錄到/var/log/messages中。能夠配置keepalived使其記錄到其它文件中。

先修改/etc/sysconfig/keepalived文件，如下是原文內容。

# Options for keepalived. See `keepalived --help' output and keepalived(8) and
# keepalived.conf(5) man pages for a list of all options. Here are the most
# common ones :
#
# --vrrp -P Only run with VRRP subsystem.
# --check -C Only run with Health-checker subsystem.
# --dont-release-vrrp -V Dont remove VRRP VIPs & VROUTEs on daemon stop.
# --dont-release-ipvs -I Dont remove IPVS topology on daemon stop.
# --dump-conf -d Dump the configuration data.
# --log-detail -D Detailed log messages.
# --log-facility -S 0-7 Set local syslog facility (default=LOG_DAEMON)
#

KEEPALIVED_OPTIONS="-D"

要配置獨立的日誌，將其中的"KEEPALIVED_OPTIONS"改成以下：

KEEPALIVED_OPTIONS="-D -S 0"

上面配置使用local0這個設備來記錄日誌，所以去修改rsyslog的配置文件/etc/rsyslog.conf，添加該設備記錄日誌的級別和路徑。

# Keepalived log config
local0.*                           /var/log/keepalived.log

再重啓rsyslog。

service rsyslog restart

6.keepalived配置文件詳解

配置文件分爲3部分：全局部分、VRRPd部分(即實現高可用部分)以及LVS虛擬服務部分(健康情況檢查以及管理的集羣服務)。

選項不少，具體的意義能夠man keepalived.conf。默認內容以下：

! Configuration File for keepalived

global_defs {                    #全局部分定義郵件報警系統，能夠不用定義
   notification_email {          #定義郵件發送目標
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc  #定義郵件發送人
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id LVS_DEVEL         #標識keepalived服務器的字符串，實現高可用時須要使用它標識節點

        # 全局部分關於靜態地址和靜態路由的配置，能夠man keepalived.conf，不過幾乎不用配置這部分
}

#定義vrrp實例。一個配置文件中能夠實現多實例。但不一樣主機上互爲master<-->backup的實例名需相同
vrrp_instance VI_1 {         
    state MASTER           #定義實例的角色狀態是master仍是backup
    interface eth0         #定義vrrp綁定的接口，即接收或發送心跳通告的接口，即HA監測接口
    virtual_router_id 51   #虛擬路由標識(VRID)，同一實例該數值必須相同，即master和backup中該值相同
                           #同一網卡上的不一樣vrrp實例，該值必須不能相同。取值範圍0-255
    priority 100           #該vrrp實例中本機的keepalived的優先級，優先級最高的爲master。該選項的優先級
                           #高於state選項，即若state指定的是backup，但這裏設置的值最高，則仍爲master。
    advert_int 1           #心跳信息發送和接收時間間隔，單位爲秒
    authentication {       #認證方式，同一實例中這個配置必須徹底同樣纔可經過認證。只建議使用PASS認證
        auth_type PASS
        auth_pass 1111     #最多支持8字符，超過8字符將只取前8字符
    }
virtual_ipaddress {      #設置的VIP。只有master節點纔會設置。master出現故障後，VIP會故障轉移到backup。
                         #這些vip默認配置在interface指定的接口別名上，可以使用dev選項來指定配置接口。
                         #使用ip add的方式添加。若要被ifconfig查看，在IP地址後加上label便可。
                         #<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>
        192.168.200.16 label eth0:1
        192.168.200.17
        192.168.200.18
        192.168.200.19/24 dev eth1
    }
}

#定義虛擬服務部分
virtual_server 192.168.200.100 443 { #虛擬服務地址和端口，使用空格分隔，其中地址爲VIP
    delay_loop 6                     #健康檢查時間間隔
    lb_algo rr                       #定義負載均衡LB的算法，這裏使用的是rr調度算法
    lb_kind NAT                      #lvs的模型，有NAT/DR/TUN三種
    nat_mask 255.255.255.0
    persistence_timeout 50           #持久會話保持時長
    protocol TCP                     #監控服務的協議類型，1.3.0版本以前只支持tcp，以後還支持udp

    real_server 192.168.201.100 443 {   #定義real_server部分，地址和端口使用空格分隔
        weight 1       #LVS權重
        SSL_GET {      #健康情況檢查的檢查方式，常見的有HTTP_GET|SSL_GET|TCP_CHECK|MISC_CHECK。
            url {      
              path /   #指定ssl_get健康情況檢查的路徑，例如檢查index.html是否正常
              digest ff20ad2481f97b1754ef3e12ecd3a9cc  
                                #健康情況須要狀態碼，能夠是status_code、digest或digest+status_code
                                #digest值用keepalived的genhash命令生成，通常使用status_code便可
              status_code 200
            }
            url {
              path /mrtg/
              digest 9b3a0c85a887a256d6939da88aabd8cd
            }
            connect_timeout 3           #表示3秒無響應就超時，即此realserver不健康，需重試鏈接
            nb_get_retry 3              #表示重試3次，3次以後都超時就是宕機，防止誤傷(nb=number)
            delay_before_retry 3        #重試的時間間隔
                                        #上述配置需12秒才能判斷節點故障，時間過久，應改小
        }
    }
}

virtual_server 10.10.10.2 1358 {
    delay_loop 6
    lb_algo rr 
    lb_kind NAT
    persistence_timeout 50
    protocol TCP

    sorry_server 192.168.200.200 1358    #定義當全部Real server都宕機的時候，由哪臺服務器繼續提供服務
                                         #通常在keepalived本機給定一個web頁面，提示網站正在維護的信息

    real_server 192.168.200.2 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.200.3 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334c
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

virtual_server 10.10.10.3 1358 {
    delay_loop 3
    lb_algo rr 
    lb_kind NAT
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.200.4 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }

    real_server 192.168.200.5 1358 {
        weight 1
        HTTP_GET {
            url { 
              path /testurl/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl2/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            url { 
              path /testurl3/test.jsp
              digest 640205b7b0fc66c1ea91c463fac6334d
            }
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

關於配置文件中的幾種時間間隔：

  • advert_int N1：vrrp主備之間發送和接收心跳信息的時間間隔。和Checker組件無關。
  • delay_loop N2：是健康情況檢查的時間間隔。每隔幾秒就檢查一次。
  • connect_timeout N3：鏈接RS的超時時間，鏈接不上說明不健康，須要重試鏈接來斷定RS是否故障。
  • nb_get_retry N4：一個節點不健康的斷定重試次數。要重試N次，N次內都不健康說明節點故障了。
  • delay_before_retry N5：斷定某節點不健康後過N秒再進行重試斷定。

N2和N5的區別在於：當上一次健康檢查結果是正常的，將會隔N2秒再檢查。若是某次檢查不健康，即聯繫不上RS，則每隔N5秒重試一次，直到N4次後才斷定該RS已經故障。所以，最終須要N3+N4*N5才能斷定一個節點的故障。

雖然健康檢查的失敗次數是能夠指定的，但通常都會設置多於1次防止誤傷。另外，成功的檢查只需一次便可。

keepalived支持4層、5層和7層的健康情況檢查，按檢查類型又可分爲TCP檢查(4層)、HTTP檢查(5層)、SSL_HTTP檢查(5層)以及自定義的MISC檢查(可實現7層)。其中：

  • TCP_CHECK：經過TCP鏈接來檢查後端RS是否健康。
  • HTTP_GET：經過獲取指定頁面來檢查後端RS是否健康。是否健康是根據是否匹配digest、status_code來判斷的。
  • SSL_GET：和HTTP_GET同樣，只不過使用的協議是HTTPS。
  • MISC_CHECK：經過加載自定義健康情況檢查的腳原本檢查對象是否健康，要求這些腳本中健康與否的返回值爲0或1。

使用MISC_CHECK檢查時，方式以下：

MISC_CHECK {
    misc_path /path_to_script/script.sh
    (or misc_path 「 /path_to_script/script.sh <arg_list>」)
}
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程