Nginx+Keepalived高可用集羣應用實踐

時間 2019-11-11

標籤 nginx+keepalived nginx keepalived 可用集羣應用實踐欄目 Nginx 简体版

原文原文鏈接

Nginx+Keepalived高可用集羣應用實踐

1.Keepalived高可用軟件

1.1 Keepalived服務的三個重要功能

1.1.1管理LVS負載均衡軟件

早期的LVS軟件，須要經過命令行或腳本實現管理，而且沒有針對LVS節點的健康檢查功能。爲了解決LVS的這些使用不便問題，Keepalived誕生了，能夠說，Keepalived軟件起初是專爲解決LVS的問題而誕生的。所以，Keepalived和LVS的感情很深，他們的關係如同夫妻同樣，能夠緊密地結合，愉快地工做。Keepalived能夠經過讀取自身的配置文件，實現經過更底層的接口直接管理LVS的配置以及控制服務的啓動，中止功能，這使得LVS的應用更加簡單方便了。html

1.1.2實現對LVS集羣節點健康檢查功能（healthcheck）

前文已講過，Keepalived能夠經過在自身的Keepalived.conf文件裏配置LVS的節點IP和相關參數實現對LVS的直接管理；除此以外，當LVS集羣中的某一個甚至是幾個節點服務器同時發生故障沒法提供服務時，Keepalived服務會自動將失效的節點服務器從LVS的正常轉發隊列中清除出去，並將請求調度到別的正常節點服務器上，從而保證最終用戶的訪問不受影響；當故障的節點服務器被修復之後，Keepalived服務又會自動地把它們加入到正常轉發隊列中，對客戶提供服務。前端

1.1.3做爲系統網絡服務的高可用功能（failover）

Keepalived能夠實現任意兩臺主機之間，例如Master和Backup主機之間的故障轉移和自動切換，這個主機能夠是普通的不能停機的業務服務器，也能夠是LVS負載均衡，Nginx反向代理這樣的服務器。

Keepalived高可用功能實現的簡單原理爲，兩臺主機同時安裝好Keepalived軟件並啓動服務，開始正常工做時，由角色爲Master的主機得到全部資源並對用戶提供服務，角色爲Backup的主機做爲Master主機的熱備；當角色爲Master的主機失效或出現故障時，角色爲Backup的主機將自動接管Master主機的全部工做，包括接管VIP資源及相應資源服務；而當角色爲Master的主機故障修復後，又會自動接管回它原來處理的工做，角色爲Backup的主機則同時釋放Master主機失效時它接管的工做，此時，兩臺主機將恢復到最初啓動時各自的原始角色及工做狀態。

1.2解答Keepalived的工做原理

Keepalived高可用之間是經過VRRP通訊的ios

VRRP也就是虛擬路由冗餘協議，它的出現就是爲了解決靜態路由的單點故障。

VRRP是經過一種競選協議機制來將路由任務交給某臺VRRP路由器的。

VRRP用IP多播的方式（默認多播地址（224.0.0.18））實現高可用之間通訊。

工做時主節點發包，備節點接包，當備節點接收不到主節點發的數據包的時候，就啓動接管程序接管主節點的資源。備節點能夠有多個，經過優先級競選，但通常Keepalived系統運維工做中都是一對。

VRRP使用了加密協議加密數據，但Keepalived官方目前仍是推薦用明文的方式配置認證類型和密碼

1.3 Keepalived服務的工做原理：

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

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

2.Keepalived高可用服務搭建準備

2.1安裝Keepalived環境說明

2.1.1硬件環境準備

準備4臺物理服務器或4臺VM虛擬機，兩臺用來作Keepalived服務，兩臺作測試的Web節點以下表所示：nginx

HOSTNAME	IP	說明
lb01	192.168.200.64	Keepalived主服務器（Nginx主負載均衡器）
lb02	192.168.200.66	Keepalived備服務器（Nginx備負載均衡器）
web01	192.168.200.63	web01服務器
web02	192.168.200.60	web02服務器

2.1.2CentOS系統及Nginx代理環境

[root@lb01 /]# cat /etc/redhat-release
CentOS release 6.5 (Final)
[root@lb01 /]# uname -r
2.6.32-431.el6.x86_64
[root@lb01 /]# uname -m
x86_64

