此文已由做者王盼受權網易雲社區發佈。數據庫
歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗~後端
現狀
計算節點發生磁盤損壞等數據沒法恢復的異常時，節點上的雲主機系統盤沒法恢復，致使雲主機只能被清理重建api
計算節點宕機但磁盤數據可用時，重啓便可恢復全部雲主機的運行服務器
計算節點屢次宕機（或一段時間內頻繁宕機），則須要遷移全部雲主機或者直接清理重建，雲硬盤須要遷移到其餘cinder-volume存儲服務節點網絡
通常來講重建過程比較耗時，而且雲主機數據盤數據會所有丟失；另外採用本地file鏡像啓動的雲主機離線或者在線遷移比較耗時並大類佔用物理機硬盤和網絡IO，會進一步加劇計算節點負載，增大宕機可能性，實際狀況下遷移操做的可執行性大打折扣。操作系統
另外有一些對咱們自動化恢復流程有利的功能或者設備已經逐步上線到新建機房，所以能夠考慮在這些機房實施相關的自動化恢復方案。好比義橋機房服務器已經所有配備遠程管理卡，而且基於ceph存儲做爲系統盤+雲硬盤的雲主機也已經上線到該機房，這是咱們實施該方案的基礎。基於ceph存儲後端的雲主機在異常恢復過程當中，沒有數據的拷貝，不會佔用硬盤和網絡IO，所以恢復速度較快，能夠作到幾秒內在正常節點恢復運行（不包含雲主機操做系統啓動時間），相比如今的直接下線沒法恢復或者數小時的更換硬件耗時，是對雲主機SLA至關大的提高。設計
需求
保證異常節點上全部被標記爲須要恢復的雲主機、雲硬盤資源被正確恢復（處理過程當中本進程退出其餘進程能夠繼續）接口
把全部被處理的資源記錄在案（資源id、所在節點、處理時間、調用nova/cinder服務的request-id、處理狀態等）進程
保證異常處理服務自己的高可用ci
場景
用戶建立雲主機
用戶建立雲主機時指定宕機恢復策略，目前有三種：
null：不作處理，節點下線以後殘留在數據庫
恢復：在其餘正常節點恢復重建
刪除：直接刪除
節點首次異常
首次異常以後要嘗試重啓節點（上面的雲主機、雲硬盤不作特殊處理），但節點已自動重啓的除外，並要分析異常緣由，找到緣由並能夠修復的軟硬件異常，則不須要記錄到節點異常次數中，不然須要記錄在案，用作下次異常時的處理依據，記錄前未找到緣由，但過後找到的，須要從異常記錄中刪除該次記錄。
節點屢次異常
屢次異常節點須要作下線處理（屢次異常包含首次異常後重啓失敗的狀況），節點上的雲主機須要根據建立時指定的宕機處理策略來執行相應的操做，雲硬盤則一概遷移到其餘正常服務的cinder-volume節點（並不會實際的遷移數據，對用戶使用沒有任何影響），處理過的雲主機、雲硬盤要記錄在案，便於過後查驗。
方案
本方案只是初步想法，還須要在開發過程當中繼續完善，尤爲是服務高可用部分，以及與哨兵系統的交互部分，會對本服務的設計形成較大影響。
Alt pic
依賴
被恢復的雲主機需使用ceph啓動盤+ceph雲硬盤
nova、cinder支持把服務強制設置爲down狀態（cinder可選，nova必須支持，不然須要等待超時變成down才能夠執行雲主機的宕機恢復操做）
哨兵系統異常主動通知機制（建議），或者哨兵系統提供api供咱們輪詢節點狀態
哨兵系統提供接口可強制重啓和下電節點
後續
L3節點宕機自動化處理流程
動態資源調度功能：可根據節點負載動態均衡雲主機分佈
節電省成本：可將空閒節點雲主機遷移以後下電節點
雲硬盤是網易雲提供多種硬件介質的塊存儲設備，用戶能夠根據實際生產環境，靈活選擇雲硬盤類型和規格大小，彈性地建立、刪除、掛載、卸載、擴容雲硬盤。
更多網易技術、產品、運營經驗分享請點擊。
文章來源： 網易雲社區