AWS在2019年1月收购了一家名为CloudEndure的以色列初创公司，这家公司主要的产品是提供本地数据中心和公有云、以及不同的公有云之间的迁移和容灾的解决方案。被AWS收购之后，AWS的合作伙伴或者用户可以利用CloudEndure来实现多种迁移／容灾需求：

• 本地数据中心／其他公有云到AWS的迁移；

• 本地数据中心和AWS之间的容灾；

• AWS不同区域之间的迁移；

• AWS不同区域之间的容灾。

相比其他开源或者商业的迁移／容灾工具，CloudEndure（以下简称CE）是一款非常优秀的产品，主要体现在以下几个方面：

• 操作简单，自动化程度高，降低了迁移和容灾的复杂度；

• 广泛的适用性，可以支持物理主机、虚机和云主机，只要操作系统满足Agent安装条件并且Agent可以访问CE服务器即可；

• 基于操作系统的连续数据块级复制，使得容灾的RPO非常小（一般为毫秒级），RTO为分钟级；

• 数据复制时占用云端的资源少，降低了容灾的运行成本。

值得一提的是，目前使用CE进行系统迁移是免费的，AWS合作伙伴和用户可以在网站：https://migration-register.cloudendure.com/上申请到免费的CE Migration License和供测试用的DR License。申请到的DR license仅供测试用，如果用在实际生产上则需要购买。

下图是CE做容灾的架构，可以看到，CE的服务器部署在云端，提供类似于SAAS的服务方式。用户通过CE User Console进行配置和执行数据同步、切换、回切等操作，CE服务器通过API在AWS云上创建复制服务器（Replication Server）实例和容灾目标实例（Target instance）。

客户本地数据中心或AWS云上的源服务器需要安装CE Agent，Agent安装后会启动源盘和复制服务器的数据全同步，并驻留在系统内存内实时监控所有对源盘的数据块更新，经过压缩和加密后复制到复制服务器。

本文中我通过一个模拟示例来说明如何利用CE来实现跨AWS 区域的容灾。对于需要使用CE做系统迁移的用户来说，可以参考此示例中从添加Project到Recovery Mode切换之间的步骤，这些步骤和迁移的过程是完全相同的，区别只在于使用的License是Migration或DR。

对于需要使用CE来做本地数据中心到AWS云的容灾的用户来说，也可以参考此示例，大部分过程是相同的，最大的区别在于回切时本地数据中心服务器需要下载一个failback client来引导启动服务器，并输入相关配置信息启动云端复制服务器到本地服务器的数据复制。

下面是这个示例的环境。容灾的源服务器位于AWS Singapore区域，有两台服务器，一台是App服务器，一台是DB服务器，分别位于VPC-1（CIDR 10.0.0.0/16）的公网段和私网段，每个服务器都有一个root卷和一个data卷。VPC-1内还有另一个私网段作为复制服务器所在的网段。容灾的目标位于AWS Seoul区域，在此区域的VPC-2（CIDR 20.0.0.0/16）也同样有一个公网段和两个私网段。VPC-1和VPC-2通过跨区域的 VPC Peering打通网络，使得源端和目标端的数据复制可以通过AWS的骨干网，而不必通过Internet。

另外，我在公网段中建了NAT 网关，并且在私网段的路由表中将对Internet的出站访问设为通过NAT网关，DB服务器上的CE agent通过此方式访问CE服务器。

由于CE的服务器位于云端，在容灾过程中源端的CE Agent需要通过TCP 443端口访问CE服务器，目标端的复制服务器也需要通过TCP 443端口去访问CE服务器和存放复制软件的S3桶以及本区域的EC2 endpoint。Agent和复制实例的数据复制是通过TCP 1500端口进行的。因此，安全组的设置非常重要，你需要配置正确的安全组以确保这些访问可以进行。下图是本示例中安全组的设置，这些设置已经考虑到了切换和回切的网络要求。

在AWS Console上，可以看到新加坡区域的APP和DB服务器处于活动状态。

首先，通过https://migration-register.cloudendure.com/ 上申请到的账号和密码，登录CE Console: https://console.cloudendure.com。

