【IT168 评论】提起ViPR，往往会涉及到软件定义存储、存储虚拟化、对象存储、OpenStack这些话题。笔者撰写本文的目的，就是想以尽量通俗的语言，站在与已有产品、技术形态对比的层面来谈谈ViPR的功能、定位，以及EMC推出该产品的目的。

　　距离EMC World 2013大会已经有一段时间，随着ViPR正式发布日期的临近，我们又看到有国外媒体撰写了一些评论。其中部分观点可能有所偏颇，或许会误导读者，因此我也想在这里进行澄清。

　　误区之一：

　　“EMC的想法是将商用存储设备与ViPR的上层存储阵列功能(VMAX、VNX、Isilon及Atmos阵列都拥有该功能)相结合;从而实现与EMC原本相对昂贵的专用设备相近的使用效果。”

　　解释：ViPR只具备在“商用存储设备”上实现对象存储服务的能力，至于数据块和文件访问阵列的功能，它也是依靠被管理阵列本身的支持来实现的。

　　误区之二：

　　“...至少NetApp已经站在了支持阵营当中。坦白讲，我还没时间研究ONTAP版本，但这很可能会是ViPR碰上的头一个钉子...”

　　解释：NetApp主动支持ViPR的说法不妥。NetApp FAS系列是EMC首先也是目前唯一支持的第三方阵列，理由不难想出：第一，NetApp是仅次于EMC的第二大存储系统厂商;其次、Data ONTAP可能是市场占有率最高的阵列操作系统，甚至超过Symmetrix的Enginuity和CLARiiON的Flare OS，EMC开发同一套API接口就可以支持从低端FAS2000到高端的FAS6000系列。另外，我们也注意到从NetApp收购LSI Engenio获得的E系列没有得到ViPR的支持。

　　以上仅仅是2段简单的说明，下面笔者将把更多的观点分享给大家。当然我并不是相关领域的专家，看到的资料也还比较有限，也不排除自己的见解中存在局限或者误区。因此，欢迎大家进一步的交流讨论。

　　EMC ViPR目前是以软件的形态，运行在3-5个服务器虚拟机组成的集群上。它包括控制平面(Control Plane)和数据平面(Data Plane)两部分功能。前者实现的是自动化存储管理，包括：多租户、自助式门户、计量和调配等;后者可以说是建立在前者对文件存储的管理之上，提供全局数据服务，包括对象存储、HDFS(Hadoop分布式文件系统)和其他服务。

　　ViPR对外提供开放的API接口，在它的底层由各种不同的阵列组成虚拟存储资源池。目前已经支持的应该有EMC VMAX、VNX、Isilon、NetApp FAS系列数据块和文件存储，VPLEX存储虚拟化产品在ViPR看来也属于一种块存储。未来还会支持Atmos、Centera对象存储、EMC收购并新推出的XtremIO全闪存阵列，更多的第三方存储(视情况而定)，以及由商品服务器、硬盘等组成的廉价存储设备。

一、关于控制平面

　　1.ViPR与存储虚拟化 

▲传统的带内(In-band)和带外存储虚拟化原理示意图

　　EMC提出ViPR是一种(高级的)存储虚拟化，IBM则认为目前的软件定义存储(SDS)属于存储虚拟化2.0，未来还会有3.0。不过我们也看到ViPR的控制平面和OpenStack的Cinder项目，与传统存储虚拟化还是有着明显的差别。

　　存储虚拟化，是位于后端存储和前端服务器之间的一个抽象层。带内块级虚拟化的代表有IBM SVC、EMC VPLEX，以及可以安装在x86服务器上的赛门铁克Storage Foundation卷管理器软件等，它们的特点是数据路径和控制路径都要经过存储虚拟化设备，这个环节上有缓存，但也可能增加延时、形成性能瓶颈，以及新的故障点。

　　带外SAN存储虚拟化的代表产品，比如早年被LSI收购的SVM(OEM给惠普的SVSP)、EMC Invista等已经基本消声匿迹。它们的特点是控制路径与数据路径分离，在后端存储与前端服务器连接的基础上，增加专门的元数据服务器，以及定制的光纤交换机或者数据路径管理器(DPM)。昆腾的StorNext SAN文件系统尽管架构上有点类似，但它向上呈现的是一个共享文件系统，而不是块设备-块设备。

