Interesting things
接着上一篇繼續延伸
準備環境
vip 192.168.12.100
lvs_director_master 192.168.12.4
lvs_director_slave 192.168.12.8
nginx1 192.168.12.2
nginx2 192.168.12.3
tomcat1 192.168.12.6
tomcat2 192.168.12.7
What did you do today
什麼是高可用?
lvs作爲負載均衡器,所有請求都先到達lvs,可見lvs處於非常重要的位置,如果lvs服務器宕機,後端web服務器將無法提供服務,影響嚴重。
爲了防止負載均衡服務器的宕機,需要建立一個備份機。主服務器和備份機上都運行高可用監控程序,通過傳送諸如”i am alive”這樣的信息來監控對方的運行狀況。當備份機不能再一定的時間內收到這樣的信息,它就接管主服務器的服務ip並繼續提供負載均衡服務,當備用服務器又從主服務器收到”i am alive”這樣的信息時,它就釋放服務ip地址,這樣主服務器就開始再次提供負載均衡服務。
什麼是keepalived?
keepalived是集羣管理中保證集羣高可用的一個服務軟件,用於防止單點故障。
keepalived的作用是檢測web服務器的狀態,如果有一臺web服務器司機或者工作出現故障,keepalived將檢測到,並且將有故障的web服務器從系統中剔除,當web服務器工作正常後keepalived自動將web服務器加入到服務器羣中 ,這些工作全部自動完成,不需要人工干涉,需要人工做的只是修復故障的web服務器。
keepalived工作原理
keepalived是以VRRP協議爲實現基礎的,VRRP全稱Virtual Router Redundancy Protocol,即虛擬路由冗餘協議。
虛擬路由冗餘協議,可以認爲是實現路由器高可用的協議,即將N臺提供相同功能的路由器組成一個路由器組,這個組裏面有一個master和多個backup。master上面有一個對外提供服務的vip(該路由器所在局域網內其他機器的默認路由爲該vip),master會發組播,當backup收不到VRRP包時就認爲master宕掉了,這時就需要根據VRRP的優先級來選舉一個backup當master,這樣的話就可以保證路由器的高可用了。
keepalived主要有3個模塊,分別是core、check和VRRP。core模塊爲keepalived的核心,負責主進程的啓動、維護以及全局配置文件的加載和解析。check負責健康檢查,包括常見的各種檢查方式。VRRP模式是來實現VRRP協議的。
LVS+Keepalived實現主備過程
初始狀態
主機宕機,備用機提供服務
主機恢復
- 對192.168.12.4和192.168.12.8配置keepalived基本環境,具體步驟請看我之前的博客【Diary Report 2017-12-28】關於FastDFS蛋疼的集羣和負載均衡(六)之Nginx高可用集羣
keepalived基礎配置完畢後,查詢系統服務是否存在
chkconfig –list
配置日誌文件
1.將keepalived日誌輸出到local0
vim /etc/sysconfig/keepalived,KEEPALIVED_OPTIONS=”-D -d -S 0”
2.在/etc/rsyslog.conf添加:
local0.* /var/log/keepalived.log
3.重啓啓動keepalived和rsyslog服務:
service rsyslog restart
service keepalived restart
4. 進入/var/log/下面,找到keepalived.log
5.查看keepalived.log。tail -f keepalived.log
6.差一點忘記說了,添加可執行權限:chmod +x /etc/init.d/keepalived
配置keepalived
- 修改/etc/keepalived/keepalived.conf之前,我們看看裏面寫了什麼東西。
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
}
notification_email_from [email protected]
smtp_server 192.168.200.1
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.200.16
192.168.200.17
192.168.200.18
}
}
virtual_server 192.168.200.100 443 {
delay_loop 6
lb_algo rr
lb_kind NAT
nat_mask 255.255.255.0
persistence_timeout 50
protocol TCP
real_server 192.168.201.100 443 {
weight 1
SSL_GET {
url {
path /
digest ff20ad2481f97b1754ef3e12ecd3a9cc
}
url {
path /mrtg/
digest 9b3a0c85a887a256d6939da88aabd8cd
}
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
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 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
}
}
}
- 我們參考官方的配置,把主lvs的keepalived.conf進行相應的修改,具體如下:
! Configuration File for keepalived
global_defs {
notification_email {
# 發生故障時發送的郵箱
#[email protected]
}
# 使用哪個郵箱發送
#notification_email_from [email protected]
# 發件服務器
#smtp_server xxx.com
smtp_connect_timeout 30
router_id LVS_DEVEL
}
vrrp_script check_lvs {
script "/etc/keepalived/lvs_check.sh" ##監控腳本
interval 2 ##時間間隔,2秒
weight -20 ##權重
}
vrrp_instance VI_1 {
state MASTER # 標示爲主lvs
interface eth0 # HA檢測端口
virtual_router_id 51 # 主備的virtual_router_id 必須相同
priority 100 # 優先級,備lvs要比主lvs稍小
advert_int 1 # VRRP Multicast 廣播週期秒數
authentication { # 定義認證
auth_type PASS # 認證方式爲口令認證
auth_pass 1111 # 定義口令
}
track_script {
check_lvs #監控腳本
}
virtual_ipaddress { # 定義vip
192.168.12.100 # 多個vip可換行添加
}
}
virtual_server 192.168.12.100 80 {
delay_loop 6 # 每隔6秒查看realserver狀態
lb_algo wlc # 調度算法爲加權最小連接數
lb_kind DR # lvs工作模式爲DR(直接路由)模式
nat_mask 255.255.255.0
persistence_timeout 50 # 同一IP 的連接50秒內被分配到同一臺realserver(測試時建議改爲0)
protocol TCP # 用TCP監測realserver的狀態
real_server 192.168.12.2 80 { # 定義realserver
weight 3 # 定義權重
TCP_CHECK { # 注意TCP_CHECK和{之間的空格,如果沒有的話只會添加第一個realserver
connect_timeout 3 # 三秒無響應超時
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
real_server 192.168.12.3 80 {
weight 3
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
connect_port 80
}
}
}
修改備用lvs下/etc/keepalived/keepalived.conf文件。配置內容基本和主lvs保持一致,需要注意的地方:修改state爲BACKUP,priority比MASTER低,virtual_router_id和master保持一致。
在主備lvs中/etc/keepalived/目錄下,創建lvs_check.sh腳本,內容如下:
#!/bin/sh
aa=`ipvsadm -ln`
str="Route"
bb=`echo $aa|grep $str|wc -l`
if [ $bb = 0 ];then
service lvsdr start
sleep 3
aa=`ipvsadm -ln`
bb=`echo $aa|grep $str|wc -l`
if [ $bb = 0 ];then
killall keepalived
fi
fi
先關閉主備lvs中的keepalived和lvsdr服務。
service lvsdr stop
service keepalived stop
然後開啓主備lvs中的keepalived服務。
我們接着通過ipvsadm查看lvs是否處於啓動狀態,發現lvs啓動了!
開啓192.168.12.2和192.16812.3的nginx服務和lvsdr服務。
開啓192.168.12.6和192.168.12.7的tomcat
接着我們通過ip a 命令查看虛擬ip
主lvs設備的虛擬ip信息
備lvs設備的虛擬ip信息
出現這種情況似乎和我們想象的不太一樣。我們可以先關閉防火牆。我們先關閉主lvs的keepalived服務,然後再關閉備lvs的keepalived服務。然後重新啓動主lvs、備用lvs的keepalived服務即可。重啓之後,我們發現備用lvs的eth0節點沒有虛擬ip192.168.12.100了,如我所願!
主備lvs啓動成功後,第一次訪問192.168.12.100。
第二次訪問192.168.12.100
當我們停掉主lvs,發現192.168.12.100還可以訪問。此時我們在備lvs,通過ip a 查看發現eth0節點多了虛擬ip 192.168.12.100
- 接着開啓主lvs,主導權又到了主lvs。
Summary
明天進行問題總結,然後實現LVS+Keepalived雙主模式。