碼上快樂

相關內容    簡體    繁體

虛擬機在 OpenStack 里沒有共享存儲條件下的在線遷移[轉]

本文轉載自   查看原文   2016-06-17 22:43   2914    OpenStack

原文鏈接：http://www.ibm.com/developerworks/cn/cloud/library/1508_wangyx_openstacklivemigrate/

　　遷移(Migration)就是把一個虛擬機從一台物理主機搬到另一台物理主機，動態(Live)就是在遷移過程中虛擬機正常工作不影響用戶的使用。對系統管理員來說，動態遷移是個非常有用的工具，當計划對一個物理主機進行更新或者升級(update/upgrade)的時候，管理員不需要關閉這個物理主機上的虛擬機，只是在更新或者升級前把虛擬機動態遷移到另外一個物理主機，等更新或者升級工作完成后，在遷移回來。從用戶的角度來看，好像這個過程沒有發生。虛擬機雖然遷來遷去，但絲毫不會影響用戶的使用。

本文嘗試回答與 Live migration 相關的幾個問題：Live migration 是什么？為什么要做 Live migration？如何做 Live migration？如果你讀完本文，基本了解了這三個問題的答案， 這篇文章的主要目的也就達到了。由於本文介紹的是 OpenStack 平台上動態遷移的實現，所以讀者必須對 OpenStack 有一定的了解。

虛擬機遷移簡介

動態遷移包括兩方面的意思，一是遷移(Migration)，遷移就是把用戶的虛擬機從一台物理主機移到另外一台物理主機。二是動態，動態的意思就是在遷移的過程中，(1):虛擬機還開着機；(2):虛擬機的網路也不受影響；(3):而且上面的運行的用戶程序依舊運行。整個過程對用戶來說是透明的，對用戶可以正常使用遷移途中的虛擬機。

OpenStack 支持兩種類型的虛擬機遷移：

  • 冷遷移(Cold migration)- 冷遷移也叫靜態遷移。在遷移過程中虛擬機必須關機，用戶也不能訪問虛擬機。因為要關機，所以他適用於用戶對系統可用性要求不是很高的時候。

  • 熱遷移(Hot or live migration)- 熱遷移也叫動態遷移。在遷移的過程中虛擬機仍舊工作，用戶可以繼續使用虛擬機。本文就介紹的就是這種類型的遷移。熱遷移又分為下面二種類型：

  •  (1):虛擬機的數據存在共享磁盤上(Shared storage-based live migration),如圖 1 所 示。

    圖 1
    圖 1

  • (2):虛擬機的數據存在本地磁盤(block migration)，如圖 2 所示，需要對鏡像文件和內存數據同時遷移。OpenStack 通過塊遷移實現這這類遷移。

    圖 2
    圖 2

虛擬機遷移的作用

每個讀者都可能會問這樣一個問題，虛擬機用的好好的，為啥要遷移呀？也就是遷移的價值和目的在哪里。在數據中心的日常運維中，常常要處理下面幾種場景和需求，了解了這些需求，這個問題也就有了答案。

  • 需求 1：物理機器硬件系統的維護，故障修復和升級(upgrade)，但運行在這台物理機器上的虛擬機不能關機，因為用戶重要的服務跑在上面。
  • 需求 2：物理機器軟件系統升級，打補丁(patch)，為了不影響上面跑的虛擬機，在升級和打補丁之前，需要把虛擬機遷移到別的物理機器上。
  • 需求 3：一個物理機器上的負載太重，需要減少一些虛擬機來釋放資源。
  • 需求 4：在一個 cluster 里，有的物理機上的虛擬機太多，有的物理機上虛擬機太少，需要做一下資源平衡。

除了上面四個主要的需求，從服務的角度來看，Live migration 有下面兩個好處：

  • 好處 1：軟件和硬件系統的維護升級，不會影響用戶的關鍵服務，提高了服務的高可用性和 用戶的滿意度。
  • 好處 2：系統管理員不用加班加點，在大半夜進行系統升級了，在正常的工作時間就可以完成這項工作，減少了公司的維護費用。

有這四個需求和兩個好處，所以動態遷移值得一作。

動態遷移方法和實現

本章詳細介紹在 OpenStack 里如何實現動態遷移。在第一節里，提到了有兩種類型的動態遷移，本文只介紹圖 2 所示的虛擬機的數據存在本地磁盤(block migration)的動態遷移。

動態遷移的條件

動態遷移是把虛擬機從一個物理主機遷移到另外一個物理主機，所以至少需要有兩個物理主機作為計算節點。下面是一個最小的 OpenStack 配置。 三個物理主機，一個用來做 OpenStack 的控制節點，兩個用來做計算節點。如圖 3 所示。

圖 3

圖 3

控制節點接受並處理動態遷移的請求，管理員可以從 Horizon、命令行、API 發起動態遷移。 動態遷移就是把客戶的 VM 從計算節點 1 遷移到計算節點 2，或者從計算節點 2 遷移到計算節點 1，如圖 4 所示。

圖 4

圖 4

