云原生趋势下的迁移与容灾思考

来源 | 阿里巴巴云原生公众号

作者 | 孙琦

导读：下一个云原生颠覆的领域会不会是在传统的容灾领域呢？在云原生的趋势下，如何构建应用系统的迁移与容灾方案？

趋势

1. 云原生发展趋势

云原生（Cloud Native）是最近几年非常火爆的话题，在 2020 年 7 月由信通院发布的《云原生发展白皮书（2020）年》明确指出：云计算的拐点已到，云原生成为驱动业务增长的重要引擎。我们不难发现云原生带给 IT 产业一次重新洗牌，从应用开发过程到 IT 从业者的技术能力，都是一次颠覆性的革命。在此基础上，出现了基于云原生平台的 Open Application Model 定义，在云原生平台基础上进一步抽象，更加关注应用而非基础架构。同时，越来越多的公有云开始支持 Serverless 服务，更加说明了未来的发展趋势：应用为核心，轻量化基础架构层在系统建设过程中的角色。但是无论如何变化，IT 整体发展方向，一定是向着更有利于业务快速迭代、满足业务需求方向演进的。

2020 年 9 月，Snowflake 以每股 120 美金 IPO，创造了今年规模最大的 IPO，也是有史以来最大的软件 IPO。Snowflake 利用云原生方式重构了数据仓库，成功颠覆了行业竞争格局。这正是市场对云原生发展趋势的最佳认可，所以下一个云原生颠覆的领域会不会是在传统的容灾领域呢？

2. 为什么云上需要全新的迁移和容灾？

1）传统方案的局限性

在这种大的趋势下，传统的迁移和容灾仍然停留在数据搬运的层次上，而忽略了面向云的特性和用户业务重新思考和构建。云计算的愿景是让云资源像水、电一样按需使用，所以基于云上的迁移和容灾也理应顺应这样的历史潮流。Snowflake 也是通过这种商业模式的创新，成功打破旧的竞争格局。

为什么传统容灾的手段无法满足云原生需求呢？简单来说，二者关注的核心不同。传统的容灾往往以存储为核心，拥有对存储的至高无上的控制权。并且在物理时代，对于计算、存储和网络等基础架构层也没有有效的调度方法，无法实现高度自动化的编排。而基于云原生构建的应用，核心变成了云原生服务本身。当用户业务系统全面上云后，用户不再享有对底层存储的绝对控制权，所以传统的容灾手段，就风光不在了。

我认为在构建云原生容灾的解决方案上，要以业务为核心去思考构建方法，利用云原生服务的编排能力实现业务系统的连续性。

2）数据安全性

AWS CTO Werner Vogels 曾经说过：Everything fails, all the time。通过 AWS 的责任共担模型，我们不难发现云商对底层基础架构负责，用户仍然要对自身自身数据安全性和业务连续性负责。

我认为在云原生趋势下，用户最直接诉求的来自数据安全性即备份，而迁移、恢复、高可靠等都是基于备份表现出的业务形态，而备份能力可能是由云原生能力提供的，也有可能是第三方能力提供的，但最终实现业务形态，是由编排产生的。

用户上云并不等于高枕无忧，相反用户要学习云的正确打开方式，才能最大程度来保证业务的连续性。虽然云在底层设计上是高可靠的，但是仍然避免不了外力造成的影响，例如：光缆被挖断、断电、人为误操作导致的云平台可用区无法使用，所以才有了类似“蓝翔决定了中国云计算稳定性”的调侃。我认为用户决定将业务迁移到云上的那一刻开始，备份、迁移、恢复、高可靠是一个连续的过程，如何合理利用云原生服务的特性实现业务连续性，同时进行成本优化，降低总体拥有成本（TCO）。

3）防止厂商锁定

某种意义上说，云原生的方向是新一轮厂商锁定，就像当年盛极一时的 IOE 架构一样，只不过现在换成了云厂商作为底座承载应用。在 IOE 时代，用户很难找到完美的替代品，但是在云时代，这种差异并不那么明显。所以大部分的客户通常选用混合云作为云建设策略，为了让应用在不同云之间能够平滑移动，利用容灾技术的迁移一定是作为一个常态化需求存在的。Gartnar 也在多云管平台定义中，将迁移和 DR 作为单独的一项能力。充分说明迁移与容灾在多云环境的的常态化趋势。

云迁移与云容灾的关系

1. 云迁移需求的产生

