Software-defined storage (SDS) within the container realm often ignores storage itself. In essence, the SDS platform assumes some chunk of storage is mapped to a container host. Then, it takes over from there. SDS for containers is the orchestration through which persistent storage is mapped to a container. This gives it a unique ability to provide a mount point the SDS layer can control. It also provides a unique view of the world. SDS for containers bypasses traditional storage yet provides for retention, replication, and erasure coding. These are just some of the features, but it does not care what storage is underneath the container host. This assumption could lead to issues down the road, but how does this work?
Articles Tagged with SDS
Software-defined storage (SDS) is about data services. Many think it is about automating storage. Yes, I can see that, but it is about what storage can deliver. So, what is the basis for SDS? There are four critical components. These components are analytics, augmentation, aggregation, and security. These four elements wrap storage to become data services. Data services and control thereof are therefore the key components of SDS. What data services can SDS provide that do not already exist? Is it just enough to add deduplication, or is more necessary? Let us look at these data services in detail.
Recently, Nutanix got awarded a key patent for software-defined storage, and it got me thinking, “What is SDS?” Well, to me, one key aspect of SDS is the fact that it is hardware agnostic. Therefore, by default, Nutanix is not a provider of SDS. Now, don’t get me wrong: Nutanix is an awesome product and quite innovative in its offerings.
But, software-defined storage it is not. Hyperconverged? Yes.
Today finally marks the announcement of the general availability of VMware VSAN. This is VMware’s most public beta to date.