ZStack——存储模型：主存储和备份存储

ZStack通过逻辑功能，将存储系统抽象成主存储和备份存储。一个主存储是一个存放VM磁盘的存储池；一个备份存储是这么一个存储，用户存储镜像模板、备份的磁盘、快照。主存储和备份存储可以是物理分离的存储系统，也可以是同一个存储系统同时扮演两种角色。存储厂商可以轻松地，通过实现相应的存储插件，在ZStack中加入他们的产品。

概述

云中的存储系统可以以它们的逻辑功能被分为两类。一类作为存储池工作，存储VM的磁盘，并可以被运行中的VM访问；这类存储可以是基于文件系统的，磁盘被作为文件存储；或者基于块存储，磁盘则变成了块设备。在ZStack的术语表中，这类存储被称为主存储，要么可以是网络共享的存储，如NFS、ISCSI：

要么是本地存储，如物理主机的硬盘：

另一类存储系统作为仓库存在，存储含有操作系统的镜像模板，以及备份的磁盘和快照；这类存储可以是基于文件系统的，实体作为文件被存储；或者是基于对象存储的，实体作为对象被存储。在ZStack的术语表中，这类存储被称为备份存储，对VM无法直接访问，只能是网络共享的存储：

这两种存储都是逻辑概念，事实上，它们可以是各自独立的存储系统，使用不同的协议。例如，ISCSI主存储和NFS备份存储。或者同一个存储系统，同时扮演两种角色。例如，ceph，它的块存储部分是用于满足主存储，而它的对象存储部分则扮演了备份存储的角色。存储厂商可以很容易地在ZStack中，同时为主存储和备份存储加入他们的存储系统，通过实现存储插件的方式。

内部实现

主存储和备份存储并不是分开工作的；它们为了执行存储相关的活动，确实需要相互合作。最重要的活动是为了创建一个新的虚拟机。当一个虚拟机是第一次在一个主存储上被创建，它的镜像模板将会被从备份存储下载到主存储的镜像缓存中。由于大多数hypervisor使用称为链式克隆的技术，一旦镜像模板被下载，它将为所有的，使用了同样的镜像模板且在同样的主存储中有根磁盘的虚拟机，作为基础磁盘来工作。

在下载镜像之外，主存储也会上传实体，像磁盘、快照，到备份存储；这些上传活动都是备份相关的；例如，当用户备份一个数据磁盘时，数据磁盘的一个副本将会被上传到备份存储，作为一个镜像模板，可以在之后被下载到主存储用于创建新的数据磁盘。

在源代码中，主存储和备份存储在不同的插件中实现。在复杂性方面，备份存储显得更直接，因为只处理自身的事情。备份存储的主要活动是下载、上传和删除。一个备份存储需要定义一些协议，规定主存储怎样下载和上传实体，但它不需要知道主存储的细节，因为这是主存储的责任去使用这些协议来执行这些活动。另外，备份存储必须实现一些协议，这些协议允许镜像服务注册和删除镜像模板。和所有的其他资源类似，备份存储有一个抽象的基类BackupStorageBase,已经实现了大多数通用的业务逻辑，存储厂商只需要实现那些和他们后台存储系统直接相关的操作，通常是通过调用SDK或调用agent。

主存储更加复杂。复杂的根源来自于这么一个事实，即它的业务逻辑不只是依赖于备份存储，也依赖于hypervisor的细节。一个主存储，首先，必须理解备份存储的协议，以下载和上传实体；例如，一个NFS主存储必须知道Sftp备份存储，亚马逊S3备份存储，Swift备份存储的信息，如果它计划支持所有的这些。另一方面，对于同一个备份存储，协议的使用方法也会随着不同的hypervisor而不同；例如，NFS主存储可以调用KVM agent去使用s3tool来从亚马逊S3备份存储下载一个镜像模板；然而，由于VMWare有一个封闭的生态系统，对于NFS主存储来说要做同样事情的唯一方式是通过VMWare的SDK。基于这些事实，主存储的复杂性是M*N，其中M是备份存储的种类，N是它所支持的hypervisor的种类。

正如ZStack—通用插件系统一文中所描述的,ZStack是一个插件系统，每一个特性都被做成一个小的插件；一个主存储需要定义两个接口来打破这个复杂性。第一个是一个hypervisor的后端，用于处理只和hypervisor有关的活动；例如，NFS主存储有个定义好的接口：NfsPrimaryStorageBackend，对每一个支持的hypervisor，都会有一个具体的类，类似NfsPrimaryStorageKVMBackend用于KVM。第二个，称之为PrimaryToBackupStorageMediator，是一个hypervisor到备份存储的后端，用于处理同时涉及到hypervisor和备份存储的后端；例如，Nfs主存储有一个NfsPrimaryToSftpBackupKVMBackup的实现，用于为KVM支持Sftp备份存储。

这听起来非常糟糕，因为一个主存储必须实现如此多的东西；然而，事实上，一个主存储可能不需要去为所有的hypervisor支持所有的备份存储；例如，为VMWare支持Sftp备份存储是毫无意义的，因为VMWare SDK没有可能允许用scp传输一个文件到它的存储仓（即使可以通过绕过SDK使得这成为可能，我们不把它视为一种可靠的方式）。而且网络共享存储上，流行的协议并不特别多，大多数的使用场景可以被处理，一旦我们把Nfs主存储和Iscsi主存储准备就位。

注意：在当前的ZStack版本中（0.6），只有Nfs主存储和Sftp备份存储被实现了。

总结

在这篇文章中，我们演示了ZStack的存储模型。通过以逻辑功能将存储划分成主存储和备份存储，ZStack提供了一个非常棒的灵活性，使得存储厂商可以选择性地以各种意图插入他们的存储系统。而且随着越来越的普遍的存储协议，比如NFS、ISCSI、S3、Swift，将被作为默认插件加入，用户将不需要忧虑他们是否能够为他们现存的存储系统找到合适的组合。