123,123

[導(dǎo)讀]1.磁盤使用率檢測(cè)（用shell腳本）root@ecs-c13b~]#catfdisk.sh#!/bin/bash#截取IPIP=`ifconfigeth0|awk-F""'NR==2{print$2}'`#定義使用率,并轉(zhuǎn)換為數(shù)字SPACE=`df-Ph|awk'{printi...

1. 磁盤使用率檢測(cè)（用shell腳本）

root@ecs-c13b ~]# cat fdisk.sh
#!/bin/bash
# 截取IP
IP=`ifconfig eth0 |awk -F " " 'NR==2{print $2}'`
# 定義使用率,并轉(zhuǎn)換為數(shù)字
SPACE=`df -Ph |awk '{print int($5)}'`

for i in $SPACE
do
if [ $i -ge 90 ]
then
 echo "$IP的磁盤使用率已經(jīng)超過(guò)了90%，請(qǐng)及時(shí)處理"
fi
done

2. LVS 負(fù)載均衡有哪些策略？

LVS一共有三種工作模式：DR，Tunnel,NAT

3. 談?wù)勀銓?duì)LVS的理解？

LVS是一個(gè)虛擬的服務(wù)器集群系統(tǒng)，在unix系統(tǒng)下實(shí)現(xiàn)負(fù)載均衡的功能；采用IP負(fù)載均衡技術(shù)和機(jī)遇內(nèi)容請(qǐng)求分發(fā)技術(shù)來(lái)實(shí)現(xiàn)。

LVS采用三層結(jié)構(gòu)，分別是：

第一層：負(fù)載調(diào)度器

第二層：服務(wù)池

第三層：共享存儲(chǔ)

負(fù)載調(diào)度器（load balancer/ Director），是整個(gè)集群的總代理，它有兩個(gè)網(wǎng)卡，一個(gè)網(wǎng)卡面對(duì)訪問(wèn)網(wǎng) 站的客戶端，一個(gè)網(wǎng)卡面對(duì)整個(gè)集群的內(nèi)部。負(fù)責(zé)將客戶端的請(qǐng)求發(fā)送到一組服務(wù)器上執(zhí)行，而客戶也認(rèn)為服務(wù)是來(lái)自這臺(tái)主的。舉個(gè)生動(dòng)的例子，集群是個(gè)公司，負(fù)載調(diào)度器就是在外接攬生意，將接攬到的生意分發(fā)給后臺(tái)的真正干活的真正的主機(jī)們。當(dāng)然需要將活按照一定的算法分發(fā)下去，讓大家都公平的干活。

服務(wù)器池（server pool/ Realserver），是一組真正執(zhí)行客戶請(qǐng)求的服務(wù)器，可以當(dāng)做WEB服務(wù)器。就是上面例子中的小員工。

共享存儲(chǔ)（shared storage），它為服務(wù)器池提供一個(gè)共享的存儲(chǔ)區(qū)，這樣很容易使得服務(wù)器池?fù)碛邢?同的內(nèi)容，提供相同的服務(wù)。一個(gè)公司得有一個(gè)后臺(tái)賬目吧，這才能協(xié)調(diào)。不然客戶把錢付給了A，而換B接待客戶，因?yàn)闆]有相同的賬目。B說(shuō)客戶沒付錢，那這樣就不是客戶體驗(yàn)度的問(wèn)題了。

4. 負(fù)載均衡的原理是什么？

當(dāng)客戶端發(fā)起請(qǐng)求時(shí)，請(qǐng)求直接發(fā)給Director Server（調(diào)度器），這時(shí)會(huì)根據(jù)設(shè)定的調(diào)度算法，將請(qǐng)求按照算法的規(guī)定智能的分發(fā)到真正的后臺(tái)服務(wù)器。以達(dá)到將壓力均攤。

但是我們知道，http的連接時(shí)無(wú)狀態(tài)的，假設(shè)這樣一個(gè)場(chǎng)景，我登錄某寶買東西，當(dāng)我看上某款商品時(shí)，我將它加入購(gòu)物車，但是我刷新了一下頁(yè)面，這時(shí)由于負(fù)載均衡的原因，調(diào)度器又選了新的一臺(tái)服務(wù)器為我提供服務(wù)，我剛才的購(gòu)物車內(nèi)容全都不見了，這樣就會(huì)有十分差的用戶體驗(yàn)。

