前言
ZStack 從1.8版本開機就支持了vCenter的納管，并不斷豐富其運維、租戶、運營等方面的能力。加之國產(chǎn)化浪潮的推動，從納管到遷移幾乎是一串順其自然的需求，遷移中客戶主要面臨兩個困難，一是部分業(yè)務(wù)連續(xù)不中斷或者盡量降低中斷時間，再則免費工具的復(fù)雜程度以及兼容性所存在的問題，導(dǎo)致客戶不得不夠買一些第三方的遷移服務(wù)。這就使得屬于ZStack云原生的遷移服務(wù)模塊, 在ZStack3.0版本中應(yīng)運而生。
在ZStack接管VMware的基礎(chǔ)上，遷移服務(wù)輕松幫助用戶將vCenter上的云主機遷移至ZStack平臺，過程全UI界面操作，IP級細粒度屬性自定義，已支持主流Windows、Linux系統(tǒng)的云主機的遷移。
ZStack V2V介紹
ZStack中有一個高級模塊叫遷移服務(wù)，可將不同平臺的云主機系統(tǒng)及數(shù)據(jù)完整遷移至當前云平臺。遷移服務(wù)除了可以將VMware的虛擬機遷移到ZStack，在3.6.0的版本中也支持將任何基于KVM的平臺(源平臺包括ZStack)遷移到ZStack。同時滿足在線遷移、離線遷移、并發(fā)遷移、指定遷移網(wǎng)絡(luò)、預(yù)修改云主機配置等多種特性。本文重點以VMware虛擬機遷移至ZStack展開。
場景設(shè)定
假定用戶已部署一套vCenter環(huán)境和一套最新的ZStack私有云環(huán)境，并已將vCenter接管到ZStack私有云云平臺。由于業(yè)務(wù)需要，現(xiàn)要將已接管的vCenter云主機遷移至當前的KVM云平臺中。
V2V遷移需要指定目標集群內(nèi)的物理機作為遷移服務(wù)器。本場景下，假定用戶已提前準備好1臺存儲服務(wù)器，并將該存儲服務(wù)器添加到目標集群內(nèi)作為計算節(jié)點，用戶將使用這臺計算節(jié)點作為遷移服務(wù)器。
用戶的源端和目標端信息如下：
具體實踐流程如下：
1.添加遷移服務(wù)器
2.創(chuàng)建遷移任務(wù)
a) 創(chuàng)建V2V遷移任務(wù)的第一步，除了填寫一些基本信息，需要指定源平臺上待遷移的云主機。若此處選擇多臺源云主機，將批量創(chuàng)建相應(yīng)的遷移任務(wù)，最多可以同時指定50臺。
b) 第二步配置目標平臺的資源，也就是ZStack端的配置。對于計算和存儲資源可以根據(jù)當時的資源池情況給出參考數(shù)據(jù)。然后選擇剛才添加的遷移服務(wù)器。最后還有一個“壓縮模式”的選項，可以根據(jù)存儲類型和帶寬情況選擇是否先壓縮成qcow2的格式再傳輸，當然壓縮本身也是需要占用整個遷移時間的。
c) 遷移任務(wù)的第三步，也是最復(fù)雜的一步。用戶通常是希望整個業(yè)務(wù)不中斷，或者中斷時間盡量縮短的，因此目標平臺上可能提前做好了相應(yīng)的網(wǎng)絡(luò)規(guī)劃。ZStack給出了每個網(wǎng)卡的源vCenter網(wǎng)絡(luò)與目標網(wǎng)絡(luò)的對應(yīng)關(guān)系，可以細粒度到每個IP和mac地址。如果對業(yè)務(wù)的私網(wǎng)地址沒有嚴格要求，可以直接以網(wǎng)段的形式做出映射即可。
3. 確認提交后，4臺vCenter云主機創(chuàng)建出4個獨立的遷移任務(wù)，如圖所示已成功遷移至當前KVM云平臺。
4. 小結(jié)，整個過程使用下來比第三方的遷移工具的體驗流暢很多，全UI操作的同時保留了云主機屬性的自定義能力，但需要先接管的要求對于某些場景可能有所限制。
后記
在筆者來看，未來幾年企業(yè)上多云是大的趨勢，有趣的是大家對“混合云”的定義也越來越寬泛。隨著不同云平臺間遷移的需求愈發(fā)旺盛，各家云廠商原生的遷移工具也會逐漸豐富，對客戶來說云的遷入成本會逐步降低。對云廠商來說，遷移技術(shù)的積累一方面可以轉(zhuǎn)化為災(zāi)備能力，另一方面也可以補充自動化運維的場景。也許有一天客戶真的會對“混合云”的彈性買單。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
