今天想跟大家分享一下 以 VMware 技术为底座的云间漫游方案 ，在开始正文之前谈谈我在写这个话题时想到的几个典故。

　　典故 1：科幻经典巨作《2001: 太空漫游》是一部伟大的作品，电影和书都是。也正如《三体》的作者刘慈欣对该作品的荐言中写道：我所有作品都是对《2001：太空漫游》的拙劣模仿。

　　上个世纪 60 年代末所畅想的人类将会在 2001 年实现太空漫游，其场景中有诸多对未来的想象与推测在今天都一一兑现了，但更多的是时至2020年我们还有很多领域没有做到该作品所预测的那样。2019年是该电影作品的50周年，我们人类仍在宇宙探索的道路上步履蹒跚的前进着。我也带着对该作品崇高的敬意期待着它的进程。

　　典故 2：清楚的记得前东家作为网络大厂，很早就提出了 Intercloud 的想法，并成立事业部，提供了解决方案。在这个事业部存在的那几年了，作为一名中国员工总是带着这玩意不靠谱的心理预期去看待它。尝试去阅读 Intercloud 的文档后，除了已知采用路由器构建VPN到公有云之外，并没有别的让我兴奋的特色。以至于后来新 CEO Chunk 上台后该事业部就被无情的连根拔了。也许是时机不成熟，也许是生态带来的壁垒，或是别的什么原因我们不得而知。

　　好了，闲篇少叙。正式开始正文部分，站在 2020 年这个时间节点来向大家介绍来自 VMware 可落地的云际漫游方案。

　　在商业虚拟化领域 VMware 以接近 90% 的市场占有率独占鳌头，而如今更是通过一系列眼花缭乱的操作强力跻身云原生领域。收购 Heptio & Pivotal 等公司使得 VMware 更是成为了 CNCF（云原生基金会） 贡献率第二的公司， 仅次于 Google。

　　即便在今天各个厂家与机构都在大力的参与云原生的事业，你可能会猜想容器Runtime会成为主流，虚拟机会逐渐淡出历史舞台？ 但就我们观察到的趋势却恰恰相反，虚拟机正在通过改良基因而成为新一代的云原生Runtime。大量的超微虚拟机支持了 OCI（Open Container Initiative）标准。如 VMware 的 CRX，AWS 的 Firecracker，Openstack 主导的 Kata，还包括 Google 的 gVisor，都是以裁剪后的虚拟机为基底作为容器的Runtime。

　　它们无一例外都是借助了虚拟机天然的优势：强隔离，硬件虚拟化，网络高性能，存储方案多样性等等。同时兼具了容器的轻量级和简便封装的核心。但不管贵司采用的是何种Runtime，标准虚拟机或者容器，亦或超微虚拟机，事实上在应用有状态时依然是难以迁移的。也就是我们常说的带存储迁移，这给云际漫游带来了实质性的障碍。

　　那我们着眼当下， 传统的企业数据中心采用的大量的 VMware vSphere 技术栈的业务，绝大多数都是带状态的业务，这些业务的平滑迁移是我们率先需要解决的。将这些业务迁移到 VMware 下一代的技术平台，亦或是迁移到 VMware 技术栈的公有云平台。当然你可以用于新老平台间，私有云与公有云间的容灾保护。该解决方案就是 VMware HCX，混合云际漫游。

　　VMware HCX 提供一套能够多云间虚拟机迁移的解决方案，上图中可概览到，在私有云环境中用户可以通过 HCX 将老版本的虚拟机业务平滑的迁移到 VMware 最新的技术栈如 VCF / SDDC中。也可以迁移至启用了 VMware 技术栈的公有云，如 VMC on AWS / Azure。在撰写本文的同时，我们也迎来了久违的 VMC on AliCloud，意味着国内用户可以通过 HCX 方案将虚拟机业务迁移或灾备在阿里云。正如我拟定的标题一样，HCX 是一套云际漫游方案，所以我们还可以实现公有云到公有云间的迁移或容灾，也可同时再与您的私有云迁移备份联动，是一套 Mesh 形态的方案。

　　被迁移的虚拟机最低平台版本可以从 ESXi 5.5 开始或更高， 也可以是非 VMware 技术栈的虚拟机如 KVM 或 Hyper-V（需要Agent）。整个虚拟机迁移的过程可以是平滑的，批量的，有计划的，去重压缩的，甚至是无业务中断的和二层延展的迁移方式。让我们通过 HCX 的架构示意图一探究竟。

　　源站点数据中心需要部署 HCX，并集成 VC，NSX（网络虚拟化）组件为可选项。目标站点也是类似部署 HCX 与 VC 集成，但 NSX 为必选项。通过最少一组或多组的 HCX InterConnect 进行加密隧道组网，并可选结合去重压缩或二层延展。也可加持 SRM 做颗粒度更高的容灾计划。

