Live Migrate 操做 - 天天5分鐘玩轉 OpenStack（42）

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。流程圖以下：

1. 向 nova-api 發送請求

2. nova-api 發送消息

3. nova-compute 執行操做

下面咱們詳細討論每個步驟。

向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 操做的詳細分析，下一節咱們討論 Evacuate。