在传统环境下，迁移的需求并不十分突出，除非是遇到机房搬迁或者硬件升级，才会想到迁移，但这里的迁移更像是搬铁，迁移工具化与自动化的需求并不明显。当 VMware 出现后，从物理环境到虚拟化的迁移需求被放大，但由于是单一的虚拟化平台，基本上虚拟化厂商自身的工具就完全能够满足需求了。在虚拟化平台上，大家突然发现原来只能人工操作的物理环境一下子轻盈起来，简单来说，我们的传统服务器从一堆铁变成了一个文件，并且这个文件还能够被来回移动、复制。再后来，进入云时代，各家云平台风生水起，国内云计算市场更是百家争鸣，上云更是成为了一种刚性需求。随着时间的推移，出于对成本、厂商锁定等诸多因素的影响，在不同云之间的互相迁移更是会成为一种常态化的需求。

2. 底层技术一致

这里提到的云迁移和容灾，并不是堆人提供的迁移服务，而是强调的高度自动化的手段。目标就是在迁移过程中保证业务连续性，缩短停机时间甚至不停机的效果。这里就借助了容灾的存储级别同步技术来实现在异构环境下的的“热迁移”。现有解决方案里，既有传统物理机搬迁时代的迁移软件，也有基于云原生开发的工具。但无论何种形式，都在不同程度上都解决了用户上云的基本诉求。最大的区别在于人效比，这一点与你的利益直接相关。

从另外一个角度也不难发现，所谓的迁移在正式切换之前实质上就是容灾的中间过程。同时，业务系统迁移到云平台后，灾备是一个连续的动作，这里既包含了传统的备份和容灾，还应该包含云上高可靠的概念。这样，用户业务系统在上云后，才能摆脱传统基础架构的负担，做到“零运维”，真正享受到云所带来的的红利。所以，我认为在云原生状态下，云迁移、云容灾、云备份本质上就是一种业务形态，底层采用的技术手段可以是完全一致的。

3. 发展方向

在上述的痛点和趋势下，必然会出现一种全新的平台来帮助客户解决数据的安全性和业务连续性问题，今天就从这个角度来分析一下，在云原生的趋势下如何构建应用系统的迁移与容灾方案。

云迁移发展趋势

1. 云迁移方式

迁移是一项重度的咨询业务，网上各家云商、MSP 都有自己的方法论，其实看下来差别都不大，之前也有很多人在分享相关话题，本文就不再赘述。这里我们重点讨论，在实际落地过程中到底该采用哪种工具，哪种方式的效率最高。所谓云迁移工具，就是将源端迁移至目标端，保证源端在目标端正确运行。常见的方式包括：物理机到虚拟化、虚拟化到虚拟化、物理机到云平台、虚拟化到云平台等。

这是经典的 6R 迁移理论（现在已经升级为了 7R，多了 VMware 出来搅局），在这个图中与真正迁移相关的其实只有 Rehosting、Replatforming、Repurchasing 和 Refactoring，但是在这 4R 中，Refactoring 明显是一个长期的迭代过程，需要用户和软件开发商共同参与解决，Repurchasing 基本上与人为重新部署没有太大的区别。所以真正由用户或 MSP 在短期完成的只剩下 Rehosting 和 Replatofrming。

与上面这张经典的迁移理论相比，我更喜欢下面这张图，这张图更能反应一个传统应用到云原生成长的全过程。与上述的结论相似，我们在真正拥抱云的时候，路径基本为上述的三条：

• Lift & Shift 是 Rehost 方式的另一种称呼，这种方式路面最宽，寓意这条路是上云的最短路径，应用不需要任何改造直接上云使用。

• Evolve 和 Go Native 都属于较窄的路径，寓意为相对于 Rehost 方式，这两条路径所消耗的时间更久，难度更高。

• 在图的最右侧，三种形态是存在互相转换的可能，最终演进为彻底的云原生，寓意为迁移并不是一蹴而就，需要循序渐进完成。

2. 重新托管（Rehost）方式

常用的重新托管方式为冷迁移和热迁移，冷迁移往往涉及到步骤比较繁琐，需要大量人力投入，并且容易出错效率低，对业务连续性有较大的影响，不适合生产系统迁移。而热迁移方案基本都是商用化的解决方案，这里又分为块级别和文件级别，再细分为传统方案与云原生方案。

1）冷迁移

