1.虛擬IP是什么？
要是單講解虛擬 IP,理解起來很困難,所以干脆把
動態 IP 、固定 IP 、實體 IP 與虛擬 IP都講解一下,加深理解和知識擴展
實體 IP：在網絡的世界里，為了要辨識每一部計算機的位置，因此有了計算機 IP 位址的定義。一個 IP 就好似一個門牌！例如，你要去微軟的網站的話，就要去『 207.46.197.101 』這個 IP 位置！這些可以直接在網際網絡上溝通的 IP 就被稱為『實體 IP 』了。
虛擬 IP：不過，眾所皆知的，IP 位址僅為 xxx.xxx.xxx.xxx 的資料型態，其中， xxx 為 1-255 間的整數，由於近來計算機的成長速度太快，實體的 IP 已經有點不足了，好在早在規划 IP 時就已經預留了三個網段的 IP 做為內部網域的虛擬 IP 之用。這三個預留的 IP 分別為：
A級：10.0.0.0 - 10.255.255.255
B級：172.16.0.0 - 172.31.255.255
C級：192.168.0.0 - 192.168.255.255
上述中最常用的是192.168.0.0這一組。不過，由於是虛擬 IP ，所以當您使用這些地址的時候﹐當然是有所限制的，限制如下：
私有位址的路由信息不能對外散播
使用私有位址作為來源或目的地址的封包﹐不能透過Internet來轉送
關於私有位址的參考紀錄(如DNS)﹐只能限於內部網絡使用
由於虛擬 IP 的計算機並不能直接連上 Internet ，因此需要特別的功能才能上網。不過，這給我們架設IP網絡做成很大的方便﹐比如﹕即使您目前的公司還沒有連上Internet﹐但不保證將來不會啊。如果使用公共IP的話﹐如果沒經過注冊﹐等到以后真正要連上網絡的時候﹐就很可能和別人沖突了。也正如前面所分析的﹐到時候再重新規划IP的話﹐將是件非常頭痛的問題。這時候﹐我們可以先利用私有位址來架設網絡﹐等到真要連上intetnet的時候﹐我們可以使用IP轉換協定﹐如 NAT (Network Addresss Translation)等技術﹐配合新注冊的IP就可以了。
固定 IP 與 動態 IP：基本上，這兩個東西是由於近來網絡公司大量的成長下的產物，例如，你如果向中華電信申請一個商業型態的 ADSL 專線，那他會給你一個固定的實體 IP ，這個實體 IP 就被稱為『固定 IP 』了。而若你是申請計時制的 ADSL ，那由於你的 IP 可能是由數十人共同使用，因此你每次重新開機上網時，你這部計算機的 IP 都不會是固定的！於是就被稱為『動態 IP』或者是『浮動式IP』。基本上，這兩個都是『實體IP』，只是網絡公司用來分配給用戶的方法不同而產生不同的名稱而已。
自己的理解
我們用路由器時，每個手機或電腦都有一個ip地址，這個IP就是虛擬IP。想象一下，如果世界上的每台設備（電腦手機都算）都有一個實際IP地址，IP地址肯定不夠用。但如果每個實際的IP地址再對應幾萬個虛擬的IP地址（比如 192.168.0.0 - 192.168.255.255），那不就夠了嗎？
我們給一個路由器分配一個實體IP（只是舉個例子），之后每個連接這個路由器的設備給他分配一個虛擬IP（比如 192.168.0.0 - 192.168.255.255 中隨機給一個），路由器記下這個虛擬IP和對應的設備，當某個設備訪問網絡數據時，先經過路由器，然后路由器與網絡進行數據交換，因為路由器有實體IP，所以網絡可以給路由器發送數據，然后路由器再根據自己分配的虛擬IP發送到相應的設備。
資料來源：http://blog.csdn.net/u014290233/article/details/53635658
2.虛擬IP與arp協議
一、虛擬IP
二、arp協議
三、虛擬IP與arp協議
虛擬IP和arp協議
虛擬IP常用於系統高可用性的場景，那么虛擬IP實現的原理是什么?虛擬能夠自由漂浮的原理是什么？
從前文介紹arp協議里面來看，主機與主機的通信過程都會涉及到一個ip地址轉換mac地址的過程，那么虛擬IP的通信也不會例外。因此，IP地址在主機通信的過程中其實就是一個邏輯地址。我們知道，每一個主機都存放着網絡內一些主機的邏輯地址與物理地址（MAC地址）的映射，問題來了，當虛擬IP VIP在主機A上時，主機A的MAC地址為MAC_A某主機M的arp緩存中存放着一個映射關系：VIP ---à MAC_A；當主機A宕機后，虛擬IPVIP漂浮到了主機B，主機B的MAC地址為MAC_B，那么此時主機M想與虛擬IP通信時，是做不到，因為它的arp高速緩存中的虛擬IP VIP的映射還指向主機A的MAC地址。這個問題解決的思路就是當虛擬IP漂浮后，刷新所有其他主機的arp緩存。
那么虛擬IP是如何實現漂浮后，是如何刷新所有其他主機的arp緩存的呢？
這里就會引入另一個概念，garp()簡稱無端arp或者免費arp，主要是用來當某一個主機C開機時，用來確認自己的IP地址沒有被人占用而做的一個檢測。廣播發送這個arp，請求得到本機IP地址的MAC地址，主機C並不希望此次arp請求會有arp應答，因為應答意味着IP地址沖突了。當其他主機收到這個arp請求后，會刷新關於這個arp請求源的主機IP地址的映射。
Garp的作用主要有兩個:
1. 檢測IP地址是否有沖突
2. 刷新其他主機關於本次IP地址的映射關系
集群管理軟件Pacemaker里面的資源代理ocf:heartbeat:IPaddr2中，在虛擬IP漂浮后，會向網絡內廣播發送garp請求，以此來刷新其他主機的arp緩存。
在配置OpenStack控制節點高可用性的時候，出現過虛擬IP切換時，某一個主機不能通信的問題，后來發現是arp緩存沒有刷新，有時候由於網絡的原因，某些主機沒有接收到此garp請求，因此ocf:heartbeat:IPaddr2資源代理中可以配置發送garp的次數，這里建議次數配置得多一點，這樣可以保證其他主機成功刷新arp緩存。
資料來源：http://blog.csdn.net/u014532901/article/details/52245138
3. 談談VIP漂移那點破事
一直以來都是用nginx的upstream模塊做網站最前端的負載均衡，為了防止nginx本身宕機導致網站不能訪問，通常都會做兩套nginx反向代理，然后用keepalive之類的軟件提供VIP。
常見的環境是nginx主節點和從節點各有一個公網IP，一個私有IP，VIP地址也使用公網IP來提供，正常情況下VIP只會在nginx主節點上工作，只有主節點宕機或者網絡不可達等情況下，VIP才會漂移到nginx從節點上。如果keepalive配置了非搶占模式，則主節點恢復后，VIP也不會漂移會主節點，而是繼續在從節工作。這種配置要求機房網絡不做mac地址綁定。
最近做的兩套培訓系統測試情況如下:
系統一：主從節點做雙網卡綁定，都只有一個私有IP，VIP也為私有IP，通過防火牆的NAT轉發用戶的訪問請求。主節點宕機后，VIP可以漂移至從節點，但用戶無法訪問網站，telnet防火牆公網IP的80端口提示無法連接。
系統二：主從節點各有兩張網卡，分別配置一個公網IP和一個私有IP。VIP地址也使用公網IP來提供。
主節點宕機后，VIP可以漂移至從節點，但用戶無法ping通VIP，自然網站也就打不開。
於是分別對這兩種情況進行排查：
系統二：屬於比較常見的配置方案。VIP漂移后無法ping通，第一反應詢問機房工作人員，是否相應的設備做了mac地址綁定。得知無綁定策略后繼續排查。
發現配置net.ipv4.ip_nonlocal_bind = 1 參數並使其生效后重新測試正常。
系統一：情況有點特殊，按系統二的解決方法嘗試無果后，懷疑端口路由器映射上出現問題。於是繼續測試VIP漂移，發現VIP漂移到從節點后，防火牆上的arp表中vip對應的mac地址依舊是主節點網卡的mac地址，原來防火牆才是罪魁禍首，坑爹的貨。機房使用的防火牆型號華為Quidway Eudemon1000E，據說默認配置下，這個arp地址表自動刷新需要20分鍾！
好吧！於是用下面的命名手工刷新后，萬事大吉，網站訪問也很順暢，比較郁悶的是當主節點重新搶占VIP后，依然需要手工刷新下，否則防火牆還是把請求轉給從節點響應。
# arping -I 網卡地址 -c 3 -s VIP地址 網關地址
后記：
要徹底解決系統一的問題，可以從兩方面去着手，首先是考慮去調整防火牆的arp表的自動刷新時間；其次是考慮在從節點上部署一個無限循環的腳本，時時去檢測是否搶占到了VIP，若搶占成功，則運行前面的刷新命令，命令成功運行后退出腳本，同時可以用nagios監控該腳本，了解最新的主從切換情況。切記，循環運行一次接受后sleep 1秒，否則會死機的哦！
如果在主節點上也部署類似的腳本，則會對網絡帶來負擔，因而主節點恢復后的刷新手工運行下就好了，如果忘記運行了，從節點依然可以工作，無傷大雅！
資料來源：
http://ylw6006.blog.51cto.com/470441/1314004/
4.HA集群中的虛擬IP原理
高可用性HA（High Availability）指的是通過盡量縮短因日常維護操作（計划）和突發的系統崩潰（非計划）所導致的停機時間，以提高系統和應用的可用性。HA系統是目前企業防止核心計算機系統因故障停機的最有效手段。
實現HA的方式，一般采用兩台機器同時完成一項功能，比如數據庫服務器，平常只有一台機器對外提供服務，另一台機器作為熱備，當這台機器出現故障時，自動動態切換到另一台熱備的機器。
怎么實現故障檢測的那？
心跳，采用定時發送一個數據包，如果機器多長時間沒響應，就認為是發生故障，自動切換到熱備的機器上去。
怎么實現自動切換那？
虛IP。何為虛IP那，就是一個未分配給真實主機的IP，也就是說對外提供數據庫服務器的主機除了有一個真實IP外還有一個虛IP，使用這兩個IP中的 任意一個都可以連接到這台主機，所有項目中數據庫鏈接一項配置的都是這個虛IP，當服務器發生故障無法對外提供服務時，動態將這個虛IP切換到備用主機。
開始我也不明白這是怎么實現的，以為是軟件動態改IP地址，其實不是這樣，其實現原理主要是靠TCP/IP的ARP協議。因為ip地址只是一個邏輯 地址，在以太網中MAC地址才是真正用來進行數據傳輸的物理地址，每台主機中都有一個ARP高速緩存，存儲同一個網絡內的IP地址與MAC地址的對應關 系，以太網中的主機發送數據時會先從這個緩存中查詢目標IP對應的MAC地址，會向這個MAC地址發送數據。操作系統會自動維護這個緩存。這就是整個實現 的關鍵。
下邊就是我電腦上的arp緩存的內容。
(192.168.1.219) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.217) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.218) at 00:21:5A:DB:7F:C2 [ether] on bond0
192.168.1.217、192.168.1.218是兩台真實的電腦，
192.168.1.217為對外提供數據庫服務的主機。
192.168.1.218為熱備的機器。
192.168.1.219為虛IP。
大家注意紅字部分，219、217的MAC地址是相同的。
再看看那217宕機后的arp緩存
(192.168.1.219) at 00:21:5A:DB:7F:C2 [ether] on bond0
(192.168.1.217) at 00:21:5A:DB:68:E8 [ether] on bond0
(192.168.1.218) at 00:21:5A:DB:7F:C2 [ether] on bond0
這就是奧妙所在。當218 發現217宕機后會向網絡發送一個ARP數據包，告訴所有主機192.168.1.219這個IP對應的MAC地址是00:21:5A:DB:7F:C2，這樣所有發送到219的數據包都會發送到mac地址為00:21:5A:DB:7F:C2的機器，也就是218的機器。
5. 基於keepalived 實現VIP轉移，lvs，nginx的高可用
一、Keepalived 高可用集群的解決方案
二、VRRP的有限狀態機
三、利用keepalived 實現主從VIP的切換
四、實現在狀態轉變的時候自定義進行通知，
五、實現負載均衡
六：實現nginx的高可用
一、Keepalived 高可用集群的解決方案
最初的誕生是為ipvs提供高可用的，在后端的realserver接收不到主節點的信息之后，keepalived能夠自己調用ipvsadm命令生成規則，能夠自動實現，將主節點的VIP以及ipvs規則“拿過來”，應用在從節點上，繼續為用戶服務。還可以實現對后端realserver的健康狀況做檢測。
keepalived在一個節點上啟動之后，會生成一個Master主進程，這個主進程又會生成兩個子進程，分別是VRRP Stack（實現vrrp協議的） Checkers(檢測ipvs后端realserver的健康狀況檢測)
二、VRRP的有限狀態機
VRRP雙方節點都啟動以后，要實現狀態轉換的，剛開始啟動的時候，初始狀態都是BACKUP，而后向其它節點發送通告，以及自己的優先級信息，誰的優先級高，就轉換為MASTER，否則就還是BACKUP，這時候服務就在狀態為MASTER的節點上啟動，為用戶提供服務，如果，該節點掛掉了，則轉換為BACKUP，優先級降低，另一個節點轉換為MASTER，優先級上升，服務就在此節點啟動，VIP,VMAC都會被轉移到這個節點上，為用戶提供服務，
實驗環境：
虛擬主機版本：
CentOS6.4-i686
兩個節點：
node1.limian.com 172.16.6.1
node2.limian.com 172.16.6.10
准備
1、節點一：
同步時間：
[root@node1 ~]# ntpdate 172.16.0.1
安裝keepalived
[root@node1 ~]# yum -y install keepalived
2、節點二做同樣的工作
三、利用keepalived 實現主從VIP的切換
3.1我們修改下keepalived的配置文件：
|
1
2
3
|
[root@node1 ~]# cd /etc/keepalived/
[root@node1 keepalived]# cp keepalived.conf keepalived.conf.back
//先給配置文件備份一下
[root@node1 keepalived]# vim keepalived.conf
|
3.2全局階段
|
1
2
3
4
5
6
7
8
9
|
global_defs {
notification_email {
//定義郵件服務的
root@localhost
//定義收件人，這里改為本機，只是測試使用
}
notification_email_from kaadmin@localhost
//定義發件人，
smtp_server
127.0
.
0.1
//定義郵件服務器，一定不能使用外部地址
smtp_connect_timeout
30
//超時時間
router_id LVS_DEVEL
}
|
3.3定義vrrp階段
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
vrrp_instance VI_1 {
//定義虛擬路由，VI_1 為虛擬路由的標示符，自己定義名稱
state MASTER
//開啟后，該節點的優先級比另一節點的優先級高，所以轉化為MASTER狀態
interface
eth0
//所有的通告等信息都從eth0這個接口出去
virtual_router_id
7
//虛擬路由的ID，而且這個ID也是虛擬MAC最后一段的來源，這個ID號一般不能大於255，且這個ID一定不能有沖突
priority
100
//初始優先級
advert_int
1
//通告的個數
authentication {
//認證機制
auth_type PASS
//認證類型
auth_pass
1111
//密碼，應該為隨機的字符串
}
virtual_ipaddress {
//虛擬地址，即VIP
172.16
.
6.100
}
}
|
這樣我們主節點的配置文件就修改好了，需要復制到從節點上，再做適當的修改就可以使用了
|
1
|
[root@node1 keepalived]# scp keepalived.conf
172.16
.
6.1
:/etc/keepalived/
|
3.4登錄到從節點;
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
[root@node2 ~]# cd /etc/keepalived/
[root@node2 keepalived]# vim keepalived.conf
vrrp_instance VI_1 {
state BACKUP
//修改從節點的狀態，主節點為MASTER,從節點就為BACKUP
interface
eth0
virtual_router_id
7
priority
99
//修改優先級，注意從節點的優先級一定要小於主節點
advert_int
1
authentication {
auth_type PASS
auth_pass
1111
}
virtual_ipaddress {
172.16
.
6.100
}
}
|
3.5然后在主節點啟動服務
|
1
2
|
[root@node1 keepalived]# service keepalived start
[root@node1 ~]# ip addr show
//查看我們定義的VIP
|
3.6在從節點啟動服務
[root@node2 keepalived]# service keepalived start
把主節點上的服務停掉，看VIP會不會到從節點上
[root@node2 ~]# ip addr show
3.7在主節點上啟動服務
|
1
2
|
[root@node1 ~]# service keepalived start
[root@node1 ~]# ip addr show
//檢測結果發現VIP轉移到了主節點
|
注：
默認情況下ARRP工作在“搶占模式”下，如果發現一個節點的服務停止了，另一個節點會立即把VIP和VMAC“搶過來”，如果在“非搶占模式”下，無論你的優先級過高，一個節點服務停止，另一個節點也不會“搶”VIP和VMAC，除非這個節點掛了，兩一個節點才會“搶”。
四、實現在狀態轉變的時候自定義進行通知，
4.1這需要依賴於腳本來完成
主節點
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
[root@node1 ~]# cd /etc/keepalived/
[root@node1 keepalived]# vim notify.sh
//編寫腳本
#!/bin/bash
vip=
172.16
.
6.100
contact=
'root@localhost'
thisip=`ifconfig eth0 | awk
'/inet addr:/{print $2}'
| awk -F:
'{print $2}'
`
Notify() {
mailsubject=
"$thisip is to bi $vip master"
mailbody=
"vrrp transaction, $vip floated to $thisip"
echo $mailbody | mail -s
"$mailsubject"
$contact
}
case
"$1"
in
master)
notify master
exit
0
;;
backup)
notify backup
exit
0
;;
fault)
notify fault
exit
0
;;
*)
echo
'Usage: `basename $0` {master|backup|fault}'
exit
1
;;
esac
[root@node1 keepalived]# chmod +x notify.sh
[root@node1 keepalived]# ./notify.sh master
[root@node1 keepalived]# mail
//查看有沒有收到通知
Heirloom Mail version
12.4
7
/
29
/
08
. Type ?
for
help.
"/var/spool/mail/root"
:
1
message
1
new
>N
1
root Wed Sep
25
14
:
54
18
/
668
"172.16.6.10 is to bi 172.16.6.100 mas"
&
|
轉換狀態查看是否會收到通知
|
1
2
3
4
5
6
7
8
9
|
[root@node1 keepalived]# ./notify.sh backup
[root@node1 keepalived]# ./notify.sh fault
[root@node1 keepalived]# mail
Heirloom Mail version
12.4
7
/
29
/
08
. Type ?
for
help.
"/var/spool/mail/root"
:
3
messages
2
new
1
root Wed Sep
25
14
:
54
19
/
679
"172.16.6.10 is to bi 172.16.6.100 mas"
>N
2
root Wed Sep
25
14
:
57
18
/
668
"172.16.6.10 is to bi 172.16.6.100 mas"
N
3
root Wed Sep
25
14
:
57
18
/
668
"172.16.6.10 is to bi 172.16.6.100 mas"
&
|
說明腳本正常工作，那么去編輯配置文件
|
1
|
[root@node1 keepalived]# vim keepalived.conf
|
在全局階段添加
|
1
2
3
4
5
|
vrrp_script chk_mantaince_down{
//定義可以手動控制狀態的腳本
script
"[[ -f /etc/keepalived/down ]] && exit 1 || exit 0"
interval
1
//檢查時間間隔
weight -
2
//如果檢測失敗，優先級-2
}
|
在vrrp階段添加如下幾行
|
1
2
3
4
5
6
|
track_script {
//引用定義的腳本
chk_mantaince_down
}
notify_master
"/etc/keepalived/notify.sh master"
notify_backup
"/etc/keepalived/notify.sh backup"
notify_fault
"/etc/keepalived/notify.sh fault"
|
4.2將該腳本復制到另一個節點，
|
1
|
[root@node1 keepalived]# scp notify.sh
172.16
.
6.1
:/etc/keepalived/
|
並在配置文件中相應的位置添加相同內容
兩個節點都重啟服務
4.3讓主節點變成從節點
|
1
|
root@node1 keepalived]# touch down
|
通過監控，發現主節點立即變成從節點，並收到一封郵件
|
1
2
|
[root@node1 keepalived]# tail -f /
var
/log/messages
You have
new
mail
in
/
var
/spool/mail/root
|
五、實現負載均衡
5.1編輯配置文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
[root@node1 keepalived]# vim keepalived.conf
#####負載均衡階段#################
virtual_server
172.16
.
6.100
80
{
//指定VIP和端口
delay_loop
6
//延遲多少個周期再啟動服務，做服務檢測
lb_algo rr loadbalance 負載均衡調度算法
lb_kind DR 類型
nat_mask
255.255
.
0.0
掩碼
persistence_timeout
0
持久連接時間
protocol TCP
//協議
real_server
172.16
.
6.11
80
{
//定義后端realserver的屬性
weight
1
HTTP_GET {
//定義檢測的方法
url {
//檢測的URL
path /
status_code
200
//獲取結果的狀態碼
}
connect_timeout
3
//連接超時時間
nb_get_retry
3
//嘗試次數
delay_before_retry
3
//每次嘗試連接的等待時間
}
}
real_server
172.16
.
6.12
80
{
//定義后端realserver的屬性
weight
1
HTTP_GET {
//定義檢測的方法
url {
//檢測的URL
path /
status_code
200
//獲取結果的狀態碼
}
connect_timeout
3
//連接超時時間
nb_get_retry
3
//嘗試次數
delay_before_retry
3
//每次嘗試連接的等待時間
}
}
}
|
5.2、在從節點上做同樣的修改
5.3重啟服務並用ipvsadm命令檢測是否會生成規則
|
1
2
3
4
5
6
7
|
[root@node1 keepalived]# service keepalived restart
[root@node1 keepalived]# ipvsadm -L -n
IP Virtual Server version
1.2
.
1
(size=
4096
)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP
172.16
.
6.100
:
80
rr
[root@node1 keepalived]#
|
但是為什么沒有我們定義的兩個realserver呢？那是因為沒啟動虛擬機呢，健康狀況檢測沒通過，就不會顯示了，我們去啟動一個虛擬機，並啟動服務即可。
並執行如下命令，做lvs負載均衡的DR模型
|
1
2
3
4
5
6
|
#ifconfig lo:
0
172.16
.
6.11
broadcast
172.16
.
6.11
netmask
255.255
.
255.255
up
#route add -host
172.16
.
6.11
dev lo:
0
#echo
1
> /proc/sys/net/ipv4/conf/lo/arp_ignore
#echo
1
> /proc/sys/net/ipv4/conf/all/arp_ignore
#echo
2
> /proc/sys/net/ipv4/conf/all/arp_announce
#echo
2
> /proc/sys/net/ipv4/conf/lo/arp_announce
|
注：
1、后端的realserver的數量可以添加多台，但是需要在主節點的配置文件中給出相應的配置，並在添加的realserver上執行相關命令即可
2、盡管keepalived可以自行添加ipvs規則，實現負載均衡，但是無法實現動靜分離，在生產環境中我們要根據場景選擇最佳的方案。
六：實現nginx的高可用
6.1前提
兩個節點上都裝上nginx服務，並確保httpd沒啟用
# netstat -tunlp //確保80端口沒占用
# service nginx start
6.2為每個節點的nginx編輯一個頁面，以便於效果更直觀一些
|
1
2
3
4
|
[root@node1 ~]# vim /usr/share/nginx/html/index.html
//節點1
172.16
.
6.10
[root@node2 ~]# vim /usr/share/nginx/html/index.html
//節點2
172.16
.
6.1
|
6.3確保nginx可以正常訪問
6.4然后停掉服務，
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
[root@node1 keepalived]# vim notify.sh
//修改腳本，讓它可以監測nginx服務，並可以啟動或關閉服務
##################
case
"$1"
in
master)
notify master
/etc/rc.d/init.d/nginx start
exit
0
;;
backup)
notify backup
/etc/rc.d/init.d/nginx stop
exit
0
;;
fault)
notify fault
/etc/rc.d/init.d/nginx stop
exit
0
;;
######################################
|
6.5同步腳本到節點2
|
1
|
[root@node1 keepalived]# scp notify.sh
172.16
.
6.1
:/etc/keepalived/
|
6.6在主節點上
|
1
2
3
4
|
[root@node1 keepalived]# touch down
[root@node1 keepalived]#ss -tunl
//發現80端口未被監聽
[root@node1 keepalived]# rm -f down
[root@node1 keepalived]#ss -tunl
//發現80端口已經被監聽
|