Keepalived高可用集羣

時間  2019-11-09
標籤 keepalived 可用 集羣 欄目 負載均衡 简体版
原文   原文鏈接

Keepalived高可用集羣前端

1、Keepalived介紹

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

Keepalived軟件主要是經過VRRP協議實現高可用功能的。VRRP是Virtual Router Redundancy Protocol（虛擬路由器冗餘協議）的縮寫，VRRP出現的目的就是爲了解決靜態路由單點故障問題的，他可以保證當個別節點宕機時，整個網絡能夠不間斷地運行。因此，Keepalived一方面具備配置管理LVS的功能，同時還具備對LVS下面節點進行健康檢查的功能，另外一方面也可實現系統網絡服務的高可用功能。數據庫

Keepalived軟件的官方站點是http://www.keepalived.orgvim

2、Keepalived服務的三個重要功能

（1）管理LVS負載均衡軟件安全

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

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

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

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

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

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

3、Keepalived高可用故障切換轉移原理

Keepalived高可用服務之間的故障切換轉移，是經過VRRP（Virtual Router Redundancy Protocol，虛擬路由器冗餘協議）來實現的。

在Keepalived服務正常工做時，主Master節點會不斷地向備節點發送（多播的方式）心跳消息，用以告訴備Backup節點本身還活着，當主Master節點發生故障時，就沒法發送心跳消息，備節點也就所以沒法繼續檢測到來自主Master節點的心跳了，因而調用自身的接管程序，接管主Master節點的IP資源及服務。而當主Master節點恢復時，備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色。

那麼，什麼是VRRP呢？ 
VRRP，全稱Virtual Router Redundancy Protocol，中文名爲虛擬路由冗餘協議，VRRP的出現就是爲了解決靜態路由的單點故障問題，VRRP是經過一種競選機制來將路由的任務交給某臺VRRP路由器的。

VRRP早期是用來解決交換機，路由器等設備單點故障的，下面是交換，路由的Master和Backup切換原理描述，一樣適用於Keepalived的工做原理。

在一組VRRP路由器集羣中，有多臺物理VRRP路由器，可是這多臺物理的機器並非同時工做的，而是由一臺稱爲Master的機器負責路由工做，其餘的機器都是Backup。Master角色並不是一成不變的，VRRP會讓每一個VRRP路由參與競選，最終獲勝的就是Master。獲勝的Master有一些特權，好比擁有虛擬路由器的IP地址等，擁有系統資源的Master負責轉發發送給網關地址的包和響應ARP請求。

VRRP經過競選機制來實現虛擬路由器的功能，全部的協議報文都是經過IP多播（Multicast）包（默認的多播地址224.0.0.18）形式發送的。虛擬路由器由VRID（範圍0-225）和一組IP地址組成，對外表現爲一個周知的MAC地址：00-00-5E-00-01-{VRID}。因此，在一個虛擬路由器中，無論誰是Master，對外都是相同的MAC和IP（稱之爲VIP）。客戶端主機並不須要因Master的改變而修改本身的路由配置。對他們來講，這種切換是透明的。

在一組虛擬路由器中，只有做爲Master的VRRP路由器會一直髮送VRRP廣播包（VRRP Advertisement messages），此時Backup不會搶佔Master。當Master不可用時，Backup就收不到來自Master的廣播包了，此時多臺Backup中優先級最高的路由器會搶佔爲Master。這種搶佔是很是快速的（可能只有1秒甚至更少），以保證服務的連續性。出於安全性考慮，VRRP數據包使用了加密協議進行了加密。

4、VRRP通訊原理

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

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

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

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

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

5、Keepalived服務的工做原理

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

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

6、Keepalived高可用單實例服務搭建

虛擬機主從服務器各添加一塊網卡並開機配置網卡

cd /etc/sysconfig/network-scripts/

cp ifcfg-eth0 ifcfg-eth1

vim ifcfg-eth1 --->把網卡名換成eth1便可

硬件環境準備

準備4臺VM虛擬機，兩臺用來作Keepalived服務，兩臺作測試的Web節點

Nginx-Master IP：192.168.200.67 --->Keepalived主服務器（Nginx主負載均衡）

Nginx-Slave IP：192.168.200.71 --->Keepalived從服務器（Nginx從負載均衡）

Nginx-WEB1 IP：192.168.200.72 --->WEBA節點

Nginx-WEB2 IP：192.168.200.73 --->WEBB節點

安裝keepalived軟件

yum -y install keepalived

啓動Keepalived服務並檢查

啓動後有3個Keepalived進程表示安裝正確

打開keepalived主配置文件

