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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　完备的应用编程接口

　　良好的弹性计算能力；

　　近乎无限的存储空间。

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

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

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

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

　　这种设计有如下好处：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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