我们先来看一下冷迁移的手动方案，以 VMware 到 OpenStack 为例，最简单的方式就是将 VMware 虚拟机文件（VMDK）通过 qemu-img 工具进行格式转换，转换为 QCOW2 或者 RAW 格式，上传至 OpenStack Glance 服务，再重新在云平台上进行启动。当然这里面需要进行 virtio 驱动注入，否则主机无法正常在云平台启动。这个过程中最耗时的应该是虚拟机文件上传至 OpenStack Glance 服务的过程，在我们最早期的实践中，一台主机从开始迁移到启动完成足足花了 24 小时。同时，在你迁移这段时间的数据是有增量产生的，除非你将源端关机等待迁移完成，否则，你还要将上述步骤重新来一遍。所以说这种方式真的不适合有业务连续性的生产系统进行迁移。

那如果是物理机的冷迁移方案怎么做呢？经过我们的最佳实践，这里为大家推荐的是老牌的备份工具 CloneZilla，中文名为再生龙。是一款非常老牌的备份软件，常用于进行整机备份与恢复，与我们常见的 Norton Ghost 原理非常相似。CloneZilla 从底层的块级别进行复制，可以进行整盘的备份，并且支持多种目标端，例如我们将磁盘保存至移动硬盘，实际格式就是 RAW，你只需要重复上述的方案即可完成迁移。但是在使用 CloneZilla 过程中，需要使用 Live CD 方式进行引导，同样会面临长时间业务系统中断的问题，这也是上面我们提到的冷迁移并不适合生产环境迁移的原因。

2）传统热迁移方案

传统的热迁移方案基本分为块级别和文件级别，两者相似之处都是利用差量同步技术进行实现，即全量和增量交叉同步方式。

文件级别的热迁移方案往往局限性较大，并不能算真正的 ReHost 方式，因为前期需要准备于源端完全一样的操作系统，无法实现整机搬迁，从操作的复杂性更大和迁移的稳定性来说都不高。我们在 Linux 上常用的 Rsync 其实可以作为文件级别热迁移的一种解决方案。

真正可以实现热迁移的方案，还要使用块级别同步，降低对底层操作系统依赖，实现整机的搬迁效果。传统的块级别热迁移方案基本上来自于传统容灾方案的变种，利用内存操作系统 WIN PE 或其他 Live CD 实现，基本原理和过程如下图所示。从过程中我们不难发现这种方式虽然在一定程度解决了迁移的目标，但是作为未来混合云常态化迁移需求来说，仍然有以下几点不足：

• 由于传统热迁移方案是基于物理环境构建的，所以我们发现在整个过程中人为介入非常多，对于使用者的技能要求比较高

• 无法满足云原生时代多租户、自服务的需求

• 安装代理是用户心中永远的芥蒂

• 一比一同步方式，从成本角度来说不够经济

• 最好的迁移验证方式，就是将业务系统集群在云端完全恢复，但是手动验证的方式，对迁移人力成本是再一次增加

3）云原生热迁移方案

正是由于传统迁移方案的弊端，应运而生了云原生的热迁移方案，这一方面的代表厂商当属 AWS 在 2019 年以 2.5 亿美金击败 Google Cloud 收购的以色列云原生容灾、迁移厂商 CloudEndure。

云原生热迁移方案是指利用块级别差量同步技术结合云原生 API 接口和资源实现高度自动化迁移效果，同时提供多租户、API 接口满足混合云租户自服务的需求。我们先从原理角度分析一下，为什么相对于传统方案，云原生的方式能够满足高度自动化、用户自服务的用户体验。通过两个方案对比，我们不难发现云原生方式的几个优势：

• 利用云原生 API 接口和资源，操作简便，完全取代了传统方案大量繁琐的人为操作，对使用者技术要求降低，学习陡峭程度大幅度降低

• 由于操作简便，迁移效率提高，有效提高迁移实施的人效比

• 一对多的同步方式，大幅度降低计算资源使用，计算资源只在验证和最终切换时使用

• 能够满足多租户、自服务的要求

• 源端也可以支持无代理方式，打消用户疑虑，并且适合大规模批量迁移

• 高度自动化的验证手段，在完成迁移切换前，能够反复进行验证

这是 CloudEndure 的架构图，当然你也可以利用 CloudEndure 实现跨区域的容灾。

不过可惜的一点是由于被 AWS 收购，CloudEndure 目前只能支持迁移至 AWS，无法满足国内各种云迁移的需求。所以这里为大家推荐一款纯国产化的迁移平台——万博智云的 HyperMotion，从原理上与 CloudEndure 非常相似，同时支持了 VMware 及 OpenStack 无代理的迁移，更重要的是覆盖了国内主流的公有云、专有云和私有云的迁移。