vim /etc/keepalived/keepalived.conf
  1. ! Configuration File for keepalived
  2. global_defs {
  3. notification_email {
  4. 1123400300@qq.com
  5. }
  6. notification_email_from Alexandre.Cassen@firewall.loc
  7. smtp_server 127.0.0.1
  8. smtp_connect_timeout 30
  9. router_id lb01
  10. }
  12. vrrp_instance VI_1 {
  13. state MASTER
  14. interface eth1
  15. virtual_router_id 66
  16. priority 150
  17. advert_int 1
  18. authentication {
  19. auth_type PASS
  20. auth_pass 1111
  21. }
  22. virtual_ipaddress {
  23. 192.168.200.166/24 dev eth0 label eth0:1
  24. }
  25. }

主配置文件詳解

  1. 1123400300@qq.com --->郵箱隨便寫
  2. smtp_server 127.0.0.1 --->郵件服務器IP
  3. router_id lb01 --->lb表明負載均衡,不能和其餘Keepalived節點相同（全局惟一）
  4. vrrp_instance VI_1 { --->實例名字爲VI_1,相同實例的備節點名字要和這個相同
  5. state MASTER --->狀態爲MASTER，備節點狀態須要爲BACKUP
  6. interface eth1 --->通訊（心跳）接口爲eth1，此參數備節點設置和主節點相同
  7. virtual_router_id 66 --->實例ID爲66，要和備節點相同
  8. priority 150 --->優先級爲150，備節點的優先級必須比此數字低,通常爲100
  9. advert_int 1 --->通訊檢查間隔時間1秒,不須要改動
  10. auth_type PASS --->PASS認證類型，此參數備節點設置和主節點相同,用默認的就能夠
  11. auth_pass 1111 --->密碼1111，此參數備節點設置和主節點相同,用默認的就能夠
  12. 192.168.200.166/24 dev eth0 label eth0:1
  13. --->VIP地址,dev綁定的意思,label別名爲eth0:1,此參數備節點設置和主節點相同

 打開keepalived從配置文件

  1. ! Configuration File for keepalived
  3. global_defs {
  4. notification_email {
  5. 1123400300@qq.com
  6. }
  7. notification_email_from Alexandre.Cassen@firewall.loc
  8. smtp_server 127.0.0.1
  9. smtp_connect_timeout 30
  10. router_id lb02
  11. }
  13. vrrp_instance VI_1 {
  14. state BACKUP
  15. interface eth1
  16. virtual_router_id 66
  17. priority 100
  18. advert_int 1
  19. authentication {
  20. auth_type PASS
  21. auth_pass 1111
  22. }
  23. virtual_ipaddress {
  24. 192.168.200.166/24 dev eth0 label eth0:1
  25. }
  26. }

從配置文件基本改動

  1. router_id lb02 --->此參數和lb01 MASTER不一樣
  3. vrrp_instance VI_1 { --->lb01 MASTER相同
  5. state BACKUP --->此參數和lb01 MASTER不一樣
  7. interface eth1 --->和lb01 MASTER相同
  9. virtual_router_id 66 --->和lb01 MASTER相同
  11. priority 100 --->此參數和lb01 MASTER不一樣

配置文件參數詳解

  1. 第1行是註釋，！開頭和#號開發同樣，都是註釋。
  3. 第2行是空行。
  5. 第3~8行是定義服務故障報警的Email地址。做用是當服務發生切換或RS節點等有故障時，發報警郵件。這幾行是可選配置，notification_email指定在Keepalived發生事件時，須要發送的Email地址，能夠有多個，每行一個。
  7. 第9行是指定發送郵件的發送人，即發件人地址，也是可選的配置。
  9. 第10行smtp_server指定發送郵件的smtp服務器，若是本機開啓了sendmail或postfix，就可使用上面默認配置實現郵件發送，也是可選配置。
  11. 第11行smtp_connect_timeout是鏈接smtp的超時時間，也是可選配置。
  13. 注意：
  14. 第4~11行全部和郵件報警相關的參數都可以不配，在實際工做中會將監控的任務交給更加擅長監控報警的Nagios或Zabbix軟件。
  16. 第12行是Keepalived服務器的路由標識（router_id）.在一個局域網內，這個標識（router_id）應該是惟一的。
  17. 大括號「{}」。用來分隔區塊，要成對出現。若是漏寫了半個大括號，Keepalived運行時，不會報錯，但也不會獲得預期的結果。另外，因爲區塊間存在多層嵌套關係，所以很容易遺漏區塊結尾處的大括號，要特別注意。
  19. 第15行表示定義一個vrrp_instance實例，名字是VI_1,每一個vrrp_instance實例能夠認爲是Keepalived服務的一個實例或者做爲一個業務服務，在Keepalived服務配置中，這樣的vrrp_instance實例能夠有多個。注意，存在於主節點中的vrrp_instance實例在備節點中也要存在，這樣才能實現故障切換接管。
  21. 第16行state MASTER表示當前實例VI_1的角色狀態，當前角色爲MASTER，這個狀態只能有MASTER和BACKUP兩種狀態，而且須要大寫這些字符。其中MASTER爲正式工做的狀態，BACKUP爲備用的狀態。當MASTER所在的服務器故障或失效時，BACKUP所在的服務器會接管故障的MASTER繼續提供服務。
  23. 第17行interface爲網絡通訊接口。爲對外提供服務的網絡接口，如eth0,eth1。當前主流的服務器都有2~4個網絡接口，在選擇服務接口時，要搞清楚了。
  25. 第18行virtual_router_id爲虛擬路由ID標識，這個標識最好是一個數字，而且要在一個keepalived.conf配置中是惟一的。可是MASTER和BACKUP配置中相同實例的virtual_router_id又必須是一致的，不然將出現腦裂問題。
  27. 第19行priority爲優先級，其後面的數值也是一個數字，數字越大，表示實例優先級越高。在同一個vrrp_instance實例裏，MASTER的優先級配置要高於BACKUP的。若MASTER的priority值爲150，那麼BACKUP的priority必須小於150，通常建議間隔50以上爲佳，例如：設置BACKUP的priority爲100或更小的數值。
  29. 第20行advert_int爲同步通知間隔。MASTER與BACKUP之間通訊檢查的時間間隔，單位爲秒，默認爲1.
  31. 第21~24行authentication爲權限認證配置。包含認證類型（auth_type）和認證密碼（auth_pass）。認證類型有PASS（Simple Passwd（suggested）），AH（IPSEC（not recommended））兩種，官方推薦使用的類型爲PASS。驗證密碼爲明文方式，最好長度不要超過8個字符，建議用4位數字，同一vrrp實例的MASTER與BACKUP使用相同的密碼才能正常通訊。
  33. 第25 ~ 29 行virtual_ipaddress爲虛擬IP地址。能夠配置多個IP地址，每一個地址佔一行，配置時最好明確指定子網掩碼以及虛擬IP綁定的網絡接口。不然，子網掩碼默認是32位，綁定的接口和前面的interface參數配置的一致。注意，這裏的虛擬IP就是在工做中須要和域名綁定的IP，即和配置的高可用服務監聽的IP要保持一致！

單實例主備模式Keepalived配置文件對比

配置完成後，啓動Keepalived服務

/etc/init.d/keepalived start

這時候發現主服務器有eth0:1而從沒有,這就表明成功了

用主漂的IP進行wdinows頁面測試

 

用從漂的IP進行wdinows頁面測試

 

7、Keepalived高可用多實例服務搭建

原先的備配置文件(如今的主)

  1. ! Configuration File for keepalived
  3. global_defs {
  4. notification_email {
  5. 1123400300@qq.com
  6. }
  7. notification_email_from Alexandre.Cassen@firewall.loc
  8. smtp_server 127.0.0.1
  9. smtp_connect_timeout 30
  10. router_id lb02
  11. }
  13. vrrp_instance VI_1 {
  14. state BACKUP
  15. interface eth1
  16. virtual_router_id 66
  17. priority 100
  18. advert_int 1
  19. authentication {
  20. auth_type PASS
  21. auth_pass 1111
  22. }
  23. virtual_ipaddress {
  24. 192.168.200.166/24 dev eth0 label eth0:1
  25. }
  26. }
  27. vrrp_instance VI_2 {
  28. state MASTER
  29. interface eth1
  30. virtual_router_id 68
  31. priority 150
  32. advert_int 1
  33. authentication {
  34. auth_type PASS
  35. auth_pass 1111
  36. }
  37. virtual_ipaddress {
  38. 192.168.200.188/24 dev eth0 label eth0:2
  39. }
  40. }

原先的主配置文件(如今的備)

  1. ! Configuration File for keepalived
  3. global_defs {
  4. notification_email {
  5. 1123400300@qq.com
  6. }
  7. notification_email_from Alexandre.Cassen@firewall.loc
  8. smtp_server 127.0.0.1
  9. smtp_connect_timeout 30
  10. router_id lb01
  11. }
  13. vrrp_instance VI_1 {
  14. state MASTER
  15. interface eth1
  16. virtual_router_id 66
  17. priority 150
  18. advert_int 1
  19. authentication {
  20. auth_type PASS
  21. auth_pass 1111
  22. }
  23. virtual_ipaddress {
  24. 192.168.200.166/24 dev eth0 label eth0:1
  25. }
  26. }
  27. vrrp_instance VI_2 {
  28. state BACKUP
  29. interface eth1
  30. virtual_router_id 68
  31. priority 100
  32. advert_int 1
  33. authentication {
  34. auth_type PASS
  35. auth_pass 1111
  36. }
  37. virtual_ipaddress {
  38. 192.168.200.188/24 dev eth0 label eth0:2
  39. }
  40. }

多實例主測試階段

 

多實例備測試階段

 

8、Keepalived高可用服務器的「裂腦」問題

什麼是裂腦

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

致使裂腦發生的緣由

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

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

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

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

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

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

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

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

重點提示

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

解決裂腦的常見方案

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

 

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

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