Yesterday, I did a post on ESA here - which is an example of tight integration and packaging of vRealize Operations Management and the EMC storage portfolio.
Today's Federation Treat cuts right to the core of the federation principle of focus in each part, with each pursuing an "open" model. Short version: Through solid VMware/EMC collaboration and the principle of "Choice" as paramount, EMC ScaleIO 1.31 now available, and along with many other goodies - also has a vmkernel loadable module for a more direct IO path that nets 2x-3x better performance than the prior VSA model.
Like all my blog posts - I'm now going to do my best to explain the ins/outs and hairball topics like "what SDS and when". It's a time investment for you, but you'll have a much more complete picture than if you're a "sound-bite only" type. :-)
"Software Defined" is getting to redonkulous levels of buzzword bingo, but I've tried to be consistent in pointing out it has 3 parts:
- Abstraction and decoupling of the control plane/policy ("what" is needed) and policy from the data plane (the thing that does the work on "how" the "what" is delivered)
- Where the data plane can be delivered in software decoupled from hardware - do it that way.
- Everything is consumed via programmable open APIs
The 1st and 3rd items in that list - a software-defined control plane (both in the networking and storage domain) are the most disruptive in the sense that it changes the way you use infrastructure - enabling much better opex models. BTW - this is the value prop of NSX around network programmability - which is difficult to quantify. Ditto with the EMC ViPR controller. Both killer technologies - but hard for people to immediately "grok" an opex benefit vs. a capex thing.
The 2nd in that list - a software-defined data plane (both in the networking domain and the storage domain) is the most disruptive in the business sense because it really messes with people's existing business models - mostly in the capex and acquisition model (appliance vs. software only). BTW - instructive to compare again to the SDN domain. in NSX, this is the value prop of NSX's microsegmentation play - which is about getting better firewall security by wrapping vApps each with their own firewall. Software defined data planes are things people tend to focus on because there is a "physical device" we're familiar with that gets displaced and the function runs on commodity hardware. Humans like to visualize things :-)
The 2nd in that list is the place where VMware VSAN and EMC ScaleIO play, and compete in the SDS domain.
Yesterday, EMC ScaleIO 1.31 was released (bits are available for EMCers and partners here*). The single most important new thing is the GA of the new client that integrates with the vmkernel in vSphere 5.5 (and will continue into vSphere 6.0). This was previewed at VMworld (and there are demos) here in gory detail. What's the net?
- 2x - 3x better throughput (IOps) and Latency when using the ESX SDC (this is the "client" part ScaleIO) than the VSA model (which follows a contorted model of presenting an iSCSI target out and then back up the IO stack through VMFS).
- The vmkernel loadable module is listed and supported through the VMware PVSP program (see here: http://kb.vmware.com/kb/2096169)
- Improvements in the vCenter plugin to make deployment and management easier.
- Broadened platform support (OpenStack Juno, RHEL 7.0, CentOS 7.0 in addition to SLES 11)
- Lots of other goodies (improvements to the RAM cache, API programmability and more)
*For customers who want to give it a whirl (or are buying another EMC thing) there is a KILLER "Starter" kit which is very low cost, and you'll immediately get a sense of where and how ScaleIO can be used.
When it comes to ScaleIO/VSAN and the topic of VSA vs. kernel IO paths - can be accused of being wrong, or delusional, but no one can accuse me of inconsistency :-) Here's a post from more than a year ago that's worth a read in the context of today's news and another as I tackled (and learnt a lot - as you can see from visible comments and edits) the topic of IO paths: ScaleIO now has a client that is a vSphere 5.5 kernel loadable module, and we've deepened the vCenter plugin integration (as well as a ton of other stuff)
Let me elaborate a little - because this comes to the crux of "if there are two SDS data planes that I could use with vSphere, which should I use, and why are there two if you are a Federation?"
Read on for more!