Software-defined Storage: Fairy tale or Reality?


Nowadays the air is filled with the Software-defined Datacenter or SDDC for short. The idea behind this is awesome: As soon as we are able to define and manage compute, storage and networking using software only, we can define, build, scale and destroy virtual datacenters at the press of a button. On top, there’s a web portal. Underneath, there is just a generic x86 hardware platform.



Software-defined Storage

Software-defined compute is something that has been going on for years already. Most vendors that sell hypervisors, especially VMware have a lot of work into the software-defined pillar that is called “compute”.

But when we look at the storage component of the Software-defined Datacenter (often called SDS or Software-defined Storage), things aren’t as advanced as in the compute pillar. Or are they?

I would like to split Software-defined Storage into two models: The Horizontal and the Vertical model. In the horizontal model we have nothing but a generic hardware layer with (distributed) software on top. A true scale-out model. By adding generic disks and SSDs in the generic hardware platform, we can now create a distributed software layer on top of this hardware, and have all the hardware work together to create a fully software driven SAN. A few good examples of such technology is EMC’s recently acquired ScaleIO or the technology announced by VMware called vSAN.

But is this horizontal model always the right model for storage? How will this model cope with performance, malfunctions and resulting availability? This is where the second model, the vertical model steps in. In this model we do still use dedicated hardware for storage, and we consume from there. The positive side of this is a vast choice of platforms, maturity, higher availability and performance guarantees. Even though some dedicated storage hardware is built using the horizontal model (good examples are EMC’s Isilon and XtremeIO), they are generally consumed in the vertical model.

But especially this vertical model posed a challenge in the Software-defined arena: Because we use specific hardware, we require specific controls for orchestration and monitoring. And here is where inefficiencies arise: What if I have multiple models of storage, or even worse, storage platforms from different vendors? What if a SAN is replaced by its more recent version?


EMC’s ViPR

EMC’s ViPR delivers a solution to the challenge above. ViPR takes control of the physical storage infrastructure, and delivers storage from the storage devices to the host(s). All of this through a standardized, open API using policy-based terminology. Through this one standard API ViPR will deliver storage to hosts, whether this storage is type X or type Y, or even brand X or brand Y.


EMC's ViPR - The first open, multi-vendor solution to Software-defined Storage!

EMC’s ViPR – The first open, multi-vendor solution to Software-defined Storage!




No matter where the physical storage needs to come from, ViPR is always controlled through the same API. With this, it is the first and only product I’ve seen that realizes a fully policy-based Software-defined Storage solution even for a multi-vendor environment. SDS is no longer just a vision, it is a reality!


Competition?

I have seen some initial responses from ViPR’s potential competition. Most responses show that either competing vendors do not get the concept of policy driven SDS, or they push their products forward stating they’ve been doing this for years (where they really have not).

When you look closer, ViPR definitely delivers something unique to the market in my opinion. We need to be able to talk to some component from for example vCenter Orchestrator (vCO) or vCenter Automation Center (vCAC) in some generic way. Then we just request X amount of bronze, silver or gold storage to be delivered to Y and Z hosts, without the hassle of finding the right tier on the right device with enough capacity and performance, then to decide which scripts we’ll require to talk to that specific piece of hardware… And I did not even mention the storage network or more complex scenarios like storage layers that virtualize and/or stretch storage like VPLEX or IBM SVC (no those are NOT SDS solutions)… ViPR makes your work in “software-defining” the datacenter SO MUCH easier when it comes to storage it’s almost scary.


Conclusion

With VMware being successful in “software-defining” compute and quickly gaining ground “software-defining” networking (look at vCD, Nexus 1000V and especially their acquisition of Nicira), it is great to see that EMC stepped up to the plate and manages to “software-defining” storage.

My guess is that it won’t be long before we can truly order virtual datacenters out of a very generic physical one through a simple web interface displaying a menu with side orders. Do you want a small, medium or large? The sweet dessert will be agility, simplicity and scalability with a touch of self-healing.

One Response to “Software-defined Storage: Fairy tale or Reality?”

Soon to come
  • Coming soon

    • Determining Linked Clone overhead
    • Designing the Future part1: Server-Storage fusion
    • Whiteboxing part 4: Networking your homelab
    • Deduplication: Great or greatly overrated?
    • Roads and routes
    • Stretching a VMware cluster and "sidedness"
    • Stretching VMware clusters - what noone tells you
    • VMware vSAN: What is it?
    • VMware snapshots explained
    • Whiteboxing part 3b: Using Nexenta for your homelab
    • widget_image
    • sidebars_widgets
  • Blogroll
    Links
    Archives