所以就還需要一個(gè)存儲(chǔ)共享，這樣就保證了用戶請(qǐng)求的數(shù)據(jù)是一樣的

5. LVS由哪兩部分組成的？

LVS 由2部分程序組成，包括 ipvs 和 ipvsadm。

1.ipvs(ip virtual server)：一段代碼工作在內(nèi)核空間，叫ipvs，是真正生效實(shí)現(xiàn)調(diào)度的代碼。

2. ipvsadm：另外一段是工作在用戶空間，叫ipvsadm，負(fù)責(zé)為ipvs內(nèi)核框架編寫規(guī)則，定義誰(shuí)是集群服務(wù)，而誰(shuí)是后端真實(shí)的服務(wù)器(Real Server)

6. 與lvs相關(guān)的術(shù)語(yǔ)有哪些？

DS：Director Server。指的是前端負(fù)載均衡器節(jié)點(diǎn)。

RS：Real Server。后端真實(shí)的工作服務(wù)器。

VIP：Virtual IP 向外部直接面向用戶請(qǐng)求，作為用戶請(qǐng)求的目標(biāo)的IP地址。

DIP：Director Server IP，主要用于和內(nèi)部主機(jī)通訊的IP地址。

RIP：Real Server IP，后端服務(wù)器的IP地址。

CIP：Client IP，訪問(wèn)客戶端的IP地址。

7. LVS-NAT模式的原理

(a). 當(dāng)用戶請(qǐng)求到達(dá)Director Server，此時(shí)請(qǐng)求的數(shù)據(jù)報(bào)文會(huì)先到內(nèi)核空間的PREROUTING鏈。此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為VIP

(b). PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標(biāo)IP是本機(jī)，將數(shù)據(jù)包送至INPUT鏈

(c). IPVS比對(duì)數(shù)據(jù)包請(qǐng)求的服務(wù)是否為集群服務(wù)，若是，修改數(shù)據(jù)包的目標(biāo)IP地址為后端服務(wù)器 IP，然后將數(shù)據(jù)包發(fā)至POSTROUTING鏈。此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為RIP

(d). POSTROUTING鏈通過(guò)選路，將數(shù)據(jù)包發(fā)送給Real Server

(e). Real Server比對(duì)發(fā)現(xiàn)目標(biāo)為自己的IP，開始構(gòu)建響應(yīng)報(bào)文發(fā)回給Director Server。此時(shí)報(bào)文的源IP為RIP，目標(biāo)IP為CIP

(f). Director Server在響應(yīng)客戶端前，此時(shí)會(huì)將源IP地址修改為自己的VIP地址，然后響應(yīng)給客戶端。此時(shí)報(bào)文的源IP為VIP，目標(biāo)IP為CIP

8. LVS-NAT模型的特性

RS應(yīng)該使用私有地址，RS的網(wǎng)關(guān)必須指向DIP

DIP和RIP必須在同一個(gè)網(wǎng)段內(nèi)

請(qǐng)求和響應(yīng)報(bào)文都需要經(jīng)過(guò)Director Server，高負(fù)載場(chǎng)景中，Director Server易成為性能瓶頸

支持端口映射

RS可以使用任意操作系統(tǒng) 缺陷：對(duì)Director Server壓力會(huì)比較大，請(qǐng)求和響應(yīng)都需經(jīng)過(guò)director server

9. LVS-DR模式原理

(a) 當(dāng)用戶請(qǐng)求到達(dá)Director Server，此時(shí)請(qǐng)求的數(shù)據(jù)報(bào)文會(huì)先到內(nèi)核空間的PREROUTING鏈。此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為VIP

(b) PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標(biāo)IP是本機(jī)，將數(shù)據(jù)包送至INPUT鏈

(c) IPVS比對(duì)數(shù)據(jù)包請(qǐng)求的服務(wù)是否為集群服務(wù)，若是，將請(qǐng)求報(bào)文中的源MAC地址修改為DIP的 MAC地址，將目標(biāo)MAC地址修改RIP的MAC地址，然后將數(shù)據(jù)包發(fā)至POSTROUTING鏈。此時(shí)的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標(biāo)MAC地址為RIP的MAC地址

