如何理解Migrate Instance 操作

這篇文章給大家介紹如何理解Migrate Instance 操作，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

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

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

向 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 Instance 操作就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。