此文已由作者王盼授權網易雲社群發布。
現狀計算節點發生磁碟損壞等資料無法恢復的異常時，節點上的雲主機系統盤無法恢復，導致雲主機只能被清理重建
計算節點宕機但磁碟資料可用時，重啟即可恢復所有雲主機的執行
計算節點多次宕機（或一段時間內頻繁宕機），則需要遷移所有雲主機或者直接清理重建，雲硬碟需要遷移到其他cinder-volume儲存服務節點
另外有一些對我們自動化恢復流程有利的功能或者裝置已經逐步上線到新建機房，因此可以考慮在這些機房實施相關的自動化恢復方案。比如義橋機房伺服器已經全部配備遠端管理卡，並且基於ceph儲存作為系統盤+雲硬碟的雲主機也已經上線到該機房，這是我們實施該方案的基礎。基於ceph儲存後端的雲主機在異常恢復過程中，沒有資料的拷貝，不會占用硬碟和網路io，因此恢復速度較快，可以做到幾秒內在正常節點恢復執行（不包含雲主機作業系統啟動時間），相比現在的直接下線無法恢復或者數小時的更換硬體耗時，是對雲主機sla相當大的提公升。
需求保證異常節點上所有被標記為需要恢復的雲主機、雲硬碟資源被正確恢復（處理過程中本程序退出其他程序可以繼續）
把所有被處理的資源記錄在案（資源id、所在節點、處理時間、呼叫nova/cinder服務的request-id、處理狀態等）
保證異常處理服務本身的高可用
場景使用者建立雲主機
使用者建立雲主機時指定宕機恢復策略，目前有三種：
null：不做處理，節點下線之後殘留在資料庫
恢復：在其他正常節點恢復重建
刪除：直接刪除
節點首次異常
首次異常之後要嘗試重啟節點（上面的雲主機、雲硬碟不做特殊處理），但節點已自動重啟的除外，並要分析異常原因，找到原因並可以修復的軟硬體異常，則不需要記錄到節點異常次數中，否則需要記錄在案，用做下次異常時的處理依據，記錄前未找到原因，但事後找到的，需要從異常記錄中刪除該次記錄。
節點多次異常
多次異常節點需要做下線處理（多次異常包含首次異常後重啟失敗的情況），節點上的雲主機需要根據建立時指定的宕機處理策略來執行相應的操作，雲硬碟則一律遷移到其他正常服務的cinder-volume節點（並不會實際的遷移資料，對使用者使用沒有任何影響），處理過的雲主機、雲硬碟要記錄在案，便於事後查驗。
方案本方案只是初步想法，還需要在開發過程中繼續完善，尤其是服務高可用部分，以及與哨兵系統的互動部分，會對本服務的設計造成較大影響。
alt pic
依賴被恢復的雲主機需使用ceph啟動盤+ceph雲硬碟
nova、cinder支援把服務強制設定為down狀態（cinder可選，nova必須支援，否則需要等待超時變成down才可以執行雲主機的宕機恢復操作）
哨兵系統異常主動通知機制（建議），或者哨兵系統提供api供我們輪詢節點狀態
哨兵系統提供介面可強制重啟和下電節點
後續l3節點宕機自動化處理流程
動態資源排程功能：可根據節點負載動態均衡雲主機分布
節電省成本：可將空閒節點雲主機遷移之後下電節點
雲硬碟是網易雲提供多種硬體介質的塊儲存裝置，使用者可以根據實際生產環境，靈活選擇雲硬碟型別和規格大小，彈性地建立、刪除、掛載、解除安裝、擴容雲硬碟。
更多網易技術、產品、運營經驗分享。
雲計算自動化運維基礎見解
第一階段 基礎知識 一 linux系統基本結構 1 系統安裝及分割槽 手動化自動裝 如何分割槽？分出根目錄 book單獨的etc home交換分割槽 交換分割槽大小？虛擬記憶體 讓它我們的記憶體分擔壓力 物理記憶體的二倍 2 檔案系統結構 經典樹形目錄結構 常用目錄及其作用 root頂級目錄 hom...
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...