(d) 由于DS和RS在同一個(gè)網(wǎng)絡(luò)中，所以是通過(guò)二層來(lái)傳輸。POSTROUTING鏈檢查目標(biāo)MAC地址為 RIP的MAC地址，那么此時(shí)數(shù)據(jù)包將會(huì)發(fā)至Real Server。

(e) RS發(fā)現(xiàn)請(qǐng)求報(bào)文的MAC地址是自己的MAC地址，就接收此報(bào)文。處理完成之后，將響應(yīng)報(bào)文通過(guò)lo接口傳送給eth0網(wǎng)卡然后向外發(fā)出。此時(shí)的源IP地址為VIP，目標(biāo)IP為CIP

(f) 響應(yīng)報(bào)文最終送達(dá)至客戶端

10. LVS-DR模型的特性

特點(diǎn)1：保證前端路由將目標(biāo)地址為VIP報(bào)文統(tǒng)統(tǒng)發(fā)給Director Server，而不是RS

RS可以使用私有地址；也可以是公網(wǎng)地址，如果使用公網(wǎng)地址，此時(shí)可以通過(guò)互聯(lián)網(wǎng)對(duì)RIP進(jìn)行直接訪問(wèn)

RS跟Director Server必須在同一個(gè)物理網(wǎng)絡(luò)中

所有的請(qǐng)求報(bào)文經(jīng)由Director Server，但響應(yīng)報(bào)文必須不能進(jìn)過(guò)Director Server

不支持地址轉(zhuǎn)換，也不支持端口映射

RS可以是大多數(shù)常見的操作系統(tǒng)

RS的網(wǎng)關(guān)絕不允許指向DIP(因?yàn)槲覀儾辉试S他經(jīng)過(guò)director)

RS上的lo接口配置VIP的IP地址

缺陷：RS和DS必須在同一機(jī)房中

11. LVS三種負(fù)載均衡模式的比較

三種負(fù)載均衡：nat，tunneling，dr

|類目|NAT|TUN|DR|

|--|--|--|--|

操作系統(tǒng)|任意|支持隧道|多數(shù)（支持non-arp）

|服務(wù)器網(wǎng)絡(luò)|私有網(wǎng)絡(luò)|局域網(wǎng)/廣域網(wǎng)|局域網(wǎng)

|服務(wù)器數(shù)目|10-20|100|大于100

效率|一般|高|最高

12. LVS的負(fù)載調(diào)度算法

輪叫調(diào)度
加權(quán)輪叫調(diào)度
最小連接調(diào)度
加權(quán)最小連接調(diào)度
基于局部性能的最少連接
帶復(fù)制的基于局部性能最小連接
目標(biāo)地址散列調(diào)度
源地址散列調(diào)度

13. LVS與nginx的區(qū)別

vs的優(yōu)勢(shì)（互聯(lián)網(wǎng)老辛）：

抗負(fù)載能力強(qiáng)，因?yàn)閘vs工作方式的邏輯是非常簡(jiǎn)單的，而且工作在網(wǎng)絡(luò)的第4層，僅作請(qǐng)求分發(fā)用，沒有流量，所以在效率上基本不需要太過(guò)考慮。lvs一般很少出現(xiàn)故障，即使出現(xiàn)故障一般也是其他地方（如內(nèi)存、CPU等）出現(xiàn)問(wèn)題導(dǎo)致lvs出現(xiàn)問(wèn)題。

配置性低，這通常是一大劣勢(shì)同時(shí)也是一大優(yōu)勢(shì)，因?yàn)闆]有太多的可配置的選項(xiàng)，所以除了增減服務(wù)器，并不需要經(jīng)常去觸碰它，大大減少了人為出錯(cuò)的幾率。

工作穩(wěn)定，因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，所以穩(wěn)定性高也是順理成章的事，另外各種lvs都有完整的雙機(jī)熱備方案，所以一點(diǎn)不用擔(dān)心均衡器本身會(huì)出什么問(wèn)題，節(jié)點(diǎn)出現(xiàn)故障的話，lvs會(huì)自動(dòng)判別，所以系統(tǒng)整體是非常穩(wěn)定的。

無(wú)流量，lvs僅僅分發(fā)請(qǐng)求，而流量并不從它本身出去，所以可以利用它這點(diǎn)來(lái)做一些線路分流之用。沒有流量同時(shí)也保住了均衡器的IO性能不會(huì)受到大流量的影響。