2.2爲服務器新開一個網卡`eth1`

[root@lb01 extar]# cd /etc/sysconfig/network-scripts/
[root@lb01 network-scripts]# cp ifcfg-eth0 ifcfg-eth1
[root@lb01 network-scripts]# cat ifcfg-eth1
DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=dhcp

[root@lb01 network-scripts]# ifup eth1
[root@lb01 network-scripts]# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:0C:29:BC:3F:E9  
          inet6 addr: fe80::20c:29ff:febc:3fe9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:241 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:66191 (64.6 KiB)  TX bytes:19038 (18.5 KiB)

提示：上述安裝過程須要在lb01和lb02兩臺服務器上同時安裝。web

2.3開始安裝Keepalived軟件

說明:下面有關Keepalived安裝，啓動服務的操做都是同時處理lb01，lb02兩臺機器數據庫

[root@lb01 /]# yum -y install keepalived
[root@lb01 /]# rpm -qa keepalived
keepalived-1.2.7-3.el6.x86_64

提示：centos

上述安裝過程須要在lb01和lb02兩臺服務器上同時安裝。

epalived版本爲2.7版

2.4啓動及檢查Keepalived服務的命令以下：

[root@lb01 /]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb01 /]# ps -ef | grep keep | grep -v grep
root     1479     1   0 00:42 ?   00:00:00  /usr/sbin/keepalived -D
root     1481   1479  0 00:42 ?   00:00:00  /usr/sbin/keepalived -D
root     1482   1479  0 00:42 ?   00:00:00  /usr/sbin/keepalived -D
#提示：啓動後有3個Keepalived進程表示安裝正確

[root@lb01 /]# ip add | grep 192.168
    inet 192.168.200.64/24 brd 192.168.200.255 scope global eth0
    inet 192.168.200.16/32 scope global eth0
    inet 192.168.200.17/32 scope global eth0
    inet 192.168.200.18/32 scope global eth0
    #提示：默認狀況會啓動三個VIP地址
    
[root@lb01 ~]# /etc/init.d/keepalived stop
Stopping keepalived:                                       [  OK  ]
#提示：測試完畢後關閉服務，上述測試須要同時在lb01和lb02兩臺服務器上進行

2.5 Keepalived配置文件說明

2.5.1全局定義（Global Definitions）部分

這部分主要用來設置Keepalived的故障通知機制和Router ID標識。示例代碼以下：瀏覽器

[root@lb01 ~]# head -13 /etc/keepalived/keepalived.conf | cat -n 
     1  ! Configuration File for keepalived
     2  
     3  global_defs {
     4     notification_email {
     5       acassen@firewall.loc
     6       failover@firewall.loc
     7       sysadmin@firewall.loc
     8     }
     9     notification_email_from Alexandre.Cassen@firewall.loc
    10     smtp_server 192.168.200.1
    11     smtp_connect_timeout 30
    12     router_id LVS_DEVEL
    13  }

基礎參數說明：bash

第1行是註釋，！開頭和#號開發同樣，都是註釋。

第2行是空行。

第3~8行是定義服務故障報警的Email地址。做用是當服務發生切換或RS節點等有故障時，發報警郵件。這幾行是可選配置，notification_email指定在Keepalived發生事件時，須要發送的Email地址，能夠有多個，每行一個.

第9行是指定發送郵件的發送人，即發件人地址，也是可選的配置。

第10行smtp_server指定發送郵件的smtp服務器，若是本機開啓了sendmail或postfix，就可使用上面默認配置實現郵件發送，也是可選配置。

第11行smtp_connect_timeout是鏈接smtp的超時時間，也是可選配置。

注意：服務器

第4~11行全部和郵件報警相關的參數都可以不配，在實際工做中會將監控的任務交給更加擅長監控報警的Nagios或Zabbix軟件。

第12行是Keepalived服務器的路由標識（router_id）.在一個局域網內，這個標識（router_id）應該是惟一的。
大括號「{}」。用來分隔區塊，要成對出現。若是漏寫了半個大括號，Keepalived運行時，不會報錯，但也不會獲得預期的結果。另外，因爲區塊間存在多層嵌套關係，所以很容易遺漏區塊結尾處的大括號，要特別注意。

