云计算 频道

ZStack如何实现混合云灾备?看完这篇就懂了

1. “吃狗粮”的灾备危机

在我司的工程实践中,最为常见的一个做法就是“吃狗粮”。也就是说,所有工程师的开发环境、测试环境都是由ZStack搭建的。最开始的时候,工程师们还蜗居在两间不大的办公室,其乐也融融。某天,随着一声声哀嚎,大家发现有位工程师不慎把主存储给误删掉了。

得益于ZStack的设计,整个环境半个小时成功恢复。原因有两点:

  1. 系统自动部署了备份服务,数据库每小时有定期备份;
  2. ZStack本身无状态,只要数据库在,环境就能恢复。

如何实现混合云灾备?看完这篇就懂了

有惊无险,上了一次“云头条”。

2. 灾备很重要,但为何是混合云灾备?

自己吃狗粮碰到的问题,用户必然也会遇到。进一步引申下来,在这个“删库跑路”、“误操作导致数据丢失”等消息常年霸占媒体头条的时代,我们需要严肃地思考一个问题:如果被删除的不仅仅是数据库记录,而是真实存储系统的数据,或者存储出了故障,怎么办?

我们需要灾备,但灾备不仅仅是数据备份。数据备份是最自然、最基础的需求。完成数据恢复后,用户真正需要恢复的是业务。在私有云的场景下,业务恢复的资源粒度可以是一台虚拟机,甚至是一个集群。如果说,“ You cannot sell a platform without a killing application running on it.” 那么,ZStack的灾备功能将会是混合云平台的一个杀手级应用。

通过在ZStack 中引入混合云灾备,用户可以将虚拟机镜像以及相关元数据备份到公有云。即使本地数据丢失,也可以抓取指定的云端备份进行重建。甚至,用户可以直接在公有云以备份数据创建一台虚拟机。灾备云。

在进一步回答为何是通过混合云实现灾备之前,我们先回顾一下私有云。

私有云

单纯的私有云环境是一个闭环,整个系统的资源在私有云内部调配。系统管理员通过IaaS软件为公司各个部门提供应用环境,IaaS软件解决的是基础设施的监控可视化,资源的灵活分配,和可维护性。

如何实现混合云灾备?看完这篇就懂了

图1 简单私有云场景

图1是一张最简化的私有云场景。私有云将IT人员的生产力从繁复琐碎的配置中解放出来。从此IT人员更多关心的是交付,而不是如何交付。IaaS软件理解系统中的所有资源关系,其中一个重要的观念是:计算机(虚拟机)不再是分离的硬件设施,而是一个独立、完整的资源交付单元。

在缺乏 IaaS 软件的环境下,灾备的主要资源实体是存储,它以对象存储、块存储或者文件系统的方式,做异地备份。但存储只是计算的诸多层面之一,如何快速、有效地将恢复的数据投入运用,还是离不开IaaS这样的上层管理软件。

混合云

混合云灾备应运而生。首先,相比于公有云 ,通常的私有云规模很难有足够大的资源池。资源过多会导致浪费,这是企业不愿意看到的情况。资源过少则无法应对突发需求,这也是企业的痛点。其次,公有云都会提供完善的IaaS应用编程接口,私有云可以通过编程接口延伸IaaS框架内的各种资源需求。由此可见,在打通了公有云的数据和网络层面后,公有云不但可以应对突发的计算需求,还是一个非常合适的灾备载体,主要原因如下:

  1. 完备的应用编程接口
  2. 良好的弹性计算能力;
  3. 近乎无限的存储空间。

如何实现混合云灾备?看完这篇就懂了

图2 混合云场景

图2展示了对接公有云后的混合云场景。对比图1和图2,我们也许会发现,这两者的区别和Subversion与Git之间的区别有些许神似之处 —— 即:系统资源的存取是否集中

3. 混合云灾备如何实现?

ZStack自有的镜像仓库设计,是实现混合云灾备的核心。

镜像仓库设计思想

图3展示了ZStack镜像仓库的高层次构架。与 Opentack Glance ,以及 Docker Registry类似,ZStack 镜像仓库(以下简称镜像仓库)并不负责实际的存储,只是完成镜像的管理工作,以及元数据的维护。

如何实现混合云灾备?看完这篇就懂了

图3 ZStack镜像仓库架构