在左上角，点击Create New Project，输入项目名称，选择项目类型（迁移或容灾），目标端只能是AWS，下面会显示License信息。

在Setup & Info -> AWS Credentials中输入AWS用户的Access Key ID /Secret Access Key:

在Setup & Info -> Replication Setting中，选择源和目标的AWS区域。在Replication Servers中，对复制服务器进行配置：

• 选择复制服务器实例类型为“Default”，缺省为t3.small；

• 如勾选Dedicated Replication Servers，则每台源服务器会配置一个xlarge的复制服务器，缺省为“空”表示系统会根据每15块源数据盘配置一个复制服务器；

• 输入复制服务器所在的子网段和安全组；

• 因为本示例中数据复制是通过EC2的Private IP和VPC peering进行的，所以必须要勾选 Use VPN or DirectConnect (using a private IP) ；

• 在Network Bandwidth Throttling选项中，选择Disabled，如果需要让复制不占用太多网络带宽，可以取消Disabled并设置允许的最大复制带宽。

接下来，要在App和DB服务器上安装CE Agent，并开始把数据复制到Seoul区的复制服务器上。

如下图蓝色虚线所示，CE Agent通过IGW和NAT与CE服务器通信，复制服务器通过NAT与CE服务器通信。安装完Agent后，如黄色线所示，源服务器的EBS卷和复制服务器的EBS卷会发起一对一的连续数据复制。

在APP和DB服务器上安装Agent的过程如下：

Agent会发起初次全同步，可以在Console主界面的Machines里面查看数据同步的进程，最终会显示Continuous Data Protection的状态。同时，在AWS Seoul区里会出现一台复制服务器实例，实例挂载了5块EBS卷（其中一块是实例的root卷）。

切换是指在目标区域生成容灾服务器的过程。CE服务器会通过API将复制服务器上存储的时间点快照生成EBS卷，并根据用户定义的Blueprint（蓝图）启动Target Instances (目标实例)。切换方式可以分为Test Mode (测试模式)和Recovery Mode（恢复模式）。

测试模式切换是指在系统发生真实的切换前，对容灾服务器是否可用进行验证。此时，应用仍然在AWS Singapore区域运行，源端和目标端的连续数据复制仍然在进行中，在AWS Seoul区域生成的APP和DB的目标实例只用于验证容灾数据是否能满足应用要求。

恢复模式切换是指灾难发生或者进行灾难演练，将应用切换到容灾服务器。此时，应用已不在AWS Singapore区域运行，源端和目标端的连续数据复制会停止，在AWS Seoul区域生成的APP和DB的目标实例用于恢复生产系统。

在切换前，可以创建一个Recovery Plan（恢复计划）。恢复计划是对目标实例的启动顺序进行编排。在本示例中，DB服务器必须先于APP服务器启动，如果同时启动或者APP先启动，可能出现APP启动出错的 情况。所以创建一个名为“Recovery Plan of start db and app”的恢复计划，设置为先启动DB目标实例，启动完等待60秒后，再启动APP目标实例。

切换前，还必须在主界面Machines 一栏中，点击服务器，进入 Blueprint（蓝图）界面设置目标实例的配置信息：

• “Machine Type”中选择目标实例的类型，可以选择各种实例类型，或者选择复制源端的实例类型；

• “Launch Type”中选择按需实例或者Spot实例；

• 选择目标实例所在的子网和安全组。如果子网选择“Copy Origin”，则CE会将源端服务器所在的VPC配置完整的复制到目标区域，包括：VPC，Subnets，Security Groups，Route Rules，ACL Rules，Internet Gateway等；

• 选择目标实例的Private IP，可选择“Copy Source”、“Create New”、“Custom”或“use ENI”，本示例中选定了IP地址；

• 选择目标实例的Elastic IP，可选择“According to Source”、“none”、“Create New”或“Use Existing”，本示例中使用已存在Elastic IP；

• 其余选项，略。

完成蓝图的配置后，选择之前定义的Recovery Plan，在Console右上角，选择Initiate Recovery Plan -> Test Mode开始进行测试模式切换。