2.5.2 VRRP實例定義區塊（VRRP instance（s））部分

[root@lb01 ~]# sed -n '15,30{=;p}' /etc/keepalived/keepalived.conf | xargs -L2
15 vrrp_instance VI_1 {
16 state MASTER
17 interface eth0
18 virtual_router_id 51
19 priority 100
20 advert_int 1
21 authentication {
22 auth_type PASS
23 auth_pass 1111
24 }
25 virtual_ipaddress {
26 192.168.200.16
27 192.168.200.17
28 192.168.200.18
29 }
30 }

參數說明：

第15行表示定義一個vrrp_instance實例，名字是VI_1,每一個vrrp_instance實例能夠認爲是Keepalived服務的一個實例或者做爲一個業務服務，在Keepalived服務配置中，這樣的vrrp_instance實例能夠有多個。注意，存在於主節點中的vrrp_instance實例在備節點中也要存在，這樣才能實現故障切換接管。

第16行state MASTER表示當前實例VI_1的角色狀態，當前角色爲MASTER，這個狀態只能有MASTER和BACKUP兩種狀態，而且須要大寫這些字符。其中MASTER爲正式工做的狀態，BACKUP爲備用的狀態。當MASTER所在的服務器故障或失效時，BACKUP所在的服務器會接管故障的MASTER繼續提供服務。

第17行interface爲網絡通訊接口。爲對外提供服務的網絡接口，如eth0,eth1。當前主流的服務器都有2~4個網絡接口，在選擇服務接口時，要搞清楚了。

第18行virtual_router_id爲虛擬路由ID標識，這個標識最好是一個數字，而且要在一個keepalived.conf配置中是惟一的。可是MASTER和BACKUP配置中相同實例的virtual_router_id又必須是一致的，不然將出現腦裂問題。

第19行priority爲優先級，其後面的數值也是一個數字，數字越大，表示實例優先級越高。在同一個vrrp_instance實例裏，MASTER的優先級配置要高於BACKUP的。若MASTER的priority值爲150，那麼BACKUP的priority必須小於150，通常建議間隔50以上爲佳，例如：設置BACKUP的priority爲100或更小的數值。

第20行advert_int爲同步通知間隔。MASTER與BACKUP之間通訊檢查的時間間隔，單位爲秒，默認爲1.

第21~24行authentication爲權限認證配置。包含認證類型（auth_type）和認證密碼（auth_pass）。認證類型有PASS（Simple Passwd（suggested）），AH（IPSEC（not recommended））兩種，官方推薦使用的類型爲PASS。驗證密碼爲明文方式，最好長度不要超過8個字符，建議用4位數字，同一vrrp實例的MASTER與BACKUP使用相同的密碼才能正常通訊。

第25 ~ 29 行virtual_ipaddress爲虛擬IP地址。能夠配置多個IP地址，每一個地址佔一行，配置時最好明確指定子網掩碼以及虛擬IP綁定的網絡接口。不然，子網掩碼默認是32位，綁定的接口和前面的interface參數配置的一致。注意，這裏的虛擬IP就是在工做中須要和域名綁定的IP，即和配置的高可用服務監聽的IP要保持一致！

3.Keepalived高可用服務單實例實戰

3.1實戰配置Keepalived主服務器lb01 MASTER

[root@lb01 keepalived]# pwd
/etc/keepalived
[root@lb01 keepalived]# cat keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
    1773464408@qq.com       #郵箱隨便寫
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1    #郵件服務器IP
}
   smtp_connect_timeout 30
   router_id yang1    #id爲yang1，不能和其餘Keepalived節點相同（全局惟一）
}