　　构建加密通道，在私有云间或到公有云，可理解为多通道 VPN：

　　可在私有到私有，私有到公有云间制定容灾计划。如果该计划由SRM制定，SRM 还可联动使用 HCX 构建的优化通道和去重压缩技术。

 

　　这个过程是不是很像友商 SDN 的 Gateway Anywhere，VM 可以选择就近的网关作为出口，又能跟通子网的其他VM通讯。你可能会说这个方案又是 Overlay 又是 Underlay，还有 BGP，很复杂。其实这个是必要的，我们变向的解释了为什么很多友商的 SDN 其控制层面是 MP-BGP，Overlay 采用 VxLAN 封装，实现 Leaf 交换机承担分布式网关的实质 ---- 全网主机路由。当然 HCX 使用这个方式只是作为二层延展迁移的过度时使用的技术，二层子网完全迁移完毕 HCX Manager 回收注入的路由条目。How？！与注入一样 API Call。

　　以一张胶片汇总一下 HCX 的两个版本的许可和功能集（ NSX企业版和 VCF 企业版默认包含了 HCX 高级版）。

　　本次的 Demo 环境会展示得比较简单，倒不是因为想偷懒，主要是 VMware 在公开 Hands on Lab 上有关于的 HCX 的动手实验。而且这个动手实验的指南有中文版本，除了没有安装步骤，几种迁移的场景的操作都包含了。步骤和截图也相当丰富，我就没必要赘述了。有兴趣的读者可以访问 https://labs.hol.vmware.com/ 找到 HCX 的实验：HOL-2081-01-HBD，注册操练起来即可。

　　我本人的测试环境是个嵌套环境，受限机器性能的原因，没有集成 SRM，没有做 Live vMotion。模拟了两个站点，SiteA（SDDC） 为目标站点，SiteB 为灾备或需迁移站点。安装好 HCX Manager 分别与两个站点的 vCenter 集成。集成后在 vCenter 的主界面就会出现 HCX 的标签页了，可以直接配置 HCX 有关的内容了，当然你也可以单独登陆 HCX IP 访问其独立的界面。

　　在 SiteA 与 SiteB 完整配对后，便可建立 InterConnect 的隧道了，建立隧道的过程可以选择附件的服务，如批量，复制辅助，二层延展等拓展服务。隧道建立完成后可以在 InterConnect 中查看隧道的状态和逻辑拓扑。

　　大家可以在我的迁移计划里看到，迁移计划是可以分组+批量进行的，并且是可以双向的。并非只能 SiteB 向 SiteA 迁移。下图中是我已完成的采用 RAV （复制加持的vMotion）和 Bulk （批量温迁移）分组和记录。当然中途有我实验过程中不熟悉或测试导致的报错，为了美观和不露怯的目的被我解决掉了。具体的操作步骤截图会不宜阅读， 还是请有兴趣的朋友使用HOL。

　　在容灾选项里我模拟了 SiteB 的一个业务灾备道 SiteA，RPO 为 15 分钟（最小 5 分钟），只保留一份快照。并且系统显示当前该虚拟机在 SiteB 与 SiteA 之间无副本差异。如果有，同步的进度条会启动，并回报同步了多少差异数据。而这个基于 HCX 的容灾，如正文中讲到的，结合SRM 会达到最佳效果。

　　好了，本次的 Demo 环节就草草结束了，如果您没有时间去实操 HCX 的实验，也可以直接阅读该实验的指南，我将该指南的中文分享到网盘链接中：

　　https://pan.baidu.com/s/1-R3w5IrHzc5upKHMnPMJsA  密码：5es6

　　亦或者您也可以下载官方 HCX 101 的胶片来浏览：

　　https://pan.baidu.com/s/1ANsIYN1xQSoUJzKLrO5Egw  密码：3c0y

　　写本文时真的让我回忆或联想到很多非 VMware HCX 的解决方案，它们大多都是多种产品的混排，各个产品都在各自专业的领域独树一帜，但用户却很难把它们有机的结合在一起。所以往往用户自己在思考如何向新平台迁移或异地容灾时，总是感觉设计之初就困难重重。多种产品混排不仅购买开销大，生态中某一环出现问题在技术支持上又很容易掉链子。

　　我本人观点，HCX 也还有很多需要优化的地方，但在今天这个时间节点，VMware HCX 却又是一款可以落地的，以 VMware 为技术支持，特性丰富的云际漫游方案。我也有理由相信它会发展得更好，带着我们的用户在 VMware Cloud 中漫游。

　　关于作者

　　Rock Zang

　　VMware中国区资深网络架构师