摘要：一個(gè)在內(nèi)存中保存靜態(tài)索引的緩存機(jī)器可以接受從負(fù)載均衡池中摘除時(shí)長時(shí)間的網(wǎng)絡(luò)中斷。處理一次重啟需要主動(dòng)替換一個(gè)沒有被同一次維護(hù)影響的服務(wù)器。主機(jī)可以被從負(fù)載均衡池中移除，數(shù)據(jù)可以存儲(chǔ)在磁盤上，服務(wù)器也可以在重啟后快速追平復(fù)制進(jìn)度。

Making Facebook self-healing: Automating proactive rack maintenance

原文：https://code.fb.com/productio...
作者： Romain Komorn
翻譯： 時(shí)序

我們一直希望facebook的產(chǎn)品和服務(wù)在任何使用它的人，無論他們?cè)谑澜绲哪睦?，都能工作正常，這驅(qū)動(dòng)我們主動(dòng)監(jiān)測(cè)和定位我們基礎(chǔ)設(shè)施產(chǎn)品的問題，讓我們避免可能引起百萬用戶在任何時(shí)間使用facebook時(shí)導(dǎo)致變慢或中斷服務(wù)的情況。

在2011，我們引入了 Facebook Auto Remediation (FBAR)服務(wù)，一組運(yùn)行在每個(gè)服務(wù)器上用來在檢測(cè)到軟件和硬件故障時(shí)自動(dòng)執(zhí)行代碼的守護(hù)進(jìn)程。每天，不需要人干預(yù)，F(xiàn)BAR將這些服務(wù)器從生產(chǎn)環(huán)境摘除并向我們的數(shù)據(jù)中心團(tuán)隊(duì)發(fā)送請(qǐng)求去執(zhí)行物理硬件維修，保障這些隔離的故障不出問題。

當(dāng)我們的基礎(chǔ)設(shè)施不斷擴(kuò)大，我們也需要在機(jī)架級(jí)別或像網(wǎng)絡(luò)交換機(jī)/備用電源單元等其他故障域檢測(cè)和定位問題。多個(gè)服務(wù)可能在一個(gè)機(jī)架上，每天運(yùn)行這樣的維護(hù)可能會(huì)在一年中多次中斷很多團(tuán)隊(duì)。

為了最小化干擾，我們?cè)贔BAR之上開發(fā)了一個(gè)叫做Aggregate Maintenance Handlers(聚合維護(hù)處理)的增強(qiáng)功能，可以提供一種一次性自動(dòng)維護(hù)多個(gè)服務(wù)器的方法。在自動(dòng)化不夠的場(chǎng)景下，我們也開發(fā)了Dapper，一個(gè)通過人工介入來保證計(jì)劃內(nèi)維護(hù)可以安全進(jìn)行的工具。文章后面的內(nèi)容會(huì)介紹Aggregate Maintenance Handlers是怎么樣在多種停機(jī)場(chǎng)景工作的，包括當(dāng)自動(dòng)化失敗時(shí)會(huì)發(fā)生什么，Dapper是如何協(xié)調(diào)自動(dòng)化和人工處理的。

FBAR有方法一次disable和reenable一個(gè)主機(jī)，當(dāng)在多個(gè)主機(jī)上一次性地按順序或并行執(zhí)行這些方法不夠保險(xiǎn)。順序執(zhí)行的方式可能會(huì)太消耗時(shí)間或讓服務(wù)處于容量不足的風(fēng)險(xiǎn)下。并行執(zhí)行的方式可能會(huì)導(dǎo)致出現(xiàn)條件競爭并使服務(wù)更快的產(chǎn)生容量不足。

Aggregate Maintenance Handlers提供框架來批量自動(dòng)disable和enable服務(wù)器，為我們的工程師執(zhí)行維護(hù)工作時(shí)提供完整的情景上下文和所有被影響的服務(wù)器范圍。

停機(jī)的影響在大小，長度，類型上都差異很大：一些影響一個(gè)多帶帶的機(jī)架，一些會(huì)影響好幾個(gè)；它們可以長或短；一些只影響網(wǎng)絡(luò)連通性而一些會(huì)影響電源。不同的服務(wù)要使用不同的方式來處理停機(jī)。當(dāng)我們計(jì)劃一個(gè)維護(hù)工作，我們提供Aggregate Maintenance Handler四塊信息來決定它在我們總體基礎(chǔ)設(shè)施上的影響：