系统会跳出一个菜单让你选择恢复时间点。CE在做连续数据复制时，会保留“latest”即最近的恢复时间点，在正常情况下和源端的数据状态相同或存在毫秒级的RPO。

同时，CE也会保留最近一个小时的每10分钟、最近一天的每24小时、最近一个月的每一天等数据恢复时间点。做容灾演练或者在源端发生服务器宕机、机房损毁等情况时，通常选择“latest”时间点恢复容灾实例。当发生数据误删除、服务器中病毒等情况，你可能会需要选择某一个时间点恢复服务器。

此时，CE会在AWS Seoul区域启动APP和DB两台容灾服务器示例。你可以通过主界面的Job Progress查看任务执行的状态。

测试模式切换完成后，AWS Seoul区域会出现App和DB的两个目标实例，接下来就可以对目标实例进行验证。如果需要调整蓝图，可以再次启动测试模式的切换，新产生的目标实例会覆盖上一次的目标实例（即终止原来的实例）。

这样，经过多次的调整蓝图和启动测试模式切换，直到你确认可以执行最终的切换。在CE console上，会显示“Tested Recently”的状态。

当你确定开始执行恢复模式的切换时，通常会在维护时间窗口内关闭源端的应用，等待数据显示同步状态后，执行切换。然后，应用将在容灾端运行。

切换完成后，CE console上显示Failed Over的状态。此时，应用将在容灾端运行。

当需要将应用回切到源端时（即将应用从AWS Seoul区域切换到AWS Singapore区域），你将启动回切的过程。

回切的第一步是将CE设为Prepared for Failback的状态。此时，CE会通过API控制AWS Singapore区域启动复制服务器，并发起从AWS Seoul区域到Singapore区域的反向数据全复制，同时也会终止AWS Seoul区域的复制服务器。如下图所示：

在CE Console上，右上角的“Project Action”处选择“Prepared for Failback”。

此时，将开始进行从AWS Seoul区域的APP和DB服务器到AWS Singapore区域的复制服务器的反向复制。你可能会碰到提示为“Firewall Rules Creation Failed”出错情况，这是因为CE在Singapore区域创建复制服务器的时候，找不到在Setup & Info -> Replication Setting中设置的子网段和安全组。

这是正常的，因为在Prepared for Failback这个步骤之前，没有地方可以设置Singapore区域内的Replication Setting。你可以在右上角的Machine Actions处选择“Modify Replication Setting for 2 Machines”,这时可以修改 Replication Setting，指定Singapore区域内的复制服务器的子网段和安全组。

CE会在30分钟内重新启动数据复制，并开始反向的数据全同步，最后变成Continuous Data Protection的状态：

接下来，你可以在原先的源端（即AWS Singapore区域）内，通过测试模式（Test Mode）切换来验证从源端启动的实例是否满足将应用回切到Singapore区域的要求。并且在预先选择的维护时间窗口，在Singapore区域执行恢复模式（Recovery Mode）切换，将应用切换回Singapore区域。具体的步骤可参照“（三）切换”部分的说明。此时，CE Console上Machine的状态为Failed Over状态，但此时数据复制的方向仍然为AWS Seoul -> AWS Singapore。

回切的第二步是执行“Back to Normal”操作，将复制的方向再次反转。此时，应用已经在AWS Singapore区域内的App和DB服务器上运行，此操作将在AWS Seoul区创建新的复制服务器，开始进行AWS Singapore -> AWS Seoul的数据全同步，并且删除Singapore区域的复制服务器。

在CE Console的右上角选择“Back to Normal”，上方的项目状态会从“Disaster Recovery | Preparing for failback to original Source” 变成“Disaster Recovery from AWS Asia Pacific (Singapore) to AWS Asia Pacific (Seoul)”状态，并且开始执行初次数据同步。

最后，回切完成，两台服务器又回到了切换之前从AWS Singapore区域向AWS Seoul区域做连续数据复制的状态。

本文介绍了CloudEndure的功能和特点，并通过一个模拟示例演示了如何通过CE做AWS跨区域的容灾。希望能对你使用CloudEndure做系统迁移和容灾有所帮助。

• 《CloudEndure官方文档》

  http://docs.cloudendure.com