分布式實現(xiàn)：如何檢測一臺機器是否宕機？

作者：日照 2010-11-22 09:29:31

運維

系統(tǒng)運維

Linux

分布式 檢測一臺機器是否宕機必須是可靠的。在大規(guī)模集群中，機器可能出現(xiàn)各種異常，比如停電，磁盤故障，過于繁忙導(dǎo)致假死等。對于機器假死，如果總控節(jié)點認(rèn)為機器宕機并將服務(wù)遷移到其它節(jié)點，假死的機器又認(rèn)為自己還可以提供服務(wù)，則會出現(xiàn)多個節(jié)點服務(wù)同一份數(shù)據(jù)而導(dǎo)致數(shù)據(jù)不一致的情況。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供羅湖網(wǎng)站建設(shè)、羅湖做網(wǎng)站、羅湖網(wǎng)站設(shè)計、羅湖網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、羅湖企業(yè)網(wǎng)站模板建站服務(wù)，十載羅湖做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

編輯導(dǎo)讀：本文轉(zhuǎn)載自淘寶核心系統(tǒng)運維團隊博客，文中描述的宕機檢測方式適用于大規(guī)模集群環(huán)境，但原理仍是基于雙節(jié)點，有需求的朋友們可以借鑒。

檢測一臺機器是否宕機的應(yīng)用場景如下：

1, 工作機器宕機，總控節(jié)點需要能夠檢測到并且將原有服務(wù)遷移到集群中的其它節(jié)點。

2, 總控節(jié)點宕機，總控節(jié)點的備份節(jié)點（一般稱為Slave）需要能夠檢測到并替換成主節(jié)點繼續(xù)對外服務(wù)。

檢測一臺機器是否宕機必須是可靠的。在大規(guī)模集群中，機器可能出現(xiàn)各種異常，比如停電，磁盤故障，過于繁忙導(dǎo)致假死等。對于機器假死，如果總控節(jié)點認(rèn)為機器宕機并將服務(wù)遷移到其它節(jié)點，假死的機器又認(rèn)為自己還可以提供服務(wù)，則會出現(xiàn)多個節(jié)點服務(wù)同一份數(shù)據(jù)而導(dǎo)致數(shù)據(jù)不一致的情況。
 

首先必須明確，理論上檢測另外一臺機器是否宕機是無法做到的，有興趣的同學(xué)可以參考Fischer的論文?？梢院唵卫斫馊缦拢篈機器往B機器發(fā)送心跳包，如果B機器不發(fā)送響應(yīng)，A無法確定B機器是宕機了還是過于繁忙，由于A和B兩臺機器的時鐘可能不同步，B機器也無法確定多久沒有收到A機器的心跳包可以認(rèn)為必須停止服務(wù)。因此，A機器沒有辦法確定B機器已經(jīng)宕機或者采取措施強制B機器停止服務(wù)。

當(dāng)然，工程實踐中，由于機器之間會進行時鐘同步，我們總是假設(shè)A和B兩臺機器的本地時鐘相差不大，比如相差不超過0.5秒。這樣，我們可以通過Lease機制進行宕機檢測。Lease機制就是帶有超時時間的一種授權(quán)。假設(shè)總控節(jié)點需要檢測工作節(jié)點是否宕機，總控節(jié)點可以給工作節(jié)點發(fā)放Lease授權(quán)，工作節(jié)點持有有效期內(nèi)的Lease才允許提供服務(wù)，否則主動下線停止服務(wù)。工作節(jié)點的Lease快要到期的時候向總控節(jié)點重新申請Lease（一般稱為renewLease），總控節(jié)點定時檢測所有工作機的Lease授權(quán)是否合法，如果發(fā)現(xiàn)某臺工作機Lease失效，可以將工作機上的服務(wù)遷移到集群中的其它機器，這時因為工作機發(fā)現(xiàn)自己Lease失效會主動停止服務(wù)。當(dāng)然，這里需要注意，由于總控節(jié)點和工作機的時鐘可能不一致且有網(wǎng)絡(luò)延遲，總控節(jié)點上的Lease超時時間要長，也就是說，如果工作節(jié)點的Lease超時時間是12秒，總控節(jié)點可能需要13秒后才能確認(rèn)工作節(jié)點已經(jīng)停止了服務(wù)，從而避免數(shù)據(jù)不一致問題。

