Nova Suspend/Rescue 操作詳解 - 每天5分鐘玩轉 OpenStack（35）
本節我們討論 Suspend/Resume 和 Rescue/Unrescue 這兩組操作。
Suspend/Resume
有時需要長時間暫停 instance，可以通過 Suspend 操作將 instance 的狀態保存到宿主機的磁盤上。當需要恢復的時候，執行 Resume 操作，從磁盤讀回 instance 的狀態，使之繼續運行。
這裏需要對 Suspend 和 Pause 操作做個比較：
相同點
兩者都是暫停 instance 的運行，並保存當前狀態，之後可以通過 Resume 操作恢復
不同點
1. Suspend 將 instance 的狀態保存在磁盤上；Pause 是保存在內存中，所以 Resume 被 Pause 的 instance 要比 Suspend 快。
2. Suspend 之後的 instance，其狀態是 Shut Down；而被 Pause 的 instance 狀態是Paused。
3. 雖然都是通過 Resume 操作恢復，Pause 對應的 Resume 在 OpenStack 內部被叫作 “Unpause”；Suspend 對應的 Resume 纔是真正的 “Resume”。這個在日誌中能體現出來。
Suspend/Resume 的日誌分析留給大家做練習。
Rescue/Unrescue
從這節開始，我們將討論幾種 instance 故障恢復的方法，不同方法適用於不同的場景。 首先我們考慮操作系統故障。
有時候由於誤操作或者突然斷電，操作系統重啓後卻起不來了。 爲了最大限度挽救數據，我們通常會使用一張系統盤將系統引導起來，然後在嘗試恢復。 問題如果不太嚴重，完全可以通過這種方式讓系統重新正常工作。 比如某個系統文件意外刪除， root 密碼遺忘等
Nova 也提供了這種故障恢復機制，叫做 Rescue。 我們來看看 rescue 的說明：
Rescue 用指定的 p_w_picpath 作爲啓動盤引導 instance，將 instance 本身的系統盤作爲第二個磁盤掛載到操作系統上。
下面是 rescue instance 的流程圖
向 nova-api 發送請求
nova-api 發送消息
nova-compute 執行操作
下面我們詳細討論每一個步驟。
向 nova-api 發送請求
目前 Rescue 操作只能通過 CLI 執行
這裏我們沒有指明用哪個 p_w_picpath 作爲引導盤，nova 將使用 instance 部署時使用的 p_w_picpath
查看日誌 /opt/stack/logs/n-api.log
nova-api 發送消息
nova-api 向 Messaging（RabbitMQ）發送了一條消息：“Rescue 這個 Instance” 源代碼在 /opt/stack/nova/nova/compute/api.py，方法是 rescue。
nova-compute執行操作
查看日誌 /opt/stack/logs/n-cpu.log
關閉 instance
通過 p_w_picpath 創建新的引導盤，命名爲 disk.rescue
啓動 instance
Rescue 執行成功後，可以通過 virsh edit <instance_name> 查看 instance 的 XML 定義，disk.rescue 作爲啓動盤 vda，真正的啓動盤 disk 作爲第二個磁盤 vdb。
登錄 instance，通過 fdisk 也可確認。
此時，instance 處於 Rescue 狀態
Rescue 操作讓我們有機會修復損壞的操作系統。 修好之後，使用 Unrescue 操作從原啓動盤重新引導 instance。
Unrescue 的日誌分析留給大家練習。