lvs基本上能支持所有應(yīng)用，因?yàn)閘vs工作在第4層，所以它可以對(duì)幾乎所有應(yīng)用做負(fù)載均衡，包括 http、數(shù)據(jù)庫(kù)、聊天室等。

nginx與LVS的對(duì)比：

nginx工作在網(wǎng)絡(luò)的第7層，所以它可以針對(duì)http應(yīng)用本身來(lái)做分流策略，比如針對(duì)域名、目錄結(jié)構(gòu) 等，相比之下lvs并不具備這樣的功能，所以nginx單憑這點(diǎn)可以利用的場(chǎng)合就遠(yuǎn)多于lvs了；但 nginx有用的這些功能使其可調(diào)整度要高于lvs，所以經(jīng)常要去觸碰，由lvs的第2條優(yōu)點(diǎn)來(lái)看，觸碰多了，人為出現(xiàn)問(wèn)題的幾率也就會(huì)大。

nginx對(duì)網(wǎng)絡(luò)的依賴較小，理論上只要ping得通，網(wǎng)頁(yè)訪問(wèn)正常，nginx就能連得通，nginx同時(shí)還能區(qū)分內(nèi)外網(wǎng)，如果是同時(shí)擁有內(nèi)外網(wǎng)的節(jié)點(diǎn)，就相當(dāng)于單機(jī)擁有了備份線路；lvs就比較依賴于網(wǎng) 絡(luò)環(huán)境，目前來(lái)看服務(wù)器在同一網(wǎng)段內(nèi)并且lvs使用direct方式分流，效果較能得到保證。另外注意，lvs需要向托管商至少申請(qǐng)多于一個(gè)ip來(lái)做visual ip。

nginx安裝和配置比較簡(jiǎn)單，測(cè)試起來(lái)也很方便，因?yàn)樗灸馨彦e(cuò)誤用日志打印出來(lái)。lvs的安裝和配置、測(cè)試就要花比較長(zhǎng)的時(shí)間，因?yàn)橥纤?，lvs對(duì)網(wǎng)絡(luò)依賴性比較大，很多時(shí)候不能配置成功都是因?yàn)榫W(wǎng)絡(luò)問(wèn)題而不是配置問(wèn)題，出了問(wèn)題要解決也相應(yīng)的會(huì)麻煩的多。

?nginx也同樣能承受很高負(fù)載且穩(wěn)定，但負(fù)載度和穩(wěn)定度差lvs還有幾個(gè)等級(jí)：nginx處理所有流量所以受限于機(jī)器IO和配置；本身的bug也還是難以避免的；nginx沒有現(xiàn)成的雙機(jī)熱備方案，所以跑在單機(jī)上還是風(fēng)險(xiǎn)比較大，單機(jī)上的事情全都很難說(shuō)。

nginx可以檢測(cè)到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等，并且會(huì) 把返回錯(cuò)誤的請(qǐng)求重新提交到另一個(gè)節(jié)點(diǎn)。目前l(fā)vs中l(wèi)directd也能支持針對(duì)服務(wù)器內(nèi)部的情況來(lái)監(jiān) 控，但lvs的原理使其不能重發(fā)請(qǐng)求。比如用戶正在上傳一個(gè)文件，而處理該上傳的節(jié)點(diǎn)剛好在上傳過(guò)程中出現(xiàn)故障，nginx會(huì)把上傳切到另一臺(tái)服務(wù)器重新處理，而lvs就直接斷掉了。

兩者配合使用：

nginx用來(lái)做http的反向代理，能夠upsteam實(shí)現(xiàn)http請(qǐng)求的多種方式的均衡轉(zhuǎn)發(fā)。由于采用的是異步轉(zhuǎn) 發(fā)可以做到如果一個(gè)服務(wù)器請(qǐng)求失敗，立即切換到其他服務(wù)器，直到請(qǐng)求成功或者最后一臺(tái)服務(wù)器失敗為止。這可以最大程度的提高系統(tǒng)的請(qǐng)求成功率。

