« Get EMC World Area 52/53 (and other) goodness here | Main | Summer Gift Part 1 Project Mercury Beta Open! »

June 09, 2014


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

Chuck Hollis

Hi Chad -- Great discussion!

I have to say, I find myself continually unsatisfied by the definitions of software-defined storage that most of us are using.

Most of them center around a programmatic exposition of pre-defined storage capabilities, e.g. here’s your gold, silver, bronze, etc. — what do you want? Maybe we’ve changed the interface, but we really haven’t changed the underlying model.

Maybe it’s the fact I work for VMware, but we’re pushing for a far richer model: storage subsystems expose potential capabilities, applications expose a policy-based manifest of what they need, and the SDS layer dynamically composes a storage container and associated data services precisely aligned on application boundaries.

Change the policy, the SDS layer either instructs the storage to adjust, or transparently moves the workload to a new location where the new conditions can be met.

The difference might be described as fast food where everything is made far in advance vs. a sit-down restaurant where your meal is cooked to order.

As I’m not all that familiar with the direction of Cinder and related projects, I’m not sure whether this is part of the broader thinking or not. From what I understand, Cinder does bring a lot to the table in terms of consistent access to underlying resources (a good thing) but seems entrenched in a static model.

Time will tell whether people demand a more dynamic model (such as we use with compute) or not.

Best regards!

-- Chuck

Keith Norbie


Love the post but slight take issue. In the overall context of SDS I do think the objective we're trying to reach is moving orgs from hardware defined to software defined on the same way servers used to be hardware defined. (remember BMR, ugh) IMO SDS can be defined for Commercial and SMB with a single array or a small amount of similar arrays. Tintri gave use one of the 1st arrays that did this. Abstracting to a non-storage specific output that is VM centric was a good start. I would argue that we just need to get beyond these barbaric means of serving storage through LUNs, etc. 2nd Platform is a good mess to address (and I'm having a ton of fun doing that with EMC). IMO 3rd platform SDS become interesting due to programmatic interfaces. I love that an Exabyte of ATMOS in run by 4 policies (no SMB, no NFS, no LUNs). THAT's SDS too :)

Chad Sakac

@Chuck - thanks for the comment, and it's great to hear from you Chuck! I don't think that you're off on an island (or that it's a uniquely VMware view). IMO, abstraction, automation and policy is good (period!), but that ultimately the infrastructure itself should adapt to policy demands, and SLO/SLA adherence.

That latter part is not an easy technical problem (and I think we're a ways away from that - but you can see the industry aiming at that target, from VM-level policy, through to QoS mechanism etc). I know we're both working on it!

@Keith - I agree that SDS has a key element of "policy" and similar to Chuck's point - when you can do it at the unit that the application/use case demands, it's good. Tintri, and VSAN with VM-level operation are examples. I'm very much looking forward to VVOLs which will (I think) move the industry as a whole forward. It's notable that not all application/use cases consider the "VM" as the desirable unit - for a lot of analytics workloads, an HDFS object is the "unit", or a KV store pair as an example. BUT - the meta point is valid: LUNs and filesystems are not (for many use cases) the "desirable unit". I stick to my guns though - while that's GOOD, the point is about programmability (with the unit of policy/automation being the right one for the given use case). I would also argue that if that programmability is "tied" to a given hardware platform, I struggle to call it "SDS"...

The debate rages!

Thanks for the input guys!

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.