3. 平台重建（Replatforming）方式

随着云原生提供越来越多的服务，降低了应用架构的复杂度，使得企业能够更专注自己的业务本身开发。但是研发侧工作量的减少意味着这部分成本被转嫁到部署及运维环节，所以 DevOps 成为在云原生运用中比不可少的一个缓解，也让企业能够更敏捷的应对业务上的复杂变化。

正如上面所提到的，用户通过少量的改造可以优先使用一部分云原生服务，这种迁移方式我们成为平台重建（Replatforming），目前选择平台重建方式的迁移，多以与用户数据相关的服务为主。常见的包括：数据库服务 RDS、对象存储服务、消息队列服务、容器服务等。这些云原生服务的引入，降低了用户运维成本。但是由于云原生服务自身封装非常严密，底层的基础架构层对于用户完全不可见，所以无法用上述 Rehost 方式进行迁移，必须采用其他的辅助手段完成。

以关系型数据库为例，每一种云几乎都提供了迁移工具，像 AWS DMS，阿里云的 DTS，腾讯云的数据传输服务 DTS，这些云原生工具都可以支持 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多种关系型数据库及 NoSQL 数据库迁移。以 MySQL 为例，这些服务都巧妙的利用了 binlog 复制的方式，实现了数据库的在线迁移。

再以对象存储为例，几乎每一种云都提供了自己的迁移工具，像阿里云的 ossimport，腾讯云 COS Migration 工具，都可以实现本地到云端对象存储的增量迁移。但是在实际迁移时，还应考虑成本问题，公有云的对象存储在存储数据上比较便宜，但是在读出数据时是要根据网络流量和请求次数进行收费的，这就要求我们在设计迁移方案时，充分考虑成本因素。如果数据量过大，还可以考虑采用离线设备方式，例如：AWS 的 Snowball，阿里云的闪电立方等。这部分就不展开介绍，以后有机会再单独为大家介绍。

如果选择平台重建方式上云，除了要进行必要的应用改造，还需要选择一款适合你的迁移工具，保证数据能够平滑上云。结合上面的 Rehost 方式迁移，能够实现业务系统的整体上云效果。由于涉及的服务较多，这里为大家提供一张迁移工具表格供大家参考。

云原生下的容灾发展趋势

目前为止，还没有一套平台能够完全满足云原生状态下的统一容灾需求，我们通过以下场景来分析一下，如何才能构建一套统一的容灾平台满足云原生的需求。

1. 传统架构

我们以一个简单的 Wordpress + MySQL 环境为例，传统下的部署环境一般是这样架构的：

如果为这套应用架构设计一套容灾方案，可以采用以下的方式：

1）负载均衡节点容灾

负载均衡分为硬件和软件层面，硬件负载均衡高可靠和容灾往往通过自身的解决方案实现。如果是软件负载均衡，往往需要安装在基础操作系统上，而同城的容灾可以使用软件高可靠的方式实现，而异地的容灾往往是通过提前建立对等节点，或者干脆采用容灾软件的块或者文件级别容灾实现。是容灾切换（Failover）很重要的一个环节。

2）Web Server 的容灾

Wordpress 的运行环境无非是 Apache + PHP，由于分离了用于存放用户上传的文件系统，所以该节点几乎是无状态的，通过扩展节点即可实现高可靠，而异地容灾也比较简单，传统的块级别和文件级别都可以满足容灾的需求。

3）共享文件系统的容灾

图中采用了 Gluster 的文件系统，由于分布式系统的一致性通常由内部维护，单纯使用块级别很难保证节点的一致性，所以这里面使用文件级别容灾更为精确。

4）数据库的容灾

单纯依靠存储层面是无法根本实现数据库 0 丢失数据的，所以一般采用从数据库层面实现，当然如果为了降低成本，数据库的容灾可以简单的使用周期 Dump 数据库的方式实现，当然如果对可靠性要求较高，还可以使用 CDP 方式实现。

从以上的案例分析不难看出，传统基础架构下的容灾往往以存储为核心，无论是磁盘阵列的存储镜像，还是基于 I/O 数据块、字节级的捕获技术，结合网络、数据库和集群的应用级别技术完成高可靠和容灾体系的构建。在整个容灾过程的参与者主要为：主机、存储、网络和应用软件，相对来说比较单一。所以在传统容灾方案中，如何正确解决存储的容灾也就成为了解决问题的关键。

