Migrate Instance 操作詳解 - 每天5分鍾玩轉 OpenStack(40)


image254.5.png

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

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

下面是 Migrate instance 的流程圖

image146.png

  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

image254.png

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。




免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM