谁曾想到，数位存储可达到如此难以置信的复杂程度呢?存储一直以来都在遵循一套数目不菲的协议，从光纤通道(Fibre Channel)到iSCSI再到SMB的各种变体等等，但闪存的出现和虚拟化的持续增长又把这一需连篇累牍解读的主题变成了一个缩写词、协议和抽象丛生的密林。
同时，数据中心的虚拟化也促使了存储虚拟化浪潮的到来，存储逐渐脱离物理协议的束缚，朝实例存储和卷存储一类逻辑、抽象存储模型进化。通过提供抽象化，数据中心逐步解除了虚拟机和存储协议之间的耦合。
另外，云数据中心的崛起还催生出一种被称作对象存储的新存储类型，为了在全局范围内提供单一名称空间，这种存储类型牺牲了传统存储协议的强一致性。
在本文中，我将通过一一列出实例、卷和对象存储在数据中心演变过程中所处的位置来澄清这几种存储类型，并说明这些新的抽象是如何被叠加到现有的存储协议之上，或是如何与现有的存储协议并存的。
云存储的历史在许多方面就是虚拟化的历史，我将先从物理环境谈起，再说到虚拟化，到这个阶段后，虚拟的和物理的模型开始分化，***再归结到云，这一阶段的物理模型几乎已被虚拟模型完全抽象化。
物理存储
每种存储的根基都是某一组物理存储协议，所以，我先来快速回顾一下物理存储。如今在用的三大物理存储模型分别是：直接附加存储(Direct Attached Storage，DAS)、存储区域网络(Storage Area Network)和网络附加存储(Network Attached Storage，NAS)。
DAS(直接附加存储)
直接附加存储是最简单的存储模型，我们都很熟悉DAS，几乎所有的笔记本电脑、手机和台式计算机都使用这一模型。DAS的基本单元是机器自身，服务器的存储没有与服务器自身分离。就手机这种情况来说，在物理上就无法把计算与存储拆开来，不过即使是理论上可以卸掉硬盘的服务器，一旦硬盘被从服务器上卸下之后，通常也会在擦除掉硬盘的内容之后才再次使用该硬盘。SCSI和SATA都是DAS协议的例子。
SAN(存储区域网络)
终于，存储厂商意识到了分离存储和机器的实用性，不再把硬盘装配到每一台机器上，而是把所有的硬盘装配在一个服务器集群上，然后通过网络访问硬盘。这简化了诸如备份和故障修复一类的存储管理。这种存储和计算分离的做法通常被称作共享存储，因为多台计算机将使用同一个存储池。
客户端和服务器之间使用同一种(或非常相似的)块协议进行通信，这些块协议之前被用来与本地附加硬盘进行通信，这是最简单的通信方式。暴露这种通信方式的存储被称作存储区域网络，光纤通道(Fibre Channel)和iSCSI都是SAN协议的例子。
在一个存储区域网络中，管理员会把一组磁盘(或一组磁盘中的部分)组成一个LUN(logical unit，逻辑单元)，之后，外部的计算机就可像操作单个磁盘一样操作这一LUN。LUN被用作管理SAN存储的基本单元。
NAS(网络附加存储)
虽然SAN支持在两台计算机之间移动LUN，但它们所使用的块协议并非被设计来在计算机之间并发访问同一LUN中的数据。为了支持这种共享，我们需要构建一种新的用于并发访问的存储。在这种新的存储中，我们使用文件系统协议与存储进行通信，这一协议酷似运行在计算机本地的文件系统。这种存储被称作网络附加存储，NFS和SMB都是NAS协议的例子。
这一文件抽象允许多台服务器同时访问同一数据，多台服务器可以同时读取同一文件，多台服务器也可同时把多个新文件写入文件系统中。因此，对于共享用户或是共享应用数据来说，NAS是一种非常便利的模型。
NAS存储允许管理员把部分存储分配给单独的文件系统，每个文件系统都是一个单一名称空间，文件系统被用作管理NAS的基本单元。
#p#
虚拟存储
就像改变了计算的前景一样，虚拟化也改变了用于存储的现代数据中心的前景。正如物理机器被抽象成虚拟机，物理存储也被抽象成了虚拟磁盘。
在虚拟化中，虚拟机管理程序(hypervisor)为每台虚拟机提供一个模拟的硬件环境，这包括了计算机、内存和存储空间。VMware是***出现的现代虚拟机管理程序，它选择的模拟本地物理磁盘的做法是为每台VM(Virtual Machine，虚拟机)提供存储空间。VMware选择了本地磁盘(DAS)模型，以此作为把存储空间暴露给虚拟机的方式。
如同DAS的基本存储单元是物理机器，虚拟磁盘存储的基本单元是VM。虚拟磁盘并未被当作独立的对象给暴露出来，而是被当成某台特定虚拟机的组成部分，就像是物理计算机的组成概念中的本地磁盘。与DAS一样，虚拟磁盘与VM本身共生共灭，若VM被删除，则虚拟磁盘也被删除。
大多数传统的虚拟平台都采用了虚拟磁盘存储模型，例如，VMware vSphere、Microsoft Hyper-V、Red Hat Enterprise Virtualization和Xen环境中的存储都采用了相类似的管理和附加方式。
实现虚拟磁盘
因为VMware想要继续为虚拟机提供共享存储带来的好处，所以它不能依赖DAS协议来实现虚拟磁盘。显然，下一种选择应该是使用SAN，因为SAN的LUN与本地磁盘非常相像。
不过，物理LUN的局限性对于其是否适用于虚拟磁盘是一个挑战，虚拟环境把一定数目的逻辑计算机整合到单台物理服务器上，这意味着指定主机上的虚拟磁盘的数目将要比物理环境中的一台主机的物理LUN的数目大得多，可被附加到某台指定物理服务器上的LUN的***数目过小，不足以支持虚拟磁盘的必需数目。
或许更重要的是，与虚拟CPU一样，虚拟磁盘必须是可被以编程方式创建、销毁和移动的逻辑对象，而这些却非SAN存储旨在要执行的操作。例如，VMware需要动态地在不同物理主机之间移动VM，这要求在迁移期间访问共享存储。
出于这些考虑，VMware选择把虚拟磁盘实现成文件系统(NFS)或SAN上的分布式文件系统(VMFS)中的文件，而不是选择原始的LUN为实现方式。
从存储协议到存储模型
VMware选择在NAS或SAN之上实现虚拟磁盘，这是一种DAS风格的块存储模型，这例证了现代数据中心存储之所以吸引人的特征之一。因为虚拟机的IO被转交给虚拟机管理程序的软件进行处理，而非被转交给设备总线上的硬件，所以，被VM用来与虚拟机管理程序进行通信的协议无需与被虚拟机管理程序用来与存储自身进行通信的协议保持一致。
这导致了被向上暴露给VM和管理员的存储模型与被虚拟机管理程序实际用来存储数据的存储协议之间的一个分离，以虚拟磁盘为例，VMware按照DAS存储模型来设计它们，然后使用一个NAS存储协议来实现它们。
这是一个非常强大的间接层，它赋予了我们混合搭配存储模型和存储协议的灵活性，我们甚至可以动态地更换存储协议而不会影响到虚拟机。例如，虚拟磁盘使用NFS中的文件或存储在光纤通道LUN上的VMFS中的文件来实现，或甚至可直接实现成iSCSI LUN，这一实现做法的选择对应用来说是完全透明的，因为最终所有的这些协议在VM和管理员看来都是相同的，它们看起来就像是被附加到VM上的本地物理磁盘。
因此，在大多数公共云基础设施上进行应用开发的开发者并不知道正在使用的是什么存储协议，实际上，协议甚至可能是在动态变化的。我们并不知道亚马逊把什么存储协议用于它的Elastic Block Storage(弹性块存储)，对我们来说，也没有必要知道。
因为存储模型和存储协议分离这一缘故，存储协议成为了基础设施要面对的一个问题，这主要体现在成本和性能方面，而非应用所面临的功能选定方面的决策。
#p#
云存储
随着虚拟环境演变成云环境，数据中心的前景再次发生了转变。云环境欣然接受了虚拟化的始作俑者虚拟磁盘模型，而且他们还提供了额外的一些模型来支持一个完整的虚拟存储栈。云环境尝试虚拟化整个存储栈，这样它们就可以提供自助服务，以及在基础设施和应用之间提供一个完全的隔离。
云环境以多种形式出现，借助OpenStack、CloudStack或是VMware vRealize套件这样的环境，它们可被企业实现成私有云，它们也可被服务提供商实现成诸如Amazon Web Services、Microsoft Azure和Rackspace一类的公共云。
有意思的是，被用在云环境中的存储模型正是被用在物理环境中的那些的一个写照，不过，与虚拟磁盘一样，它们是一些从多种可被用来实现它们的存储协议中抽象出来的存储模型。
三种云存储模型
实例存储：云端的虚拟磁盘
虚拟磁盘存储模型是传统虚拟环境中主要(或唯一)的存储模型，然而，在云环境中，该模型只是三种之一，因此，该模型在云环境中被赋予了一个特定的名称：实例存储(instance storage)，意即存储的使用方式类似传统虚拟磁盘。
需要注意的很重要的一点是，实例存储是一种存储模型，而非一种存储协议，可使用多种方式来实现。例如，有时实例存储会使用计算节点自身的DAS来实现，以这种方式来实现的存储通常被称作临时存储(ephemeral storage)，因为这种存储通常不具有高可靠性。
此外，借助NAS或接下来要介绍的第二种存储模型卷存储，实例存储也可被实现成可靠的存储。例如，OpenStack允许用户把实例存储实现成主机上的临时存储、NFS挂载点上的文件，或是实现成使用了卷启动(boot-from-volume)机制的Cinder卷。
卷存储：不涉及物理层面的SAN
然而，实例存储有它的局限性，开发云端原生应用(cloud-native application)的开发者通常会显式地把配置数据，例如OS和应用数据，和用户数据，例如数据库表和数据文件，加以区分开来，通过分离这两者，开发人员可以在把配置设成瞬态的和可重构建的同时，仍然保持用户数据的高可靠性。
相应的，这种区分又导致了另一种存储类型：卷存储(volume storage)的出现，这种存储模型是实例存储和SAN的混体。卷存储的基本单元是卷而非VM，卷可被从某台VM上卸下，然后再被附加到另一台VM上。然而，与虚拟磁盘一样，在规模和抽象方面，卷更酷似文件而非LUN。与实例存储相比，卷存储通常被认定是高可靠的，因此常被用于用户数据存储。
OpenStack的Cinder就是卷存储的一个例子，Docker的独立的卷抽象也是。同样，这里要提醒一下，卷存储是一种存储模型而非存储协议。卷存储可在诸如NFS一类的文件协议或是诸如iSCSI一类的块协议之上实现，这种实现对应用而言是透明的。
对象存储:Web规模的NAS
此外,云端原生应用也需要有一个可用来在VM之间共享数据的空间，不过他们通常需要的是可跨地域扩展至多个数据中心的名称空间，对象存储(object storage)所提供的正是这类存储。例如，亚马逊S3提供了跨整个区域，也可以说是跨全球的一个单一的逻辑名称空间。为了达成这一规模，S3需要牺牲掉传统NAS的强一致性和细粒度更新。
对象存储提供了一种被称作对象的类文件抽象，不过它提供了最终一致性。这意味着虽然所有客户端发出的请求最终都能获得相同的答案，但它们也有可能间中会收到不同的回答。这种一致性类似Dropbox在两台计算机之间提供的一致性，客户端可能间中偏离了同步轨道，但最终一切都会被拉回正轨。
此外，传统的对象存储还特地为在高延迟WAN连接上的使用提供了一组简化的数据操作：列出“桶(bucket)”中的对象、读取对象的全部内容，以及使用新数据来全部更换对象中的数据。该模型提供了一组比NAS更为基础的操作，允许应用读写某个文件内部的小块内容、按新的大小截断文件、在目录之间移动文件等等。
这种宽松模型允许对象存储以很低的成本和很好的整体性能来提供跨大区域的极大型名称空间，因为它的这一规模和成本优势，许多旨在运行于云环境中的应用都被实现成使用对象存储而非使用NAS。例如，云端原生应用通常会使用对象存储来存储图片、静态Web内容、备份数据、分析数据集和客户文件等。
此外，还需要注意的很重要的一点是，对于许多用例来说，对象存储的宽松一致性和粗粒度更新也使其成为了一种不合适的选择。例如，它并不适合用作实例存储或卷存储的替代(至少对于它的原始形式来说是如此)。实例存储和卷存储支持强一致性、小块更新，以及重度写(write-heavy)、随机工作负载等，所有这些方面对于对象存储的使用来说都是挑战。
而且，要求强一致性的NAS工作负载也并不适用于对象存储，所以，NAS极有可能会继续与对象一起并存于云环境中。
与NAS一样，对象存储是一种软件构造，而非一种硬件构造，应用自身直接通过REST API访问对象存储。私有云中存在着两种主要的(也是相似的)对象API：Amazon的S3 API和 OpenStack的Swift API。
许多厂商都提供了对象存储实现，如OpenStack的Swift、Amazon的S3、Red Hat的Ceph和Cleversafe等，通常，除了其他一些API之外，所有这些产品还都支持S3 API或 Swift API或两者。一些诸如EMC Isilon一类的现有文件系统厂商也为他们已有的文件接口提供了对象接口。
#p#
现在来归纳一下
现在，我们已经对云存储模型及其与被用在更传统的存储环境中的存储模型的关系做了一个完整的描述，正如DAS、SAN和NAS提供了一组工具来解决各种物理的或虚拟的用例的问题，实例、卷和对象存储也共同为云提供了一个灵活的泛型。虽然并非所有的安装实例都会用到所有的这些存储类型，但也没有一种存储类型依靠自身就能够处理所有必需的用例。
新的云存储模型
下面的表格回顾了每种模型的实现方式，每种模型被暴露给VM的方式，以及每种模型提供给管理员的管理方式。
实例和卷存储充当现有的DAS和SAN物理存储模型的逻辑抽象，在新的数据中心环境中，这些虚拟存储模型存在于存储协议之上。与之相反，对象存储提供了一种新的主要专注于大规模的存储类型，该存储类型处理一系列类似于物理环境中的NAS所处理的那种用例。
虽然这些抽象初看很复杂，但它们给数据中心和应用管理员带来了新的自由。应用管理员不再被数据中心的基础设施决策所束缚，他们可以随意选用对应用有意义的模型来管理数据。相应的，数据中心管理员可在对用户来说很重要的抽象层面管理存储，同时又可以利用适合于数据中心需求的***存储实现。
就像DAS、SAN和NAS模型支持物理数据中心的创新一样，实例、卷和对象存储也会让现代虚拟数据中心的持续创新成为可能。
关于作者
Brandon Salmon是Tintri公司的CTO，@Tintri，2009 年加入Tintri。他是被称作系统小子的那类人，喜欢思考用户体验，这个爱好从他在卡内基·梅隆大学进行关于家居分布式文件系统的博士研究工作时就开始了。他设计和实现了Tintri的在闪存和磁盘之间移动数据的最初算法，此后又致力于多个领域的研究工作，最近的研究方向是云技术。
原文链接：了解云存储模型
