LVS專題-(3) 虛擬ip理解
1.虛擬IP是什麼？html
要是單講解虛擬 IP,理解起來很困難,因此乾脆把
動態 IP 、固定 IP 、實體 IP 與虛擬 IP都講解一下,加深理解和知識擴展前端
實體 IP：在網絡的世界裏，爲了要辨識每一部計算機的位置，所以有了計算機 IP 位址的定義。一個 IP 就好似一個門牌！例如，你要去微軟的網站的話，就要去『 207.46.197.101 』這個 IP 位置！這些能夠直接在網際網絡上溝通的 IP 就被稱爲『實體 IP 』了。node
虛擬 IP：不過，衆所皆知的，IP 位址僅爲 xxx.xxx.xxx.xxx 的資料型態，其中， xxx 爲 1-255 間的整數，因爲近來計算機的成長速度太快，實體的 IP 已經有點不足了，好在早在規劃 IP 時就已經預留了三個網段的 IP 作爲內部網域的虛擬 IP 之用。這三個預留的 IP 分別爲：ios
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.255nginx
上述中最經常使用的是192.168.0.0這一組。不過，因爲是虛擬 IP ，因此當您使用這些地址的時候﹐固然是有所限制的，限制以下：算法
私有位址的路由信息不能對外散播
使用私有位址做爲來源或目的地址的封包﹐不能透過Internet來轉送
關於私有位址的參考紀錄(如DNS)﹐只能限於內部網絡使用數據庫
因爲虛擬 IP 的計算機並不能直接連上 Internet ，所以須要特別的功能才能上網。不過，這給咱們架設IP網絡作成很大的方便﹐好比﹕即便您目前的公司尚未連上Internet﹐但不保證未來不會啊。若是使用公共IP的話﹐若是沒通過註冊﹐等到之後真正要連上網絡的時候﹐就極可能和別人衝突了。也正如前面所分析的﹐到時候再從新規劃IP的話﹐將是件很是頭痛的問題。這時候﹐咱們能夠先利用私有位址來架設網絡﹐等到真要連上intetnet的時候﹐咱們可使用IP轉換協定﹐如 NAT (Network Addresss Translation)等技術﹐配合新註冊的IP就能夠了。vim
固定 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協議
1、虛擬IP
2、arp協議
3、虛擬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.21七、192.168.1.218是兩臺真實的電腦，
192.168.1.217爲對外提供數據庫服務的主機。
192.168.1.218爲熱備的機器。
192.168.1.219爲虛IP。
你們注意紅字部分，21九、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的高可用
1、Keepalived 高可用集羣的解決方案
2、VRRP的有限狀態機
3、利用keepalived 實現主從VIP的切換
4、實如今狀態轉變的時候自定義進行通知，
5、實現負載均衡
六：實現nginx的高可用
1、Keepalived 高可用集羣的解決方案
最初的誕生是爲ipvs提供高可用的，在後端的realserver接收不到主節點的信息以後，keepalived可以本身調用ipvsadm命令生成規則，可以自動實現，將主節點的VIP以及ipvs規則「拿過來」，應用在從節點上，繼續爲用戶服務。還能夠實現對後端realserver的健康情況作檢測。
keepalived在一個節點上啓動以後，會生成一個Master主進程，這個主進程又會生成兩個子進程，分別是VRRP Stack（實現vrrp協議的） Checkers(檢測ipvs後端realserver的健康情況檢測)
2、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
準備
一、節點一：
同步時間：
[root@node1 ~]# ntpdate 172.16.0.1
安裝keepalived
[root@node1 ~]# yum -y install keepalived
二、節點二作一樣的工做
3、利用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、實如今狀態轉變的時候自定義進行通知，
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、實現負載均衡
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.二、在從節點上作一樣的修改
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
|
注：
一、後端的realserver的數量能夠添加多臺，可是須要在主節點的配置文件中給出相應的配置，並在添加的realserver上執行相關命令便可
二、儘管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端口已經被監聽
|
- 1. 3，虛擬機理解
- 2. 虛擬IP和IP漂移
- 3. lvs，nginx反向代理，虛擬主機
- 4. lvs 理論3
- 5. 讀深刻理解Java虛擬機-3
- 6. 虛擬IP
- 7. 虛擬專網×××
- 8. 虛擬IP(VIP)
- 9. Linux虛擬服務器--LVS
- 10. LVS虛擬服務器
- 更多相關文章...
- • IP數據報格式詳解 - TCP/IP教程
- • Markdown 標題 - Markdown 教程
- • PHP Ajax 跨域問題最佳解決方案
- • Docker 清理命令
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 外部其他進程嵌入到qt FindWindow獲得窗口句柄 報錯無法鏈接的外部符號 [email protected] 無法被([email protected]@[email protected]@@引用
- 2. UVa 11524 - InCircle
- 3. The Monocycle（bfs）
- 4. VEC-C滑窗
- 5. 堆排序的應用-TOPK問題
- 6. 實例演示ElasticSearch索引查詢term,match,match_phase,query_string之間的區別
- 7. 數學基礎知識 集合
- 8. amazeUI 復擇框問題解決
- 9. 揹包問題理解
- 10. 算數平均-幾何平均不等式的證明,從麥克勞林到柯西
- 1. 3，虛擬機理解
- 2. 虛擬IP和IP漂移
- 3. lvs，nginx反向代理，虛擬主機
- 4. lvs 理論3
- 5. 讀深刻理解Java虛擬機-3
- 6. 虛擬IP
- 7. 虛擬專網×××
- 8. 虛擬IP(VIP)
- 9. Linux虛擬服務器--LVS
- 10. LVS虛擬服務器