亚马逊AWS官方博客

利用 CloudEndure 实现跨 AWS 区域系统容灾

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服务器处于活动状态。

 

利用CE实现AWS跨区域容灾的具体步骤

(一)初始设置

首先,通过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官方文档: https://docs.cloudendure.com

 

 

本篇作者

夏卫东

AWS 解决方案架构师,有20年IT从业经验,加入AWS之前在IBM和EMC从事售前工作。在IT基础架构设计方面,尤其是数据存储相关领域有丰富的实践经验。目前专注于企业整体上云方面的架构规划,设计和实施,同时也是AWS存储社区专家成员