keepalived實作服務高可用第1章 keepalived服務說明第2章 keepalived軟體使用

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

　　Keepalived軟體主要是通過VRRP協定實作高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛拟路由器備援協定）的縮寫，VRRP出現的目的就是為了解決靜态路由單點故障問題的，它能夠保證當個别節點當機時，整個網絡可以不間斷地運作。

　　是以，Keepalived 一方面具有配置管理LVS的功能，同時還具有對LVS下面節點進行健康檢查的功能，另一方面也可實作系統網絡服務的高可用功能。

　　管理LVS負載均衡軟體

　　實作LVS叢集節點的健康檢查中

　　作為系統網絡服務的高可用性（failover）

　　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路由器的。

Keepalived的工作原理：

　　Keepalived高可用對之間是通過VRRP通信的，是以，我們從 VRRP開始了解起：

　　　　1) VRRP,全稱 Virtual Router Redundancy Protocol,中文名為虛拟路由備援協定，VRRP的出現是為了解決靜态路由的單點故障。

　　　　2) VRRP是通過一種竟選協定機制來将路由任務交給某台 VRRP路由器的。

　　　　3) VRRP用 IP多點傳播的方式（預設多點傳播位址（224.0_0.18))實作高可用對之間通信。

　　　　4) 工作時主節點發包，備節點接包，當備節點接收不到主節點發的資料包的時候，就啟動接管程式接管主節點的開源。備節點可以有多個，通過優先級競選，但一般 Keepalived系統運維工作中都是一對。

　　　　5) VRRP使用了加密協定加密資料，但Keepalived官方目前還是推薦用明文的方式配置認證類型和密碼。

　　介紹完 VRRP,接下來我再介紹一下 Keepalived服務的工作原理：

　　Keepalived高可用對之間是通過 VRRP進行通信的， VRRP是遑過競選機制來确定主備的，主的優先級高于備，是以，工作時主會優先獲得所有的資源，備節點處于等待狀态，當主挂了的時候，備節點就會接管主節點的資源，然後頂替主節點對外提供服務。

　　在 Keepalived服務對之間，隻有作為主的伺服器會一直發送 VRRP廣播包,告訴備它還活着，此時備不會槍占主，當主不可用時，即備監聽不到主發送的廣播包時，就會啟動相關服務接管資源，保證業務的連續性.接管速度最快可以小于1秒。

 yum install keepalived -y 

第二個裡程碑： 進行預設配置測試

1-13行表示全局配置

15-30行 虛拟ip配置 brrp

配置管理LVS

主負載均衡伺服器配置

備負載均衡伺服器配置

測試連通性.    後端節點

　　Keepalived主備配置檔案差別：

　　　　01. router_id 資訊不一緻

　　　　02. state 狀态描述資訊不一緻

　　　　03. priority 主備競選優先級數值不一緻

    　　在高可用（HA）系統中，當聯系2個節點的“心跳線”斷開時，本來為一整體、動作協調的HA系統，就分裂成為2個獨立的個體。由于互相失去了聯系，都以為是對方出了故障。兩個節點上的HA軟體像“裂腦人”一樣，争搶“共享資源”、争起“應用服務”，就會發生嚴重後果——或者共享資源被瓜分、2邊“服務”都起不來了；或者2邊“服務”都起來了，但同時讀寫“共享存儲”，導緻資料損壞（常見如資料庫輪詢着的聯機日志出錯）。

 　　對付HA系統“裂腦”的對策，目前達成共識的的大概有以下幾條：

　　　　1）添加備援的心跳線，例如：雙線條線（心跳線也HA），盡量減少“裂腦”發生幾率；

　　　　2）啟用磁盤鎖。正在服務一方鎖住共享磁盤，“裂腦”發生時，讓對方完全“搶不走”共享磁盤資源。但使用鎖磁盤也會有一個不小的問題，如果占用共享盤的一方不主動“解鎖”，另一方就永遠得不到共享磁盤。現實中假如服務節點突然當機或崩潰，就不可能執行解鎖指令。後備節點也就接管不了共享資源和應用服務。于是有人在HA中設計了“智能”鎖。即：正在服務的一方隻在發現心跳線全部斷開（察覺不到對端）時才啟用磁盤鎖。平時就不上鎖了。

　　　　3）設定仲裁機制。例如設定參考IP（如網關IP），當心跳線完全斷開時，2個節點都各自ping一下參考IP，不通則表明斷點就出在本端。不僅“心跳”、還兼對外“服務”的本端網絡鍊路斷了，即使啟動（或繼續）應用服務也沒有用了，那就主動放棄競争，讓能夠ping通參考IP的一端去起服務。更保險一些，ping不通參考IP的一方幹脆就自我重新開機，以徹底釋放有可能還占用着的那些共享資源。

　　一般來說，裂腦的發生，有以下幾種原因：

　　　　 高可用伺服器對之間心跳線鍊路發生故障，導緻無法正常通信。

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

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

　　　　　　　　因心跳線間連接配接的裝置故障（網卡及交換機）。

　　　　　　　　因仲裁的機器出問題（采用仲裁的方案）。

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

　　　　 高可用伺服器上心跳網卡位址等資訊配置不正确，導緻發送心跳失敗。

　　　　 其他服務配置不當等原因，如心跳方式不同，心跳廣插沖突、軟體Bug等。

　　　　提示： Keepalived配置裡同一 VRRP執行個體如果 virtual_router_id兩端參數配置不一緻也會導緻裂腦問題發生。

　　在實際生産環境中，我們可以從以下幾個方面來防止裂腦問題的發生：

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

　　 當檢測到裂腦時強行關閉一個心跳節點（這個功能需特殊裝置支援，如Stonith、feyce）。相當于備節點接收不到心跳消患，通過單獨的線路發送關機指令關閉主節點的電源。

　　  做好對裂腦的監控報警（如郵件及手機短信等或值班）.在問題發生時人為第一時間介入仲裁，降低損失。例如，百度的監控報警短倍就有上行和下行的差別。報警消息發送到管理者手機上，管理者可以通過手機回複對應數字或簡單的字元串操作傳回給伺服器.讓伺服器根據指令自動處理相應故障，這樣解決故障的時間更短.

　　當然，在實施高可用方案時，要根據業務實際需求确定是否能容忍這樣的損失。對于一般的網站正常業務.這個損失是可容忍的。

　　備上面出現vip情況：

         　　1）腦裂情況出現

         　　2）正常主備切換也會出現

         編寫完腳本後要給腳本賦予執行權限

　　1）利用負載均衡伺服器，在伺服器上curl所有的節點資訊（web伺服器配置有問題）

　　2）curl 負載均衡伺服器位址，可以實作負載均衡

　　3）windows上綁定虛拟IP，浏覽器上進行測試

　　　　keepalived日志檔案位置 /var/log/messages

修改nginx監聽參數  listen 10.0.0.3:80; 

修改核心參數，實作監聽本地不存在的ip

　　編寫執行腳本

注意腳本的授權

　　說明 執行的腳本名稱盡量不要和服務名稱相同或相似

修改nginx配置檔案，讓bbs 與www分别監聽不同的ip位址

lb01

lb02

 本文出自“慘綠少年”，歡迎轉載，轉載請注明出處！http://blog.znix.top