本節我們討論 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 的流程圖

向 nova-api 發送請求

nova-api 發送消息

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 的日志分析留給大家練習。

總結

以上是生活随笔為你收集整理的Nova Suspend/Rescue 操作详解 - 每天5分钟玩转 OpenStack（35）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。