1. 磁盤使用率檢測（用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)超過了90%，請及時處理"
fi
done2. LVS 負載均衡有哪些策略？

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

3. 談談你對LVS的理解？

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

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

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

第二層：服務池

第三層：共享存儲

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

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

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

4. 負載均衡的原理是什么？

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

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

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

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

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

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

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

6. 與lvs相關的術語有哪些？

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

RS：Real Server。后端真實的工作服務器。

VIP：Virtual IP 向外部直接面向用戶請求，作為用戶請求的目標的IP地址。

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

RIP：Real Server IP，后端服務器的IP地址。

CIP：Client IP，訪問客戶端的IP地址。

7. LVS-NAT模式的原理

(a). 當用戶請求到達Director Server，此時請求的數(shù)據(jù)報文會先到內(nèi)核空間的PREROUTING鏈。此時報文的源IP為CIP，目標IP為VIP

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

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

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

(e). Real Server比對發(fā)現(xiàn)目標為自己的IP，開始構建響應報文發(fā)回給Director Server。此時報文 的源IP為RIP，目標IP為CIP

(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然后響應給客戶 端。此時報文的源IP為VIP，目標IP為CIP

8. LVS-NAT模型的特性

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

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

請求和響應報文都需要經(jīng)過Director Server，高負載場景中，Director Server易成為性能瓶頸

支持端口映射

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

9. LVS-DR模式原理

(a) 當用戶請求到達Director Server，此時請求的數(shù)據(jù)報文會先到內(nèi)核空間的PREROUTING鏈。此 時報文的源IP為CIP，目標IP為VIP

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

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

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

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

(f) 響應報文最終送達至客戶端

10. LVS-DR模型的特性

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

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

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

所有的請求報文經(jīng)由Director Server，但響應報文必須不能進過Director Server

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

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

RS的網(wǎng)關絕不允許指向DIP(因為我們不允許他經(jīng)過director)

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

缺陷：RS和DS必須在同一機房中

11. LVS三種負載均衡模式的比較

三種負載均衡：nat，tunneling，dr

|類目|NAT|TUN|DR|

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

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

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

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

|服務器網(wǎng)關|負載均衡器|自己的路由|自己的路由|

效率|一般|高|最高

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

• 輪叫調(diào)度

• 加權輪叫調(diào)度

• 最小連接調(diào)度

• 加權最小連接調(diào)度

• 基于局部性能的最少連接

• 帶復制的基于局部性能最小連接

• 目標地址散列調(diào)度

• 源地址散列調(diào)度

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

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

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

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

工作穩(wěn)定，因為其本身抗負載能力很強，所以穩(wěn)定性高也是順理成章的事，另外各種lvs都有完整 的雙機熱備方案，所以一點不用擔心均衡器本身會出什么問題，節(jié)點出現(xiàn)故障的話，lvs會自動判 別，所以系統(tǒng)整體是非常穩(wěn)定的。

無流量，lvs僅僅分發(fā)請求，而流量并不從它本身出去，所以可以利用它這點來做一些線路分流之 用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。

lvs基本上能支持所有應用，因為lvs工作在第4層，所以它可以對幾乎所有應用做負載均衡，包括 http、數(shù)據(jù)庫、聊天室等。

nginx與LVS的對比：

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

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

nginx安裝和配置比較簡單，測試起來也很方便，因為它基本能把錯誤用日志打印出來。lvs的安裝 和配置、測試就要花比較長的時間，因為同上所述，lvs對網(wǎng)絡依賴性比較大，很多時候不能配置成 功都是因為網(wǎng)絡問題而不是配置問題，出了問題要解決也相應的會麻煩的多。

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

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

兩者配合使用：

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

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

進一步來說：當做為負載均衡服務器的nginx和lvs處理相同的請求時，所有的請求和響應流量都會經(jīng)過 nginx；但是使用lvs時，僅請求流量經(jīng)過lvs的網(wǎng)絡，響應流量由后端服務器的網(wǎng)絡返回。

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

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

14. 負載均衡的作用有哪些？

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

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

2、故障移除

通過心跳檢測的方式，判斷應用服務器當前是否可以正常工作，如果服務器期宕掉，自動將請求發(fā)送到 其他應用服務器。

3、恢復添加

如檢測到發(fā)生故障的應用服務器恢復工作，自動將其添加到處理用戶請求隊伍中。

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

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

1)、輪詢 ——1：1 輪流處理請求（默認）

每個請求按時間順序逐一分配到不同的應用服務器，如果應用服務器down掉，自動剔除，剩下的繼續(xù)輪詢。

2)、權重 ——you can you up 通過配置權重，指定輪詢幾率，權重和訪問比率成正比，用于應用服務器性能不均的情況。

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

16. keepalived 是什么？

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

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

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

所以，keepalived的核心功能就是健康檢查和失敗且換。所謂的健康檢查，就是采用tcp三次握手，icmp請求，http請求，udp echo請求等方式對負載均衡器后 面的實際的服務器(通常是承載真實業(yè)務的服務器)進行?；睿?/p>而失敗切換主要是應用于配置了主備模式的負載均衡器，利用VRRP維持主備負載均衡器的心跳，當主負載均衡器出現(xiàn)問題時，由備負載均衡器承載對應的業(yè)務，從而在最大限度上減少流量損失，并提供服務的穩(wěn)定性

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

為什么使用VRRP？

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

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

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

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

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

Master狀態(tài)；

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

18. keepalived的工作原理？

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

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

core：是keepalived的核心，負責主進程的啟動和維護，全局配置文件的加載解析等

check：負責healthchecker(健康檢查)，包括了各種健康檢查方式，以及對應的配置的解析包括LVS的 配置解析；可基于腳本檢查對IPVS后端服務器健康狀況進行檢查

vrrp：VRRPD子進程，VRRPD子進程就是來實現(xiàn)VRRP協(xié)議的

Keepalived高可用對之間是通過 VRRP進行通信的， VRRP是通過競選機制來確定主備的，主的優(yōu)先級高 于備，因此，工作時主會優(yōu)先獲得所有的資源，備節(jié)點處于等待狀態(tài)，當主宕機的時候，備節(jié)點就會接 管主節(jié)點的資源，然后頂替主節(jié)點對外提供服務

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

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

什么是腦裂？

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

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

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

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

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

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

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

因仲裁的機器出問題（采用仲裁的方案）

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

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

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

20. 如何解決keepalived腦裂問題？

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

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

當檢查腦裂時強行關閉一個心跳節(jié)點（這個功能需要特殊設備支持，如stonith、fence）相當于備 節(jié)點接收不到心跳消息，通過單獨的線路發(fā)送關機命令關閉主節(jié)點的電源，做好對腦裂的監(jiān)控報警。

解決常見方案：

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

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