De-Mystifying Software-Defined Storage
De-Mystifying Software-Defined Storage
Join the DZone community and get the full member experience.Join For Free
Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.
Software-defined Storage (SDS) is being spoken about everywhere these days and various definitions of SDS are floating! This write-up is an attempt to represent SDS in simple language!
Storage has traditionally been defined and managed in software only – create LUNs/volumes or NFS/CIFS shares on storage arrays and export them! So, why is the industry abuzz with Software-defined Storage and how is this different?
In a single line - the attempt is to make the software intelligent, so as to make it easy for the user!
In traditional systems, the requirement was to have block or file storage to execute I/Os, which required software configurations like RAID-levels, LUN creation, NFS/CIFS share creation and so on. But, as technologies evolved, various configurations like thin provisioning, compression, deduplication, tiering got introduced! This provided a better control and optimization with respect to user’s requirements, but at the same time it complicated things as everything has a trade-off! For instance, inline deduplication would optimize storage capacity but impact performance! So, how does a user ensure that all his requirements are met within the acceptable limits i.e. optimal storage capacity with acceptable performance numbers? This is how the scenario can be represented -
And, imagine the scenario when requirements get refined! The admin has to revisit and redo stuff!
Now, consider the case of Software-defined compute – Server Virtualization! With hypervisor software from VMware, Hyper-V, etc. the user defines the basic requirements like CPU cores, CPU speed, RAM, HDD capacity and he is automatically provided a VM to work with!
Can something similar be done for Storage? (In fact, it started under the name of Storage Hypervisor and eventually got renamed to Software-defined!) The idea is to let the user define his requirements in terms of Quality of Service (QoS) parameters like storage capacity, IOPS, bandwidth, etc. and he should be given a storage interface to store his data irrespective of what lies underneath!
Also, reconfiguring or modifying the properties should be as simple as shutting the VM and making the changes! Add to this advance capabilities like cloning, migration, DR, etc. on a per storage entity basis! The idea is to make it simple in line with Server virtualization with all the benefits of scalability, availability, etc.
There are many debates as to what a SDS solution should do, but at high-level, it should certainly do the following –
· Hardware Abstraction aka Storage Virtualization – Like the Hypervisor Software layer does! The user should be able to obtain storage without worrying about underlying hardware or associated proprietary storage management software!
· Orchestrate the complete process of mapping the QoS parameters to storage allocation – Based on the QoS requirements like data availability, capacity, CPU performance, the software will algorithmically decide which RAID levels are to be applied, which replication or erasure coding mechanism is to be applied and so on. For instance, when a user requires 500K IOPS, the software will be intelligent enough to assign SSD drives instead of HDD drives! Hence, once the parameters are entered by the user, the software will automatically provision and provide the user with access to corresponding storage (Just like how VMs can be obtained from public cloud like AWS)
· Provide APIs – To allow applications to programmatically make adjustments to storage! For instance, an application can ask for more resources when it predicts that a peak period is about to begin!
And this is how the above illustrated scenario can be represented after incorporating SDS –
All the individual software levers (compression, RAID levels, etc.) are set automatically by SDS software, based on the QoS requirements. Hence, SDS needs to have the intelligence to match QoS parameters to Storage parameters (done manually by the admin earlier). An example of the parameters to match could be –
Lot of discussions around open standards, commodity hardware, additional features, vendor lock-in, etc. are being carried out and this is will continue as SDS evolves! But, the basic idea is to make user’s life simple!
Opinions expressed by DZone contributors are their own.