此文已由作者王盼授權網易雲社群釋出。

歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗~

現狀

• 計算節點發生磁碟損壞等資料無法恢復的異常時，節點上的雲主機系統盤無法恢復，導致雲主機只能被清理重建

• 計算節點宕機但磁碟資料可用時，重啟即可恢復所有云主機的執行

• 計算節點多次宕機（或一段時間內頻繁宕機），則需要遷移所有云主機或者直接清理重建，雲硬碟需要遷移到其他cinder-volume儲存服務節點

一般來說重建過程比較耗時，並且雲主機資料盤資料會全部丟失；另外採用本地file映象啟動的雲主機離線或者線上遷移比較耗時並大類佔用物理機硬碟和網路IO，會進一步加重計算節點負載，增大宕機可能性，實際情況下遷移操作的可執行性大打折扣。

另外有一些對我們自動化恢復流程有利的功能或者裝置已經逐步上線到新建機房，因此可以考慮在這些機房實施相關的自動化恢復方案。比如義橋機房伺服器已經全部配備遠端管理卡，並且基於ceph儲存作為系統盤+雲硬碟的雲主機也已經上線到該機房，這是我們實施該方案的基礎。基於ceph儲存後端的雲主機在異常恢復過程中，沒有資料的拷貝，不會佔用硬碟和網路IO，因此恢復速度較快，可以做到幾秒內在正常節點恢復執行（不包含雲主機作業系統啟動時間），相比現在的直接下線無法恢復或者數小時的更換硬體耗時，是對雲主機SLA相當大的提升。

需求

• 保證異常節點上所有被標記為需要恢復的雲主機、雲硬碟資源被正確恢復（處理過程中本程序退出其他程序可以繼續）

• 把所有被處理的資源記錄在案（資源id、所在節點、處理時間、呼叫nova/cinder服務的request-id、處理狀態等）

• 保證異常處理服務本身的高可用

場景

使用者建立雲主機

使用者建立雲主機時指定宕機恢復策略，目前有三種：

• null：不做處理，節點下線之後殘留在資料庫

• 恢復：在其他正常節點恢復重建

• 刪除：直接刪除

節點首次異常

首次異常之後要嘗試重啟節點（上面的雲主機、雲硬碟不做特殊處理），但節點已自動重啟的除外，並要分析異常原因，找到原因並可以修復的軟硬體異常，則不需要記錄到節點異常次數中，否則需要記錄在案，用做下次異常時的處理依據，記錄前未找到原因，但事後找到的，需要從異常記錄中刪除該次記錄。

節點多次異常

多次異常節點需要做下線處理（多次異常包含首次異常後重啟失敗的情況），節點上的雲主機需要根據建立時指定的宕機處理策略來執行相應的操作，雲硬碟則一律遷移到其他正常服務的cinder-volume節點（並不會實際的遷移資料，對使用者使用沒有任何影響），處理過的雲主機、雲硬碟要記錄在案，便於事後查驗。

方案

本方案只是初步想法，還需要在開發過程中繼續完善，尤其是服務高可用部分，以及與哨兵系統的互動部分，會對本服務的設計造成較大影響。

依賴

• 被恢復的雲主機需使用ceph啟動盤+ceph雲硬碟

• nova、cinder支援把服務強制設定為down狀態（cinder可選，nova必須支援，否則需要等待超時變成down才可以執行雲主機的宕機恢復操作）

• 哨兵系統異常主動通知機制（建議），或者哨兵系統提供api供我們輪詢節點狀態

• 哨兵系統提供介面可強制重啟和下電節點

後續

• L3節點宕機自動化處理流程

• 動態資源排程功能：可根據節點負載動態均衡雲主機分佈

• 節電省成本：可將空閒節點雲主機遷移之後下電節點

雲硬碟是網易雲提供多種硬體介質的塊儲存裝置，使用者可以根據實際生產環境，靈活選擇雲硬碟型別和規格大小，彈性地建立、刪除、掛載、解除安裝、擴容雲硬碟。

更多網易技術、產品、運營經驗分享請點選。

相關文章：
【推薦】 巧用Scrum與Kanban
【推薦】 關於評審--從思想到落地
【推薦】 微服務化的資料庫設計與讀寫分離