　　带外存储虚拟化理论上可以减少延时的产生，但元数据服务器却容易成为瓶颈，特别是在高IOPS的交易型数据存储应用中。最初这些产品不能支持精简配置(thin-provisioning)，另外由于不像带内虚拟化那样具备缓存，包括复制在内的数据保护等高级功能也很难实现。

　　EMC ViPR的控制平面与以上两者都不同。尽管也是带外的控制路径，但它并不处理元数据，抽象的只是存储设备的管理功能，完全不参与服务器到存储之间的数据访问。

　　在EMC的资料中这样写道：

　　“ViPR 将存储及其所有独特功能从物理阵列中抽象出来，并创建单个虚拟存储池。ViPR 将存储控制路径与数据路径分开，数据路径可帮助 ViPR 集中所有数据调配和数据管理任务，而且支持应用程序访问数据块和文件数据，因为它们始终具有并且继续使用底层阵列的独特功能... ViPR 数据块和文件服务保留了阵列的所有高级功能，如镜像、克隆、快照、多站点高可用性以及复制。”

　　ViPR也宣称掩盖了底层存储的复杂性，但它实际上调用的都是那些阵列的功能。相比之下，SVC、VPLEX这些才是真的将后端阵列当作标准块设备来使用，事实上后者更多地用于数据镜像，远程复制、容灾等用途，也包括EMC宣传的“双活数据中心”概念。这部分是ViPR之类的软件定义存储产品所无法替代的，也就是传统存储虚拟化继续存在的价值。

　　最后一个问题，IBM SVC、EMC VPLEX使用标准的FC协议仿真主机的形式来连接后端阵列，因此它们比较容易拥有一套庞大的设备兼容性(互操作性)列表。而ViPR则不同，即使EMC自己的不同产品线也使用不同的操作系统，像VMAX和VNX的FAST(全自动存储分层)功能可能还有代码上的通用性，而Isilon集群NAS的OenFS则完全是收购来的技术。要想通过ViPR实现所有高级功能，针对每个家族的阵列应该都要通过一些专用的API来实现，因此要做的工作很多。关于这些我在后面还会有具体一些的讨论。

　　2.ViPR与存储管理

　　我听说过IBM TPC(Tivoli Storage Productivity Center)、NetApp OnCommand等存储资源管理软件，NetApp的FAS/V产品线相对单一，而TPC每次升级版本，加入自家新产品支持都不只是做些兼容性测试那么简单的事情。ViPR与这些传统的存储管理软件有什么不同呢，我在EMC中文技术社区中看到了下面这个问答：

　　Uehara Y.问道：“与比如Storage Essentials (HP)这样的软件相比，ViPR的优势是什么？它们都能提供存储虚拟化，但区别在哪？”

　　Mark_Prahl 回答：“Storage Essentials是类似与EMC Resource Management Suite的解决方案，用来监控并报告存储性能、容量使用情况以及可用性，帮助你了解存储环境。

　　ViPR创建虚拟存储池，以服务目录的形式呈现给用户，这可以通过自助服务网站访问。与Storage Essentials此类仅提供存储环境信息的存储资源管理软件不同的是，ViPR能将性能度量信息告知存储资源管理解决方案软件，而且ViPR可以集成EMC Storage Resource Managment Suite。”

　　3.VMAX Cloud Edition的扩展？

　　在“自助服务网站”，以及根据用户的性能需求SLA分配存储资源的特性方面，我觉得ViPR可能是之前的VMAX Cloud Edition(最早叫VMAX SP)的进一步延伸，或者说受到后者的启发——即EMC尝到了甜头之后，把这些功能推广到各条产品线。

　　ViPR与“Cloud Edition”共同的特点是：简化部署，并使管理工作智能化。

　　4.ViPR与OpenStack

　　记得在EMC刚宣布ViPR的时候，国内一位熟悉OpenStack的专家曾表示：“所谓控制平面和数据平面，不就相当于Cinder和Swift吗？”关于OpenStack的Swift对象存储服务，我们在后面还会谈到，这里先看看Cinder块存储服务与ViPR的差异。

