如何進行Live Migrate 操作

這篇文章將為大家詳細講解有關如何進行Live Migrate 操作，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

Migrate 操作會先將 instance 停掉，也就是所謂的“冷遷移”。而 Live Migrate 是“熱遷移”，也叫“在線遷移”，instance不會停機。

Live Migrate 分兩種：

1. 源和目標節點沒有共享存儲，instance 在遷移的時候需要將其鏡像文件從源節點傳到目標節點，這叫做 Block Migration（塊遷移）

2. 源和目標節點共享存儲，instance 的鏡像文件不需要遷移，只需要將 instance 的狀態遷移到目標節點。

源和目標節點需要滿足一些條件才能支持 Live Migration：

1. 源和目標節點的 CPU 類型要一致。

2. 源和目標節點的 Libvirt 版本要一致。

3. 源和目標節點能相互識別對方的主機名稱，比如可以在 /etc/hosts 中加入對方的條目。
   

4. 在源和目標節點的 /etc/nova/nova.conf 中指明在線遷移時使用 TCP 協議。
   

5. Instance 使用 config driver 保存其 metadata。在 Block Migration 過程中，該 config driver 也需要遷移到目標節點。由于目前 libvirt 只支持遷移 vfat 類型的 config driver，所以必須在 /etc/nova/nova.conf 中明確指明 launch instance 時創建 vfat 類型的 config driver。
   

6. 源和目標節點的 Libvirt TCP 遠程監聽服務得打開，需要在下面兩個配置文件中做一點配置。

/etc/default/libvirt-bin

start_libvirtd="yes" libvirtd_opts="-d -l"

/etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
unix_sock_group = "libvirtd"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"
auth_tcp = "none"

然后重啟 Libvirtd 服務
service libvirt-bin restart

非共享存儲 Block Migration

我們先討論非共享存儲的 Block Migration。流程如下：

向nova-api發送請求

客戶（可以是 OpenStack 最終用戶，也可以是其他程序）向API（nova-api）發送請求：“幫我將這個 Instance 從節點 A Live Migrate 到節點 B”

這里源節點是 devstack-compute1，目標節點是 devstack-controller，因為是非共享存儲，記得將“Block Migration”勾選上。

這里還有一個“Disk Over Commit”選項，如果勾選了此選項，nova 在檢查目標節點的磁盤空間是否足夠時，是以 instance 磁盤鏡像文件定義的最大容量為準；否則，以磁盤鏡像文件當前的實際大小為準。

查看日志 /opt/stack/logs/n-api.log

nova-api 發送消息

nova-api 向 Messaging（RabbitMQ）發送了一條消息：“Live Migrate 這個 Instance” 源代碼在 /opt/stack/nova/nova/compute/api.py，方法是 live_migrate。

nova-compute 執行操作

源和目標節點執行 Live Migrate 的操作過程如下：

1. 目標節點執行遷移前的準備工作，首先將 instance 的數據遷移過來，主要包括鏡像文件、虛擬網絡等資源，日志在 devstack-controller:/opt/stack/logs/n-cpu.log
   

2. 源節點啟動遷移操作，暫停 instance
   

3. 在目標節點上 Resume instance
   

4. 在源節點上執行遷移的后處理工作，刪除 instance
   

5. 在目標節點上執行遷移的后處理工作，創建 XML，在 Hypervisor 中定義 instance，使之下次能夠正常啟動。
   

Instance 在 Live Migrate 的整個過程中不會停機，我們通過 Ping 操作來觀察

可見在遷移過程中，Ping 進程沒有中斷，只是有一個 ping 包的延遲增加了。

下面我們再來看源和目標節點共享存儲下的 Live Migrate。

共享存儲 Live Migration

有多種方式可以實現共享存儲，比如可以將 instance 的鏡像文件放在 NFS 服務器上，或者使用 NAS 服務器，或者分布式文件系統。

作為學習和實驗，這里我們采用 NFS 方案。其他共享存儲方案對于 Live Migration 本質上是一樣的，只是在性能和高可用性上更好。

搭建 NFS 環境

將 devstack-controller 作為 NFS 服務器，共享其目錄 /opt/stack/data/nova/instances。 devstack-compute1 作為 NFS 客戶端將此目錄 mount 到本機，如下所示：

這樣，OpenStack 的 instance 在 devstack-controller 和 devstack-compute1 上就實現共享存儲了。

共享存儲的遷移過程與 Block Migrate 基本上一樣，只是幾個環節有點區別：

1. 向 nova-api 提交請求的時候，不能勾選“Block Migrate”
   

2. 因為源和目標節點都能直接訪問 instance 的鏡像，所以目標節點在準備階段不需要傳輸鏡像文件，源節點在遷移后處理階段也無需刪除 instance 的目錄。

3. 只有 instance 的狀態需要從源節點傳輸到的目標節點，整個遷移速遞比 Block Migration 快很多。

關于如何進行Live Migrate 操作就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。