轉載自:https://blog.csdn.net/u010391029/article/details/48311699php
1. 前言
VRRP(Virtual Router Redundancy Protocol)協議是用於實現路由器冗餘的協議,最新協議在RFC3768中定義,原來的定義RFC2338被廢除,新協議相對還簡化了一些功能。
2. 協議說明
2.1 協議
VRRP協議是爲消除在靜態缺省路由環境下的缺省路由器單點故障引發的網絡失效而設計的主備模式的協議,使得在發生故障而進行設備功能切換時能夠不影響內外數據通訊,不須要再修改內部網絡的網絡參數。VRRP協議須要具備IP地址備份,優先路由選擇,減小沒必要要的路由器間通訊等功能。
VRRP協議將兩臺或多臺路由器設備虛擬成一個設備,對外提供虛擬路由器IP(一個或多個),而在路由器組內部,若是實際擁有這個對外IP的路由器若是工做正常的話就是MASTER,或者是經過算法選舉產生,MASTER實現針對虛擬路由器IP的各類網絡功能,如ARP請求,ICMP,以及數據的轉發等;其餘設備不擁有該IP,狀態是BACKUP,除了接收MASTER的VRRP狀態通告信息外,不執行對外的網絡功能。當主機失效時,BACKUP將接管原先MASTER的網絡功能。
配置VRRP協議時須要配置每一個路由器的虛擬路由器ID(VRID)和優先權值,使用VRID將路由器進行分組,具備相同VRID值的路由器爲同一個組,VRID是一個0~255的正整數;同一組中的路由器經過使用優先權值來選舉MASTER,優先權大者爲MASTER,優先權也是一個0~255的正整數。
VRRP協議使用多播數據來傳輸VRRP數據,VRRP數據使用特殊的虛擬源MAC地址發送數據而不是自身網卡的MAC地址,VRRP運行時只有MASTER路由器定時發送VRRP通告信息,表示MASTER工做正常以及虛擬路由器IP(組),BACKUP只接收VRRP數據,不發送數據,若是必定時間內沒有接收到MASTER的通告信息,各BACKUP將宣告本身成爲MASTER,發送通告信息,從新進行MASTER選舉狀態。
2.2 MASTER選舉
若是對外的虛擬路由器IP就是路由器自己配置的IP地址的話,該路由器始終都是MASTER;
不然若是不具有虛擬IP的話,將進行MASTER選舉,各路由器都宣告本身是MASTER,發送VRRP通告信息;
若是收到其餘機器的發來的通告信息的優先級比本身高,將轉回BACKUP狀態;
若是優先級相等的話,將比較路由器的實際IP,IP值較大的優先權高;
不過若是對外的虛擬路由器IP就是路由器自己的IP的話,該路由器始終將是MASTER,這時的優先級值爲255。
2.3 協議狀態機
VRRP協議狀態比較簡單,就三種狀態,初始化,主機,備份機。html
|
初始化:
路由器啓動時,若是路由器的優先級是255(最高優先級,路由器擁有路由器地址),要發送VRRP通告信息,併發送廣播ARP信息通告路由器IP地址對應的MAC地址爲路由虛擬MAC,設置通告信息定時器準備定時發送VRRP通告信息,轉爲MASTER狀態;
不然進入BACKUP狀態,設置定時器檢查定時檢查是否收到MASTER的通告信息。
主機:
主機狀態下的路由器要完成以下功能:
設置定時通告定時器;
用VRRP虛擬MAC地址響應路由器IP地址的ARP請求;
轉發目的MAC是VRRP虛擬MAC的數據包;
若是是虛擬路由器IP的擁有者,將接受目的地址是虛擬路由器IP的數據包,不然丟棄;
當收到shutdown的事件時刪除定時通告定時器,發送優先權級爲0的通告包,轉初始化狀態;
若是定時通告定時器超時時,發送VRRP通告信息;
收到VRRP通告信息時,若是優先權爲0,發送VRRP通告信息;不然判斷數據的優先級是否高於本機,或相等並且實際IP地址大於本地實際IP,設置定時通告定時器,復位主機超時定時器,轉BACKUP狀態;不然的話,丟棄該通告包;
備機:
備機狀態下的路由器要實現如下功能:
設置主機超時定時器;
不能響應針對虛擬路由器IP的ARP請求信息;
丟棄全部目的MAC地址是虛擬路由器MAC地址的數據包;
不接受目的是虛擬路由器IP的全部數據包;
當收到shutdown的事件時刪除主機超時定時器,轉初始化狀態;
主機超時定時器超時的時候,發送VRRP通告信息,廣播ARP地址信息,轉MASTER狀態;
收到VRRP通告信息時,若是優先權爲0,表示進入MASTER選舉;不然判斷數據的優先級是否高於本機,若是高的話認可MASTER有效,復位主機超時定時器;不然的話,丟棄該通告包;
2.4 ARP查詢處理
當內部主機經過ARP查詢虛擬路由器IP地址對應的MAC地址時,MASTER路由器回覆的MAC地址爲虛擬的VRRP的MAC地址,而不是實際網卡的MAC地址,這樣在路由器切換時讓內網機器覺察不到;而在路由器從新啓動時,不能主動發送本機網卡的實際MAC地址。若是虛擬路由器開啓的ARP代理(proxy_arp)功能,代理的ARP迴應也迴應VRRP虛擬MAC地址;
2.5 VRRP應用舉例
node
|
這是一般VRRP使用拓撲,兩臺路由器運行VRRP互爲備份,路由器1做爲VRID組1的MASTER,IP地址A,VRID組2的BACKUP,路由器2做爲VRID組2的MASTER,IP地址B,VRID組1的BACKUP,內部網絡中一部分機器的缺省網關地址是IP地址A,一部分是IP地址B,正常狀況下以A爲網關的數據將走路由器1,以B爲網關的數據將走路由器2,若是一臺路由器發生故障,全部數據將走另外一臺路由器。
3. 協議定義
3.1 以太頭
源MAC地址必須爲虛擬MAC地址:00-00-5E-00-01-{VRID},VRID爲虛擬路由器ID值,16進制格式,因此同一網段中最多有255個VRRP路由器;目的MAC爲多播類型的MAC。
這裏能夠看出VRID很是重要
3.2 IP頭參數
VRRP包的源地址是本機地址,目的地址必須爲224.0.0.18,爲一多播地址;IP協議號爲112;IP包的TTL值必須爲255。
3.3 VRRP協議數據格式mysql
|
其中:
version:版本,4位,在RFC3768中定義爲2;
Type:類型,4位,目前只定義一種類類型:通告數據,取值爲1;
Virtual Rtr ID:虛擬路由器ID,8位
Priority:優先級,8位,具有冗餘IP地址的設備的優先級爲255;
Count IP Addrs:VRRP包中的IP地址數量,8位;
Auth Type:認證類型,8位,RFC3768中認證功能已經取消,此字段值定義0(不認證),爲1,2只做爲對老版本的兼容;
Adver Int:通告包的發送間隔時間,8位,單位是秒,缺省是1秒;
Checksum:校驗和,16位,校驗數據範圍只是VRRP數據,即從VRRP的版本字段開始的數據,不包括IP頭;
IP Address(es):和虛擬路由器相關的IP地址,數量由Count IP Addrs決定
Authentication Data:RFC3768中定義該字段只是爲了和老版本兼容,必須置0。
3.4 接收數據時的必須檢查
收到VRRP數據包時要進行如下驗證,不知足的數據包將被丟棄:
- TTL必須爲255;
- VRRP版本號必須爲2;
- 一個包中數據字段必須完整;
- 校驗和必須正確;
- 必須驗證在接收的網卡上配置了VRID值,並且本地路由器不是路由IP地址的擁有者
- 必須驗證VVRP認證類型和配置的一致;
4. 結論
linux
VRRP實現了對路由器IP地址的冗餘功能,防止了單點故障形成的網絡失效,VRRP自己是熱備形式的,但能夠經過互相熱備實現路由器的均衡處理,新版的VRRP較老版簡化了認證處理,實際再也不進行數據的認證,這是由於在實際應用中常常出現認證成爲形成多個MASTER同時使用的異常狀況。nginx
什麼是Keepalived呢,keepalived觀其名可知,保持存活,在網絡裏面就是保持在線了,也就是所謂的高可用或熱備,用來防止單點故障(單點故障是指一旦某一點出現故障就會致使整個系統架構的不可用)的發生,那說到keepalived時不得不說的一個協議就是VRRP協議,能夠說這個協議就是keepalived實現的基礎,那麼首先咱們來看看VRRP協議
注:搞運維的要有足夠的耐心哦,不理解協議就很難透徹的掌握keepalived的了
web
VRRP協議
學過網絡的朋友都知道,網絡在設計的時候必須考慮到冗餘容災,包括線路冗餘,設備冗餘等,防止網絡存在單點故障,那在路由器或三層交換機處實現冗餘就顯得尤其重要,在網絡裏面有個協議就是來作這事的,這個協議就是VRRP協議,Keepalived就是巧用VRRP協議來實現高可用性(HA)的
VRRP協議有一篇文章寫的很是好,你們能夠直接看這裏(記得認真看看哦,後面基本都已這個爲基礎的了)
帖子地址:http://bbs.ywlm.net/thread-790-1-1.html
只須要把服務器看成路由器便可!
在《VRRP協議》裏講到了虛擬路由器的ID也就是VRID在這裏比較重要
keepalived徹底遵照VRRP協議,包括競選機制等等
算法
Keepalived原理
keepalived也是模塊化設計,不一樣模塊複雜不一樣的功能,下面是keepalived的組件
core check vrrp libipfwc libipvs-2.4 libipvs-2.6
core:是keepalived的核心,複雜主進程的啓動和維護,全局配置文件的加載解析等
check:負責healthchecker(健康檢查),包括了各類健康檢查方式,以及對應的配置的解析包括LVS的配置解析
vrrp:VRRPD子進程,VRRPD子進程就是來實現VRRP協議的
libipfwc:iptables(ipchains)庫,配置LVS會用到
libipvs*:配置LVS會用到
注意,keepalived和LVS徹底是兩碼事,只不過他們各負其責相互配合而已
sql
keepalived啓動後會有三個進程
父進程:內存管理,子進程管理等等
子進程:VRRP子進程
子進程:healthchecker子進程
有圖可知,兩個子進程都被系統WatchDog看管,兩個子進程各自複雜本身的事,healthchecker子進程複雜檢查各自服務器的健康程度,例如HTTP,LVS等等,若是healthchecker子進程檢查到MASTER上服務不可用了,就會通知本機上的兄弟VRRP子進程,讓他刪除通告,而且去掉虛擬IP,轉換爲BACKUP狀態
shell
keepalived配置詳解
keepalived有三類配置區域(姑且就叫區域吧),注意不是三種配置文件,是一個配置文件裏面三種不一樣類別的配置區域
全局配置(Global Configuration)
VRRPD配置
LVS配置
一,全局配置
全局配置又包括兩個子配置:
全局定義(global definition)
靜態路由配置(static ipaddress/routes)
1,全局定義(global definition)配置範例
全局配置解析
global_defs全局配置標識,表面這個區域{}是全局配置
表示keepalived在發生諸如切換操做時須要發送email通知,以及email發送給哪些郵件地址,郵件地址能夠多個,每行一個
notification_email_from admin@example.com
表示發送通知郵件時郵件源地址是誰
smtp_server 127.0.0.1
表示發送email時使用的smtp服務器地址,這裏能夠用本地的sendmail來實現
smtp_connect_timeout 30
鏈接smtp鏈接超時時間
router_id node1
機器標識
2,靜態地址和路由配置範例
這裏實際上和系統裏面命令配置IP地址和路由同樣例如:
192.168.1.1/24 brd + dev eth0 scope global 至關於: ip addr add 192.168.1.1/24 brd + dev eth0 scope global
就是給eth0配置IP地址
路由同理
通常這個區域不須要配置
這裏實際上就是給服務器配置真實的IP地址和路由的,在複雜的環境下可能須要配置,通常不會用這個來配置,咱們能夠直接用vi /etc/sysconfig/network-script/ifcfg-eth1來配置,切記這裏可不是VIP哦,不要搞混淆了,切記切記!
二,VRRPD配置
VRRPD配置包括三個類
VRRP同步組(synchroization group)
VRRP實例(VRRP Instance)VRRP腳本
1,VRRP同步組(synchroization group)配置範例
其中:
http和mysql是實例名和下面的實例名一致
notify /path/to/notify.sh:
smtp alter表示切換時給global defs中定義的郵件地址發送郵件通知(在這裏咱們能夠利用一款很是小巧的郵件發送工具mailx來進行郵件的發送工做)
2,VRRP實例(instance)配置範例
state:state指定instance(Initial)的初始狀態,就是說在配置好後,這臺服務器的初始狀態就是這裏指定的,但這裏指定的不算,仍是得要經過競選經過優先級來肯定,裏若是這裏設置爲master,但如若他的優先級不及另一臺,那麼這臺在發送通告時,會發送本身的優先級,另一臺發現優先級不如本身的高,那麼他會就回搶佔爲master
interface:實例綁定的網卡,由於在配置虛擬IP的時候必須是在已有的網卡上添加的
dont track primary:忽略VRRP的interface錯誤
track interface:跟蹤接口,設置額外的監控,裏面任意一塊網卡出現問題,都會進入故障(FAULT)狀態,例如,用nginx作均衡器的時候,內網必須正常工做,若是內網出問題了,這個均衡器也就沒法運做了,因此必須對內外網同時作健康檢查
mcast src ip:發送多播數據包時的源IP地址,這裏注意了,這裏實際上就是在那個地址上發送VRRP通告,這個很是重要,必定要選擇穩定的網卡端口來發送,這裏至關於heartbeat的心跳端口,若是沒有設置那麼就用默認的綁定的網卡的IP,也就是interface指定的IP地址
garp master delay:在切換到master狀態後,延遲進行免費的ARP(gratuitous ARP)請求
virtual router id:這裏設置VRID,這裏很是重要,相同的VRID爲一個組,他將決定多播的MAC地址
priority 100:設置本節點的優先級,優先級高的爲master
advert int:檢查間隔,默認爲1秒
virtual ipaddress:這裏設置的就是VIP,也就是虛擬IP地址,他隨着state的變化而增長刪除,當state爲master的時候就添加,當state爲backup的時候刪除,這裏主要是有優先級來決定的,和state設置的值沒有多大關係,這裏能夠設置多個IP地址
virtual routes:原理和virtual ipaddress同樣,只不過這裏是增長和刪除路由
lvs sync daemon interface:lvs syncd綁定的網卡
authentication:這裏設置認證
auth type:認證方式,能夠是PASS或AH兩種認證方式
auth pass:認證密碼
nopreempt:設置不搶佔,這裏只能設置在state爲backup的節點上,並且這個節點的優先級必須別另外的高。當主mysql恢復後不搶佔資源
preempt delay:搶佔延遲
debug:debug級別
notify master:和sync group這裏設置的含義同樣,能夠單獨設置,例如不一樣的實例通知不一樣的管理人員,http實例發給網站管理員,mysql的就發郵件給DBA
3,VRRP腳本
script "/usr/local/bin/check_running"interval 10 #腳本執行間隔weight 10 #腳本結果致使的優先級變動:10表示優先級+10;-10則表示優先級-10}
而後在實例()裏面引用,有點相似腳本里面的函數引用同樣:先定義,後引用函數名
check_running weight 20
}
注意:VRRP腳本(vrrp_script)和VRRP實例()屬於同一個級別
若是你沒有配置LVS+keepalived那麼無需配置這段區域,裏若是你用的是nginx來代替LVS,這無限配置這款,這裏的LVS配置是專門爲keepalived+LVS集成準備的。
注意了,這裏LVS配置並非指真的安裝LVS而後用ipvsadm來配置他,而是用keepalived的配置文件來代替ipvsadm來配置LVS,這樣會方便不少,一個配置文件搞定這些,維護方便,配置方即是也!
這裏LVS配置也有兩個配置
一個是虛擬主機組配置
一個是虛擬主機配置
1,虛擬主機組配置文件詳解
這個配置是可選的,根據需求來配置吧,這裏配置主要是爲了讓一臺realserver上的某個服務能夠屬於多個Virtual Server,而且只作一次健康檢查
virtual_server_group <STRING> {
# VIP port
<IPADDR> <PORT>
<IPADDR> <PORT>
fwmark <INT>
}
2,虛擬主機配置
virtual server能夠如下面三種的任意一種來配置
下面以第一種比較經常使用的方式來配詳細解說一下
virtual_server 192.168.1.2 80 { #設置一個virtual server: VIP:Vport
delay_loop 3 # service polling的delay時間,即服務輪詢的時間間隔
lb_algo rr|wrr|lc|wlc|lblc|sh|dh #LVS調度算法
lb_kind NAT|DR|TUN #LVS集羣模式
persistence_timeout 120 #會話保持時間(秒爲單位),即以用戶在120秒內被分配到同一個後端realserver
persistence_granularity <NETMASK> #LVS會話保持粒度,ipvsadm中的-M參數,默認是0xffffffff,即每一個客戶端都作會話保持
protocol TCP #健康檢查用的是TCP仍是UDP
ha_suspend #suspendhealthchecker’s activity
virtualhost <string> #HTTP_GET作健康檢查時,檢查的web服務器的虛擬主機(即host:頭)
sorry_server <IPADDR> <PORT> #備用機,就是當全部後端realserver節點都不可用時,就用這裏設置的,也就是臨時把全部的請求都發送到這裏啦
real_server <IPADDR> <PORT> #後端真實節點主機的權重等設置,主要,後端有幾臺這裏就要設置幾個
{
weight 1 #給每臺的權重,0表示失效(不知給他轉發請求知道他恢復正常),默認是1
inhibit_on_failure #表示在節點失敗後,把他權重設置成0,而不是衝IPVS中刪除
notify_up <STRING> | <QUOTED-STRING> #檢查服務器正常(UP)後,要執行的腳本
notify_down <STRING> | <QUOTED-STRING> #檢查服務器失敗(down)後,要執行的腳本
HTTP_GET #健康檢查方式
{
url { #要堅持的URL,能夠有多個
path / #具體路徑
digest <STRING>
status_code 200 #返回狀態碼
}
connect_port 80 #監控檢查的端口
bindto <IPADD> #健康檢查的IP地址
connect_timeout 3 #鏈接超時時間
nb_get_retry 3 #重連次數
delay_before_retry 2 #重連間隔
} # END OF HTTP_GET|SSL_GET
#下面是經常使用的健康檢查方式,健康檢查方式一共有HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK這些
#TCP方式
TCP_CHECK {
connect_port 80
bindto 192.168.1.1
connect_timeout 4
} # TCP_CHECK
# SMTP方式,這個能夠用來給郵件服務器作集羣
SMTP_CHECK
host {
connect_ip <IP ADDRESS>
connect_port <PORT> #默認檢查25端口
14 KEEPALIVED
bindto <IP ADDRESS>
}
connect_timeout <INTEGER>
retry <INTEGER>
delay_before_retry <INTEGER>
# "smtp HELO"ž|·-ë꧌à"
helo_name <STRING>|<QUOTED-STRING>
} #SMTP_CHECK
#MISC方式,這個能夠用來檢查不少服務器只須要本身會些腳本便可
MISC_CHECK
{
misc_path <STRING>|<QUOTED-STRING> #外部程序或腳本
misc_timeout <INT> #腳本或程序執行超時時間
misc_dynamic #這個就很好用了,能夠很是精確的來調整權重,是後端天天服務器的壓力都能均衡調配,這個主要是經過執行的程序或腳本返回的狀態代碼來動態調整weight值,使權重根據真實的後端壓力來適當調整,不過這須要有過硬的腳本功夫才行哦
#返回0:健康檢查沒問題,不修改權重
#返回1:健康檢查失敗,權重設置爲0
#返回2-255:健康檢查沒問題,可是權重卻要根據返回代碼修改成返回碼-2,例如若是程序或腳本執行後返回的代碼爲200,#那麼權重這回被修改成 200-2
}
} # Realserver
} # Virtual Server
配置文件到此就講完了,下面是一份未加備註的完整配置文件
- global_defs
- {
- notification_email
- {
- admin@example.com
- }
- notification_email_from admin@example.com
- smtp_server 127.0.0.1
- stmp_connect_timeout 30
- router_id node1
- }
- notification_email
- {
- admin@example.com
- admin@ywlm.net
- }
- static_ipaddress
- {
- 192.168.1.1/24 brd + dev eth0 scope global
- 192.168.1.2/24 brd + dev eth1 scope global
- }
- static_routes
- {
- src $SRC_IP to $DST_IP dev $SRC_DEVICE
- src $SRC_IP to $DST_IP via $GW dev $SRC_DEVICE
- }
- vrrp_sync_group VG_1 {
- group {
- http
- mysql
- }
- notify_master /path/to/to_master.sh
- notify_backup /path_to/to_backup.sh
- notify_fault "/path/fault.sh VG_1"
- notify /path/to/notify.sh
- smtp_alert
- }
- group {
- http
- mysql
- }
- vrrp_script check_running {
- script "/usr/local/bin/check_running"
- interval 10
- weight 10
- }
- vrrp_instance http {
- state MASTER
- interface eth0
- dont_track_primary
- track_interface {
- eth0
- eth1
- }
- mcast_src_ip <IPADDR>
- garp_master_delay 10
- virtual_router_id 51
- priority 100
- advert_int 1
- authentication {
- auth_type PASS
- autp_pass 1234
- }
- virtual_ipaddress {
- #<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPT> label <LABEL>
- 192.168.200.17/24 dev eth1
- 192.168.200.18/24 dev eth2 label eth2:1
- }
- virtual_routes {
- # src <IPADDR> [to] <IPADDR>/<MASK> via|gw <IPADDR> dev <STRING> scope <SCOPE> tab
- src 192.168.100.1 to 192.168.109.0/24 via 192.168.200.254 dev eth1
- 192.168.110.0/24 via 192.168.200.254 dev eth1
- 192.168.111.0/24 dev eth2
- 192.168.112.0/24 via 192.168.100.254
- }
- track_script {
- check_running weight 20
- }
- nopreempt
- preemtp_delay 300
- debug
- }
- virtual_server_group <STRING> {
- # VIP port
- < IPADDR> <PORT>
- < IPADDR> <PORT>
- fwmark <INT>
- }
- virtual_server 192.168.1.2 80 {
- delay_loop 3
- lb_algo rr|wrr|lc|wlc|lblc|sh|dh
- lb_kind NAT|DR|TUN
- persistence_timeout 120
- persistence_granularity <NETMASK>
- protocol TCP
- ha_suspend
- virtualhost <string>
- sorry_server <IPADDR> <PORT>
- real_server <IPADDR> <PORT>
- {
- weight 1
- inhibit_on_failure
- notify_up <STRING> | <QUOTED-STRING>
- notify_down <STRING> | <QUOTED-STRING>
- #HTTP_GET方式
- HTTP_GET | SSL_GET
- {
- url {
- path /
- digest <STRING>
- status_code 200
- }
- connect_port 80
- bindto <IPADD>
- connect_timeout 3
- nb_get_retry 3
- delay_before_retry 2
- }
- }
- }
這裏咱們僅僅只利用Keepalive作雙機熱備,也就是保證服務器的高可用性,其餘的不用管。可能您會說這樣在實際應用中不多會這樣用,這您可就錯了,Keepalived僅僅作雙機熱備的狀況仍是有的,我就碰到過幾回這樣的案例,下面就我碰到的幾個案例作個小結
一,Keepalived雙機熱備的應用場景
1,網站流量不高,壓力不大,可是對服務器的可靠性要求極其高,例如實時在線OA系統,政府部門網站系統,醫院實時報醫系統,公安局在線報案系統,股市後臺網站系統等等,他們的壓力不是很大,可是對可靠性要求是很是高的
2,有錢沒地方花的,典型的政府企業,公辦學校等等
二,Keepalived雙機熱備的特性以及優缺點
特性:
1,至少須要兩臺服務器,其中一臺爲master始終提供服務,另一臺做爲backup始終處於空閒狀態,只有在主服務器掛掉的時候他就來幫忙了,這是典型的雙擊熱備
2,能根據需求判斷服務是否可用,在不可用的時候要即便切換
優缺點:
優勢:數據同步很是簡單,不像負載均衡對數據一致性要求很是高,實現起來相對複雜維護也頗爲不便,雙機熱備用rsync就能夠實現了操做和維護很是簡單
缺點:服務器有點浪費,始終有一臺處於空閒狀態
三,Keepalived雙機熱備的配置
首先畫個雙機熱備拓撲圖吧:
這裏我只寫最終實現的配置,至於Keepalived的理論知識請參考《Keepalived原理與實戰精講》
1,本例經過Keepalived來實現兩臺LNMP(也就是linux+nginx+mysql+php)架構服務器的雙機熱備
LNMP的配置請參考:《Lnmp配置精講初版》
2,Keepalived配置雙機安裝配置
1》Keepalived安裝
keepalived官方地址:http://www.keepalived.org/download.html,你們能夠到這裏下載最新版本的keepalived
操做系統:centos 5.5 32bit
系統安裝:最小化安裝,也就是去掉全部組件
環境配置:安裝make 和 gcc openssl openssl-devel等等
預編譯後出現:
這裏注意哦,我上面是指通用的安裝方法,若是你沒有用到LVS能夠把lvs去掉即
./configure --prefix=/usr/local/keepalived --with-kernel-dir=/usr/src/kernels/2.6.18-238.19.1.el5-i686/ --disable-lvs-syncd --disable-lvs
但這個沒有影響,就按照個人來配置吧,不過若是你要是集成了LVS,那麼就不可加這兩個參數了哦
整理管理文件:
cp /usr/local/keepalived/sbin/keepalived /usr/sbin/
cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/
)
兩臺服務器(兩個節點)都這樣安裝便可
2》配置
節點A配置以下:
vi /etc/keepalived/keepalived.conf
節點B配置以下:
vi /etc/keepalived/keepalived.conf
四,啓動調試
在節點A上啓動
/usr/local/keepalived/sbin/keepalived
啓動日誌:
Sep 8 18:26:02 centosa Keepalived_vrrp: Registering Kernel netlink reflector
Sep 8 18:26:02 centosa Keepalived_vrrp: Registering Kernel netlink command channel
Sep 8 18:26:02 centosa Keepalived_vrrp: Registering gratutious ARP shared channel
Sep 8 18:26:02 centosa Keepalived_vrrp: Opening file '/etc/keepalived/keepalived.conf'.
Sep 8 18:26:02 centosa Keepalived_vrrp: Configuration is using : 36076 Bytes
Sep 8 18:26:02 centosa Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
Sep 8 18:26:02 centosa Keepalived: Starting VRRP child process, pid=5606
Sep 8 18:26:07 centosa Keepalived_vrrp: VRRP_Instance(lnmp) Transition to MASTER STATE
Sep 8 18:26:12 centosa Keepalived_vrrp: VRRP_Instance(lnmp) Entering MASTER STATE
Sep 8 18:26:12 centosa avahi-daemon[2528]: Registering new address record for 192.168.17.200 on eth0.
在節點B上啓動
/usr/local/keepalived/sbin/keepalived
開機自動啓動
echo /usr/local/keepalived/sbin/keepalived >> /etc/rc.local
啓動日誌:
Sep 8 18:30:02 centosb Keepalived: Starting Keepalived v1.2.2 (09/08,2011)
Sep 8 18:30:02 centosb Keepalived: Starting Healthcheck child process, pid=5837
Sep 8 18:30:02 centosb Keepalived_vrrp: Registering Kernel netlink reflector
Sep 8 18:30:02 centosb Keepalived_vrrp: Registering Kernel netlink command channel
Sep 8 18:30:02 centosb Keepalived_vrrp: Registering gratutious ARP shared channel
Sep 8 18:30:02 centosb Keepalived: Starting VRRP child process, pid=5839
Sep 8 18:30:02 centosb kernel: IPVS: Registered protocols (TCP, UDP, AH, ESP)
Sep 8 18:30:02 centosb kernel: IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
Sep 8 18:30:02 centosb kernel: IPVS: ipvs loaded.
Sep 8 18:30:02 centosb Keepalived_healthcheckers: Registering Kernel netlink reflector
Sep 8 18:30:02 centosb Keepalived_healthcheckers: Registering Kernel netlink command channel
Sep 8 18:30:02 centosb Keepalived_healthcheckers: Opening file '/etc/keepalived/keepalived.conf'.
Sep 8 18:30:02 centosb Keepalived_vrrp: Opening file '/etc/keepalived/keepalived.conf'.
Sep 8 18:30:02 centosb Keepalived_vrrp: Configuration is using : 36252 Bytes
Sep 8 18:30:02 centosb Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
Sep 8 18:30:02 centosb Keepalived_healthcheckers: Configuration is using : 6271 Bytes
Sep 8 18:30:02 centosb Keepalived_healthcheckers: Using LinkWatch kernel netlink reflector...
Sep 8 18:30:02 centosb Keepalived_vrrp: VRRP_Instance(lnmp) Entering BACKUP STATE
從日誌能夠看出,啓動都沒有問題,而且安裝我給的優先級完成了競選,各自成就了各自的狀態
關閉節點A的網卡測試切換是否正常
ifdown eth0
觀察節點B的日誌:
Sep 8 18:32:55 centosb Keepalived_vrrp: VRRP_Instance(lnmp) Transition to MASTER STATE
Sep 8 18:33:00 centosb Keepalived_vrrp: VRRP_Instance(lnmp) Entering MASTER STATE
Sep 8 18:33:00 centosb avahi-daemon[2531]: Registering new address record for 192.168.17.200 on eth0.
啓動節點A的網卡測試切換是否正常
ifup eth0
觀察節點B的日誌:
Sep 8 18:33:31 centosb Keepalived_vrrp: VRRP_Instance(lnmp) Received higher prio advert
Sep 8 18:33:31 centosb Keepalived_vrrp: VRRP_Instance(lnmp) Entering BACKUP STATE
Sep 8 18:33:31 centosb avahi-daemon[2531]: Withdrawing address record for 192.168.17.200 on eth0.
Received higher prio advert:表示接收到更高優先級的公告(advert公告的意思)
Withdrawing:撤回的意思,能夠看出切換過程一目瞭然
OK,到這裏咱們的安裝部分完成,下面咱們來看看如何監控服務吧,咱們這裏僅僅是監控了網絡故障和keepalived自己進程,在網絡或者keepalived進程出現問題的時候會切換,可是個人節點A裏面還有不少服務呢,例如nginx,PHP,mysql進程出問題或高負載的時候相應過慢怎麼辦,怎麼切換的呢,這時就要用到腳本了,下面咱們來看看keepalived是如何控制腳原本實現對服務器的監控和切換的
寫個腳原本實時監控三個服務,如有一個出現問題遍切換mkdir /root/shell/
cd /root/shell
vi keepcheck.sh
注意,用啓動腳本:
節點B也用這個腳本
寫入/etc/rc.local開機自動啓動