▲OpenStack Cinder连接EMC VNX/VMAX提供iSCSI访问模型

　　由上图我们看到，用户通过REST连接到Cinder的Volume API(Cinder是从Nova Volume发展而来)，而Volume Manager则使用EMC提供的驱动连接到SMI-S Server，再通过REST连接到阵列——这样的一个控制路径。Cinder同样只负责存储资源的分配，而不参与到数据访问路径中。

▲OpenStack Cinder连接NetApp FAS提供iSCSI访问模型

　　上图中的NetApp Filer指的就是FAS系列，由于做NAS出名了人们习惯将它称为文件管理器，在这里也是提供iSCSI访问(OpenStack后来的Cinder版本已经支持FC了)。我们看到稍有不同的是，NetApp的Cinder驱动不像EMC那样通过业内标准的SMI-S管理规范来实现与阵列的对接，而是使用了自家的OnCommand管理平台。相应的，在Cinder驱动和管理服务之间的接口也由CIM换成了REST。

　　EMC ViPR同样能够支持SMI-S和REST，后面的一个图片中有简单说明。

　　这张图，是在EMC发布ViPR之前对软件定义存储的描述，其中浅蓝色的部分正是今天的ViPR。或许它描述了ViPR与OpenStack之间的关系——既然ViPR已经实现了对底层不同产品线的支持，向上就可以使用几个通用的适配器驱动来分别支持Swift对象、Glance虚拟机镜像和Cinder卷服务？即而ViPR充当中间层，不用再为每个系列的存储单独写驱动了？

　　5.扩展阵列支持

　　上图中可以看到ViPR与存储阵列之间的几种接口，以及对第三方阵列开放支持的架构。下面我摘录了EMC资料中的一些文字：

　　“要成为真正意义上的软件定义的存储，平台必须能够可编程。ViPR 提供简单而强大的表述性状态转移 (REST) API，从而与多供应商存储资源建立了连接，就好像它们是一个大的存储池一样。”

　　“使用 SMI-S 和供应商阵列提供的大量 API，EMC 为不同的阵列构建了适配器，并且提供了简单一致的 API，用于构建新适配器以支持新阵列。这将创建一个可扩展的“即插即用”存储环境，该环境可以自动连接到、发现和映射阵列、主机以及 SAN 连接结构。管理员和开发人员还可以开发跨阵列并且支持混合数据类型(如文件中对象)的独特新数据服务。”

　　“EMC 将发布 ViPR API，以帮助添加新阵列适配器和新数据服务。这样，开发人员可以专注于添加的功能和价值，而不必操心底层存储的细枝末节。ViPR 还支持企业和服务提供商建立开发人员社区，吸引开发人员和 ISV 加入进来，进而不断扩大增值数据服务的规模。”

　　OpenStack最大的优势在于开源，因此主流厂商纷纷支持并提供驱动，但相对松散的联盟使它在存储管理方面暂时还只能实现一些相对基本的功能，比如Cinder项目还不够成熟完善，由NetApp提出的文件服务还处于Beta阶段，Swift不适合一些场景(没有适合所有场景的吧？)等。

　　ViPR则恰恰相反，尽管还未正式发布并处于完善的过程中，但可以预料它在OpenStack不足的那些方面可能会做的更好。但是友商们会积极支持ViPR，并愿意看到它成为业内标准吗？

　　二、关于数据平面

　　1.文件中的对象数据服务

　　谈到ViPR数据平面提供的对象存储功能，暂时还没有看到相关的图片，下面从EMC资料中摘录了一些文字。

　　“开发人员可以创建这样的对象数据服务：

　　不仅能在普通廉价磁盘上运行，而且还可以访问对象，将对象存储在文件服务器上并利用该文件服务器的性能。在此示例中，ViPR 还提供通过数据路径访问对象存储，也可以通过数据路径访问文件服务器。例如，组织可以在高性能 NAS 设备上存储、访问和操作对象，而不必重写现有基于文件的应用程序。”

　　“最初，ViPR 文件中对象数据服务为用户提供了使用 Amazon S3、OpenStack Swift 和 EMC Atmos API 管理对象数据以及访问文件系统上的数据的功能。ViPR 文件中对象数据服务提供对文件阵列的直接路径访问。特别是，由于企业写入到文件系统的现有应用程序不必重新编码即可利用 ViPR，因此他们可以从此功能受益。”

