Making Facebook self-healing: Automating proactive rack maintenanceweb
原文:https://code.fb.com/productio...
做者: Romain Komorn
翻譯: 時序數據庫
咱們一直但願facebook的產品和服務在任何使用它的人,不管他們在世界的哪裏,都能工做正常,這驅動咱們主動監測和定位咱們基礎設施產品的問題,讓咱們避免可能引發百萬用戶在任什麼時候間使用facebook時致使變慢或中斷服務的狀況。緩存
在2011,咱們引入了 Facebook Auto Remediation (FBAR)服務,一組運行在每一個服務器上用來在檢測到軟件和硬件故障時自動執行代碼的守護進程。天天,不須要人干預,FBAR將這些服務器從生產環境摘除並向咱們的數據中心團隊發送請求去執行物理硬件維修,保障這些隔離的故障不出問題。安全
當咱們的基礎設施不斷擴大,咱們也須要在機架級別或像網絡交換機/備用電源單元等其餘故障域檢測和定位問題。多個服務可能在一個機架上,天天運行這樣的維護可能會在一年中屢次中斷不少團隊。服務器
爲了最小化干擾,咱們在FBAR之上開發了一個叫作Aggregate Maintenance Handlers(聚合維護處理)的加強功能,能夠提供一種一次性自動維護多個服務器的方法。在自動化不夠的場景下,咱們也開發了Dapper,一個經過人工介入來保證計劃內維護能夠安全進行的工具。文章後面的內容會介紹Aggregate Maintenance Handlers是怎麼樣在多種停機場景工做的,包括當自動化失敗時會發生什麼,Dapper是如何協調自動化和人工處理的。微信
FBAR有方法一次disable和reenable一個主機,當在多個主機上一次性地按順序或並行執行這些方法不夠保險。順序執行的方式可能會太消耗時間或讓服務處於容量不足的風險下。並行執行的方式可能會致使出現條件競爭並使服務更快的產生容量不足。網絡
Aggregate Maintenance Handlers提供框架來批量自動disable和enable服務器,爲咱們的工程師執行維護工做時提供完整的情景上下文和全部被影響的服務器範圍。app
停機的影響在大小,長度,類型上都差別很大:一些影響一個單獨的機架,一些會影響好幾個;它們能夠長或短;一些隻影響網絡連通性而一些會影響電源。不一樣的服務要使用不一樣的方式來處理停機。當咱們計劃一個維護工做,咱們提供Aggregate Maintenance Handler四塊信息來決定它在咱們整體基礎設施上的影響:負載均衡
咱們的工程師能夠用這個影響描述來決定如何自動化並優化怎樣處理停機。讓咱們看下三個簡單例子:框架
計算中斷的類型和時長可讓咱們爲每一個服務創建一個簡單的決策矩陣:
當一個可用的維護計劃被計劃和選擇後,處理器遵循一個四步工做流來關閉影響的主機:
起飛前檢查: 起飛前檢查會在關閉過程的最開始被調用,用來檢查沒有被影響的服務器是否有足夠的容量來保障動做的安全性。它返回一個true或false來指導維護工做能夠繼續進行或終止。起飛前檢查也能夠做爲定時調度進程的一部分獨立調用,讓團隊能夠有更多時間處理其可能返回false的場景。
讓咱們想象下給定約束下的6個機架:
如今讓咱們設想下兩個維護場景:
起飛檢查會檢查兩個場景下的web服務器,但在場景B,起飛檢查會在緩存和數據庫服務器上失敗,維護任務不容許自動化運行(這個場景會在下節詳細介紹)
當全部起飛檢查經過,咱們的Aggregate Maintenance Handlers讓咱們能夠在以前已經有的主機級別disable/enable邏輯上包裝一層更智能的代碼層。
未完待續。
本文來自微信公衆號「麥芽麪包,id「darkjune_think」轉載請註明。交流Email: zhukunrong@yeah.net