One of the challenges with storage sprawl is managing all the different islands of storage. Physically separate storage systems can be more difficult to manage. This is especially the case if they’re from different vendors, since each system has a unique software management layer, with unique features and capabilities. Each software management layer operates differently, which can add to the complexity of a sprawling storage environment.
Software Defined Storage (SDS) attempts to resolve this by removing all the different storage management software solutions and replacing them with a common one. To work, IT needs to assign all available capacity on all systems to the SDS system and gradually migrate workloads to the new volumes under control of the SDS software. IT must learn a new way of executing the various features, including volume creation, snapshots, and cloning.
One of the primary frustrations with most SDS solutions is that they often don’t provide capabilities beyond what the organization has already been using. At best, the features may be a replacement of what already existed on the various storage systems. It’s rare for the SDS system to add capabilities or improve performance. In many cases, there are capabilities built into the hardware vendor’s software that are lacking in the SDS system, forcing the organization to compromise and sacrifice capabilities to get a single management plane.
Another point of irritation is that SDS replaces something the customer already owns. The problem lies in the fact that most storage management software is bundled in with the storage hardware, and very few vendors have the option of removing it for a reduced price. At this point, SDS is even impacting future purchases. Again, the customer needs to compromise, choosing between buying storage from a tier two vendor or continue buying from their tier one vendor, but do so knowing they are paying twice for software.
Another challenge is that as storage media gets faster and continues reducing latency, storage software may become the bottleneck. Typically, the storage software runs on a server or virtual machine, now separated from the storage hardware, and the overhead of accessing that storage may be bottleneck performance. There are a few SDS vendors that address the performance problems, but they require attaching white box storage systems directly to their control server.
A final challenge is, even if the organization goes all in with SDS, they may find themselves running multiple SDS software solutions. It’s not uncommon for a software-defined data center (SDDC) to have multiple SDS solutions. They may have an SDS solution for their virtual environment, another for the high-performance unstructured data environment, and still another for secondary storage. Once they introduce multiple SDS solutions, the organization loses most of the management efficiency it gained when it committed to SDS in the first place.
Conclusion
SDS can be a big leap of faith. The organization should commit fully on the SDS solution for it to buy off as a consolidation solution, because the commitment to migrate data into the environment is significant. While SDS does provide storage hardware flexibility in the future, SDS locks the organization into its software. The addition of new workloads may force the organization to introduce new SDS solutions, eliminating any management advantage they might have gained.
The software approach of SDS is the right start, but alternatively the software can be less ambitious. Instead of taking over storage operations, let the software monitor the environment, providing IT with a dashboard. When a problem occurs, the dashboard automatically directs IT to the management software specifically designed for the affected storage system.
There is another consolidation method that organizations also consider when trying to get their arms around storage resources—it’s called hyperconvergence. We’ll examine this approach in our next blog/chapter.