范圍（維護(hù)會(huì)影響的服務(wù)器列表）

維護(hù)類型（網(wǎng)絡(luò)中斷，電源中斷）

維護(hù)開始時(shí)間（如太平洋標(biāo)準(zhǔn)時(shí)間早上十點(diǎn)）

維護(hù)時(shí)長（如2小時(shí)）

我們的工程師可以用這個(gè)影響描述來決定如何自動(dòng)化并優(yōu)化怎樣處理停機(jī)。讓我們看下三個(gè)簡單例子：

一個(gè)無狀態(tài)的web服務(wù)器在被從負(fù)載均衡池中移除是可以接受任意時(shí)長的網(wǎng)絡(luò)和電源中斷。這個(gè)場(chǎng)景里唯一需要關(guān)心的是保證仍有足夠的web服務(wù)器來處理所有請(qǐng)求。

一個(gè)在內(nèi)存中保存靜態(tài)索引的緩存機(jī)器可以接受從負(fù)載均衡池中摘除時(shí)長時(shí)間的網(wǎng)絡(luò)中斷。當(dāng)網(wǎng)絡(luò)恢復(fù)，機(jī)器可以立即提供索引服務(wù)。一個(gè)短的電源中斷，則需要重新將索引加載到內(nèi)存。處理一次重啟需要主動(dòng)替換一個(gè)沒有被同一次維護(hù)影響的服務(wù)器。

一個(gè)進(jìn)行高吞吐復(fù)制的MySQL復(fù)制服務(wù)可以接受一次短的電源中斷。主機(jī)可以被從負(fù)載均衡池中移除，數(shù)據(jù)可以存儲(chǔ)在磁盤上，MySQL服務(wù)器也可以在重啟后快速追平復(fù)制進(jìn)度。相反的，如果中斷幾小時(shí)的網(wǎng)絡(luò)會(huì)導(dǎo)致數(shù)據(jù)落后太多，所以此時(shí)對(duì)復(fù)制服務(wù)器進(jìn)行主動(dòng)替換會(huì)是一個(gè)更好的選擇。

計(jì)算中斷的類型和時(shí)長可以讓我們?yōu)槊總€(gè)服務(wù)建立一個(gè)簡單的決策矩陣：

當(dāng)一個(gè)可用的維護(hù)計(jì)劃被計(jì)劃和選擇后，處理器遵循一個(gè)四步工作流來關(guān)閉影響的主機(jī)：

起飛前檢查

預(yù)關(guān)閉

主機(jī)級(jí)別關(guān)閉

關(guān)閉后處理

起飛前檢查： 起飛前檢查會(huì)在關(guān)閉過程的最開始被調(diào)用，用來檢查沒有被影響的服務(wù)器是否有足夠的容量來保障動(dòng)作的安全性。它返回一個(gè)true或false來指導(dǎo)維護(hù)工作可以繼續(xù)進(jìn)行或終止。起飛前檢查也可以作為定時(shí)調(diào)度進(jìn)程的一部分獨(dú)立調(diào)用，讓團(tuán)隊(duì)可以有更多時(shí)間處理其可能返回false的場(chǎng)景。

讓我們想象下給定約束下的6個(gè)機(jī)架：

現(xiàn)在讓我們?cè)O(shè)想下兩個(gè)維護(hù)場(chǎng)景：

起飛檢查會(huì)檢查兩個(gè)場(chǎng)景下的web服務(wù)器，但在場(chǎng)景B，起飛檢查會(huì)在緩存和數(shù)據(jù)庫服務(wù)器上失敗，維護(hù)任務(wù)不允許自動(dòng)化運(yùn)行（這個(gè)場(chǎng)景會(huì)在下節(jié)詳細(xì)介紹）

當(dāng)所有起飛檢查通過，我們的Aggregate Maintenance Handlers讓我們可以在之前已經(jīng)有的主機(jī)級(jí)別disable/enable邏輯上包裝一層更智能的代碼層。

未完待續(xù)。

本文來自微信公眾號(hào)「麥芽面包，id「darkjune_think」轉(zhuǎn)載請(qǐng)注明。
交流Email: zhukunrong@yeah.net