計算節點上的 Hypervisor 是 KVM，操作系統是 redhat6.5，OpenStack 是 Juno。計算節點 1 和 2 上的虛擬機分別存儲在本地文件系統，如圖 2 所示。

上面提到的 Hypervisor 和 KVM 相關概念，以及 OpenStack 各個模塊的詳細介紹，您可以閱讀參考資料里文檔，這里不在做介紹。

動態遷移的實現

本節分別從基本概念、傳輸協議和遷移的步驟三個方面介紹動態遷移是如何實現的。

基本概念

在了解動態遷移之前，必須了解鏡像文件的格式 QCOW2。Qcow2 是 QEMU 目前推薦的鏡像格式，它支持稀疏文件以節省存儲空間，支持加密以提高鏡像文件的安全性，支持基於 zlib 的壓縮。Qcow2 鏡像可以用來保存另一個鏡像文件的變化，它並不去修改原始鏡像文件，原始鏡像文件也叫后端鏡像(backing_file)。只記錄與原始鏡像文件的不同部分的鏡像文件，這種鏡像文件就叫做 copy-on-write 鏡像，它雖然是一個單獨的鏡像文件，但它的大部分數據都來自原始鏡像，只有基於原始鏡像文件的增量部分才會被記錄下來。本文提及的虛擬機都是 OpenStack 用 Qcow2 格式的鏡像文件建立的，如圖 5 所示，包含兩部分。

  • 后端鏡像(libvirt base)
  • 虛擬機單獨的增量鏡像文件(libvirt instance disks)，copy-on-write 鏡像
圖 5

圖 5

在物理機的磁盤上，當我們建了一個虛擬機后，就會生成如圖 6 列的這些文件。其中_base 下面的文件，就是后端鏡像(libvirt base)，目錄 6e783272-31b5-4fdc-8828-2b8892daab39 下面是虛擬機單獨的增量鏡像文件(libvirt instance disks)，它只記錄和 base 文件不同的內容。

圖 6

圖 6

用 qemu-img 查看虛擬機單獨的增量鏡像文件的信息，我們可以看到他的 backing file 是_base 目錄下的鏡像文件，如圖 7 所示。

圖 7

圖 7

費了這么多篇幅介紹 QCOW2，您會奇怪，目的何在？其實上面介紹的后端鏡像(libvirt Base)，虛擬機單獨的增量鏡像文件(libvirt instance disks)，它們就是要被遷移的數據。動態遷移的最終目標就是把它們完整地從源物理主機遷移到目標物理主機。除了他們兩個之外，還有一個需要遷移的對象就是內存里運行的虛擬機的數據。

總結一下：虛擬機的遷移，其實就是數據的轉移，因為計算節點之間沒有共享存儲，所以要轉移的數據包括兩部分：

  1. 靜態數據：存儲在本地的虛擬機的鏡像文件，包括后端鏡像(libvirt Base)和虛擬機單獨的增量鏡像文件(libvirt instance disks)。
  2. 動態數據：內存里虛擬機的運行時數據，內存里的數據是動態變化的數據，虛擬機里運行的負載的大小直接影響遷移的時間長短。

遷移通道和傳輸協議

OpenStack 調用底層的 libvirt 來完成動態遷移。虛擬機的遷移，其實就是數據的轉移。libvirt 提供了隧道化的數據傳輸（libvirt tunnelled transport）方式來完成數據轉移。如圖 8 所示。

圖 8

圖 8

數據的轉移就涉及數據的傳輸，數據的傳輸需要通過網絡，本文介紹使用 TCP 網路協議完實現動態遷移。Libvirt 默認情況下不支持 TCP 協議，需要對 libvirt 的配置做修改，使 libvirt 能夠支持 TCP 協議，后面的章節會詳細的介紹如何配置。 在遷移的過程中，運行在目的物理主機（Dest Host）中的 libvirtd 進程要根據 address 和 port 創建一個 URI，URI 是目的物理主機用來接收數據和發回數據到源物理主機（Source Host）的 libvirtd 進程的，如圖 9。

圖 9

圖 9

在目的物理主機和源物理主機，只要下面的命令能夠執行，就說明能夠傳輸數據了。

在 compute01 上執行：

[root@compute01]# virsh -c qemu+tcp://nova@compute02/system

在 compute02 上執行：

[root@compute01]# virsh -c qemu+tcp://nova@compute02/system

如下例所示在 compute01 上執行 virsh 命令，如果有圖 10 所示的輸出，就說明傳輸通道正常。

圖 10

圖 10

遷移的步驟

遷移的基本概念弄清楚了，下面我們繼續介紹遷移的步驟。OpenStack 做動態遷移一個正常的流程主要包括四部分：遷移前的條件檢查、遷移前的預處理、遷移、遷移后的處理。

遷移前的條件檢查

