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 用指定的 image 做爲啓動盤引導 instance，將 instance 自己的系統盤做爲第二個磁盤掛載到操做系統上。

下面是 rescue instance 的流程圖

1. 向 nova-api 發送請求

2. nova-api 發送消息

3. nova-compute 執行操做

下面咱們詳細討論每個步驟。

向 nova-api 發送請求

目前 Rescue 操做只能經過 CLI 執行

這裏咱們沒有指明用哪一個 image 做爲引導盤，nova 將使用 instance 部署時使用的 image

查看日誌 /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

經過 image 建立新的引導盤，命名爲 disk.rescue

啓動 instance

Rescue 執行成功後，能夠經過 virsh edit <instance_name> 查看 instance 的 XML 定義，disk.rescue 做爲啓動盤 vda，真正的啓動盤 disk 做爲第二個磁盤 vdb。

登陸 instance，經過 fdisk 也可確認。

此時，instance 處於 Rescue 狀態

Rescue 操做讓咱們有機會修復損壞的操做系統。 修好以後，使用 Unrescue 操做從原啓動盤從新引導 instance。

Unrescue 的日誌分析留給你們練習。