Last week, in part one of this blog series, we explored the business and technological benefits of Software-Defined Storage (SDS). Catch up here.
Now, let’s take a look at best practices in selecting and deploying an SDS solution.
Assuming we’ve bought in to the theory that SDS will improve the lives of storage administrators (while simultaneously lowering operating costs for the business), how should we approach this new paradigm shift in our industry?
If you have deployed new technologies in the past, you probably have some scars (physical or emotional) to prove it. Your experience has taught you that there is no magic bullet. You know that you are not setting up a brand new SAN with static business requirements for the life of your equipment. You need flexibility and agility to pivot with business requirements (a big benefit of the SDS design).
When undertaking a shift of this magnitude, it helps to remind yourself that “Paradigm shifts in technology compels paradigm shifts in methodology.”
In fewer syllables: “when tech changes, we need to change too.” When evangelizing VDI in its infancy, several of my customers tried to use their implementation practices that had been successful for 20 years. Unfortunately for them, the test methodologies and focused POCs just didn’t work in this new technology architecture. Drawing on past experience with implementing new technologies with what we know about SDS, let’s look at one of the first things to consider when deploying Software-Defined Storage.
Software-only SDS vendors provide the software without associated hardware and allow you to assemble your storage infrastructure using the methods described above, either by aggregating existing storage resources or by building your own storage array. These products should provide all the cost reduction and increased flexibility benefits that we discussed last week.
Vendor-provided SDS comes bundled with the storage hardware. These vendors have leveraged the basic tenets of SDS (ie; abstraction of software from hardware), but still bundle the software with their specific hardware.
There are benefits and drawbacks to both solutions. Software-only adds the burden of making it difficult to determine what hardware is supported by each software vendor and how much support they provide for hardware/software conflicts. Following hardware selection, Software-only also tends to have a more complicated initial implementation due to the options/combinations an architect needs to configure.
Vendor-provided solutions provide the vendor (not the customer) with flexibility. While this type of SDS may not be considered “true” SDS, it can still provide value for the customer. It allows the vendor and customer to quickly upgrade hardware technologies. If the vendor separates the software upgrade process from the hardware upgrade process, it eliminates the nasty double charge.
Next week, we’ll take a look at a few suggestions on getting starting with your SDS environment.