One thing I really hate about our industry is all the people who just take their existing product and then re-label it as the new hotness. Come on people, you're better than that.
Just as Cloud before it and SDDC more recently, the term "Software Defined Storage" (SDS) has suddenly become very hot in the storage industry. Amazingly, it turns out that almost every storage vendor ALREADY HAS a great SDS product that they've been making for years!! WOW! These guys are really good.
Wait, what?
Yes, that's right. Now that SDS is hot, everyone is simply claiming that their product is already a great SDS platform (surprise!). Sometimes they do this by simply redefining the term (see here for example). Others just blatantly ignore the facts. Still others do actually have really cool SDS products.
You can see the problem here. Those not very close to the subject quickly become confused. What does this term actually mean? What should I do about it? Is this something I should really care about? This then becomes FUD (Fear, Uncertainty and Doubt) that prevents truly great products from being adopted because of all the noise. You can see this happening with SDS on Wikipedia where they claim SDS is simply a marketing term and doesn't really have a definition or purpose.
That's really sad because SDS is actually one of the more revolutionary things to come out of the storage world I quite a while.
So, what is SDS, really?
Software Defined Storage (SDS) is
a Storage Management Architectural Pattern that allows for the remote
management and configuration of storage assets. Because SDS is a
management architecture, it is completely abstracted from the underlying
hardware infrastructure. In other words, SDS describes a “Control Plane”
architecture that is separate and distinct from a “Data Plane” (or “Data Path”)
architecture. SDS is being driven by the movement of datacenter
architectures to highly automated, policy driven management frameworks (such as
VMware’s vCloud Suite or OpenStack). This movement is closely related to "Cloud" and to what is sometimes referred to as "Software Defined Data Center" or SDDC. These frameworks require highly
abstracted management layers in order to isolate the Cloud Management Framework
(CMF) from underlying infrastructure details and/or changes. There are
three main components to these Cloud infrastructures: Compute, Storage
and Network. SDS is the control plane for the Storage component of cloud
infrastructures.
SDS has the following mandatory
attributes:
1)
All functions must be
available via a simple remoting interface. This is normally done via a
web style (SOAP, REST, etc.) interface but this is not a requirement.
2)
SDS is defined as a
“Control Plane” or out of band management channel. This is normally done
via an IP based management network but this is not a requirement. Note
that SDS cannot be implemented in band by definition due to the restrictions of
physical connectivity.
3)
SDS solutions must
offer a single control plane (also referred to as a “control surface”).
Underlying systems can be disjoint or multi-vendor but the SDS solution must be
unified to claim that it is actually a SDS solution.
4)
SDS is independent of
the “Data Plane” or I/O path. This implies that all current and future
storage protocols (FCP, FCOE, iSCSI, NFS, etc.) can be driven by an SDS based
interface. However, all dependent components must also be managed by a
single control plane. For example, FCP based solutions must have a single
control plane for zoning and LUN masking.
5)
SDS implies deep
integration with physical storage assets and supported operating systems and
hypervisors. Being able to present, remove, backup, replicate and perform
other storage operations implies a deep level of integration with the
underlying physical asset and the hosts (physical or virtual) being
serviced. However, SDS does not specify how this is performed. SDS
is not synonymous with virtualized storage.
It is important to note that SDS
is not synonymous with cloud nor is a SDS compliant platform required in cloud
scale architectures. However, SDS does provide many of the storage
abstractions required by these types of architectures. Also, SDS is not
synonymous with “Virtualized Storage” which is also commonly associated with
cloud scale architectures.
It is important to note that
abstraction and “virtualization” of Data Plane constructs (LUNs, iSCSI, Storage Aggregation Layers, Storage "Hypervisors," etc.)
is separate from but related to control plane constructs. Innovations
such as auto-tiering, Flash based cache, de-duplication, virtual storage
controllers, software based arrays, etc. are all concentrated in the data
plane. Each of these provides opportunities for SDS innovation via the
control plane but they, themselves, are not directly related to SDS nor is SDS
dependent on any one of these data plane technologies or architectural models.
Anyone care to offer a different definition? Let's get it on!
