今天想跟大家分享一下 以 VMware 技術為底座的云間漫游方案 ，在開始正文之前談談我在寫這個話題時想到的幾個典故。
典故 1：科幻經(jīng)典巨作《2001: 太空漫游》是一部偉大的作品，電影和書都是。也正如《三體》的作者劉慈欣對該作品的薦言中寫道：我所有作品都是對《2001：太空漫游》的拙劣模仿。
上個世紀 60 年代末所暢想的人類將會在 2001 年實現(xiàn)太空漫游，其場景中有諸多對未來的想象與推測在今天都一一兌現(xiàn)了，但更多的是時至2020年我們還有很多領域沒有做到該作品所預測的那樣。2019年是該電影作品的50周年，我們人類仍在宇宙探索的道路上步履蹣跚的前進著。我也帶著對該作品崇高的敬意期待著它的進程。
典故 2：清楚的記得前東家作為網(wǎng)絡大廠，很早就提出了 Intercloud 的想法，并成立事業(yè)部，提供了解決方案。在這個事業(yè)部存在的那幾年了，作為一名中國員工總是帶著這玩意不靠譜的心理預期去看待它。嘗試去閱讀 Intercloud 的文檔后，除了已知采用路由器構建VPN到公有云之外，并沒有別的讓我興奮的特色。以至于后來新 CEO Chunk 上臺后該事業(yè)部就被無情的連根拔了。也許是時機不成熟，也許是生態(tài)帶來的壁壘，或是別的什么原因我們不得而知。
好了，閑篇少敘。正式開始正文部分，站在 2020 年這個時間節(jié)點來向大家介紹來自 VMware 可落地的云際漫游方案。
02、VMware 混合云體驗 （HCX）
在商業(yè)虛擬化領域 VMware 以接近 90% 的市場占有率獨占鰲頭，而如今更是通過一系列眼花繚亂的操作強力躋身云原生領域。收購 Heptio & Pivotal 等公司使得 VMware 更是成為了 CNCF（云原生基金會） 貢獻率第二的公司， 僅次于 Google。
即便在今天各個廠家與機構都在大力的參與云原生的事業(yè)，你可能會猜想容器Runtime會成為主流，虛擬機會逐漸淡出歷史舞臺？ 但就我們觀察到的趨勢卻恰恰相反，虛擬機正在通過改良基因而成為新一代的云原生Runtime。大量的超微虛擬機支持了 OCI（Open Container Initiative）標準。如 VMware 的 CRX，AWS 的 Firecracker，Openstack 主導的 Kata，還包括 Google 的 gVisor，都是以裁剪后的虛擬機為基底作為容器的Runtime。
它們無一例外都是借助了虛擬機天然的優(yōu)勢：強隔離，硬件虛擬化，網(wǎng)絡高性能，存儲方案多樣性等等。同時兼具了容器的輕量級和簡便封裝的核心。但不管貴司采用的是何種Runtime，標準虛擬機或者容器，亦或超微虛擬機，事實上在應用有狀態(tài)時依然是難以遷移的。也就是我們常說的帶存儲遷移，這給云際漫游帶來了實質性的障礙。
那我們著眼當下， 傳統(tǒng)的企業(yè)數(shù)據(jù)中心采用的大量的 VMware vSphere 技術棧的業(yè)務，絕大多數(shù)都是帶狀態(tài)的業(yè)務，這些業(yè)務的平滑遷移是我們率先需要解決的。將這些業(yè)務遷移到 VMware 下一代的技術平臺，亦或是遷移到 VMware 技術棧的公有云平臺。當然你可以用于新老平臺間，私有云與公有云間的容災保護。該解決方案就是 VMware HCX，混合云際漫游。
VMware HCX 提供一套能夠多云間虛擬機遷移的解決方案，上圖中可概覽到，在私有云環(huán)境中用戶可以通過 HCX 將老版本的虛擬機業(yè)務平滑的遷移到 VMware 最新的技術棧如 VCF / SDDC中。也可以遷移至啟用了 VMware 技術棧的公有云，如 VMC on AWS / Azure。在撰寫本文的同時，我們也迎來了久違的 VMC on AliCloud，意味著國內用戶可以通過 HCX 方案將虛擬機業(yè)務遷移或災備在阿里云。正如我擬定的標題一樣，HCX 是一套云際漫游方案，所以我們還可以實現(xiàn)公有云到公有云間的遷移或容災，也可同時再與您的私有云遷移備份聯(lián)動，是一套 Mesh 形態(tài)的方案。
HCX 方案的主要商業(yè)價值：
- 數(shù)據(jù)中心搬遷 / 新構數(shù)據(jù)中心的遷移 / 原數(shù)據(jù)中心的升級
- 嘗試采用混合云 / 混合云間的用量平衡
- 制定災備計劃 / 采用混合云進行災備
- 其他平臺遷移至 VMware 新一代的技術棧
03、HCX 架構與特性概述：
被遷移的虛擬機最低平臺版本可以從 ESXi 5.5 開始或更高， 也可以是非 VMware 技術棧的虛擬機如 KVM 或 Hyper-V（需要Agent）。整個虛擬機遷移的過程可以是平滑的，批量的，有計劃的，去重壓縮的，甚至是無業(yè)務中斷的和二層延展的遷移方式。讓我們通過 HCX 的架構示意圖一探究竟。
源站點數(shù)據(jù)中心需要部署 HCX，并集成 VC，NSX（網(wǎng)絡虛擬化）組件為可選項。目標站點也是類似部署 HCX 與 VC 集成，但 NSX 為必選項。通過最少一組或多組的 HCX InterConnect 進行加密隧道組網(wǎng)，并可選結合去重壓縮或二層延展。也可加持 SRM 做顆粒度更高的容災計劃。
核心技術點：
構建加密通道，在私有云間或到公有云，可理解為多通道 VPN：
- 支持多路徑通道 / 自動最優(yōu)路徑， TCP會話修剪。
- 可構建在私有專線上如 MPLS VPN 或 SDH 等， 也可以基于互聯(lián)網(wǎng)出口構建（甚至無需固定公網(wǎng)IP）， 當然兩種或多種形態(tài)的鏈接可同時存在。
可雙向批量遷移，同時結合去重壓縮技術減少廣域網(wǎng)開銷：
- 構建鏈路時可輕松的附帶出重壓縮功能，和流量管控。在批量遷移虛擬機時帶來可觀的廣域網(wǎng)開銷節(jié)省。
- 支持批量，按計劃的批量熱遷移和批量溫遷移。熱遷移即虛擬機不關機遷移，溫遷移在同步時業(yè)務無影響遷移切換時虛擬機重啟。
網(wǎng)絡功能延展，保持原 IP 遷移，改動 IP 遷移，或二層延展遷移：
- 批量遷移時可選是否同時修改被遷移虛擬機的 IP （需要 VM Tools 的支持）。
- 也可采用二層延展技術，使虛擬機平滑二層遷移，并能與原數(shù)據(jù)中心相同子網(wǎng)的虛擬機通訊，但出口已優(yōu)化至本地。
簡化遷移難度：
- 用戶無需在目標數(shù)據(jù)中心開啟 EVC 兼容模式。
- 遷移計劃中還可指定，遷移后同時升級虛擬機版本以及 VM Tools。
多向容災保護，并可結合 VMware SRM：
可在私有到私有，私有到公有云間制定容災計劃。如果該計劃由SRM制定，SRM 還可聯(lián)動使用 HCX 構建的優(yōu)化通道和去重壓縮技術。
- HCX 的批量遷移可以為容災自動產(chǎn)生容災種子文件，使得遷移完成后的虛擬機可以輕松的指定原數(shù)據(jù)中心的種子文件為其容災，大大減少了同步成本和網(wǎng)絡開銷。
- HCX 提供容災演練，同步狀態(tài)追蹤，按計劃構建保護快照等高級功能。
- 源目站點由 HCX NET-EXT（VM） 來構建二層延展的隧道， 也就是我們常說的 Overlay 路徑。
- HCX NET-EXT 阻斷源目站點的廣播報文。
- 橙色 VM-A20 保持IP 192.168.10.20 不變，遷移到目標站點。通過 ARP 找到了目標站點的 NSX 路由器為網(wǎng)關。
- HCX Manager 向 NSX 路由器注入 VM-A20 的 32 位主機路由（即 NSX 路由器上增加 192.168.10.20/32 條目）。
- NSX 路由器通過 BGP 對外宣告該主機路由，源數(shù)據(jù)中心路由器學習到 VM-A20 來自目標數(shù)據(jù)中心。
- 此時若 VM-A20 與 VM-A10 通訊，看似在一個子網(wǎng)，實際上是通過 Underlay 路由進行通訊的，并非走 HCX NET-EXT 的隧道。
這個過程是不是很像友商 SDN 的 Gateway Anywhere，VM 可以選擇就近的網(wǎng)關作為出口，又能跟通子網(wǎng)的其他VM通訊。你可能會說這個方案又是 Overlay 又是 Underlay，還有 BGP，很復雜。其實這個是必要的，我們變向的解釋了為什么很多友商的 SDN 其控制層面是 MP-BGP，Overlay 采用 VxLAN 封裝，實現(xiàn) Leaf 交換機承擔分布式網(wǎng)關的實質 ---- 全網(wǎng)主機路由。當然 HCX 使用這個方式只是作為二層延展遷移的過度時使用的技術，二層子網(wǎng)完全遷移完畢 HCX Manager 回收注入的路由條目。How？！與注入一樣 API Call。
以一張膠片匯總一下 HCX 的兩個版本的許可和功能集（ NSX企業(yè)版和 VCF 企業(yè)版默認包含了 HCX 高級版）。
04、Demo Time
本次的 Demo 環(huán)境會展示得比較簡單，倒不是因為想偷懶，主要是 VMware 在公開 Hands on Lab 上有關于的 HCX 的動手實驗。而且這個動手實驗的指南有中文版本，除了沒有安裝步驟，幾種遷移的場景的操作都包含了。步驟和截圖也相當豐富，我就沒必要贅述了。有興趣的讀者可以訪問 https://labs.hol.vmware.com/ 找到 HCX 的實驗：HOL-2081-01-HBD，注冊操練起來即可。
我本人的測試環(huán)境是個嵌套環(huán)境，受限機器性能的原因，沒有集成 SRM，沒有做 Live vMotion。模擬了兩個站點，SiteA（SDDC） 為目標站點，SiteB 為災備或需遷移站點。安裝好 HCX Manager 分別與兩個站點的 vCenter 集成。集成后在 vCenter 的主界面就會出現(xiàn) HCX 的標簽頁了，可以直接配置 HCX 有關的內容了，當然你也可以單獨登陸 HCX IP 訪問其獨立的界面。
在 SiteA 與 SiteB 完整配對后，便可建立 InterConnect 的隧道了，建立隧道的過程可以選擇附件的服務，如批量，復制輔助，二層延展等拓展服務。隧道建立完成后可以在 InterConnect 中查看隧道的狀態(tài)和邏輯拓撲。
大家可以在我的遷移計劃里看到，遷移計劃是可以分組+批量進行的，并且是可以雙向的。并非只能 SiteB 向 SiteA 遷移。下圖中是我已完成的采用 RAV （復制加持的vMotion）和 Bulk （批量溫遷移）分組和記錄。當然中途有我實驗過程中不熟悉或測試導致的報錯，為了美觀和不露怯的目的被我解決掉了。具體的操作步驟截圖會不宜閱讀， 還是請有興趣的朋友使用HOL。
在容災選項里我模擬了 SiteB 的一個業(yè)務災備道 SiteA，RPO 為 15 分鐘（最小 5 分鐘），只保留一份快照。并且系統(tǒng)顯示當前該虛擬機在 SiteB 與 SiteA 之間無副本差異。如果有，同步的進度條會啟動，并回報同步了多少差異數(shù)據(jù)。而這個基于 HCX 的容災，如正文中講到的，結合SRM 會達到最佳效果。
好了，本次的 Demo 環(huán)節(jié)就草草結束了，如果您沒有時間去實操 HCX 的實驗，也可以直接閱讀該實驗的指南，我將該指南的中文分享到網(wǎng)盤鏈接中：
https://pan.baidu.com/s/1-R3w5IrHzc5upKHMnPMJsA 密碼：5es6
亦或者您也可以下載官方 HCX 101 的膠片來瀏覽：
https://pan.baidu.com/s/1ANsIYN1xQSoUJzKLrO5Egw 密碼：3c0y
小結
寫本文時真的讓我回憶或聯(lián)想到很多非 VMware HCX 的解決方案，它們大多都是多種產(chǎn)品的混排，各個產(chǎn)品都在各自專業(yè)的領域獨樹一幟，但用戶卻很難把它們有機的結合在一起。所以往往用戶自己在思考如何向新平臺遷移或異地容災時，總是感覺設計之初就困難重重。多種產(chǎn)品混排不僅購買開銷大，生態(tài)中某一環(huán)出現(xiàn)問題在技術支持上又很容易掉鏈子。
我本人觀點，HCX 也還有很多需要優(yōu)化的地方，但在今天這個時間節(jié)點，VMware HCX 卻又是一款可以落地的，以 VMware 為技術支持，特性豐富的云際漫游方案。我也有理由相信它會發(fā)展得更好，帶著我們的用戶在 VMware Cloud 中漫游。
關于作者
Rock Zang
VMware中國區(qū)資深網(wǎng)絡架構師
