State of the art – integrating storage and VMware – Part II

In the first part of this post (definitely start there if you haven’t already read it) we talked about our early steps (which are available!) to make storage more 'invisible” for VMware administrators – admittedly by actually making it MORE visible to them – giving them easy access to the information they need to understand quickly and easily the relationships from the VM layer to the storage layer.

The next part – how do we do that for storage administrators?  

This is the “upcoming present for CLARiiON folks using VMware” I’ve been referring to.  

Today, a storage administrator lives in the land of LUNs and filesystems and hosts (and to a lesser extent object storage models).   In the mainstream cases, the storage admin has no awareness of the objects inside the LUNs/filesystems or beyond the host connectivity itself.   This makes resolving problems and optimizing much much harder in virtualized configurations because in the end, the virtual machine is the atomic unit.  The virtual machine is the thing that is either happy/unhappy.

Ideally – storage would become VM-object aware.

Now, this is our first major steps down this path – and only just the beginning (and will not be CLARiiON only, but all EMC platforms).  As I said in part I – ideally all the parameters of what the virtual machine needs would be wrapped up in the OVF definition, and the infrastructure simply adjusts to respond (hint, think of what EMC is doing with FAST and what we’ve talked about publicly).

We’ve actually already delivered this for the last year in our “manager of managers” for storage – ControlCenter, which has been VMware Ready certified (meaning it leverages the VI SDK and ESX CIM APIs) for some time.

Today – I want to show you what this is making us to do our platform element managers themselves with a quick preview of what’s coming in the next major FLARE rev.   We are doing the same

If you’re a CLARiiON customer using VMware – READ ON!

Rather than explain this in large amounts of text (as I’m wont to do) – watch this.

It’s here in high-rez format

I think this will be awesome for EMC customers. 

While we are the first vendor (that I know of) to do this publicly, over time I think this becomes pervasive as a core design principle in all our element managers.   BTW - this idea of “VM object awareness” is also already in Recoverpoint also as of 3.2 which is GA, will do a post on that shortly.

In the mid-to-long term, we are actively working down the path of even deeper integration (there’s only so much you can do via the VI SDK) using the vStorage APIs.

If you have many arrays, and want to see how we do this today across environments (including heterogenous ones), look at this post here.

Thanks – and this is just a TINY part of what we’re gearing up for VMworld – remember, you can sign up via the EMC link and get a discount off the standard price….

Comments

[Elias Patsalos]

Cool stuff.

thanks!

Elias P

[Justin Watermann]

So basically its like Xiotech's Virtual View a year later? Does it leverage web services as well?

[Chad Sakac]

Justin - thanks for the comment.

The key thing that we think we're doing differently is tackling this from both ends - the VMware Administrator and the Storage Administrator. In some cases there is only one person doing both, but in many cases, there are two people.

Both want to have end-to-end visibility in their natural context. For VMware administrators - that's in vCenter, and for the Storage Admin - it's in the storage management interface (which is either an element manager - like Navisphere; or a heterogenous manager of managers - like Control Center).

As far as I know - this is indeed the first instance of the actual element manager integrating with the vCenter APIs. It's considerably harder than an external model that reads both the storage array APIs and the vCenter APIs and presents them in a new format. The reason it's harder is you have to fit into into the release train and development path of the full-blown element manager (or manager of managers).

This is why our vCenter plugin actually came before the VM-Aware Navisphere update. We've now covered 3 bases - the VMware administrator, the Storage admin using the element manager, and the storage admin using an manager of manager (enterprise storage resource management).

(BTW outside the area of storage - we also have a security plugin, a configuration compliance plugin, and something we're demoing at VMworld this year that will blow people minds on the topic of end-to-end dependency and relationship mapping).

BUT - the upside for the customer is that it's in the right, natural context - for both types of users.

Now, I don't claim to be an expert on Xiotech. A quick glance at the public materials suggests that Xiotech's tool is an MMC plugin. Is that the rest of their management model as well? MMC plugins can be hard to "extend" - does the virtual info kind of "hang off" the rest, or is it right integrated in? For example, when you're doing a task on a LUN (in the natural context the Xiotech user would be, can they (in context) drill down and get VMware-level info including virtual disk relationships, performance info, and other (applied against those objects, in context?).

BTW - there's no restriction on innovation - I think it's great that many vendors are integrating in all sorts of ways with VMware, and customers can look at, evaluate and make a choice that best suits them!