国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

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

wangbjun / 2981人閱讀

摘要:一個在內存中保存靜態索引的緩存機器可以接受從負載均衡池中摘除時長時間的網絡中斷。處理一次重啟需要主動替換一個沒有被同一次維護影響的服務器。主機可以被從負載均衡池中移除,數據可以存儲在磁盤上,服務器也可以在重啟后快速追平復制進度。

Making Facebook self-healing: Automating proactive rack maintenance

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

我們一直希望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服務器,為我們的工程師執行維護工作時提供完整的情景上下文和所有被影響的服務器范圍。

基于維護影響范圍來做決定

停機的影響在大小,長度,類型上都差異很大:一些影響一個多帶帶的機架,一些會影響好幾個;它們可以長或短;一些只影響網絡連通性而一些會影響電源。不同的服務要使用不同的方式來處理停機。當我們計劃一個維護工作,我們提供Aggregate Maintenance Handler四塊信息來決定它在我們總體基礎設施上的影響:

范圍(維護會影響的服務器列表)

維護類型(網絡中斷,電源中斷)

維護開始時間(如太平洋標準時間早上十點)

維護時長(如2小時)

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

一個無狀態的web服務器在被從負載均衡池中移除是可以接受任意時長的網絡和電源中斷。這個場景里唯一需要關心的是保證仍有足夠的web服務器來處理所有請求。

一個在內存中保存靜態索引的緩存機器可以接受從負載均衡池中摘除時長時間的網絡中斷。當網絡恢復,機器可以立即提供索引服務。一個短的電源中斷,則需要重新將索引加載到內存。處理一次重啟需要主動替換一個沒有被同一次維護影響的服務器。

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

計算中斷的類型和時長可以讓我們為每個服務建立一個簡單的決策矩陣:

處理器disable/enable過程

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

起飛前檢查

預關閉

主機級別關閉

關閉后處理

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

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

現在讓我們設想下兩個維護場景:

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

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

未完待續。

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

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/73750.html

相關文章

  • facebook自愈動化主動機架維護 - 2

    摘要:讓自愈自動化主動機架維護原文作者翻譯時序預關閉這一步主要是保證目前池子中認為是空閑的主機在主機級別關閉或批量操作期間交換多個主機時不會重新被加入到生產環境。 讓facebook自愈:自動化主動機架維護 - 2Making Facebook self-healing: Automating proactive rack maintenance 原文:https://code.fb.co...

    glumes 評論0 收藏0
  • 2018年十大數據中心新聞

    摘要:年可以說是軟件定義數據中心的一年,大量自動化和人工智能研發力量致力于打造下一代可擴展的靈活的數據中心。年,致力在軟件定義數據中心占據一席之地,并將目標瞄準了在年之前實現軟件和支持收入億美元。公有云沒有扼殺數據中心,盡管有些人預測這會在2018年發生。不僅數據中心還在,而且服務器、存儲和網絡等數據中心基礎設施的全球支出正呈現蓬勃增長的態勢。2018年可以說是軟件定義數據中心的一年,大量自動化和...

    Kaede 評論0 收藏0

發表評論

0條評論

wangbjun

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<