lvs采用的是同步請(qǐng)求轉(zhuǎn)發(fā)的策略。這里說(shuō)一下同步轉(zhuǎn)發(fā)和異步轉(zhuǎn)發(fā)的區(qū)別。同步轉(zhuǎn)發(fā)是在lvs服務(wù)器接收到請(qǐng)求之后，立即redirect到一個(gè)后端服務(wù)器，由客戶端直接和后端服務(wù)器建立連接。異步轉(zhuǎn)發(fā)是nginx 在保持客戶端連接的同時(shí)，發(fā)起一個(gè)相同內(nèi)容的新請(qǐng)求到后端，等后端返回結(jié)果后，由nginx返回給客戶端。

進(jìn)一步來(lái)說(shuō)：當(dāng)做為負(fù)載均衡服務(wù)器的nginx和lvs處理相同的請(qǐng)求時(shí)，所有的請(qǐng)求和響應(yīng)流量都會(huì)經(jīng)過(guò) nginx；但是使用lvs時(shí)，僅請(qǐng)求流量經(jīng)過(guò)lvs的網(wǎng)絡(luò)，響應(yīng)流量由后端服務(wù)器的網(wǎng)絡(luò)返回。

也就是，當(dāng)作為后端的服務(wù)器規(guī)模龐大時(shí)，nginx的網(wǎng)絡(luò)帶寬就成了一個(gè)巨大的瓶頸。

但是僅僅使用lvs作為負(fù)載均衡的話，一旦后端接受到請(qǐng)求的服務(wù)器出了問(wèn)題，那么這次請(qǐng)求就失敗了。但是如果在lvs的后端在添加一層nginx（多個(gè)），每個(gè)nginx后端再有幾臺(tái)應(yīng)用服務(wù)器，那么結(jié)合兩者的優(yōu)勢(shì)，既能避免單nginx的流量集中瓶頸，又能避免單lvs時(shí)一錘子買賣的問(wèn)題。

14. 負(fù)載均衡的作用有哪些？

1、轉(zhuǎn)發(fā)功能

按照一定的算法【權(quán)重、輪詢】，將客戶端請(qǐng)求轉(zhuǎn)發(fā)到不同應(yīng)用服務(wù)器上，減輕單個(gè)服務(wù)器壓力，提高系統(tǒng)并發(fā)量。

2、故障移除

通過(guò)心跳檢測(cè)的方式，判斷應(yīng)用服務(wù)器當(dāng)前是否可以正常工作，如果服務(wù)器期宕掉，自動(dòng)將請(qǐng)求發(fā)送到其他應(yīng)用服務(wù)器。

3、恢復(fù)添加

如檢測(cè)到發(fā)生故障的應(yīng)用服務(wù)器恢復(fù)工作，自動(dòng)將其添加到處理用戶請(qǐng)求隊(duì)伍中。

15. nginx實(shí)現(xiàn)負(fù)載均衡的分發(fā)策略

Nginx 的 upstream目前支持的分配算法：

1)、輪詢 ——1：1 輪流處理請(qǐng)求（默認(rèn)）

每個(gè)請(qǐng)求按時(shí)間順序逐一分配到不同的應(yīng)用服務(wù)器，如果應(yīng)用服務(wù)器down掉，自動(dòng)剔除，剩下的繼續(xù)輪詢。

2)、權(quán)重 ——you can you up 通過(guò)配置權(quán)重，指定輪詢幾率，權(quán)重和訪問(wèn)比率成正比，用于應(yīng)用服務(wù)器性能不均的情況。

3)、ip_哈希算法每個(gè)請(qǐng)求按訪問(wèn)ip的hash結(jié)果分配，這樣每個(gè)訪客固定訪問(wèn)一個(gè)應(yīng)用服務(wù)器，可以解決session共享的問(wèn)題。

16. keepalived 是什么？

廣義上講是高可用，狹義上講是主機(jī)的冗余和管理

Keepalived起初是為L(zhǎng)VS設(shè)計(jì)的，專門用來(lái)監(jiān)控集群系統(tǒng)中各個(gè)服務(wù)節(jié)點(diǎn)的狀態(tài)，它根據(jù)TCP/IP參考模型的第三、第四層、第五層交換機(jī)制檢測(cè)每個(gè)服務(wù)節(jié)點(diǎn)的狀態(tài)，如果某個(gè)服務(wù)器節(jié)點(diǎn)出現(xiàn)異常，或者工作出現(xiàn)故障，Keepalived將檢測(cè)到，并將出現(xiàn)的故障的服務(wù)器節(jié)點(diǎn)從集群系統(tǒng)中剔除，這些工作全部是自動(dòng)完成的，不需要人工干涉，需要人工完成的只是修復(fù)出現(xiàn)故障的服務(wù)節(jié)點(diǎn)。

