作者 | 孙琦
导读：下一个云原生颠覆的畛域会不会是在传统的容灾畛域呢？在云原生的趋势下，如何构建利用零碎的迁徙与容灾计划？
趋势
- 云原生发展趋势
云原生（Cloud Native）是最近几年十分火爆的话题，在 2020 年 7 月由信通院公布的《云原生倒退白皮书（2020）年》明确指出：云计算的拐点已到，云原生成为驱动业务增长的重要引擎。咱们不难发现云原生带给 IT 产业一次从新洗牌，从利用开发过程到 IT 从业者的技术能力，都是一次颠覆性的反动。在此基础上，呈现了基于云原生平台的 Open Application Model 定义，在云原生平台根底上进一步形象，更加关注利用而非基础架构。同时，越来越多的私有云开始反对 Serverless 服务，更加阐明了将来的发展趋势：利用为外围，轻量化基础架构层在零碎建设过程中的角色。然而无论如何变动，IT 整体倒退方向，肯定是向着更有利于业务疾速迭代、满足业务需要方向演进的。
2020 年 9 月，Snowflake 以每股 120 美金 IPO，发明了往年规模最大的 IPO，也是有史以来最大的软件 IPO。Snowflake 利用云原生形式重构了数据仓库，胜利颠覆了行业竞争格局。这正是市场对云原生发展趋势的最佳认可，所以下一个云原生颠覆的畛域会不会是在传统的容灾畛域呢？
- 为什么云上须要全新的迁徙和容灾？
1）传统计划的局限性
在这种大的趋势下，传统的迁徙和容灾依然停留在数据搬运的档次上，而疏忽了面向云的个性和用户业务从新思考和构建。云计算的愿景是让云资源像水、电一样按需应用，所以基于云上的迁徙和容灾也理当适应这样的历史潮流。Snowflake 也是通过这种商业模式的翻新，胜利打破旧的竞争格局。
为什么传统容灾的伎俩无奈满足云原生需要呢？简略来说，二者关注的外围不同。传统的容灾往往以存储为外围，领有对存储的至高无上的控制权。并且在物理时代，对于计算、存储和网络等基础架构层也没有无效的调度办法，无奈实现高度自动化的编排。而基于云原生构建的利用，外围变成了云原生服务自身。当用户业务零碎全面上云后，用户不再享有对底层存储的相对控制权，所以传统的容灾伎俩，就风光不在了。
我认为在构建云原生容灾的解决方案上，要以业务为外围去思考构建办法，利用云原生服务的编排能力实现业务零碎的连续性。
2）数据安全性
AWS CTO Werner Vogels 已经说过：Everything fails, all the time。通过 AWS 的责任共担模型，咱们不难发现云商对底层基础架构负责，用户依然要对本身本身数据安全性和业务连续性负责。
我认为在云原生趋势下，用户最间接诉求的来自数据安全性即备份，而迁徙、复原、高牢靠等都是基于备份体现出的业务状态，而备份能力可能是由云原生能力提供的，也有可能是第三方能力提供的，但最终实现业务状态，是由编排产生的。
用户上云并不等于居安思危，相同用户要学习云的正确打开方式，能力最大水平来保障业务的连续性。尽管云在底层设计上是高牢靠的，然而依然防止不了外力造成的影响，例如：光缆被挖断、断电、人为误操作导致的云平台可用区无奈应用，所以才有了相似“蓝翔决定了中国云计算稳定性”的调侃。我认为用户决定将业务迁徙到云上的那一刻开始，备份、迁徙、复原、高牢靠是一个间断的过程，如何正当利用云原生服务的个性实现业务连续性，同时进行老本优化，升高总体领有老本（TCO）。
3）避免厂商锁定
某种意义上说，云原生的方向是新一轮厂商锁定，就像当年盛极一时的 IOE 架构一样，只不过当初换成了云厂商作为底座承载利用。在 IOE 时代，用户很难找到完满的替代品，然而在云时代，这种差别并不那么显著。所以大部分的客户通常选用混合云作为云建设策略，为了让利用在不同云之间可能平滑挪动，利用容灾技术的迁徙肯定是作为一个常态化需要存在的。Gartnar 也在多云管平台定义中，将迁徙和 DR 作为独自的一项能力。充分说明迁徙与容灾在多云环境的的常态化趋势。
云迁徙与云容灾的关系
- 云迁徙需要的产生
在传统环境下，迁徙的需要并不非常突出，除非是遇到机房搬迁或者硬件降级，才会想到迁徙，但这里的迁徙更像是搬铁，迁徙工具化与自动化的需要并不显著。当 VMware 呈现后，从物理环境到虚拟化的迁徙需要被放大，但因为是繁多的虚拟化平台，基本上虚拟化厂商本身的工具就齐全可能满足需要了。在虚拟化平台上，大家忽然发现原来只能人工操作的物理环境一下子轻捷起来，简略来说，咱们的传统服务器从一堆铁变成了一个文件，并且这个文件还可能被来回挪动、复制。再起初，进入云时代，各家云平台风生水起，国内云计算市场更是百家争鸣，上云更是成为了一种刚性需要。随着工夫的推移，出于对老本、厂商锁定等诸多因素的影响，在不同云之间的相互迁徙更是会成为一种常态化的需要。
- 底层技术统一
这里提到的云迁徙和容灾，并不是堆人提供的迁徙服务，而是强调的高度自动化的伎俩。指标就是在迁徙过程中保障业务连续性，缩短停机工夫甚至不停机的成果。这里就借助了容灾的存储级别同步技术来实现在异构环境下的的“热迁徙”。现有解决方案里，既有传统物理机搬迁时代的迁徙软件，也有基于云原生开发的工具。但无论何种模式，都在不同水平上都解决了用户上云的根本诉求。最大的区别在于人效比，这一点与你的利益间接相干。
从另外一个角度也不难发现，所谓的迁徙在正式切换之前本质上就是容灾的两头过程。同时，业务零碎迁徙到云平台后，灾备是一个间断的动作，这里既蕴含了传统的备份和容灾，还应该蕴含云上高牢靠的概念。这样，用户业务零碎在上云后，能力解脱传统基础架构的累赘，做到“零运维”，真正享受到云所带来的的红利。所以，我认为在云原生状态下，云迁徙、云容灾、云备份实质上就是一种业务状态，底层采纳的技术手段能够是完全一致的。
- 倒退方向
在上述的痛点和趋势下，必然会呈现一种全新的平台来帮忙客户解决数据的安全性和业务连续性问题，明天就从这个角度来剖析一下，在云原生的趋势下如何构建利用零碎的迁徙与容灾计划。
云迁徙发展趋势
- 云迁徙形式
迁徙是一项重度的征询业务，网上各家云商、MSP 都有本人的方法论，其实看下来差异都不大，之前也有很多人在分享相干话题，本文就不再赘述。这里咱们重点探讨，在理论落地过程中到底该采纳哪种工具，哪种形式的效率最高。所谓云迁徙工具，就是将源端迁徙至指标端，保障源端在指标端正确运行。常见的形式包含：物理机到虚拟化、虚拟化到虚拟化、物理机到云平台、虚拟化到云平台等。
这是经典的 6R 迁徙实践（当初曾经降级为了 7R，多了 VMware 进去搅局），在这个图中与真正迁徙相干的其实只有 Rehosting、Replatforming、Repurchasing 和 Refactoring，然而在这 4R 中，Refactoring 显著是一个长期的迭代过程，须要用户和软件开发商独特参加解决，Repurchasing 基本上与人为重新部署没有太大的区别。所以真正由用户或 MSP 在短期实现的只剩下 Rehosting 和 Replatofrming。
与下面这张经典的迁徙实践相比，我更喜爱上面这张图，这张图更能反馈一个传统利用到云原生成长的全过程。与上述的论断类似，咱们在真正拥抱云的时候，门路根本为上述的三条：
- Lift & Shift 是 Rehost 形式的另一种称说，这种形式路面最宽，寓意这条路是上云的最短门路，利用不须要任何革新间接上云应用。
- Evolve 和 Go Native 都属于较窄的门路，寓意为绝对于 Rehost 形式，这两条门路所耗费的工夫更久，难度更高。
- 在图的最右侧，三种状态是存在相互转换的可能，最终演进为彻底的云原生，寓意为迁徙并不是欲速不达，须要循序渐进实现。
- 从新托管（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 无代理的迁徙，更重要的是笼罩了国内支流的私有云、专有云和公有云的迁徙。
- 平台重建（Replatforming）形式
随着云原生提供越来越多的服务，升高了利用架构的复杂度，使得企业可能更专一本人的业务自身开发。然而研发侧工作量的缩小意味着这部分老本被转嫁到部署及运维环节，所以 DevOps 成为在云原生使用中比不可少的一个缓解，也让企业可能更麻利的应答业务上的简单变动。
正如下面所提到的，用户通过大量的革新能够优先应用一部分云原生服务，这种迁徙形式咱们成为平台重建（Replatforming），目前抉择平台重建形式的迁徙，多以与用户数据相干的服务为主。常见的包含：数据库服务 RDS、对象存储服务、音讯队列服务、容器服务等。这些云原生服务的引入，升高了用户运维老本。然而因为云原生服务本身封装十分紧密，底层的基础架构层对于用户齐全不可见，所以无奈用上述 Rehost 形式进行迁徙，必须采纳其余的辅助伎俩实现。
以关系型数据库为例，每一种云简直都提供了迁徙工具，像 AWS DMS，阿里云的 DTS，腾讯云的数据传输服务 DTS，这些云原生工具都能够反对 MySQL、MariaDB、PostgreSQL、Redis、MongoDB 等多种关系型数据库及 NoSQL 数据库迁徙。以 MySQL 为例，这些服务都奇妙的利用了 binlog 复制的形式，实现了数据库的在线迁徙。
再以对象存储为例，简直每一种云都提供了本人的迁徙工具，像阿里云的 ossimport，腾讯云 COS Migration 工具，都能够实现本地到云端对象存储的增量迁徙。然而在理论迁徙时，还应思考老本问题，私有云的对象存储在存储数据上比拟便宜，然而在读出数据时是要依据网络流量和申请次数进行免费的，这就要求咱们在设计迁徙计划时，充分考虑老本因素。如果数据量过大，还能够思考采纳离线设施形式，例如：AWS 的 Snowball，阿里云的闪电立方等。这部分就不开展介绍，当前有机会再独自为大家介绍。
如果抉择平台重建形式上云，除了要进行必要的利用革新，还须要抉择一款适宜你的迁徙工具，保证数据可能平滑上云。联合下面的 Rehost 形式迁徙，可能实现业务零碎的整体上云成果。因为波及的服务较多，这里为大家提供一张迁徙工具表格供大家参考。
云原生下的容灾发展趋势
目前为止，还没有一套平台可能齐全满足云原生状态下的对立容灾需要，咱们通过以下场景来剖析一下，如何能力构建一套对立的容灾平台满足云原生的需要。
- 传统架构
咱们以一个简略的 WordPress + MySQL 环境为例，传统下的部署环境个别是这样架构的：
如果为这套利用架构设计一套容灾计划，能够采纳以下的形式：
1）负载平衡节点容灾
负载平衡分为硬件和软件层面，硬件负载平衡高牢靠和容灾往往通过本身的解决方案实现。如果是软件负载平衡，往往须要装置在根底操作系统上，而同城的容灾能够应用软件高牢靠的形式实现，而异地的容灾往往是通过提前建设对等节点，或者罗唆采纳容灾软件的块或者文件级别容灾实现。是容灾切换（Failover）很重要的一个环节。
2）Web Server 的容灾
WordPress 的运行环境无非是 Apache + PHP，因为拆散了用于寄存用户上传的文件系统，所以该节点简直是无状态的，通过扩大节点即可实现高牢靠，而异地容灾也比较简单，传统的块级别和文件级别都能够满足容灾的需要。
3）共享文件系统的容灾
图中采纳了 Gluster 的文件系统，因为分布式系统的一致性通常由外部保护，单纯应用块级别很难保障节点的一致性，所以这外面应用文件级别容灾更为准确。
4）数据库的容灾
单纯依附存储层面是无奈基本实现数据库 0 失落数据的，所以个别采纳从数据库层面实现，当然如果为了降低成本，数据库的容灾能够简略的应用周期 Dump 数据库的形式实现，当然如果对可靠性要求较高，还能够应用 CDP 形式实现。
从以上的案例剖析不难看出，传统基础架构下的容灾往往以存储为外围，无论是磁盘阵列的存储镜像，还是基于 I/O 数据块、字节级的捕捉技术，联合网络、数据库和集群的利用级别技术实现高牢靠和容灾体系的构建。在整个容灾过程的参与者次要为：主机、存储、网络和应用软件，相对来说比拟繁多。所以在传统容灾计划中，如何正确解决存储的容灾也就成为了解决问题的要害。
- 混合云容灾
这应该是目前最常见的混合云的计划，也是各大容灾厂商主推的一种形式。这里咱们相当于将云平台当成了一套虚拟化平台，简直没有利用云平台任何个性。在复原过程中，须要大量人为的接入能力将业务零碎复原到可用状态。这样的架构并不合乎云上的最佳实际，但确实是很多业务零碎备份或迁徙上云后实在的写照。
这样的架构的确能解决容灾的问题，然而从老本上来说很高，当初咱们来换一种形式。咱们利用了对象存储和数据库进行一次优化。咱们将原有存储服务寄存至对象存储中，而应用数据传输服务来进行实时的数据库复制。云主机依然采纳传统的块级别进行同步。一旦呈现故障，则须要自动化编排能力，从新将备份进行复原，在最短时间内依据咱们预设的计划进行复原，实现容灾。
- 云上同城容灾架构
上述的备份形式，本质上就是利用平台重建的形式进行的迁徙，既然曾经利用迁徙进行了备份，那齐全能够对架构进行如下革新，造成同城的容灾架构。咱们依据云平台的最佳实际，对架构进行了如下调整：
这个架构不仅实现了利用级高牢靠，还可能撑持肯定的高并发性，用户在起码革新代价下就可能在同城实现双活的成果。咱们来剖析一下在云上利用了多少云原生的服务：
- 域名解析服务
- VPC 服务
- 负载平衡服务
- 主动伸缩服务
- 云主机服务
- 对象存储服务
- 关系型数据库 RDS 服务
除了云主机外，其余服务均是人造就反对跨可用区的高可用个性，对于云主机咱们能够制作镜像形式，由主动伸缩服务负责实例的状态。因为云上可用区就是同城容灾的概念，这里咱们就实现了同城的业务零碎容灾。
通过调整的架构在肯定水平上满足了业务连续性的要求，然而对于数据的安全性依然不足保障。近几年，勒索病毒横行，大量企业为此遭受巨大损失，所以数据备份是上云后必须施行的。云原生服务自身提供了备份计划，例如云主机的定期快照等，但往往服务比拟扩散，不容易对立进行治理。同时，在复原时往往也是只能每一个服务进行复原，如果业务零碎规模较大，也会减少大量的复原老本。尽管云原生服务解决了本身备份问题，然而将备份从新组织成利用是须要利用自动化的编排能力实现。
- 同云异地容灾架构
大部分的云原生服务都在可用区内，提供了高牢靠能力，然而对于跨区域上通常提供的是备份能力。例如：能够将云主机变为镜像，将镜像复制到其余区域内；关系型数据库和对象存储也具备跨域的备份能力。利用这些组件本身的备份能力，外加上云本身资源的编排能力，咱们能够实现在容灾可用域将零碎复原至可用状态。那如何触发切换呢？
这里咱们依据业务零碎的特点，在云原生的监控上定制告警，利用告警平台的触发能力触发函数计算，实现业务零碎的跨域切换，造成异地容灾的成果。
- 跨云容灾
但跨云容灾不像同云容灾时，在不同的可用区之间至多服务是统一的，那么此时，在同云上应用的办法根本生效，齐全须要指标云平台的能力或者中立的第三方的解决方案。这里除了数据的备份，还有一点是服务配置的相互匹配。能力齐全满足跨云容灾复原的需要。另外须要思考的一点就是老本为例，以对象存储为例，是典型的的“上云容易下云难”。所以如何利用云原生资源个性正当设计容灾计划是对老本的极大考验。
总结
云原生容灾还处于晚期阶段，目前尚没有残缺的平台可能反对以上各种场景的容灾需要，是值得继续摸索的话题。云原生容灾以备份为外围，以迁徙、复原和高牢靠为业务场景，实现多云之间的自在流转，最终满足用户的业务需要。
所以，作为面向云原生的容灾平台要解决好三方面的能力：
- 以数据为外围，让数据在多云之间相互流转。数据是用户外围价值，所以无论底层基础架构如何变动，数据备份肯定是用户的刚醒需要。对于不同云原生服务如何解决好数据备份，是数据流转的必要根底。
- 利用云原生编排能力，实现高度自动化，在数据根底上构建业务场景。利用自动化编排能力实现更多的基于数据层的利用，帮忙用户实现更多的业务翻新。
- 灵活运用云原生资源特点，升高总体领有老本。解决传统容灾投入微小的问题，让用户的老本真的能像水、电一样按需付费。
原文链接
本文为阿里云原创内容，未经容许不得转载。