ZStack跨平臺遷移能夠如此簡單

做者：蘇楠

前言

在國家政策大力推進信息安全戰略的背景下，從早期的去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操做的同時保留了雲主機屬性的自定義能力，但須要先接管的要求對於某些場景可能有所限制。

 

後記

在筆者來看，將來幾年企業上多雲是大的趨勢，有趣的是你們對「混合雲」的定義也愈來愈寬泛。隨着不一樣雲平臺間遷移的需求愈發旺盛，各家雲廠商原生的遷移工具也會逐漸豐富，對客戶來講雲的遷入成本會逐步下降。對雲廠商來講，遷移技術的積累一方面能夠轉化爲災備能力，另外一方面也能夠補充自動化運維的場景。也許有一天客戶真的會對「混合雲」的彈性買單。