Migrate Instance 操做詳解 - 天天5分鐘玩轉 OpenStack（40）

Migrate 操做的做用是將 instance 從當前的計算節點遷移到其餘節點上。

Migrate 不要求源和目標節點必須共享存儲，固然共享存儲也是能夠的。 Migrate 前必須知足一個條件：計算節點間須要配置 nova 用戶無密碼訪問。

下面是 Migrate instance 的流程圖

1. 向 nova-api 發送請求

2. nova-api 發送消息

3. nova-scheduler 執行調度

4. nova-scheduler 發送消息

5. nova-compute 執行操做

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

向 nova-api 發送請求

客戶（能夠是 OpenStack 最終用戶，也能夠是其餘程序）向 API（nova-api）發送請求：「幫我遷移這個 Instance」 Migrate 操做是特權操做，只能在 Admin 的 instance 菜單中執行

查看日誌 /opt/stack/logs/n-api.log

nova-api 發送消息

nova-api 向 Messaging（RabbitMQ）發送了一條消息：「遷移這個 Instance」 查看源代碼 /opt/stack/nova/nova/compute/api.py，方法是 resize。 沒錯，是 resize 而非 migrate。
這是因爲 migrate 其實是經過 resize 操做實現的，至於爲何要這樣設計，咱們會在下一節 resize 中詳細分析。

nova-scheduler 執行調度

nova-scheduler 收到消息後，會爲 instance 選擇合適的目標計算節點。 查看日誌 /opt/stack/logs/n-sch.log

能夠看到，由於 devstack-compute1 的權值比 devstack-controller 大，最終選擇 devstack-compute1 做爲目標節點。

看到上面的日誌，你們發現什麼問題沒有？

在分析這段日誌的時候，我發現 scheduler 選出來的計算節點有多是當前節點源節點！ 由於 scheduler 並沒在初始的時候將源節點剔除掉，而是與其餘節點放在一塊兒作 filter，按照這個邏輯，只要源節點的權值足夠大，是有可能成爲目標節點的。

那緊接着的問題是：若是源節點和目標節點是同一個，migrate 操做會怎樣進行呢？

實驗得知，nova-compute 在作 migrate 的時候會檢查目標節點，若是發現目標節點與源節點相同，會拋出 UnableToMigrateToSelf 異常。Nova-compute 失敗以後，scheduler 會從新調度，因爲有 RetryFilter，會將以前選擇的源節點過濾掉，這樣就能選到不一樣的計算節點了。 關於 RetryFilter，你們還有印象嗎？若是生疏了能夠看前面章節。

好，言歸正傳。在上面的操做中 sheduler 選擇的目標節點是 devstack-compute1，意味着 instance 將從 devstack-controller 遷移到 devstack-compute1。

nova-scheduler 發送消息

nova-scheduler 發送消息，通知計算節點能夠遷移 instance 了。 源代碼在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法爲 select_destinations

nova-compute 執行操做

nova-compute 會在源計算節點和目標計算節點上分別執行操做。

源計算節點 devstack-controller

遷移操做在源節點上首先會關閉 instance，而後將 instance 的鏡像文件傳到目標節點上。 日誌在 /opt/stack/logs/n-cpu.log，具體步驟以下：

開始 migrate

在目標節點上建立 instance 的目錄

nova-compute 首先會嘗試經過 ssh 在目標節點上的 instance 目錄裏 touch 一個臨時文件，日誌以下

若是 touch 失敗，說明目標節點上尚未該 instance 的目錄，也就是說，源節點和目標節點沒有共享存儲。那麼接下來就要在目標節點上建立 instance 的目錄，日誌以下

關閉 instance

將 instance 的鏡像文件經過 scp 傳到目標節點上

目標計算節點 devstack-compute1

在目標節點上啓動 instance，過程與 launch instance 很是相似。 會通過以下幾個步驟： 1. 爲 instance 準備 CPU、內存和磁盤資源 2. 建立 instance 鏡像文件 3. 建立 instance 的 XML 定義文件 4. 建立虛擬網絡並啓動 instance

日誌記錄在 /opt/stack/logs/n-cpu.log，分析留給你們練習。

Confirm

這時，instance 會處於 「Confirm or Revert Resize/Migrate」狀態，須要用戶確認或者回退當前的遷移操做，實際上給了用戶一個反悔的機會。

當咱們按下 Confirm 按鈕後，會發生以下事情：

1. nova-api 接收到 confirm 的消息
   

2. 源計算節點刪除 instance 的目錄，並在 Hypervisor 上刪除 instance。
   
   
   

3. 目標計算節點不須要作任何事情

Revert

若是執行的是 Revert 操做會發生什麼事情呢？

1. nova-api 接收到 revert 的消息
   

2. 在目標計算節點上關閉 instance，刪除 instance 的目錄，並在 Hypervisor 上刪除 instance。
   

3. 源計算節點上啓動 instance 由於以前遷移的時候只是在源節點上關閉了該 instance，revert 操做只需從新啓動 instance。
   
   
   

以上是 Migrate 操做的完整流程，這裏有一點須要特別注意： 遷移過程當中源和目標節點以前須要使用 ssh 和 scp，爲了使操做順利進行，必需要保證 nova-compute 進程的啓動用戶（一般是 nova，也多是 root，能夠經過 ps 命令確認）可以在計算節點之間無密碼訪問。不然 nova-compute 會等待密碼輸入，但後臺服務是沒法輸入密碼的，遷移操做會一直卡在那裏。

以上是 Migrate 操做的詳細分析，下一節咱們討論 Resize。