虛擬機器在 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

• (2):虛擬機器的資料存在本地磁碟(block migration)， 2 所示，需要對鏡像檔案和記憶體資料同時遷移。OpenStack 通過塊遷移實現這這類遷移。

  圖 2

虛擬機器移轉的作用

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

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

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

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

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

動態遷移方法和實現

本章詳細介紹在 OpenStack 裡如何?動態遷移。在第一節裡，提到了有兩種類型的動態遷移，本文只介紹圖 2 所示的虛擬機器的資料存在本地磁碟(block migration)的動態遷移。

動態遷移的條件

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

圖 3

控制節點接受並處理動態遷移的請求，管理員可以從 Horizon、命令列、API 發起動態遷移。 動態遷移就是把客戶的 VM 從計算節點 1 遷移到計算節點 2，或者從計算節點 2 遷移到計算節點 1， 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

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

圖 6

用 qemu-img 查看虛擬機器單獨的增量鏡像檔案的資訊，我們可以看到他的 backing file 是_base 目錄下的鏡像檔案， 7 所示。

圖 7

費了這麼多篇幅介紹 QCOW2，您會奇怪，目的何在？其實上面介紹的後端鏡像(libvirt Base)，虛擬機器單獨的增量鏡像檔案(libvirt instance disks)，它們就是要被遷移的資料。動態遷移的最終目標就是把它們完整地從源物理主機遷移到目標物理主機。除了他們兩個之外，還有一個需要遷移的對象就是記憶體裡啟動並執行虛擬機器的資料。

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

1. 待用資料：儲存在本地的虛擬機器的鏡像檔案，包括後端鏡像(libvirt Base)和虛擬機器單獨的增量鏡像檔案(libvirt instance disks)。
2. 動態資料：記憶體裡虛擬機器的運行時資料，記憶體裡的資料是動態變化的資料，虛擬機器裡啟動並執行負載的大小直接影響遷移的時間長短。

遷移通道和傳輸協議

OpenStack 調用底層的 libvirt 來完成動態遷移。虛擬機器的遷移，其實就是資料的轉移。libvirt 提供了隧道化的資料轉送（libvirt tunnelled transport）方式來完成資料轉移。 8 所示。

圖 8

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

圖 9

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

在 compute01 上執行：

[[email protected]]# virsh -c qemu+tcp://[email protected]/system

在 compute02 上執行：

[[email protected]]# virsh -c qemu+tcp://[email protected]/system

如下例所示在 compute01 上執行 virsh 命令，如果有圖 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=0listen_tcp=1auth_tcp="none"

3. 重啟 libvirtd 服務

物理主機上 DNS

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

192.168.0.1     compute-1  compute-1.ibm.com192.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

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

   點擊查看代碼清單

   圖 12

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

   圖 13

3. 執行動態遷移

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

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

   圖 14

4. 檢查遷移的結果

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

   圖 15

總結

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

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

虛擬機器在 OpenStack 裡沒有共用儲存條件下的線上遷移[轉]