　　在“普通廉价磁盘”上运行的对象存储，这就和Swift等比较类似了，而EMC的主要意图应该是后者——存储在文件中的对象。

　　对象存储通常不强调性能，比如IOPS以及单个对象访问的带宽等，但像一些高端对象存储可以实现的整体带宽也相当惊人。比如用于高性能计算的Lustre文件系统其实也属于一种对象存储。从某种角度上说，ViPR的对象数据服务，能够利用到Isilon这样高端NAS的性能这种说法也可以讲的通。

　　ViPR不仅可以让VNX、Isilon和NetApp FAS这些文件存储增加了对象访问，它还能够让相同的数据同时支持文件协议和对象接口，这一点的好处除了上面提到的，还可以在NAS和兼容Amazon S3、EMC Atoms的云存储之间直接进行数据迁移。

　　就像国外某内部人士的观点：Atmos与Isilon用例的定位“……非常清晰;Atmos旨在满足地理分布类需求，而Isilon+ViPR的组合则实现通过对象接口访问现有NAS数据的愿望。”

　　他为什么拿Isilon用例而不是VNX、FAS(ONTAP 7-Mode)来做说明呢?可能是Isilon的容量、文件系统单一命名空间和节点扩展的数量与那些大型对象存储部署相对接近吧?

　　这句话来自国外的一篇“EMC四大对象存储内部竞争的讨论”，里面提到了Centera、Atmos、Isilon和ViPR四款产品。首先应该排除Isilon，因为它是通过ViPR来支持对象数据的;其次Centera应该说基本处于不再投入，有人要就卖的“等死阶段”，毕竟Atmos已经兼容它的API了。

　　在这里我有一个疑问：就是对象存储通常有独立的数据路径和控制路径，就像HDFS单独的NameNode那样。如此说来，在不对NAS设备文件系统改变的情况下，提供对象支持也就意味着由ViPR节点来提供元数据服务?

　　如果是这样的话，在添加ViPR之前NAS中已有的数据如果想通过对象方式访问，就需要先遍历所有文件系统生成相应的元数据，并在后续数据写入时同步更新NAS和对象存储的元数据?

　　接下来再看看其他厂商的情况：

　　华为N9000(MVX)大数据存储参考架构图，该产品基于他们的CSS分布式文件系统

　　我们注意到，华为的N9000集群存储也提供了S3对象访问接口，但笔者不确定同一个数据对象是否能够兼容NFS/CIFS和Amazon S3访问。

　　惠普在IBRIX集群文件系统方面的动向是：“适用于 StoreAll REST API 的 HP StoreAll OS v6.3 附带提供对象模式，可在一个存储平台中支持融合文件和对象。”

　　至于HDS的HUS和HUS VM，号称数据块、文件和对象真正的统一存储，它们得益于HNAS(收购自BlueArc)带有对象特征的文件系统。

　　2.HDFS支持与Isilon

　　ViPR对HDFS的支持，其实与对象存储比较类似了。需要注意的是，Isilon早在去年就宣布提供对HDFS的支持，类似像上面的华为N9000也是如此。

▲Isilon OenFS操作系统兼容HDFS访问

　　3.业务连续性/移动数据服务

　　最后一点，ViPR与业务连续性和远程数据访问有什么关系呢?

        再引用一段EMC资料中的文字：

　　“EMC ViPR(虚拟)块控制器与 VPLEX 和 RecoverPoint(物理)块数据节点相结合，为通过快照、复制、高可用性和城域内的移动性支持任何工作负载的 VMAX 和 VNX 块存储提供全球业务连续性和移动数据服务，而所有这一切都通过一个管理控制点进行理。”

　　这里主要针对的是本地和跨数据中心存储高可用、容灾，加入ViPR的意义同样在于实现“单点管理”，包括对VMAX、VNX阵列，VPLEX(它们都集成了RecoverPoint拆分器)，应该还有RecoverPoint设备本身。

　　本文中部分文字和图片，引用自EMC官方文档、媒体翻译国外网站的内容、以及国内同行发表的相关内容。