« EMC World Day 1: Data Protection Beyond Backup, Cloud, Simpler. | Main | EMC World Day 1: VxRack 1000 Technology Preview »

May 04, 2015


Feed You can follow this conversation by subscribing to the comment feed for this post.

Isaac Aldana

Great post it´s the answer for a lot of customers


Very interesting read. This is something my organization is working through at the moment, so it is a very timely post.

I was wondering what would be used for running open SDS?

Mark Burgess

Hi Chad,

All interesting stuff - I am particularly keen on the idea of using VxBlock with commodity servers as this will open up the market for the product to the entire mid-market where UCS is overkill.

I would also be keen to get your thoughts on EVO:RAIL/VSPEX Blue as I am struggling to understand the target market.

I appreciate it needs to be simple, but it just does not look like a good fit for most organisations - specifically:

Why would you have to use vSphere Enterprise Plus?
Why would you not have perpetual rights to all of the software?
Why would you want 4 under-powered nodes?
Why would you want the minimum number of nodes to be 4 (2 or 3 would be better)?
Why would you scale in 4 node increments (1 would be better)?
Why would you not allow the addition of extra drives?

More thoughts are at http://blog.snsltd.co.uk/vmware-changes-evorail-licensing-but-still-gets-it-all-wrong/

I just do not get it, hopefully you can help.

Many thanks

Chad Sakac

@Issac - glad you liked the post!

@Alex - in the case of the "Open SDS", I'm talking about a transactional SDS layer that could be used to underpin the persistence layer of a transactional (think low latency) VM on vSphere, KVM, Hyper-V, or a physical host, or a container abstraction layer. What we would use would be ScaleIO (more info here: http://virtualgeek.typepad.com/virtual_geek/2015/05/emc-day-3-scaleio-unleashed-for-the-world.html

@Mark - VSPEX Blue/EVO:RAIL is designed for simplicity above all else. This means the answers to your questions are:

Q: Why would you have to use vSphere Enterprise Plus? A: frankly, in the appliance market, the question isn't "what is the licensing of the sub-component" - but rather "do we get the economic envelope right". If we don't do that - it doesn't matter how simple it is :-)

Q: Why would you not have perpetual rights to all of the software? A: do you know of any of the appliance models that have a perpetual right to all the software? on all enterprise appliances that I can think of, there is a term for maintenance and support. That is, in effect, the terminus for the rights to the software that powers the appliance. There is always some form of term. Personally, I think the EVO:RAIL OEMs should be able to make that variable (based on licensing terms from VMware). Unfortunately, we don't.

Q: Why would you want 4 under-powered nodes? A: Currently the EVO:RAIL program specifies the hardware down to a very proscriptive degree to ensure a very consistent experience, and that applies to VSPEX Blue and all the OEMs. You'll note that the VxRack will have current Haskell-Based systems and a large degree of hardware variation day one.

Q: Why would you want the minimum number of nodes to be 4 (2 or 3 would be better)? A: partially this is technical. Almost all SDS stacks that are real scale-out designs need 3 nodes as a minimum. This then translated to the "should the EVO:RAIL program enable a 3 node config with a 'add a fourth'".

Q: Why would you scale in 4 node increments (1 would be better)? A: tight configuration control = simplest experience. VxRack should enable more flexible scaling, including single nodes. I'll update you at the GA target (note that VxRack is a 'tech preview' - which means not GA in that quarter - ergo will be July 1st at minimum :-)

Q: Why would you not allow the addition of extra drives? A: see the theme :-) tight hardware configuration control = simplest experience. Mark, respectfully, for most customers, this falls way off the "config variation" desirability spectrum (I get the hardware power/memory and node count ones). Adding a "disk only enclosure", or "detect and add more spindles in existing chassis" adds more variation that in general doesn't net much.

To summarize - your Qs are exactly why IMO, there's a need for a hyper-converged stack that enables more flexibility in multiple dimensions. Disk-only enclosures are an example. More rapid introduction of new hardware. More variations of hardware (VxRack will start with 15 node types). More variability in what software stacks arrive.

It will be interesting ultimately to see what the market is for very fixed appliances relative to the more flexible hyper-converged systems.

Thanks for the input!


Hi Chad,
Hope you are doing well !

With the ScaleIO Node launch today we were very careful not to use CI nomenclature, and hold strong to our "Software Defined Storage" ground.
However the "Performance Optimized" config, is designed for the provided servers to run applications. With Compute+Memory+[software defined]Storage, this distinguished guest, while in disguise, may be permitted to the CI club, may it not?

Agreeably SIO Node is not HCI, however your HCI taxonomy is still logically applicable, and I tried to align the SIO node with it in my mind:

Massive Scalability, Supreme Elasticity, unparalleled Flexibility, spell RACKS (Design Center = Flexibility). Agrees with your terms "System Architecture = Defined by the SDS layer". Presumably EMC white box servers are COTS.

At the same time, the name "Node" and the "Proven" theme (Pre-Validated, Certified, single support by EMC) smells of "BLOCK" ("disaggregated compute/memory/network/storage – loads of variation") ...

Relating to the quote you referred to in another blog: "[..the multitude of single-trick products in EMC's ever-confusing product portfolio - with an increasingly incoherent architecture ..]" - is not entirely without grounds..

Wonder what your thoughts are ?

Chad Sakac

@Boaz - thanks for the comment. May I suggest taking a read through this: http://virtualgeek.typepad.com/virtual_geek/2015/09/scaleio-node-whats-the-scoop-and-whats-up.html#comments

The short answer: The "system architecture = defined by the SDS layer" is actually not fully correct. It's better stated this way: "system architecture = defined by the M&O layer sophistication + SDS layer"


Thank you, thank you, thank you, thank you!!!!

This is the first and only post that really explained the use cases of the varying VCE offerings. This should be on the EMC site!

Great work!

The comments to this entry are closed.

  • BlogWithIntegrity.com


  • The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by Dell Technologies and does not necessarily reflect the views and opinions of Dell Technologies or any part of Dell Technologies. This is my blog, it is not an Dell Technologies blog.