东风吹,战鼓擂,数据丢失要怪谁——使用ASR对虚机行进保护之站点恢复篇

ASR站点恢复

  业务系统的安全除了备份,往往还有业务持续性。备份虽然可以恢复业务,但是只能回退到备份点,比较粗燥,并且要通过恢复才能拉起业务,所需时间较长,用行话来讲就是RPO和RTO都比较大。这时候就需要ASR的站点恢复功能了。

  ASR站点恢复通过连续数据保护将生产系统的虚机不断复制到另一个Region,当生产系统出现宕机故障时,可迅速拉起容灾站点的系统,实现业务系统恢复;生产环境恢复后,再从容灾站点恢复到生产环境。当然,容灾站点也可用作系统测试等功能。

ASR站点恢复搭建

  ASR站点恢复的搭建如同ASR备份一样,在保管库的建立时,有region的要求,简单来说,要遵循以下两点:

  • 受保护的虚机与所在的资源组必须在同一个region
  • 保管库与其所在的资源组必须不在同一个region
      例如,需要保护的虚机和其所在的资源组都在美国西部,那么建立保管库和保管库的资源组就必须在美西以外的region。
      此外,还需要注意虚机的兼容性:
      ASR站点恢复兼容性
      ASR站点恢复的搭建比较简单,先按上述要求创建保管库,然后选择“+复制”即可开始:
    Capto_Capture 2018-06-09_09-10-54_PM
      然后选择源(Azure)、源位置、部署模型、源资源组(位于源位置):
    Capto_Capture 2018-06-09_09-13-16_PM
      再选择需保护的虚机:
    Capto_Capture 2018-06-09_09-14-20_PM
      确认容灾端Region相关的复制选项:
    Capto_Capture 2018-06-09_09-15-38_PM
      Azure验证创建所需的资源。完成后启用复制,就开始相关配置并启动复制:
    Capto_Capture 2018-06-09_09-35-42_PM

  与备份的简单复制数据不一样,站点恢复需要按一定规则自动启动容灾虚机,这就涉及到可用性集、网络架构等各种计算因素。下边从最简单的单机容灾开始,一步步了解ASR站点恢复的功能。

单机容灾

自动化容灾和恢复

  如果复制选项选择默认配置,将自动生成一个后缀为asr的对应资源组和若干后缀为asr的对应资源。并且网络架构与生产环境一致。
  进入复制项里可以查看容灾的整体状况和架构:
Capto_Capture 2018-06-09_10-33-50_PM

  其中,最近一次复制发生在2分钟前。
  现在模拟客户想在容灾端将业务起来做测试,但不影响生产系统,选择测试故障切换:
Capto_Capture 2018-06-09_10-37-46_PM

  最重要就是恢复点的选择,默认会有两个选项:最低RPO和最新的应用一致性。
  点开自定义查看:
Capto_Capture 2018-06-09_10-40-11_PM

  可以看到,基本上每5分钟会产生一次恢复点。
  ASR的站点复制连续将数据写入到容灾端,并每几分钟生成一个还原点,而为了保证应用一致性,Azure通过VSS(windows)和类似VSS(linux)的方式短暂hang住应用来落地所有数据到磁盘。如果每5分钟一次,将会导致系统频繁hang住,体现为应用性能下降。
  所以在此,ASR的站点恢复引入了应用一致恢复点的概念,首次数据复制时,保证应用一致,以后按设置每过固定时间(默认4小时,可设置为最短1小时)做一次应用在一致性的恢复点,其他时间恢复点只保证磁盘块级一致性。
  另一个必须选择的是vnet,这里只有一个,就选择该网络即可:
Capto_Capture 2018-06-09_10-50-00_PM

  在一些复杂的环境里,如生产环境和另一个环境有应用级主备设置,当切换到容灾端时,仍需保证应用级主备,这时候测试就需注意避免网络方面冲突。
  启动切换测试后,将自动生成恢复点的硬盘,并按照相关设置配置计算网络资源,然后启动容灾虚机。
  启动完成,可以看到在虚机列表里,有一台和受保护虚机一样的虚机,在不同region,但默认情况下,该虚机没有公网ip:
Capto_Capture 2018-06-09_10-59-48_PM

  回到复制项,选择清理测试故障转移,将会删除所有配置:
Capto_Capture 2018-06-09_11-01-39_PM

  清理结束后,可以看到,临时生成的虚机会自动被删除:
Capto_Capture 2018-06-09_11-06-59_PM

  现在进行故障切换模拟。
  在生产虚机的home路径里生成一个文件:
Capto_Capture 2018-06-09_11-04-12_PM

  5分钟后(确保生成文件后有一次复制),在ASR里启动故障转移:
Capto_Capture 2018-06-09_11-10-00_PM

  默认选择最近一次复制点,并关闭主机,避免干扰。切换完成后,主机停机,容灾端生产一台新的相同的主机:
Capto_Capture 2018-06-09_11-19-18_PM

  现在给该虚机一个公网ip:
Capto_Capture 2018-06-09_11-23-23_PM

  由于这台虚机是从生产虚机复制生成,所以可以使用原有的登录方式登录,并且生产虚机上新生成的文件也被复制过来:
Capto_Capture 2018-06-09_11-26-00_PM

  在容灾端虚机生成一个新文件:
Capto_Capture 2018-06-09_11-27-02_PM

  现在将容灾站点提升为生产站点,并对外提供服务。:
Capto_Capture 2018-06-09_11-38-41_PM

  查看复制关系,容灾站点已提升为主站点:
Capto_Capture 2018-06-10_12-18-17_AM

  主站点恢复正常,按如上步骤再次执行故障转移,切回主站点:
Capto_Capture 2018-06-10_09-30-09_AM

  现在主站点的虚机启动投入生产,备站点虚机停机:
Capto_Capture 2018-06-10_09-32-22_AM

  备战点产生的文件在主站点也可以看到了,切换成功:
Capto_Capture 2018-06-10_09-36-25_AM

复制的选项配置

  在建立复制关系时,可以看到有很多选项可以配置:
Capto_Capture 2018-06-09_09-15-38_PM
  这里边分为4个部分:

目标位置

容灾端所在的region,不能与生产站点在同一个region

资源组、网络、存储和可用性集

通常用自动配置的就可以了,但是如果有特殊需求,可以自定义:
Capto_Capture 2018-06-10_11-28-22_AM

  这里要注意几点:

  • 可用性集与主站点要保持一致,即主站点有,容站站点也必须有,反之亦然
  • 在这里不能新建资源,如果要自定义,需要提前建好所有资源
  • 如果需要自定义,需要同时自定义所有资源;例如自定义资源组后,如果有可用性集,可用性集不能采用默认创建,也需要自定义
  • 目标虚拟网络需要在网络映射中配置:
    Capto_Capture 2018-06-10_11-28-52_AM
复制策略

  复制策略主要定义了恢复点的保留时间及应用一致性快照的频率:
Capto_Capture 2018-06-10_11-32-52_AM

  默认恢复点保留时间为24小时,也就是可以恢复到24小时内的容灾时间点,如果设置过长,将会大量占用存储空间,所以只适合短时间的精细化保护。应用一致性快照频率默认4小时一次,最低1小时,但如果太频繁会影响系统性能。
  另外,如果同时对多台虚机进行复制,可以通过多VM一致性保证VM之间的一致性。

扩展设置

  扩展设置主要是对虚机扩展进行了定义:
Capto_Capture 2018-06-10_11-33-45_AM

复制的网络配置

  在生产环境里,网络是一个非常重要的元素,如果设置不正确很有可能导致业务系统无法启动。
  默认情况下,ASR将在容灾端创建一个和生产环境一样的vnet,尽可能保持网络环境一致。但是真实生产环境里,可能会出现不同的情况。

DHCP的ip空缺

  众所周知,一般情况下,虚机采用DHCP的方式按顺序获得ip地址。当一个subnet的所有虚机都复制到容灾端时,容灾端也将按顺序给虚机分配IP。但是当不是所有虚机都复制时,会出现什么情况?
  现在建立两台虚机,通过DHCP获得地址:
Capto_Capture 2018-06-10_12-06-32_PM

  这次只对第二台虚机进行复制保护:
Capto_Capture 2018-06-10_12-08-33_PM

  网络配置还是保持默认的DHCP:
Capto_Capture 2018-06-10_12-09-15_PM

  复制完成进入复制虚机的计算和网络,通过测试故障切换启动容灾端虚机查看:
Capto_Capture 2018-06-10_02-33-54_PM

  新建虚机由于通过DHCP分配,所以自动获得第一个IP地址,与源虚机不一样。

固定IP

  为了避免这种IP变化导致生成故障,可以将源虚机设置为固定IP:
Capto_Capture 2018-06-10_02-36-55_PM

  复制完成后查看复制项的计算和网络,可以看到容灾端网络的配置与源虚机一样,为固定IP:
Capto_Capture 2018-06-10_03-22-34_PM

  通过故障转移启动容灾端虚机,查看虚机的IP配置,确认是固定IP:
Capto_Capture 2018-06-10_03-42-18_PM

  由此可知,对于IP要求比较严格的环境,源虚机最好配置为固定IP

不同IP段

  某些场合,为了避免冲突,需要容灾端和生产端具备不同的IP地址,这时候就需要用到网络映射。
  先在容灾端的资源组(如没有,需手工建立)创建一个vnet,地址空间(10.1.0.0、16)不同于生产端(10.0.0.0、16):
Capto_Capture 2018-06-10_03-00-46_PM

  在保管库的Site Recovery基础价格——针对Azure虚拟机——网络映射里添加网络映射:
Capto_Capture 2018-06-10_04-54-47_PM

  这里双向都需要建立:
Capto_Capture 2018-06-10_04-56-27_PM

  现在对VM01(DHCP)和VM02(固定IP)都启动复制:
Capto_Capture 2018-06-10_04-57-31_PM

  现在配置设置里可以看到目标虚拟网络自动设置为网络映射的网络:
Capto_Capture 2018-06-10_04-58-50_PM

  由于目标IP端没有VM02的固定IP,所以配置过程中会出现一个警告:
Capto_Capture 2018-06-10_05-41-44_PM

  复制完成后通过故障转移启动容灾端虚机,并查看状态:
Capto_Capture 2018-06-10_05-48-16_PM

  VM01采用DHCP方式,在目标端新网段按顺序获得IP;而VM02由于固定IP不在目标端IP范围,所以被分配了IP端最后的IP。

多机容灾

  对于生产环境,一般是多台业务相关虚机需要同时容灾。多机容灾和单机没有什么区别,只是在配置设置时如果续集之间有业数据关联,需要考虑虚机间是否要保证一致性。
  典型的如电商做读写分离,如果虚机间没有一致性保护,可能出现商品数量错误。
  如果需要做虚机间的一致性,在配置设置的复制策略做自定义:
Capto_Capture 2018-06-10_06-59-13_PM

  在此为需要做一致性的VM创建一致性组即可。
  进入复制项可以看到,一致性组里的虚机被组合到了一起:
Capto_Capture 2018-06-10_07-26-14_PM

  对一致性组里的一台虚机进行测试故障切换,出现错误:

  Capto_Capture 2018-06-10_07-46-46_PM

  需要在保管库——管理——Recovery Plan(Site Recovery)里创建恢复计划:
Capto_Capture 2018-06-10_07-49-50_PM

  新建一个恢复任务,并选择相应一致性组:
Capto_Capture 2018-06-10_07-54-47_PM

  现在就可以如同单个虚机一样执行测试或故障切换:
Capto_Capture 2018-06-10_07-57-04_PM

总结

  Azure为跨地域容灾做了很好的基础架构,用户只需要按图索骥即可,非常简单。
  不过在使用时要注意如下几点:

  • 选择合适Region,避免无法选择虚机
  • 注意网络配置,以免业务恢复时无法正常启动
  • 合理选择虚机应用的一致性和虚机间的一致性配置
  • 注意容灾端的虚机配额,避免切换时无法启动虚机
  • 合适制定恢复演练策略,熟悉操作
  • 结合其他容灾手段(如基于应用的容灾),提供完整的业务保护方案
      最后,祝大家永远都不会有用到容灾的机会。