2. 混合云容灾

这应该是目前最常见的混合云的方案，也是各大容灾厂商主推的一种方式。这里我们相当于将云平台当成了一套虚拟化平台，几乎没有利用云平台任何特性。在恢复过程中，需要大量人为的接入才能将业务系统恢复到可用状态。这样的架构并不符合云上的最佳实践，但的确是很多业务系统备份或迁移上云后真实的写照。

这样的架构确实能解决容灾的问题，但是从成本上来说很高，现在我们来换一种方式。我们利用了对象存储和数据库进行一次优化。我们将原有存储服务存放至对象存储中，而使用数据传输服务来进行实时的数据库复制。云主机仍然采用传统的块级别进行同步。一旦出现故障，则需要自动化编排能力，重新将备份进行恢复，在最短时间内根据我们预设的方案进行恢复，完成容灾。

3. 云上同城容灾架构

上述的备份方式，实质上就是利用平台重建的方式进行的迁移，既然已经利用迁移进行了备份，那完全可以对架构进行如下改造，形成同城的容灾架构。我们根据云平台的最佳实践，对架构进行了如下调整：

这个架构不仅实现了应用级高可靠，还能够支撑一定的高并发性，用户在最少改造代价下就能够在同城实现双活的效果。我们来分析一下在云上利用了多少云原生的服务：

• 域名解析服务
• VPC 服务
• 负载均衡服务
• 自动伸缩服务
• 云主机服务
• 对象存储服务
• 关系型数据库 RDS 服务

除了云主机外，其他服务均是天然就支持跨可用区的高可用特性，对于云主机我们可以制作镜像方式，由自动伸缩服务负责实例的状态。由于云上可用区就是同城容灾的概念，这里我们就实现了同城的业务系统容灾。

经过调整的架构在一定程度上满足了业务连续性的要求，但是对于数据的安全性仍然缺乏保障。近几年，勒索病毒横行，大量企业为此蒙受巨大损失，所以数据备份是上云后必须实施的。云原生服务本身提供了备份方案，例如云主机的定期快照等，但往往服务比较分散，不容易统一进行管理。同时，在恢复时往往也是只能每一个服务进行恢复，如果业务系统规模较大，也会增加大量的恢复成本。虽然云原生服务解决了自身备份问题，但是将备份重新组织成应用是需要利用自动化的编排能力实现。

4. 同云异地容灾架构

大部分的云原生服务都在可用区内，提供了高可靠能力，但是对于跨区域上通常提供的是备份能力。例如：可以将云主机变为镜像，将镜像复制到其他区域内；关系型数据库和对象存储也具备跨域的备份能力。利用这些组件自身的备份能力，外加上云自身资源的编排能力，我们可以实现在容灾可用域将系统恢复至可用状态。那如何触发切换呢？

这里我们根据业务系统的特点，在云原生的监控上定制告警，利用告警平台的触发能力触发函数计算，完成业务系统的跨域切换，形成异地容灾的效果。

5. 跨云容灾

但跨云容灾不像同云容灾时，在不同的可用区之间至少服务是一致的，那么此时，在同云上使用的方法基本失效，完全需要目标云平台的能力或者中立的第三方的解决方案。这里除了数据的备份，还有一点是服务配置的互相匹配。才能完全满足跨云容灾恢复的需求。另外需要考虑的一点就是成本为例，以对象存储为例，是典型的的“上云容易下云难”。所以如何利用云原生资源特性合理设计容灾方案是对成本的极大考验。

总结

云原生容灾还处于早期阶段，目前尚没有完整的平台能够支持以上各种场景的容灾需求，是值得持续探索的话题。云原生容灾以备份为核心，以迁移、恢复和高可靠为业务场景，实现多云之间的自由流转，最终满足用户的业务需求。

所以，作为面向云原生的容灾平台要解决好三方面的能力：

• 以数据为核心，让数据在多云之间互相流转。数据是用户核心价值，所以无论底层基础架构如何变化，数据备份一定是用户的刚醒需求。对于不同云原生服务如何解决好数据备份，是数据流转的必要基础。

• 利用云原生编排能力，实现高度自动化，在数据基础上构建业务场景。利用自动化编排能力实现更多的基于数据层的应用，帮助用户完成更多的业务创新。

• 灵活运用云原生资源特点，降低总体拥有成本。解决传统容灾投入巨大的问题，让用户的成本真的能像水、电一样按需付费。