同構(gòu)節(jié)點之間的選主也有一個宕機檢測問題。比如總控節(jié)點宕機，備份節(jié)點需要能夠檢測并升級為主節(jié)點繼續(xù)對外服務(wù)。Mysql數(shù)據(jù)庫經(jīng)常采用Heartbeat + DRBD (Distributed Replicated Block Device) + Mysql的高可用性方案，據(jù)說能夠達到3個9的高可用性，主節(jié)點和備節(jié)點維持Heartbeat心跳，當(dāng)提供服務(wù)的主節(jié)點出現(xiàn)故障時，備節(jié)點的Heartbeat檢測到主節(jié)點沒有心跳（例如，Ping不通主節(jié)點），備節(jié)點自動接管虛擬IP，升級為主節(jié)點提供Mysql讀寫服務(wù)。由于Heartbeat檢測機器主節(jié)點宕機不可靠，這個方案存在眾所周知的腦裂問題，即集群中可能同時存在多個主節(jié)點同時提供服務(wù)。解決這個問題本質(zhì)上還是需要引入仲裁節(jié)點，比如Heartbeat + DRBD方案中引入Fence節(jié)點使出現(xiàn)問題的節(jié)點從集群中脫離，或者引入分布式鎖服務(wù)，比如Chubby的開源實現(xiàn)Zookeeper服務(wù)。分布式鎖服務(wù)實現(xiàn)主節(jié)點選舉大致如下：主節(jié)點和備節(jié)點到Chubby中搶鎖，搶到鎖的節(jié)點在鎖的有效期(Lease期)內(nèi)提供服務(wù)，當(dāng)主節(jié)點鎖的Lease快要到期時，主節(jié)點申請延長鎖的超時時間，正常情況下分布式鎖服務(wù)總是優(yōu)先滿足主節(jié)點的請求，當(dāng)主節(jié)點出現(xiàn)故障時，備節(jié)點能夠搶到鎖切換為主節(jié)點提供服務(wù)。

***還有一個問題，假設(shè)總控節(jié)點通過Lease機制檢測工作節(jié)點是否宕機，這種方案是可靠的，不過當(dāng)總控節(jié)點宕機時，如果不采取任何措施，集群中的所有工作節(jié)點都將因為無法重新申請Lease而停止服務(wù)，這就是帶有總控節(jié)點的設(shè)計固有的脆弱性，某個設(shè)計或者編碼的錯誤都有可能造成嚴(yán)重的影響。解決這個問題一般會有一個叫做Grace Period的機制，工作節(jié)點Lease超時時將停止服務(wù)，但是工作節(jié)點并不一開始就重啟或者下線，而是處于一種危險狀態(tài)(稱為Jeopardy)，這種狀態(tài)持續(xù)一個Grace Period，比如45秒。如果在Grace Period 內(nèi)總控節(jié)點重啟，工作節(jié)點和總控節(jié)點重新聯(lián)系上從而可以切換為正常狀態(tài)繼續(xù)提供服務(wù)。

如果需要較好地理解宕機及選舉相關(guān)的問題，可以閱讀并思考Paxos相關(guān)的論文，比如Paxos made simple, The Part-time Parliament, Paxos made live, Paxos made practical, Chubby等。有任何問題，歡迎討論。

【編輯推薦】

1. 互聯(lián)網(wǎng)40年：千里之行始于“宕機”
2. 國外十大流行的服務(wù)器監(jiān)控工具（外篇）
3. 10款免費的企業(yè)級安全監(jiān)控工具

網(wǎng)站欄目：分布式實現(xiàn)：如何檢測一臺機器是否宕機？
URL標(biāo)題：http://uogjgqi.cn/article/dpcsosc.html