Hyperconverged Infrastructures (HCI) move software-defined storage (SDS) – described in the last blog – into the hypervisor cluster. The SDS component either runs as a virtual machine or as part of the hypervisor kernel itself. The SDS solution typically leverages storage media internal to each node in the hypervisor cluster, creating a virtual pool of storage. Some solutions cache data locally on each node for each VM to assist with read acceleration, and stripe new or modified data across the cluster for data durability. The pseudo-tiering technique motivates some HCI vendors to claim that they consolidate storage, in addition to converging infrastructure.
If each node has its VM’s data cached locally, and new or modified data is striped across the cluster, then the software is performing some level of storage consolidation. Also, as new compute nodes are added to the cluster, storage capacity is included with it. If the primary reason for storage sprawl is lack of per storage system capacity, then the data center may see a storage consolidation benefit from HCI.
The challenge is that many storage expansions are not necessarily capacity-motivated. Often, there is a performance motivation for purchasing a new storage system because the current storage system can’t meet the performance demands of new or scaling applications. In HCI the problem is more pronounced. HCI only works as a storage consolidation tool if all workloads are virtualized into it. Most data centers that use HCI don’t have 100% of their workloads in the HCI environment, and most data centers don’t have 100% of their workload virtualized in any form. There are simply too many concerns with delivering consistent performance to mission-critical applications when those applications need to share their storage resources with the rest of the data center.
In fact, in many cases, the opposite is true: HCI is used for a specific workload, like Virtual Desktop Infrastructures (VDI), and the other workloads run in their own environment. Since most HCI solutions do not support storage outside the hypervisor cluster, they actually make storage sprawl worse by forcing the creation of a separate storage system.
The reality is that the concept of scale-out storage is not exclusive to HCI. Plenty of capacity-centric storage systems provide scale-out capabilities. But even dedicated scale-out solutions have their issues. Once again, if the primary reason for expanding a scale-out system is capacity driven, then it may be able to consolidate storage. The problem is that scale-out systems typically have limitations on performance. For scale-out architectures, if there are many workloads running in parallel, then additional nodes will keep up with the performance demand. If, however, the organization has just a few applications that need hundreds of thousands of input/output operations per second (IOPS), which is often the case, then the scale-out system will struggle to meet performance expectations.
While software is – yet again – the right direction, using HCI for consolidation is a challenge. Performance-oriented storage systems almost always run alongside HCI storage. Additionally, most organizations have a stand-alone NAS system to meet unstructured data requirements.
The reality for most data centers is that there are too many workloads where a generic storage solution, be it a single hardware solution or a software replacement of storage management software, won’t be enough. The situation continues to worsen as new applications, like NoSQL and environments like containers, are brought into the enterprise. Instead, organizations need a software solution that provides oversight and insight into storage system usage and data storage, but also leverages the capabilities of those specific systems for the task at hand.
In our next blog we’ll explore the advantages of a distributed storage architecture, and then we’ll conclude with a blueprint of that architecture, yet still be able to manage it properly.