Nova Suspend/Rescue 操作詳解 - 每天5分鐘玩轉 OpenStack（35）Suspend/ResumeRescue/Unrescue

本節我們讨論 Suspend/Resume 和 Rescue/Unrescue 這兩組操作。

有時需要長時間暫停 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 的日志分析留給大家做練習。

從這節開始，我們将讨論幾種 instance 故障恢複的方法，不同方法适用于不同的場景。

首先我們考慮作業系統故障。

有時候由于誤操作或者突然斷電，作業系統重新開機後卻起不來了。

為了最大限度挽救資料，我們通常會使用一張系統盤将系統引導起來，然後在嘗試恢複。

問題如果不太嚴重，完全可以通過這種方式讓系統重新正常工作。

比如某個系統檔案意外删除， root 密碼遺忘等

Nova 也提供了這種故障恢複機制，叫做 Rescue。

我們來看看 rescue 的說明：

Rescue 用指定的 image 作為啟動盤引導 instance，将 instance 本身的系統盤作為第二個磁盤挂載到作業系統上。

下面是 rescue instance 的流程圖

向 nova-api 發送請求

nova-api 發送消息

nova-compute 執行操作

下面我們詳細讨論每一個步驟。

目前 Rescue 操作隻能通過 CLI 執行

這裡我們沒有指明用哪個 image 作為引導盤，nova 将使用 instance 部署時使用的 image

檢視日志 /opt/stack/logs/n-api.log

nova-api 向 Messaging（RabbitMQ）發送了一條消息：“Rescue 這個 Instance”

源代碼在 /opt/stack/nova/nova/compute/api.py，方法是 rescue。

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

本文轉自CloudMan6 51CTO部落格，原文連結:http://blog.51cto.com/cloudman/1774577