Migrate 操作的作用是將 instance 從當前的計算節(jié)點遷移到其他節(jié)點上。

Migrate 不要求源和目標節(jié)點必須共享存儲，當然共享存儲也是可以的。 Migrate 前必須滿足一個條件：計算節(jié)點間需要配置 nova 用戶無密碼訪問。

下面是 Migrate instance 的流程圖

向 nova-api 發(fā)送請求

nova-api 發(fā)送消息

nova-scheduler 執(zhí)行調(diào)度

nova-scheduler 發(fā)送消息

nova-compute 執(zhí)行操作

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

向 nova-api 發(fā)送請求

客戶（可以是 OpenStack 最終用戶，也可以是其他程序）向 API（nova-api）發(fā)送請求：“幫我遷移這個 Instance” Migrate 操作是特權(quán)操作，只能在 Admin 的 instance 菜單中執(zhí)行

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

nova-api 發(fā)送消息

nova-api 向 Messaging（RabbitMQ）發(fā)送了一條消息：“遷移這個 Instance” 查看源代碼 /opt/stack/nova/nova/compute/api.py，方法是 resize。 沒錯，是 resize 而非 migrate。
這是由于 migrate 實際上是通過 resize 操作實現(xiàn)的，至于為什么要這樣設(shè)計，我們會在下一節(jié) resize 中詳細分析。

nova-scheduler 執(zhí)行調(diào)度

nova-scheduler 收到消息后，會為 instance 選擇合適的目標計算節(jié)點。 查看日志 /opt/stack/logs/n-sch.log

可以看到，因為 devstack-compute1 的權(quán)值比 devstack-controller 大，最終選擇 devstack-compute1 作為目標節(jié)點。

看到上面的日志，大家發(fā)現(xiàn)什么問題沒有？

在分析這段日志的時候，我發(fā)現(xiàn) scheduler 選出來的計算節(jié)點有可能是當前節(jié)點源節(jié)點！ 因為 scheduler 并沒在初始的時候?qū)⒃垂?jié)點剔除掉，而是與其他節(jié)點放在一起做 filter，按照這個邏輯，只要源節(jié)點的權(quán)值足夠大，是有可能成為目標節(jié)點的。

那緊接著的問題是：如果源節(jié)點和目標節(jié)點是同一個，migrate 操作會怎樣進行呢？

實驗得知，nova-compute 在做 migrate 的時候會檢查目標節(jié)點，如果發(fā)現(xiàn)目標節(jié)點與源節(jié)點相同，會拋出 UnableToMigrateToSelf 異常。Nova-compute 失敗之后，scheduler 會重新調(diào)度，由于有 RetryFilter，會將之前選擇的源節(jié)點過濾掉，這樣就能選到不同的計算節(jié)點了。 關(guān)于 RetryFilter，大家還有印象嗎？如果生疏了可以看前面章節(jié)。

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

nova-scheduler 發(fā)送消息

nova-scheduler 發(fā)送消息，通知計算節(jié)點可以遷移 instance 了。 源代碼在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行，方法為 select_destinations

nova-compute 執(zhí)行操作

nova-compute 會在源計算節(jié)點和目標計算節(jié)點上分別執(zhí)行操作。

源計算節(jié)點 devstack-controller

遷移操作在源節(jié)點上首先會關(guān)閉 instance，然后將 instance 的鏡像文件傳到目標節(jié)點上。 日志在 /opt/stack/logs/n-cpu.log，具體步驟如下：

開始 migrate

在目標節(jié)點上創(chuàng)建 instance 的目錄

nova-compute 首先會嘗試通過 ssh 在目標節(jié)點上的 instance 目錄里 touch 一個臨時文件，日志如下

如果 touch 失敗，說明目標節(jié)點上還沒有該 instance 的目錄，也就是說，源節(jié)點和目標節(jié)點沒有共享存儲。那么接下來就要在目標節(jié)點上創(chuàng)建 instance 的目錄，日志如下

關(guān)閉 instance

將 instance 的鏡像文件通過 scp 傳到目標節(jié)點上

目標計算節(jié)點 devstack-compute1

在目標節(jié)點上啟動 instance，過程與 launch instance 非常類似。 會經(jīng)過如下幾個步驟： 1. 為 instance 準備 CPU、內(nèi)存和磁盤資源 2. 創(chuàng)建 instance 鏡像文件 3. 創(chuàng)建 instance 的 XML 定義文件 4. 創(chuàng)建虛擬網(wǎng)絡(luò)并啟動 instance

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

Confirm

這時，instance 會處于 “Confirm or Revert Resize/Migrate”狀態(tài)，需要用戶確認或者回退當前的遷移操作，實際上給了用戶一個反悔的機會。

當我們按下 Confirm 按鈕后，會發(fā)生如下事情：

nova-api 接收到 confirm 的消息

源計算節(jié)點刪除 instance 的目錄，并在 Hypervisor 上刪除 instance。

目標計算節(jié)點不需要做任何事情

Revert

如果執(zhí)行的是 Revert 操作會發(fā)生什么事情呢？

nova-api 接收到 revert 的消息

在目標計算節(jié)點上關(guān)閉 instance，刪除 instance 的目錄，并在 Hypervisor 上刪除 instance。

源計算節(jié)點上啟動 instance 因為之前遷移的時候只是在源節(jié)點上關(guān)閉了該 instance，revert 操作只需重新啟動 instance。

以上是 Migrate 操作的完整流程，這里有一點需要特別注意： 遷移過程中源和目標節(jié)點之前需要使用 ssh 和 scp，為了使操作順利進行，必須要保證 nova-compute 進程的啟動用戶（通常是 nova，也可能是 root，可以通過 ps 命令確認）能夠在計算節(jié)點之間無密碼訪問。否則 nova-compute 會等待密碼輸入，但后臺服務(wù)是無法輸入密碼的，遷移操作會一直卡在那里。

以上是 Migrate 操作的詳細分析，下一節(jié)我們討論 Resize。

轉(zhuǎn)載于:https://www.cnblogs.com/CloudMan6/p/5538599.html

總結(jié)

以上是生活随笔為你收集整理的Migrate Instance 操作详解 - 每天5分钟玩转 OpenStack（40）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。