Resize 的做用是調整 instance 的 vCPU、內存和磁盤資源。web
Instance 須要多少資源是定義在 flavor 中的,resize 操做是經過爲 instance 選擇新的 flavor 來調整資源的分配。api
有了前面對 Migrate 的分析,再來看 Resize 的實現就很是簡單了。 由於 instance 須要分配的資源發生了變化,在 resize 以前須要藉助 nova-scheduler 從新爲 instance 選擇一個合適的計算節點,若是選擇的節點與當前節點不是同一個,那麼就須要作 Migrate。網絡
因此本質上講:Resize 是在 Migrate 的同時應用新的 flavor。 Migrate 能夠看作是 resize 的一個特例: flavor 沒發生變化的 resize,這也是爲何咱們在上一節日誌中看到 migrate 其實是在執行 resize 操做。spa
下面是 Resize instance 的流程圖日誌
向 nova-api 發送請求orm
nova-api 發送消息進程
nova-scheduler 執行調度內存
nova-scheduler 發送消息資源
nova-compute 執行操做it
Resize 分兩種狀況:
nova-scheduler 選擇的目標節點與源節點是不一樣節點。操做過程跟上一節 Migrate 幾乎徹底同樣,只是在目標節點啓動 instance 的時候按新的 flavor 分配資源。 同時,由於要跨節點複製文件,也必需要保證 nova-compute 進程的啓動用戶(一般是 nova,也多是 root,能夠經過 ps 命令確認)可以在計算節點之間無密碼訪問。 對這一種狀況咱們再也不贅述,請參看前面 Migrate 小節。
目標節點與源節點是同一個節點。則不須要 migrate。下面咱們重點討論這一種狀況。
客戶(能夠是 OpenStack 最終用戶,也能夠是其餘程序)向 API(nova-api)發送請求:「幫我 Resize 這個 Instance」
選擇新的 flavor
點擊 Resize 按鈕
查看日誌 /opt/stack/logs/n-api.log
nova-api 向 Messaging(RabbitMQ)發送了一條消息:「Resize 這個 Instance」 查看源代碼 /opt/stack/nova/nova/compute/api.py,方法是 resize_instance。
nova-scheduler 收到消息後,會爲 instance 選擇合適的目標計算節點。 查看日誌 /opt/stack/logs/n-sch.log
在本例中,nova-scheduler 選擇了 devstack-compute1 做爲的目節點,與源節點相同。
nova-scheduler 發送消息,通知計算節點能夠遷移 instance 了 源代碼在 /opt/stack/nova/nova/scheduler/filter_scheduler.py 第 95 行,方法爲 select_destinations
在目標節點上啓動 instance,過程與 launch instance 很是相似。 日誌記錄在 /opt/stack/logs/n-cpu.log
會通過以下幾個步驟:
按新的 flavor 爲 instance 準備 CPU、內存和磁盤資源
關閉 instance
建立 instance 鏡像文件
將 instance 的目錄備份一份,命名爲<instance_id>_resize,以便 revert。
建立 instance 的 XML 定義文件
準備虛擬網絡
啓動 instance
這時,instance 的狀態處於「Confirm or Revert Resize/Migrate」狀態,須要用戶確認或者回退當前的遷移操做,實際上給了用戶一個反悔的機會。
當咱們按下 Confirm 按鈕後,會發生以下事情:
nova-api 接收到 confirm 的消息
刪除計算節上備份的 instance 目錄 <instance_id>_resize
反過來,若是執行 Revert 操做會發生什麼事情呢?
nova-api 接收到 revert 的消息
在計算節點上關閉 instance
經過備份目錄 <instance_id>_resize 恢復 instance 目錄。
從新啓動 instance
以上是 Resize 操做的詳細分析,下一節咱們討論 Live Migrate。