vrrp_instance VI_1 {        #實例名字爲VI_1,相同實例的備節點名字要和這個相同
state MASTER                #狀態爲MASTER，備節點狀態須要爲BACKUP
    interface eth1          #通訊（心跳）接口爲eth1，此參數備節點設置和主節點相同
    virtual_router_id 55    #實例ID爲55，要和備節點相同
    priority 150            #優先級爲150，備節點的優先級必須比此數字低
    advert_int 1            #通訊檢查間隔時間1秒
    authentication { 
        auth_type PASS      #PASS認證類型，此參數備節點設置和主節點相同
        auth_pass 1111      #密碼1111，此參數備節點設置和主節點相同
    }
    virtual_ipaddress {
        192.168.200.123/24 dev eth0 label eth0:1
  #虛擬IP，即VIP爲192.168.200.123,子網掩碼爲24位，綁定接口爲eth0，別名爲eth0：1，此參數備節點設置和主節點相同
   }
}

3.2啓動Keepalived服務

[root@lb01 keepalived]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

3.3檢查配置結果，查看是否有虛擬IP 192.168.200.123

[root@lb01 keepalived]# ip a | grep 192.168.200.123
    inet 192.168.81.123/24 scope global eth0:1
    #出現上述帶有vip:192.168.200.123行的結果表示lb01的Keepalived服務單實例配置成功

3.4實戰配置Keepalived備服務器lb02 BACKUP

[root@lb02 keepalived]# pwd
/etc/keepalived
[root@lb02 keepalived]# cat keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
    1773464408@qq.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
}
   smtp_connect_timeout 30
   router_id yang2         #此參數和lb01 MASTER不一樣
}

vrrp_instance VI_1 {       #和lb01 MASTER相同
    state BACKUP           #此參數和lb01 MASTER不一樣
    interface eth1         #和lb01 MASTER相同
    virtual_router_id 55   #和lb01 MASTER相同
    priority 100           #此參數和lb01 MASTER不一樣
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.123/24 dev eth0 label eth0:1
   }
}

3.5啓動Keepalived服務

[root@lb02 keepalived]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

3.6檢查配置結果，查看是否有虛擬IP 192.168.200.123

[root@lb02 keepalived]# ip a | grep 192.168.200.123
[root@lb02 keepalived]# 
    #這裏沒有返回任何結果就對了，由於lb02爲BACKUP，當主節點活着的時候，它不會接管VIP 192.168.200.123

出現上述無任何結果的現象，表示lb02的Keepalived服務單實例配置成功。若是配置過濾後有192.168.200.123的IP，則表示Keepalived工做不正常，同一個IP地址同一時刻應該只能出現一臺服務器。

若是查看BACKUP備節點VIP有以下信息，說明高可用裂腦了，裂腦是兩臺服務器爭搶同一資源致使的，例如：兩邊都配置了同一個VIP地址。

出現上述兩臺服務器爭搶同一IP資源問題，通常要先考慮排查兩個地方：
1）主備兩臺服務器對應的Keepalived.conf配置文件是否有錯誤？例如，是否同一實例的virtual_router_id配置不一致。

3.7進行高可用主備服務器切換實驗

[root@lb01 keepalived]# ip a | grep 192.168.200.123   #虛擬VIP在lb01服務器上
    inet 192.168.200.123/24 scope global eth0:1
[root@lb01 keepalived]# /etc/init.d/keepalived stop  #停掉服務
Stopping keepalived:                                       [  OK  ]
[root@lb01 keepalived]# ip a | grep 192.168.200.123   #虛擬VIP消失了
[root@lb01 keepalived]# 

#再檢查lb02服務器
[root@lb02 keepalived]# ip a | grep 192.168.200.123   #虛擬VIP出如今了lb02上
    inet 192.168.200.123/24 scope global eth0:1

咱們能夠發現，備節點lb02已經接管綁定了192.168.200.123這個VIP，這期間備節點還會發送ARP廣播，讓全部的客戶端更新本地的ARP表，以便客戶端訪問新接管VIP服務的節點。

此時若是再啓動主服務器的Keepalived服務，主服務器就會接管回VIP 192.168.200.123，啓動後能夠觀察下主備的IP漂移狀況，備服務器是否釋放了IP？主服務器是否又接管了IP？

3.8主節點啓動Keepalived服務後，發現很快就又接管了VIP192.168.200.123，操做及檢查步驟以下

[root@lb01 keepalived]# ip a | grep 192.168.200.123
[root@lb01 keepalived]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb01 keepalived]# ip a | grep 192.168.200.123
    inet 192.168.200.123/24 scope global eth0:1

#與此同時，備節點上的VIP 192.168.200.123則被釋放了，以下：
[root@lb02 keepalived]# ip a | grep 192.168.200.123
#這樣就實現了單實例Keepalived服務IP自動漂移接管了，VIP飄逸到了新機器新服務上，用戶的訪問請求天然就會找新機器新服務了

說明：

這裏僅實現了VIP的自動漂移切換，所以，僅適合兩臺服務器提供的服務均保持開啓的應用場景，這也是工做中經常使用的高可用解決方案。

3.9單實例主備模式Keepalived配置文件對比(只有三項不一樣)

Keepalived配置參數	MASTER節點特殊參數	BACKUP節點特殊參數
router_id(惟一標識)	router_id yang1	router_id yang2
state（角色狀態）	state MASTER	state BACKUP
priority(競選優先級)	priority 150	priority 100

4.Keepalived高可用服務器的「裂腦」問題

4.1什麼是裂腦

因爲某些緣由，致使兩臺高可用服務器對在指定時間內，沒法檢測到對方的心跳消息，各自取得資源及服務的全部權，而此時的兩臺高可用服務器對都還活着並在正常運行，這樣就會致使同一個IP或服務在兩端同時存在而發生衝突，最嚴重的是兩臺主機佔用同一個VIP地址，當用戶寫入數據時可能會分別寫入到兩端，這可能會致使服務器兩端的數據不一致或形成數據丟失，這種狀況就被稱爲裂腦。

4.2致使裂腦發生的緣由

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

心跳線壞了（包括斷了,老化）

網卡及相關驅動壞了，IP配置及衝突問題（網卡直連）。

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

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

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

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

其餘服務配置不當等緣由，如心跳方式不一樣，心跳廣播衝突，軟件BUG等

提示：

Keepalived配置裏同一VRRP實例若是virtual_router_id兩端參數配置不一致，也會致使裂腦問題發生.

4.3在實際生產環境中，咱們能夠從如下幾個方面來防止裂腦問題的發生：

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

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

作好對裂腦的監控報警（如郵件及手機短信等或值班），在問題發生時人爲第一時間介入仲裁，下降損失。例如，百度的監控報警短信就有上行和下行的區別。報警信息發送到管理員手機上，管理員能夠經過手機回覆對應數字或簡單的字符串操做返回給服務器，讓服務器根據指令自動處理相應故障，這樣解決故障的時間更短。

固然，在實施高可用方案時，要根據業務實際需求肯定是否能容忍這樣的損失。對於通常的網站常規業務，這個損失是可容忍的。

4.4解決Keepalived裂腦的常見方案

做爲互聯網應用服務器的高可用，特別是前端Web負載均衡器的高可用，裂腦的問題對普通業務的影響是能夠忍受的，若是是數據庫或者存儲的業務，通常出現裂腦問題就很是嚴重了。所以，能夠經過增長冗餘心跳線路來避免裂腦問題的發生，同時增強對系統的監控，以便裂腦發生時人爲快速介入解決問題。

若是開啓防火牆，必定要讓心跳消息經過，通常經過容許IP段的形式解決。

能夠拉一條以太網網線或者串口線做爲主被節點心跳線路的冗餘。

開發檢測程序經過監控軟件（例如Nagios）檢測裂腦。

4.5生產場景檢測裂腦故障的一些思路

簡單判斷的思想：只要備節點出現VIP就報警，這個報警有兩種狀況，一是主機宕機了備機接管了；二是主機沒宕，裂腦了。無論屬於哪一個狀況，都進行報警，而後由人工查看判斷及解決。

比較嚴謹的判斷：備節點出現對應VIP，而且主節點及對應服務（若是能遠程鏈接主節點看是否有VIP就更好了）還活着，就說明發生裂腦了。

5.Keepalived雙實例雙主模式配置實戰

5.1下圖爲Keepalived雙實例雙主模式IP及VIP規劃表

HOSTNAME	IP	說明
lb01	192.168.200.64	VIP:192.168.81.123(用於綁定A服務www.yunjisuan.com域名)
lb02	192.168.200.66	VIP:192.168.81.124(用於綁定B服務bbs.yunjisuan.com域名)

