Software-defined storage provides IT organizations the ability to separate the individual costs of software and hardware when deploying storage architectures.
SDS systems effectively let customers take open source or licensed software and deploy it onto physical infrastructure, usually generic servers. The benefit of using SDS over traditional hardware appliances is that the IT department can optimize the acquisition costs of each part of the infrastructure to suit their own needs. This can mean, for example, choosing hardware that fits within existing internal practices or support models.
Why SDS now?
Why has SDS become a viable option for storage deployments? Over the last five or more years, storage vendors have been gradually transforming their products to work with commodity or "off-the-shelf" architecture and removing the complexity of custom hardware components. Today's servers, controllers, hard drives and SSDs are relatively cheap and reliable. As a result, many functions that in the past would have been delivered through custom hardware can now be delivered with commodity components and software. This is the key essence of SDS systems -- software is becoming smarter and this is now where the value sits.
Why SDS over traditional?
The idea of building a bespoke storage system may seem daunting for many IT organizations; however, in today's data storage market, the challenge isn't as great as people think. The majority of new object storage platforms, for example, are being designed to be software-only, with vendors letting the customer choose the hardware or pick from a list of reference designs. SDS also offers some operational benefits that can't be achieved without moving to a software-based platform, such as integration with the public cloud. Most SDS systems can be run as virtual machines or public cloud instances, making them a practical way to move data in and out of public cloud environments without being tied to the cloud provider's storage product.
Picking the right hardware
Finding the right hardware platform is an important first step in implementing an SDS infrastructure. Typically, there are three ways to implement SDS:
- On commodity hardware recommended by the SDS vendor. The SDS vendor provides a range of hardware products that have been pretested and validated to work with the software.
- On commodity hardware selected by the customer. The IT organization chooses its own hardware components and builds the product directly.
- As virtual instances. The software is run entirely on virtual infrastructure.
Choosing hardware recommended by the vendor has its benefits. First, the configuration will have been tested and validated to work with the SDS system -- there are unlikely to be any firmware or driver compatibility issues or surprises. Second, the SDS vendor will have designed the hardware configuration based on optimizing the combination of processor, memory, flash and disk. Totally self-built products will require the IT organization to do testing in order to validate each component and how they work together and to identify the right ratios of each, without wasting expensive resources or building in bottlenecks.
Vendor-supplied hardware configurations may well come with support, taking the headache away from managing device and component failures. However, this will naturally come with a cost. If the IT department already has support contracts in place with a server vendor, then the hardware component of the SDS implementation could simply be rolled into an existing master contract.
There is no right or wrong decision to be made here. The right hardware support model depends on existing vendor relationships and the ability for the IT organization to directly support hardware validation, both from initial design and testing through to spares stocking and replacement. The latter points may, of course, require developing new skills and operational processes to get working.
Management and monitoring
One of the key benefits of using a traditional vendor offering is in the ability to take the knowledge and experiences of many customers and identify hardware issues at an early stage. Having data from many customers allows storage vendors to identify patterns that may emerge in, for example, higher than average drive failures or perhaps performance issues with certain controller cards.
IT organizations building their own SDS infrastructure need to put processes in place to identify these kinds of issues. Otherwise there is a risk that the storage deployed will be less reliable and potentially more expensive than necessary.
Building a TCO
Without putting in place some total cost of ownership (TCO) calculations, there's no direct way to tell whether an SDS-based storage product offers better value than simply going with a traditional vendor. So far in this discussion we have highlighted some of the components to be considered, whether to use commodity or vendor recommended hardware, building out a design and support operation, and monitoring the success of storage deployments.
Each of these areas needs to be built into a comprehensive TCO calculation that compares the cost of running SDS compared to a traditional storage structure. Many organizations compare simply on the cost of hardware acquisition, and this can be acceptable if the operational requirements of SDS don't have a direct burden on the overall cost. The key here is being sensitive to those costs and adjusting behavior accordingly.
Finally, we should give a mention to continual improvement of SDS infrastructures. Storage vendors have to be more conservative in their adoption of cheaper and better hardware components -- for example, large-capacity HDDs -- due to the potential impact on their customer base. With SDS systems, IT organizations can be more agile to make use of new hardware as it emerges, continually reducing the cost of delivering storage over time.
To make SDS systems work successfully, IT has to effectively become its own storage provider. At scale, the opportunities for savings are significant and worth the effort of investing the time and energy to deliver.
Reduce the confusion around SDS systems
Is SDS really as innovative as they say?
A hard look at the claims of SDS vendors