讓facebook自愈:自動化主動機架維護 - 1

Making Facebook self-healing: Automating proactive rack maintenanceweb

原文:https://code.fb.com/productio...
做者: Romain Komorn
翻譯: 時序數據庫

clipboard.png

咱們一直但願facebook的產品和服務在任何使用它的人,不管他們在世界的哪裏,都能工做正常,這驅動咱們主動監測和定位咱們基礎設施產品的問題,讓咱們避免可能引發百萬用戶在任什麼時候間使用facebook時致使變慢或中斷服務的狀況。緩存

在2011,咱們引入了 Facebook Auto Remediation (FBAR)服務,一組運行在每一個服務器上用來在檢測到軟件和硬件故障時自動執行代碼的守護進程。天天,不須要人干預,FBAR將這些服務器從生產環境摘除並向咱們的數據中心團隊發送請求去執行物理硬件維修,保障這些隔離的故障不出問題。安全

當咱們的基礎設施不斷擴大,咱們也須要在機架級別或像網絡交換機/備用電源單元等其餘故障域檢測和定位問題。多個服務可能在一個機架上,天天運行這樣的維護可能會在一年中屢次中斷不少團隊。服務器

爲了最小化干擾,咱們在FBAR之上開發了一個叫作Aggregate Maintenance Handlers(聚合維護處理)的加強功能,能夠提供一種一次性自動維護多個服務器的方法。在自動化不夠的場景下,咱們也開發了Dapper,一個經過人工介入來保證計劃內維護能夠安全進行的工具。文章後面的內容會介紹Aggregate Maintenance Handlers是怎麼樣在多種停機場景工做的,包括當自動化失敗時會發生什麼,Dapper是如何協調自動化和人工處理的。微信

使用Aggregate Maintenance Handlers進行自動化

FBAR有方法一次disable和reenable一個主機,當在多個主機上一次性地按順序或並行執行這些方法不夠保險。順序執行的方式可能會太消耗時間或讓服務處於容量不足的風險下。並行執行的方式可能會致使出現條件競爭並使服務更快的產生容量不足。網絡

Aggregate Maintenance Handlers提供框架來批量自動disable和enable服務器,爲咱們的工程師執行維護工做時提供完整的情景上下文和全部被影響的服務器範圍。app

基於維護影響範圍來作決定

停機的影響在大小,長度,類型上都差別很大:一些影響一個單獨的機架,一些會影響好幾個;它們能夠長或短;一些隻影響網絡連通性而一些會影響電源。不一樣的服務要使用不一樣的方式來處理停機。當咱們計劃一個維護工做,咱們提供Aggregate Maintenance Handler四塊信息來決定它在咱們整體基礎設施上的影響:負載均衡

  1. 範圍(維護會影響的服務器列表)
  2. 維護類型(網絡中斷,電源中斷)
  3. 維護開始時間(如太平洋標準時間早上十點)
  4. 維護時長(如2小時)

咱們的工程師能夠用這個影響描述來決定如何自動化並優化怎樣處理停機。讓咱們看下三個簡單例子:框架

  1. 一個無狀態的web服務器在被從負載均衡池中移除是能夠接受任意時長的網絡和電源中斷。這個場景裏惟一須要關心的是保證仍有足夠的web服務器來處理全部請求。
  2. 一個在內存中保存靜態索引的緩存機器能夠接受從負載均衡池中摘除時長時間的網絡中斷。當網絡恢復,機器能夠當即提供索引服務。一個短的電源中斷,則須要從新將索引加載到內存。處理一次重啓須要主動替換一個沒有被同一次維護影響的服務器。
  3. 一個進行高吞吐複製的MySQL複製服務能夠接受一次短的電源中斷。主機能夠被從負載均衡池中移除,數據能夠存儲在磁盤上,MySQL服務器也能夠在重啓後快速追平復制進度。相反的,若是中斷幾小時的網絡會致使數據落後太多,因此此時對複製服務器進行主動替換會是一個更好的選擇。

計算中斷的類型和時長可讓咱們爲每一個服務創建一個簡單的決策矩陣:

clipboard.png

處理器disable/enable過程

當一個可用的維護計劃被計劃和選擇後,處理器遵循一個四步工做流來關閉影響的主機:

  1. 起飛前檢查
  2. 預關閉
  3. 主機級別關閉
  4. 關閉後處理

起飛前檢查: 起飛前檢查會在關閉過程的最開始被調用,用來檢查沒有被影響的服務器是否有足夠的容量來保障動做的安全性。它返回一個true或false來指導維護工做能夠繼續進行或終止。起飛前檢查也能夠做爲定時調度進程的一部分獨立調用,讓團隊能夠有更多時間處理其可能返回false的場景。

讓咱們想象下給定約束下的6個機架:

clipboard.png

如今讓咱們設想下兩個維護場景:

clipboard.png

clipboard.png

起飛檢查會檢查兩個場景下的web服務器,但在場景B,起飛檢查會在緩存和數據庫服務器上失敗,維護任務不容許自動化運行(這個場景會在下節詳細介紹)

當全部起飛檢查經過,咱們的Aggregate Maintenance Handlers讓咱們能夠在以前已經有的主機級別disable/enable邏輯上包裝一層更智能的代碼層。

未完待續。


本文來自微信公衆號「麥芽麪包,id「darkjune_think」轉載請註明。交流Email: zhukunrong@yeah.net

相關文章
相關標籤/搜索