但是镜像仓库采用的数据组织方式与前述两者完全不同。简单来说,镜像仓库的数据存储方式与git类似,是一个内容可寻址存储。所有存储入口都通过一层中间件封装,实际的存储工作则由后台存储插件完成。可以对接本地存储,或者Aliyun OSS 等云存储。

这种设计有如下好处:

  1. 数据存储和管理逻辑分离;
  2. 因为内容可寻址,客户端和服务器可以分别对所有数据(包括元数据)做哈希验证,互不信任;
  3. 数据不可更改(包括元数据),任何更改都会改变哈希值。

说到镜像的组织,ZStack镜像仓库通过元数据维护了镜像之间的关系,对于镜像的格式并不关心。仓库中的镜像来源可以是qcow2 文件,也可以是 RBD 镜像,重建整个镜像的工作由客户端负责。比如,对于 qcow2 文件可以用 qemu-img 工具,而对于 RBD 镜像则可以使用rbd工具进行管理。

如何用镜像仓库实现混合云灾备

现在我们来看看,如何用镜像仓库实现混合云灾备。

具体来说,我们在镜像仓库上实现了 push 和 pull 操作,使得不同镜像仓库之间可以方便地同步指定镜像。和git类似:

  • push 是将本地的镜像推送到远程;
  • pull 是将远程的镜像抓取到本地。

如何实现混合云灾备?看完这篇就懂了

图4 ZStack镜像仓库的push和pull

对于任意备份在公有云上的镜像仓库,其中包含的镜像和本地镜像仓库并无二致。同样由于内容可寻址,在镜像的传输过程中可以避免大量不必要的数据传输。这一点是非常关键的:

  1. 数据的完整性可以轻松验证;
  2. 极大地提高了镜像传输速度,节省了时间;
  3. 节省了出数据中心的流量,节约客户成本。

在具体实现中,还需要考虑如何处理读写冲突、写写合并以及横向扩展等问题。限于篇幅,细节不再赘述。

以下是ZStack基于镜像仓库的几个典型灾备策略。

备份策略

用户可以对需要备份的虚拟机执行手动备份,或者指定备份策略执行自动备份。比如,备份间隔时间等等。手动备份能力是必要的,这使得用户可以及时对虚拟机做备份,避免时间窗口的风险。

恢复虚拟机

当用户对根云盘进行备份之后,恢复虚拟机只需要将远程的备份抓取到本地镜像仓库,然后创建虚拟机即可。就像开启了时光隧道,用户使虚拟机回到任意的备份点。

恢复数据盘

同样的逻辑也适用于数据盘。镜像仓库并不区分根云盘或者数据盘。恢复数据盘只需要将远程的备份抓取到本地,然后加载到虚拟机。

如何实现混合云灾备?看完这篇就懂了

图5镜像仓库就是这只“魔戒”

综前所述,镜像仓库对本地、异地,rbd 以及 qcow2,以及不同的存储后端,都呈现了统一的服务接口。这是策略与机制分离的典型应用,镜像仓库只提供镜像的存储和维护机制,而对如何使用镜像毫不关心。另外,由于镜像仓库的数据组织特性,仓库间的数据可以按需指定资源同步。正是这种灵活的设计,为ZStack的灾备能力提供了坚实的基础条件。

如果没有公有云

退一步,用户没有对接公有云环境的状况下,只要数据通道的速度有充分保证,用户可以异地(比如IDC机房)部署镜像仓库,同样可以很容易地实现异地备份。唯一的缺点在于,如果本地私有云突然发生灾难,没有办法利用公有云的能力,快速恢复关键应用。

小结

正如同鸡蛋不能放在同一只篮子里,重要的数据也不能全都放在本地。随着硬件能力的不断进步,用户拥有单位资源的成本在不断降低,但是数据的潜在价值却在不断攀升。数据越庞大,业务规模越庞大,导致的代价也随之越来越高昂。拥有灾备能力,拥有系统化恢复业务的能力,才能全无后顾之忧。在云的世界里,“后悔药”其实是存在的。

特别提醒:本网信息来自于互联网,目的在于传递更多信息,并不代表本网赞同其观点。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,并请自行核实相关内容。本站不承担此类作品侵权行为的直接责任及连带责任。如若本网有任何内容侵犯您的权益,请及时联系我们,本站将会在24小时内处理完毕。
0
相关文章