Migrate Instance 操作詳解 - 每天5分鐘玩轉 OpenStack（40）向 nova-api 發送請求nova-api 發送消息nova-scheduler 執行排程nova-scheduler 發送消息nova-compute 執行操作

Migrate 操作的作用是将 instance 從目前的計算節點遷移到其他節點上。

Migrate 不要求源和目标節點必須共享存儲，當然共享存儲也是可以的。 Migrate 前必須滿足一個條件：計算節點間需要配置 nova 使用者無密碼通路。

下面是 Migrate instance 的流程圖

向 nova-api 發送請求

nova-api 發送消息

nova-scheduler 執行排程

nova-scheduler 發送消息

nova-compute 執行操作

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

客戶（可以是 OpenStack 最終使用者，也可以是其他程式）向 API（nova-api）發送請求：“幫我遷移這個 Instance” Migrate 操作是特權操作，隻能在 Admin 的 instance 菜單中執行

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

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

檢視源代碼 /opt/stack/nova/nova/compute/api.py，方法是 resize。

沒錯，是 resize 而非 migrate。

這是由于 migrate 實際上是通過 resize 操作實作的，至于為什麼要這樣設計，我們會在下一節 resize 中詳細分析。

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 發送消息，通知計算節點可以遷移 instance 了。

源代碼在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法為 select_destinations

nova-compute 會在源計算節點和目标計算節點上分别執行操作。

遷移操作在源節點上首先會關閉 instance，然後将 instance 的鏡像檔案傳到目标節點上。

日志在 /opt/stack/logs/n-cpu.log，具體步驟如下：

開始 migrate

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

nova-compute 首先會嘗試通過 ssh 在目标節點上的 instance 目錄裡 touch 一個臨時檔案，日志如下

如果 touch 失敗，說明目标節點上還沒有該 instance 的目錄，也就是說，源節點和目标節點沒有共享存儲。那麼接下來就要在目标節點上建立 instance 的目錄，日志如下

關閉 instance

将 instance 的鏡像檔案通過 scp 傳到目标節點上

在目标節點上啟動 instance，過程與 launch instance 非常類似。

會經過如下幾個步驟：

1. 為 instance 準備 CPU、記憶體和磁盤資源

2. 建立 instance 鏡像檔案

3. 建立 instance 的 XML 定義檔案

4. 建立虛拟網絡并啟動 instance

日志記錄在 /opt/stack/logs/n-cpu.log，分析留給大家練習。

這時，instance 會處于 “Confirm or Revert Resize/Migrate”狀态，需要使用者确認或者回退目前的遷移操作，實際上給了使用者一個反悔的機會。

當我們按下 Confirm 按鈕後，會發生如下事情：

nova-api 接收到 confirm 的消息

源計算節點删除 instance 的目錄，并在 Hypervisor 上删除 instance。

目标計算節點不需要做任何事情        

如果執行的是 Revert 操作會發生什麼事情呢？

nova-api 接收到 revert 的消息

在目标計算節點上關閉 instance，删除 instance 的目錄，并在 Hypervisor 上删除 instance。

源計算節點上啟動 instance

因為之前遷移的時候隻是在源節點上關閉了該 instance，revert 操作隻需重新啟動 instance。

以上是 Migrate 操作的完整流程，這裡有一點需要特别注意：

遷移過程中源和目标節點之前需要使用 ssh 和 scp，為了使操作順利進行，必須要保證 nova-compute 程序的啟動使用者（通常是 nova，也可能是 root，可以通過 ps 指令确認）能夠在計算節點之間無密碼通路。否則 nova-compute 會等待密碼輸入，但背景服務是無法輸入密碼的，遷移操作會一直卡在那裡。

以上是 Migrate 操作的詳細分析，下一節我們讨論 Resize。

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