EMC ViPR：步入商用正轨前经受锤炼

SRM榜样

但在ViPR路线图中，我们面对的是一个睽违已久却又非常新鲜的领域，且与之前的异构存储管理产品紧密相关。还记得AppIQ吗？2005年该公司被惠普收购，其存储资源管理（简称SRM）软件产品能够管理采用SMI-S标准的各品牌阵列方案。但仅做到这一点还远远不够，总体来说大多数拥有上述特性的SRM产品供应商都没能在市场上生存下来。

ViPR也许会成为一款多厂商SRM产品；但只有第三方存储阵列供应商或其它第三方开发商愿意为ViPR编写软件模块，帮助其与目前市场上的存储阵列产品进行对接时这一假设才成立。另外，他们还需要在产品更新换代及功能开发变更的同时继续保持这一趋势。

大家不妨考虑这个问题：为什么惠普希望为StoreServ编写ViPR接口模块？惠普这样做的目的是什么？这个问题恐怕无法得到肯定答案。与此类似的还有戴尔、IBM、富士通以及HDS。EMC可能在开发NetApp接口。这一方面是因为EMC能够利用一套模块实现ONTAP产品的全面对接支持，而且NetApp也是EMC最大的独立存储业务竞争对手。

云存储经济学

ViPR还希望通过云存储经济学帮助EMC吸引客户，且无需对原先已经部署的EMC遗留工具进行改动或者更换。EMC的想法是将商用存储设备与ViPR的上层存储阵列功能（VMAX、VNX、Isilon及Atmos阵列都拥有该功能）相结合；从而实现与EMC原本相对昂贵的专用设备相近的使用效果。

当然，我们不可能获得可与VMAX、VNX、Isilon或者Atmos方案比肩的性能表现，但从企业运营角度看，经济优势比使用效果更加重要。

商用存储硬件的引入意味着什么？这表示ViPR必须与之相连接，并向其发出指令；因此我们期待一台仅由处理器与存储硬件构成的极简型机箱，而不再依赖过去的JBOD方案。除非商用存储使用标准化操作系统，否则软件就要由处理器来运行，而且每台商用存储设备都必须搭配与之相适应的ViPR连接模块。

大家不可能像利用磁盘驱动器填充Drobo阵列那样随便通过商用存储组件构建ViPR体系。

ViPR接口模块

要使用来自其它供应商的商用存储，供应商或者EMC自己必须为ViPR编写接口模块。我们不禁要问，EMC公司会如何帮助商用存储供应商（例如Infotrend）编写ViPR接口模块，并把他们推向EMC客户？恐怕单凭“不要再花钱买什么VNX或者Atmos了，我们的廉价工具能帮你搞定一切块、文件或者对象存储工作”这样的说法无法令人信服。

那么EMC需要采取怎样的客户激励措施？

EMC如果能够确保商用存储硬件能够以附加周边设备的形式用于特定用例，且对VMAX、VNX、Isilon以及Atmos的营收不造成影响，那么这套方案就有受到接纳的可能。但其实现过程仍将困难重重。

正如之前的多厂商SRM产品及多厂商存储虚拟化产品一样，ViPR很可能无法彻底发挥自身的潜在价值。这是因为将ViPR接口模块与底层硬件的软件版本层保持匹配绝非易事——更不用提为来自各家异构存储硬件供应商的设备各自开发接口了。

另一方面，它无法将用于替代昂贵专用阵列的商用存储设备推向EMC客户群，因此ViPR用户也就无法从规模经济中获得成本回报。

如果Srivastava和他的技术团队能跨过这两道障碍、真正让ViPR进入商用化正轨，那么这套方案的发展前景将不可估量。祝他们好运。