后來(lái)Keepalived又加入了VRRP（VritrualRouterRedundancyProtocol，虛擬路由冗余協(xié)議）的功能，VRRP出現(xiàn)的目的是解決靜態(tài)路由出現(xiàn)的單點(diǎn)故障問(wèn)題，通過(guò)VRRP可以實(shí)現(xiàn)網(wǎng)絡(luò)不間斷穩(wěn)定運(yùn)行，因此 Keepalvied一方面具有服務(wù)器狀態(tài)檢測(cè)和故障隔離功能，另外一方面也有HAcluster功能。

所以，keepalived的核心功能就是健康檢查和失敗且換。所謂的健康檢查，就是采用tcp三次握手，icmp請(qǐng)求，http請(qǐng)求，udp echo請(qǐng)求等方式對(duì)負(fù)載均衡器后面的實(shí)際的服務(wù)器(通常是承載真實(shí)業(yè)務(wù)的服務(wù)器)進(jìn)行?；?；

而失敗切換主要是應(yīng)用于配置了主備模式的負(fù)載均衡器，利用VRRP維持主備負(fù)載均衡器的心跳，當(dāng)主負(fù)載均衡器出現(xiàn)問(wèn)題時(shí)，由備負(fù)載均衡器承載對(duì)應(yīng)的業(yè)務(wù)，從而在最大限度上減少流量損失，并提供服務(wù)的穩(wěn)定性

17. 你是如何理解VRRP協(xié)議的

為什么使用VRRP？

主機(jī)之間的通信都是通過(guò)配置靜態(tài)路由或者(默認(rèn)網(wǎng)關(guān))來(lái)完成的，而主機(jī)之間的路由器一旦發(fā)生故障，通信就會(huì)失效，因此這種通信模式當(dāng)中，路由器就成了一個(gè)單點(diǎn)瓶頸，為了解決這個(gè)問(wèn)題，就引入了VRRP 協(xié)議。

VRRP協(xié)議是一種容錯(cuò)的主備模式的協(xié)議，保證當(dāng)主機(jī)的下一跳路由出現(xiàn)故障時(shí)，由另一臺(tái)路由器來(lái)代替出現(xiàn)故障的路由器進(jìn)行工作，通過(guò)VRRP可以在網(wǎng)絡(luò)發(fā)生故障時(shí)透明的進(jìn)行設(shè)備切換而不影響主機(jī)之間的數(shù)據(jù)通信。

VRRP的三種狀態(tài)：

VRRP路由器在運(yùn)行過(guò)程中有三種狀態(tài)：

Initialize狀態(tài)：系統(tǒng)啟動(dòng)后就進(jìn)入Initialize，此狀態(tài)下路由器不對(duì)VRRP報(bào)文做任何處理；

Master狀態(tài)；

Backup狀態(tài)；一般主路由器處于Master狀態(tài)，備份路由器處于Backup狀態(tài)。

18. keepalived的工作原理？

keepalived采用是模塊化設(shè)計(jì)，不同模塊實(shí)現(xiàn)不同的功能。

keepalived主要有三個(gè)模塊，分別是core、check和vrrp。

core：是keepalived的核心，負(fù)責(zé)主進(jìn)程的啟動(dòng)和維護(hù)，全局配置文件的加載解析等

check：負(fù)責(zé)healthchecker(健康檢查)，包括了各種健康檢查方式，以及對(duì)應(yīng)的配置的解析包括LVS的配置解析；可基于腳本檢查對(duì)IPVS后端服務(wù)器健康狀況進(jìn)行檢查

vrrp：VRRPD子進(jìn)程，VRRPD子進(jìn)程就是來(lái)實(shí)現(xiàn)VRRP協(xié)議的

