|
|
软件定义存储之傻瓜说
提起ViPR，往往会涉及到软件定义存储、存储虚拟化、对象存储、OpenStack这些话题。笔者撰写本文的目的，就是想以尽量通俗的语言，站在与已有产品、技术形态对比的层面来谈谈ViPR的功能、定位，以及EMC推出该产品的目的。
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设备本身。
责编：驼铃声声
微信扫一扫实时了解行业动态
著作权声明：kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴，部分非原创文章作者信息可能有所缺失，如需补充或修改请与我们联系，工作人员会在1个工作日内配合处理。
|
最新专题
|
《存储前沿趋势开讲啦》第一季 .为大数据再造存..
华赛存储培训：第三章_raid技术_v2.0.ppt|
|
