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

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

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

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

系统自动部署了备份服务，数据库每小时有定期备份；

ZStack本身无状态，只要数据库在，环境就能恢复。

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

2.灾备很重要，但为何是混合云灾备？

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

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

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

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

私有云

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

简单私有云场景

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

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

混合云

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

完备的应用编程接口

良好的弹性计算能力；

近乎无限的存储空间。

混合云场景

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

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

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

镜像仓库设计思想

图3展示了ZStack镜像仓库的高层次构架。与OpentackGlance，以及DockerRegistry类似，ZStack镜像仓库（以下简称镜像仓库）并不负责实际的存储，只是完成镜像的管理工作，以及元数据的维护。

ZStack镜像仓库架构

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

这种设计有如下好处：

数据存储和管理逻辑分离；

因为内容可寻址，客户端和服务器可以分别对所有数据（包括元数据）做哈希验证，互不信任；

数据不可更改（包括元数据），任何更改都会改变哈希值。

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

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

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

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

push是将本地的镜像推送到远程；

pull是将远程的镜像抓取到本地。

ZStack镜像仓库的push和pull

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

数据的完整性可以轻松验证；

极大地提高了镜像传输速度，节省了时间；

节省了出数据中心的流量，节约客户成本。

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

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

备份策略

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

恢复虚拟机

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

恢复数据盘

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

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

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

如果没有公有云

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

小结

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

李群，ZStack首席工程师。统筹负责ZStack研发工作，在云计算以及安全领域有丰富的研发经验。2007年加入EMC云计算基础设施部，负责通用Appliance平台的研发工作；2010年加入Intel开发者产品部，负责SGX指令集的SDK研发；2015年加入微软中国云计算创新中心，负责Azure中国区CDN服务的研发。

【作者简介】

李群，ZStack首席工程师。统筹负责ZStack研发工作，在云计算以及安全领域有丰富的研发经验。2007年加入EMC云计算基础设施部，负责通用Appliance平台的研发工作；2010年加入Intel开发者产品部，负责SGX指令集的SDK研发；2015年加入微软中国云计算创新中心，负责Azure中国区CDN服务的研发。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。