Keepalived高可用對(duì)之間是通過(guò) VRRP進(jìn)行通信的， VRRP是通過(guò)競(jìng)選機(jī)制來(lái)確定主備的，主的優(yōu)先級(jí)高于備，因此，工作時(shí)主會(huì)優(yōu)先獲得所有的資源，備節(jié)點(diǎn)處于等待狀態(tài)，當(dāng)主宕機(jī)的時(shí)候，備節(jié)點(diǎn)就會(huì)接管主節(jié)點(diǎn)的資源，然后頂替主節(jié)點(diǎn)對(duì)外提供服務(wù)

在Keepalived服務(wù)對(duì)之間，只有作為主的服務(wù)器會(huì)一直發(fā)送 VRRP廣播包,告訴備它還活著，此時(shí)備不會(huì) 搶占主，當(dāng)主不可用時(shí)，即備監(jiān)聽不到主發(fā)送的廣播包時(shí)，就會(huì)啟動(dòng)相關(guān)服務(wù)接管資源，保證業(yè)務(wù)的連續(xù)性.接管速度最快

19. 出現(xiàn)腦裂的原因

什么是腦裂？

在高可用（HA）系統(tǒng)中，當(dāng)聯(lián)系2個(gè)節(jié)點(diǎn)的“心跳線”斷開時(shí)，本來(lái)為一整體、動(dòng)作協(xié)調(diào)的HA系統(tǒng)，就分裂成為2個(gè)獨(dú)立的個(gè)體。

由于相互失去了聯(lián)系，都以為是對(duì)方出了故障。兩個(gè)節(jié)點(diǎn)上的HA軟件像“裂腦人”一樣，爭(zhēng)搶“共享資源”、爭(zhēng)起“應(yīng)用服務(wù)”，就會(huì)發(fā)生嚴(yán)重后果。共享資源被瓜分、兩邊“服務(wù)”都起不來(lái)了；或者兩邊 “服務(wù)”都起來(lái)了，但同時(shí)讀寫“共享存儲(chǔ)”，導(dǎo)致數(shù)據(jù)損壞。

都有哪些原因?qū)е履X裂？

高可用服務(wù)器對(duì)之間心跳線鏈路發(fā)生故障，導(dǎo)致無(wú)法正常通信。

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

因網(wǎng)卡及相關(guān)驅(qū)動(dòng)壞了，ip配置及沖突問(wèn)題（網(wǎng)卡直連）

因心跳線間連接的設(shè)備故障（網(wǎng)卡及交換機(jī)）

因仲裁的機(jī)器出問(wèn)題（采用仲裁的方案）

高可用服務(wù)器上開啟了 iptables防火墻阻擋了心跳消息傳輸。

高可用服務(wù)器上心跳網(wǎng)卡地址等信息配置不正確，導(dǎo)致發(fā)送心跳失敗

其他服務(wù)配置不當(dāng)?shù)仍?，如心跳方式不同，心跳廣插沖突、軟件Bug等。

20. 如何解決keepalived腦裂問(wèn)題？

在實(shí)際生產(chǎn)環(huán)境中，我們從以下方面防止腦裂：

同時(shí)使用串行電纜和以太網(wǎng)電纜連接、同時(shí)使用兩條心跳線路，這樣一條線路斷了，另外一條還是好的，依然能傳送心跳消息。

當(dāng)檢查腦裂時(shí)強(qiáng)行關(guān)閉一個(gè)心跳節(jié)點(diǎn)（這個(gè)功能需要特殊設(shè)備支持，如stonith、fence）相當(dāng)于備節(jié)點(diǎn)接收不到心跳消息，通過(guò)單獨(dú)的線路發(fā)送關(guān)機(jī)命令關(guān)閉主節(jié)點(diǎn)的電源，做好對(duì)腦裂的監(jiān)控報(bào)警。

解決常見方案：

如果開啟防火墻，一定要讓心跳消息通過(guò)，一般通過(guò)允許IP段的形式解決。可以拉一條以太網(wǎng)網(wǎng)線或者串口線作為主被節(jié)點(diǎn)心跳線路的冗余，開發(fā)檢測(cè)程序通過(guò)監(jiān)控軟件檢測(cè)腦裂。

END
來(lái)源：一口Linux版權(quán)歸原作者所有，如有侵權(quán)，請(qǐng)聯(lián)系刪除。
▍

跳槽必備！Linux運(yùn)維工程師20道面試題及解析