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

Making Facebook self-healing: Automating proactive rack maintenance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

起飛前檢查

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

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

關(guān)閉后處理

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

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

現(xiàn)在讓我們設(shè)想下兩個維護(hù)場景：

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

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

未完待續(xù)。

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