動態遷移要成功執行，一些條件必須滿足，所以在執行遷移前必須做一些條件檢查。

  1. 權限檢查，執行遷移的用戶是否有足夠的權限執行動態遷移。
  2. 參數檢查，傳遞給 API 的參數是否足夠和正確，如是否指定了 block-migrate 參數。
  3. 檢查目標物理主機是否存在。
  4. 檢查被遷移的虛擬機是否是 running 狀態。
  5. 檢查源和目的物理主機上的 nova-compute service 是否正常運行。
  6. 檢查目的物理主機和源物理主機是否是同一台機器。
  7. 檢查目的物理主機是否有足夠的內存(memory)。
  8. 檢查目的和源物理主機器 hypervisor 和 hypervisor 的版本是否相同。

遷移前的預處理

在真正執行遷移前，必須做一下熱身，做一些准備工作。

  1. 在目的物理主機上獲得和准備虛擬機掛載的塊設備(volume)。
  2. 在目的物理主機上設置虛擬機的網絡(networks)。
  3. 目的物理主機上設置虛擬機的防火牆(fireware)。

遷移

條件滿足並且做完了預處理工作后，就可以執行動態遷移了。主要步驟如下：

  1. 調用 libvirt python 接口 migrateToURI，來把源主機遷移到目的主機。
    • dom.migrateToURI(CONF.live_migration_uri % dest,logical_sum,None,CONF.live_migration_bandwidth)
    • live_migration_uri：這個 URI 就是在 3.2.2 里介紹的 libvirtd 進程定義的。
    • live_migration_bandwidth：這個參數定義了遷移過程中所使用的最大的帶寬。
  2. 以一定的時間間隔（0.5）循環調用 wait_for_live_migration 方法，來檢測虛擬機遷移 的狀態，一直到虛擬機成功遷移為止。

遷移后的處理

當虛擬機遷移完成后，要做一些善后工作。

  1. 在源物理主機上 detach volume。
  2. 在源物理主機上釋放 security group ingress rule。
  3. 在目的物理主機上更新數據庫里虛擬機的狀態。
  4. 在源物理主機上刪除虛擬機。

上面四步正常完成后，虛擬機就成功的從源物理主機成功地遷移到了目的物理主機了。系統管理員就可以執行第二章所列的哪些管理任務了。

動態遷移的配置

本節列出了支持動態遷移的配置，必須確保所有物理主機上配置真確，動態遷移才能成功完成。

Libvirt

libvirt 默認情況下支持遠程連接的 TLS 協議，不支持 TCP 協議，因此將 listen_tls=0 listen_tcp=1 使 libvirt 能夠支持 TCP 協議。

  1. 修改/etc/sysconfig/libvirtd 文件。 
    LIBVIRTD_ARGS="--listen"
  2. 在/etc/libvirt/libvirtd.conf 文件中做如下配置。 
    listen_tls=0
listen_tcp=1
auth_tcp="none"
  3. 重啟 libvirtd 服務

物理主機上 DNS

配置每個物理主機上的/etc/host，加入每個物理主機的 hostname 和 IP，如下例：

192.168.0.1     compute-1  compute-1.ibm.com
192.168.0.2     compute-2  compute-2.ibm.com

防火牆

配置/etc/sysconfig/iptables，打開 TCP 端口 16509。

-A INPUT -p tcp -m multiport --ports 16509 -m comment --comment "libvirt" -j ACCEPT

OpenStack Nova

在/etc/nova/nova.conf 文件里配置 live_migration 標記。live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

動態遷移的實例

本節通過下面的例子來演示如何做動態遷移。這個例子的目標就是把虛擬機從 tor01kvm001ccz048 遷移到 tor01kvm002ccz048。如圖 11 所示。

圖 11

圖 11

  1. 在 tor01kvm001ccz048 上建一個虛擬機 lm001，如圖 12 所示。

    點擊查看代碼清單

    圖 12
    圖 12

  2. 檢查虛擬機 lm001 建在了 tor01kvm001ccz048 上，如圖 13 所示。

    圖 13
    圖 13

  3. 執行動態遷移

    #nova live-migration --block-migrate lm001 tor01kvm002ccz048

    我們可以看到虛擬機的 Task State 變成了 migrating 狀態，如圖 14 所示。

    圖 14
    圖 14

  4. 檢查遷移的結果

    通過 nova show 命令，可以看到 lm001 已經成功遷移到了 tor01kvm002ccz048，如圖 15 所示。

    圖 15
    圖 15

總結

從前面的介紹我們可以看出，即使沒有共享存儲，我們也可以對虛擬機實現無中斷的動態遷移，不過所有的計算節點之間需要快的網路支持。另外還需要注意兩點：

  1. 本文使用的是沒有沒有加密的 TCP/IP socket，所以在生產環境不推薦使用，除非是在一個安全可信的網路里執行動態遷移。
  2. 在遷移的過程中，虛擬機會有 downtime。詳細的信息，可以閱讀參考資料里的塊遷移的性能報告。


免責聲明！

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



猜您在找 基於本地存儲的kvm虛擬機在線遷移 OpenStack遷移虛擬機流程分析 openstack虛擬機遷移的操作記錄 OpenStack虛擬機冷遷移與熱遷移 OpenStack虛擬機冷遷移與熱遷移 OpenStack在線調整虛擬機的大小報錯 虛擬機遷移 虛擬機遷移 虛擬機遷移 openstack轉移新建虛擬機存儲路徑
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM