作者：蘇楠
前言
在國家政策大力推動信息安全戰略的背景下，從早期的去IOE，到當下倡導的自主創新、安全可信，越來越多的企業開始逐步向國產化IT轉型，承載所有IT基礎設施的雲平臺是其中重要的一環。由於歷史的原因，不少企業的IT中仍保留着VMware的環境，這就導致這些企業無法及時響應政策的號召，而且軟件本身也會面臨升級等問題。
對於上述的問題，ZStack1.8版本中支持了vCenter的納管，並不斷豐富運維、租戶、運營等方面的能力。從納管到遷移幾乎是順其自然的一串需求，遷移中客戶主要面臨兩個困難，一是部分業務連續不中斷或者儘量降低中斷時間，再則免費工具的複雜程度以及兼容性所存在的問題，導致客戶不得不夠買一些第三方的遷移服務。這就使得屬於ZStack雲原生的遷移服務模塊, 在ZStack3.0版本中應運而生。
在ZStack接管VMware的基礎上，遷移服務輕鬆幫助用戶將vCenter上的雲主機遷移至ZStack平臺，過程全UI界面操作，IP級細粒度屬性自定義，已支持主流Windows、Linux系統的雲主機的遷移。
ZStack V2V介紹
ZStack中有一個高級模塊叫遷移服務，可將不同平臺的雲主機系統及數據完整遷移至當前雲平臺。遷移服務除了可以將VMware的虛擬機遷移到ZStack，在3.6.0的版本中也支持將任何基於KVM的平臺（源平臺包括ZStack）遷移到ZStack。同時滿足在線遷移、離線遷移、併發遷移、指定遷移網絡、預修改雲主機配置等多種特性。本文重點以VMware虛擬機遷移至ZStack展開。
場景設定
假定用戶已部署一套vCenter環境和一套最新的ZStack私有云環境，並已將vCenter接管到ZStack私有云雲平臺。由於業務需要，現要將已接管的vCenter雲主機遷移至當前的KVM雲平臺中。
V2V遷移需要指定目標集羣內的物理機作爲遷移服務器。本場景下，假定用戶已提前準備好1臺存儲服務器，並將該存儲服務器添加到目標集羣內作爲計算節點，用戶將使用這臺計算節點作爲遷移服務器。
用戶的源端和目標端信息如下：
具體實踐流程如下：
1.添加遷移服務器
2創建遷移任務
a)創建V2V遷移任務的第一步，除了填寫一些基本信息，需要指定源平臺上待遷移的雲主機。若此處選擇多臺源雲主機，將批量創建相應的遷移任務，最多可以同時指定50臺。
b)第二步配置目標平臺的資源，也就是ZStack端的配置。對於計算和存儲資源可以根據當時的資源池情況給出參考數據。然後選擇剛纔添加的遷移服務器。最後還有一個“壓縮模式”的選項，可以根據存儲類型和帶寬情況選擇是否先壓縮成qcow2的格式再傳輸，當然壓縮本身也是需要佔用整個遷移時間的。
c)遷移任務的第三步，也是最複雜的一步。用戶通常是希望整個業務不中斷，或者中斷時間儘量縮短的， 因此目標平臺上可能提前做好了相應的網絡規劃。ZStack給出了每個網卡的源vCenter網絡與目標網絡的對應關係，可以細粒度到每個IP和mac地址。如果對業務的私網地址沒有嚴格要求，可以直接以網段的形式做出映射即可。
3. 確認提交後，4臺vCenter雲主機創建出4個獨立的遷移任務，如圖所示已成功遷移至當前KVM雲平臺。
4. 小結，整個過程使用下來比第三方的遷移工具的體驗流暢很多，全UI操作的同時保留了雲主機屬性的自定義能力，但需要先接管的要求對於某些場景可能有所限制。
後記
在筆者來看，未來幾年企業上多雲是大的趨勢，有趣的是大家對“混合雲”的定義也越來越寬泛。隨着不同雲平臺間遷移的需求愈發旺盛，各家雲廠商原生的遷移工具也會逐漸豐富，對客戶來說雲的遷入成本會逐步降低。對雲廠商來說，遷移技術的積累一方面可以轉化爲災備能力，另一方面也可以補充自動化運維的場景。也許有一天客戶真的會對“混合雲”的彈性買單。