5.2配置lb01的Keepalived.conf，在單實例的基礎上增長一個`vrrp_instance VI_2`實例

[root@lb01 keepalived]# pwd
/etc/keepalived
[root@lb01 keepalived]# cat keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
    1773464408@qq.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
}
   smtp_connect_timeout 30
   router_id yang1
}

vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 55
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.123/24 dev eth0 label eth0:1 
  
   }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth1
    virtual_router_id 56
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.124/24 dev eth0 label eth0:2 
  
   }
}

#提示：
以vrrp_instance VI_1在lb01 192.168.200.64服務器上的角色爲主
以vrrp_instance VI_2在lb01 192.168.200.66服務器上的角色爲備

5.3配置lb02的Keepalived.conf，在單實例的基礎上增長一個`vrrp_instance VI_2`實例

[root@lb02 keepalived]# pwd
/etc/keepalived
[root@lb02 keepalived]# cat keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
    1773464408@qq.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
}
   smtp_connect_timeout 30
   router_id yang2
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 55
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.123/24 dev eth0 label eth0:1
  
   }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth1
    virtual_router_id 56
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.200.124/24 dev eth0 label eth0:2
  
   }
}

#提示：
以vrrp_instance VI_1在lb01 192.168.200.66服務器上的角色爲主
以vrrp_instance VI_2在lb01 192.168.200.64服務器上的角色爲備

5.4實戰演練

5.4.1在lb01上進行以下操做：

[root@lb01 keepalived]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb01 keepalived]# ip a | egrep "192.168.200.123|192.168.200.124"
    inet 192.168.200.123/24 scope global secondary eth0:1
    inet 192.168.200.124/24 scope global secondary eth0:2

#因爲lb02還沒開服務,主備VIP都顯示在lb01上

5.4.2在lb02上進行以下操做：

[root@lb02 keepalived]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb02 keepalived]# ip a | egrep "192.168.200.123|192.168.200.124"
    inet 192.168.200.124/24 scope global secondary eth0:2

#lb01開啓的狀況下，lb02開啓服務後，只顯示了vrrp_instance VI_2實例lb02做爲主模式的VIP 192.168.0.124

[root@lb01 keepalived]# ip a | egrep "192.168.200.123|192.168.200.124"
    inet 192.168.200.123/24 scope global secondary eth0:1

#lb01上只有192.168.0.123了

5.4.3宕掉lb01進行實驗

[root@lb01 keepalived]# /etc/init.d/keepalived stop
Stopping keepalived:                                       [  OK  ]
[root@lb01 keepalived]# ip a | egrep "192.168.200.123|192.168.200.124"
[root@lb01 keepalived]#  #宕掉lb01後發現什麼VIP都沒有顯示

[root@lb02 keepalived]# ip a | egrep "192.168.200.123|192.168.200.124"
    inet 192.168.200.124/24 scope global secondary eth0:2
    inet 192.168.200.123/24 scope global secondary eth0:1
    
#因爲lb01宕掉以後，主備VIP都顯示在lb02上了

特別提示：

若是測試結果不符，請查看是否沒有關閉iptables,eth1有沒有掉線
到此爲止，咱們發現lb01，lb02主備節點已經實現了初始配置的VIP服務狀態，當任意一端宕機，VIP能夠實現互相切換接管。在實際工做中，能夠把www.yunjisuan.com解析到192.168.200.123提供服務，把bbs.yunjisuan.com解析到192.168.200.124提供服務，固然了，lb01，lb02也要配置相應服務，例如：Nginx反向代理服務等。

5.5 雙實例雙主模式的配置文件對比

tate（狀態）

priority(精選優先級)
其中優先級決定VIP在哪一個機器上初始運行

6.Nginx負載均衡配合Keepalived服務案例實戰

注意：調整好主負載均衡器lb01，備用負載均衡器lb02服務器上Nginx負載均衡環境，兩臺服務器的安裝基礎環境如出一轍

6.1在lb01和lb02上配置Nginx負載均衡

