97 lines
5.2 KiB
Markdown
97 lines
5.2 KiB
Markdown
---
|
|
date: 2013-05-13
|
|
title: EMC ViPR thoughts
|
|
category: Opinions
|
|
---
|
|
|
|
I have been a little slow on the uptake on this one. I would like to say
|
|
it is because I was carefully digesting the information, but that is not
|
|
true; the reality is that I have just had 2 5 day weekends in 2 weeks
|
|
:-).
|
|
|
|
The big announcement at this years EMC World is ViPR. Plenty of people
|
|
with far bigger reputations than me in the industry have already made
|
|
their comments:
|
|
|
|
- [Chad
|
|
Sakac](https://virtualgeek.typepad.com/virtual_geek/2013/05/storage-virtualization-platform-re-imagined.html)
|
|
has really good and deep, but long.
|
|
- [Chuck
|
|
Hollis](https://chucksblog.emc.com/chucks_blog/2013/05/introducing-emc-vipr-a-breathtaking-approach-to-software-defined-storage.html)
|
|
is nowhere near as technical but (as is normal for Chuck) sells it
|
|
beautifully
|
|
- [Scott
|
|
Lowe](https://blog.scottlowe.org/2013/05/06/very-early-thoughts-about-emc-vipr/)
|
|
has an excellent overview
|
|
- [Kate
|
|
Davies](https://h30507.www3.hp.com/t5/Around-the-Storage-Block-Blog/ViPR-or-Vapor-The-Software-Defined-Storage-saga-continues/ba-p/138013?utm_source=feedly#.UZCd_covj3w)
|
|
gives HP's take on it, which I sort of agree with, but not
|
|
completely. As she says, the StoreAll VSA is not really in the same
|
|
market, but I think it is the closest thing HP have so comparisons
|
|
will always be drawn.
|
|
|
|
ViPR is EMC's response to two major storage problems: 1. Storage is
|
|
missing some sort of abstraction layer, particularly for management (the
|
|
Control Plane). 1. There is more to storage than NFS and iSCSI. As well
|
|
as NAS/SAN we now have multiple forms of object stores, plus important
|
|
non-POSIX file systems such as HDFS.
|
|
|
|
Another problem I would add is that of *Openness*. For now there is not
|
|
really any protocols for managing multiple arrays from different
|
|
manufacturers, even at a basic level. They have been attempts in the
|
|
past (SMI-S), but they have never taken off. ViPR attacks that problem
|
|
as well, sort of.
|
|
|
|
In some respects I am quite excited about ViPR. The ability to
|
|
completely abstract the management of my storage is potentially very
|
|
powerful. For now it is not really possible to integrate storage with
|
|
Configuration Management tools. ViPR gives all supported arrays a REST
|
|
API, thus it would be very simple to create bindings for the scripting
|
|
language of your choice. Low and behold, a Puppet module to manage all
|
|
my storage arrays becomes possible. This very neatly solves problem \#1.
|
|
|
|
This is where my excitement ends however. The problem is that issue of
|
|
*Openness* I mentioned above. EMC has gone to great lengths to describe
|
|
ViPR as open, but the fact remains that it is not. EMC have published
|
|
the specifications of the REST API, they have also created a plugin
|
|
interface for third-parties to add their own arrays; this is where it
|
|
ends however. All development of ViPR is at the mercy of EMC, so why
|
|
would other vendors support it?
|
|
|
|
A lot of the management tools in ViPR are already in Openstack Cinder,
|
|
which supports a much wider range of backends than ViPR at present. In
|
|
that vendors have a completely open source management layer to develop
|
|
against. Why would they sell their souls to a competitor? Simple, they
|
|
will not. EMC exclusive shops will find ViPR to be an excellent way
|
|
integrating their storage with a DevOps style workflow. Unfortunately my
|
|
experience is that the sort of organizations that buy EMC (especially
|
|
the big ones like VMAX) are not really ready for DevOps yet.
|
|
|
|
Another feature that EMC has been touted is multi-protocol access to
|
|
your data. Block volumes can be accessed via both iSCSI and FC protocols
|
|
- nothing really clever there I\'m afraid. Dot Hill has been doing that
|
|
for several years with the [AssuredSAN
|
|
39x0](https://www.dothill.com/wp-content/uploads/2011/08/AssuredSAN-n-3920-3930-C-10.15.11.pdf)
|
|
models (and by extension the the HP P2000 as well). That is also easy
|
|
enough to do on commodity hardware using [LIO
|
|
target](https://linux-iscsi.org/wiki/Main_Page) plus a whole lot more.
|
|
On the file side, it gives you not only access to your data via both
|
|
CIFS and NFS, but it does add object access to that. They touted this as
|
|
being very clever, but once again you can already do this using well
|
|
respected, production proven open source. Glusterfs has an object
|
|
translator, so that covers that super clever feature. All the data
|
|
abstraction features it has are already there in in the open source
|
|
world. If you want object and NAS access to the same peta-byte storage
|
|
system, you have it in both Glusterfs and Ceph, both of which can easily
|
|
be managed by CM tools such as Puppet.
|
|
|
|
{% pullquote %} EMC has really pushed ViPR in the last couple of weeks,
|
|
but it fails to impress me. This is a shame, because in general I like
|
|
EMC\'s products. I don\'t like their marketing, but in their gear does
|
|
just work. ViPR will probably do well with large EMC/NetApp shops, but
|
|
it is by no means the ground-breaking product that EMC would have people
|
|
believe (to be honest, I\'m not sure anything ever is). It can never be
|
|
the universal gateway to manage our storage, it is too tied in to EMC.
|
|
{\"To be a universal standard it would need to be an open (source)
|
|
standard\"}, which is not really part of EMC\'s culture (with the
|
|
exception of the awesome Razor). {% endpullquote %}
|