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

  “没有经历过数据丢失的运维不是一个成熟的运维。”
                          ——尼古拉斯.苦逼.运维

  如果要评选运维人员最不愿遇到的事,毫无疑问,数据丢失一定会名列前三。作为一个曾经做存储的工程师,每次在给用户方案设计时,都要反复叮嘱:一定要考虑数据保护!
  在Azure,同样也需要考虑数据保护。Azure原生提供了多种数据保护方式,往往容易给用户造成疑惑,到底如何选择,其实简单归纳如何:

方式 原理 类比 适用场景 缺点
LRS、GRS等 多副本 镜子 业务连续性 没有历史数据
快照或ASR备份 备份 照相 基于时间点的保护 恢复时间较长、颗粒度比较粗糙
ASR站点恢复 连续数据保护 录像 对短时间内精细化的恢复任意时间点 占用空间较大

  所以数据保护是一个立体的体系,通常会由多种手段组合一套完整的容灾备份方案。而对于不同的应用(例如各种数据库、ERP软件、文档管理系统等),通常要根据具体应用选择不同的技术工具来实现。
  而在虚拟化和云平台上,由于整个虚机的硬盘变成了虚拟化平台的一个文件(VHD、VMDK等等),于是就有了一个简短粗暴的方法,从底层直接对整个虚机的硬盘镜像进行保护,屏蔽应用层的差异。ASR就是基于这种方式在Azure上提供的一个数据保护方案。

原理

  Azure在虚拟化层为虚机提供了快照的功能。
  对于快照,最大的问题是应用数据一致性。因为内存里有脏数据,落盘的的数据并不能保证应用层一致(例如数据库的时间戳)。并且在快照过程中,还有数据持续写入,更导致数据不一致。造成的后果就是,通过快照生成的虚机,系统启动后,应用却无法启动,需要做回滚等操作,退回到上一个一致性时间点,才能启动应用。
  对于Windows平台,这个问题已经不是问题,很早Windows就开始内置VSS(Volume Snapshot Service)功能。当调用Windows快照时,会自动清空(Flush)内存的数据到硬盘,并短暂hang住系统的写IO(例如数据库的增删改操作进入队列但不commit),保证快照点数据的一致性。
  但是在Linux平台上,没有VSS类似的功能。但在我软开发狗的努力下,Azure平台的Linux也实现了类似VSS的功能。
  有了一致性快照的基础,ASR就可以对虚机进行一致性快照,完成后再将快照数据备份或复制到其他地方,实现虚机的数据保护。

ASR备份

备份虚机

  首先,我们创建一个ASR的保管库。
  在Azure的所有服务里搜索“site recoverry”就可以看到ASR服务:
Capto_Capture 2018-06-06_09-12-36_PM

  进入后点击增加即可创建一个ASR的保管库:
Capto_Capture 2018-06-06_09-13-47_PM

  可以看到,保管库的创建很简单,只有三项:保管名称、资源组和区域。但是有一点要注意,保管库必须要与需要备份的虚机在同一个区域。
  创建后进入保管库,可以看到目前没有任何备份或者站点恢复:
Capto_Capture 2018-06-06_09-22-46_PM

  现在准备一台虚机,用作备份测试:
Capto_Capture 2018-06-06_09-24-37_PM

  该虚机除了OS盘,还特意附加了一块数据盘,并且通过fstab文件自动挂载:
Capto_Capture 2018-06-06_09-25-55_PM

  Capto_Capture 2018-06-06_09-30-30_PM

  Capto_Capture 2018-06-06_09-31-24_PM

  Tips

  • 使用UUID而不使用设备路径,避免设备路径变化导致挂载不成功
  • 通过nofail避免挂载不成功导致虚机启动时系统无法启动

  现在对该虚机进行备份。
  点击保管库——Getting Started——Backup:
Capto_Capture 2018-06-06_09-36-01_PM

  这里有两种备份方案:Azure和On-premises。其中Azure只支持虚机备份,而On-Premises则可支持多种备份::
Capto_Capture 2018-06-06_09-38-47_PM

Capto_Capture 2018-06-06_09-37-44_PM

  所以,ASR不仅支持Azure平台的虚机备份,也可用作On-Premises的备份工具。
  选在Azure的虚机备份,并点击Backup:
Capto_Capture 2018-06-06_09-39-37_PM

  第一步是备份策略的选择,默认备份策略是每天早上12:30备份,数据保留30天;也可以根据实际环境创建新的备份策略。
  点击OK进入第二步,选择虚机:
Capto_Capture 2018-06-06_09-41-31_PM

  这里在同一个订阅下的同一个区域里所有虚机都会被列出,可以备份一台虚机,也可以同时备份多台虚机(最多20台),当然,最好参照最佳实践,降低备份对生产的影响。这里,勾选VM01并点击ok:
Capto_Capture 2018-06-06_09-45-09_PM

  然后点击Enable backup,Azure开始配置备份:
Capto_Capture 2018-06-06_09-46-07_PM

Capto_Capture 2018-06-06_09-46-36_PM

  配置完成。现在进入Protected Items——Backup Items:
Capto_Capture 2018-06-06_10-40-19_PM

  有一台虚机已经配置好备份,但是因为没到备份时间,所以处于Pending状态。
  点击Buckup Now,可以发起On-Demand备份,给该备份去个名字,点击ok就可以了:
Capto_Capture 2018-06-06_10-42-17_PM

  点击保管库的Monitoring and Reports——Jobs,可以看到所有备份任务:
Capto_Capture 2018-06-06_10-43-52_PM

  点击正在进行的备份任务,可以看到备份分为两个阶段:拍摄快照和传输数据:
Capto_Capture 2018-06-06_10-45-00_PM

恢复虚机

  备份的目标是恢复。
  现在进入保护虚机的状态页,可以看到多出一个恢复时间点,即刚才做好的备份:
Capto_Capture 2018-06-06_11-10-03_PM

  选择这个恢复点,可以看到有两种恢复方式:虚机恢复和文件恢复。

文件恢复

  先看看文件恢复,对于Linux虚机,Azure将生成一个脚本和密码:
Capto_Capture 2018-06-06_11-22-25_PM

  在一台Linux系统上执行此脚本并输入密码:
Capto_Capture 2018-06-06_11-23-15_PM

  恢复点里源虚机的磁盘分区会被临时挂载到此linux里:
Capto_Capture 2018-06-06_11-26-11_PM

  进入相应目录,可以将需恢复文件拷贝出来实现恢复。

虚机恢复

  选择虚机恢复,有两种方式(直接恢复虚机或只恢复硬盘):
Capto_Capture 2018-06-06_11-30-03_PM

  如果直接恢复虚机,需要提供虚机名、资源组、vnet、subnet,以及一个存储账户:
Capto_Capture 2018-06-06_11-32-18_PM

  可以发现,直接恢复虚机时,将恢复为非托管磁盘的虚机,需要回复后转化为托管磁盘;但是,更严重的是,虚机恢复后,没有可用性集,而且由于可用性集是在虚机创建时需要指定的,无法在创建后修改,所以这样恢复的虚机无法加入可用性集。

  要解决此问题,恢复的方式就需要更改成恢复硬盘,此时只需提供存放硬盘的存储账号:
Capto_Capture 2018-06-06_11-41-05_PM

  硬盘恢复后再按照虚机复制那篇文档的内容使用已有硬盘创建虚机的方式去创建虚机,创建过程中指定各种属性(包括网络、可用性集等)。

Tips

  • 直接恢复虚机的方式,如果虚机采用密码登录,出于安全性,有可能密码会被屏蔽,请重置密码
  • 如果有多个硬盘,使用硬盘恢复后重建虚机时,请记得附加数据盘(临时盘不会被备份,也无需附加);恢复后硬盘的UUID不变,可以直接挂载
  • 如果备份的虚机时固定ip,恢复会变为动态ip,避免ip冲突

小结

  除了可以按策略自动化的保护虚机数据以外,相对于直接硬盘复制的方式去复制虚机,ASR备份恢复方式去复制虚机,有如下优势:

  • 无需关机,直接保证数据一致性
  • 如果同一虚机有多块硬盘,无需一一复制,备份会同时对所有硬盘进行备份并可保证一致性
  • 可以恢复多个虚机去做各种用途(测试、开发、培训等)

  最后,希望大家能用好备份,合理保护数据。