[root@lb01 /]# cat /usr/local/nginx/conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    upstream www_server_pools {          
    server 192.168.200.63:80 weight=1;    
    server 192.168.200.60:80 weight=1;    
    }

    server {             
        listen       80;
        server_name  www.yunjisuan.com;
        location / {
        proxy_pass http://www_server_pools;
        include extar/proxy.conf;   
        }
    }
}

6.2在lb01和lb02上配置Keepalived服務(與上面實驗配置同樣)

6.3 用戶訪問準備

6.3.1準備工做

在客戶端hosts文件裏把www.yunjisuan.com域名解析到VIP 192.168.0.240上，正式場景需經過DNS解析

6.3.2下面模擬實際的訪問過程

6.3.3如今模擬宕掉lb01

[root@lb01 /]# /etc/init.d/keepalived stop
Stopping keepalived:                                       [  OK  ]
[root@lb01 /]# ip a | grep 192.168.200.123

[root@lb02 /]#  ip a | grep 192.168.200.123
    inet 192.168.200.123/24 scope global secondary eth0:1
    
#觀察lb02備節點是否接管了VIP 192.168.200.123/24

6.3.4再次在客戶端瀏覽器輸入www.yunjisuan.com測試訪問

6.3.5從新開啓lb01的Keepalived服務

[root@lb01 /]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb01 /]# ip a | grep 192.168.200.123
    inet 192.168.200.123/24 scope global secondary eth0:1
    
#能夠看到，VIP很快就接管回來了，此時瀏覽器訪問結果依然正常

[root@lb02 /]# ip a | grep 192.168.200.123
[root@lb02 /]#

7.解決高可用服務只針對物理服務器的問題

默認狀況下Keepalived軟件僅僅在對方機器宕機或Keepalived停掉的時候纔會接管業務。但在實際工做中，有業務服務中止而Keepalived服務還在工做的狀況，這就會致使用戶訪問的VIP沒法找到對應的服務，那麼，如何解決業務服務宕機能夠將IP漂移到備節點使之接管提供服務呢？

7.1能夠寫守護進程腳原本處理。

當Nginx業務有問題時，就停掉本地的Keepalived服務，實現IP漂移到對端繼續提供服務。

7.1.1實際工做中部署及開發的示例腳本以下：

[root@lb01 scripts]# cat check_nginx.sh
#!/bin/sh
while true
do
    if [ `netstat -antup | grep nginx | wc -l` -ne 1 ];then
        /etc/init.d/keepalived stop
    fi
    sleep 5
done

#此腳本的基本思想是若沒有80端口存在，就停掉Keepalived服務實現釋放本地的VIP

7.1.2在後臺執行上述腳本並檢查：

[root@lb01 scripts]# sh check_nginx.sh &
[1] 1521
[root@lb01 scripts]# ps -ef | grep check | grep -v grep
root       1521   1195  0 10:49 pts/0    00:00:00 sh check_nginx.sh
#確認Nginx以及Keepalived服務是正常的

[root@lb01 scripts]# netstat -antup | grep nginx
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      1492/nginx          
[root@lb01 scripts]# /etc/init.d/keepalived status
keepalived (pid  1512) is running...

#而後模擬Nginx服務掛掉，看IP是否發生切換。
[root@lb01 scripts]# /usr/local/nginx/sbin/nginx -s stop
[root@lb01 scripts]# Stopping keepalived:                  [  OK  ]
[root@lb01 scripts]# /etc/init.d/keepalived status
keepalived is stopped

[root@lb01 scripts]# netstat -antup | grep nginx
#此時，備節點已接管：
[root@lb02 ~]# ip a | grep 192.168.0.240
    inet 192.168.0.240/24 scope global secondary eth0:1

7.2可使用Keepalived的配置文件參數觸發寫好的監測服務腳本。

7.2.1首先要開發檢測服務腳本(注意這個腳本與上一個腳本的不一樣)

[root@lb01 scripts]# cat chk_nginx_proxy.sh 
#!/bin/bash
if [ `netstat -antup | grep nginx | wc -l` -ne 1 ];then
    /etc/init.d/keepalived stop
fi

7.2.2

[root@lb01 scripts]# chmod +x chk_nginx_proxy.sh 
[root@lb01 scripts]# ls -l chk_nginx_proxy.sh 
-rwxr-xr-x. 1 root root 102 Jul 31 10:59 chk_nginx_proxy.sh
此時，Keepalived服務的完整配置爲：

[root@lb01 scripts]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
   notification_email {
    1773464408@qq.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id yang1
}
vrrp_script chk_nginx_proxy {       #定義vrrp腳本，檢測HTTP端口
    script "/server/scripts/chk_nginx_proxy.sh"     #執行腳本，當Nginx服務有問題，就停掉Keepalived服務
    interval 2          #間隔2秒
    weight 2
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 55
    priority 150
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    192.168.200.123/24 dev eth0 label eth0:1
    }
    track_script {
    chk_nginx_proxy         #觸發檢查
    }
}

7.2.3下面測試接管結果

#先殺掉以前的後臺進程腳本的運行，以後進行以下操做
[root@lb01 scripts]# /usr/local/nginx/sbin/nginx 
[root@lb01 scripts]# netstat -antup | grep nginx
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      3937/nginx          
[root@lb01 scripts]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@lb01 scripts]# /etc/init.d/keepalived status
keepalived (pid  3949) is running...
[root@lb01 scripts]# ip a | grep 192.168.0.240
    inet 192.168.0.240/24 scope global secondary eth0:1
[root@lb01 scripts]# /usr/local/nginx/sbin/nginx -s stop
[root@lb01 scripts]# ip a | grep 192.168.0.240
[root@lb01 scripts]# /etc/init.d/keepalived status
keepalived is stopped
#當停掉Nginx的時候，Keepalived 2秒鐘內會被自動停掉，VIP被釋放，由對端接管，這樣就實現了即便服務宕機也會進行IP漂移，業務切換。

8.解決多組Keepalived服務器在一個局域網的衝突問題

當在同一個局域網內部署了多組Keepalived服務器對，而又未使用專門的心跳線通訊時，可能會發生高可用接管的嚴重故障問題。以前已經講解過Keepalived高可用功能是經過VRRP協議實現的，VRRP協議默認經過IP多播的形式實現高可用對之間的通訊，若是同一個局域網內存在多組Keepalived服務器對，就會形成IP多播地址衝突問題，致使接管錯亂，不一樣組的Keepalived都會使用默認的224.0.0.18做爲多播地址。此時的解決辦法是，在同組的Keepalived服務器全部的配置文件裏指定獨一無二的多播地址，配置以下：

global_defs {

router_id LVS_19
vrrp_mcast_group4 224.0.0.19    #這個就是指定多播地址的配置

}

#提示：
1）不一樣實例的通訊認證密碼也最好不一樣，以確保接管正常。
2）另外一款高可用軟件Heartbeat，若是採用多播方式實現主備通訊，一樣會有多播地址衝突問題。

9.開發檢測Keepalived裂腦的腳本

檢測思路：在備節點上執行腳本，若是能夠ping通主節點而且備節點有VIP就報警，讓人員介入檢查是否裂腦。

9.1在lb02備節點開發腳本並執行

[root@lb02 scripts]# cat check_split_brain.sh 
#!/bin/bash
lb01_vip=192.168.200.123
lb01_ip=192.168.200.64
while true
do
    ping -c 2 -W 3 $lb01_ip &>/dev/null
    if [ $? -eq 0 -a `ip a | grep "$lb01_vip" | wc -l` -eq 1 ];then
        echo "ha is split brain.warning."
    else
        echo "ha is OK"
    fi
    sleep 5
done
[root@lb02 scripts]# sh check_split_brain.sh 
ha is OK
ha is OK
ha is OK

#正常狀況下，主節點活着，VIP 192.168.200.123在主節點，所以不會報警，提示「ha is OK」

9.2關掉lb01服務器

[root@lb01 scripts]# /etc/init.d/keepalived stop
Stopping keepalived:                                       [  OK  ]
[root@lb01 scripts]# ip a | grep 192.168.200.123
[root@lb01 scripts]#

9.3再觀察lb02腳本的輸出。

[root@lb02 scripts]# sh check_split_brain.sh 
ha is OK
ha is OK
ha is OK
ha is split brain.warning.
ha is split brain.warning.
ha is split brain.warning.
ha is OK
ha is OK
ha is OK
#裂腦報警恢復了。