What Is Hyperconverged Infrastructure and How HCI Works
This is the first of a five-part series on HCI. I hope you enjoy and this prompts discussion. Please feel free to reach out to me via Twitter at @MBLeib.
What Is Hyperconverged Infrastructure?
Hyperconverged infrastructure is one of the new hot areas of technology in the IT data center space. Like most areas of technology, there are the marketing words and then there’s the definition. So, what’s the definition? There’s no industry-wide meaning, but in my opinion, it involves the management of an architecture based on hardware, software, storage, and a hypervisor. As this audience is familiar with hypervisors, I’m happy to skip the “what is a hypervisor” conversation, but in certain cases the architecture supports VMware but not KVM, Hyper-V, or some flavor of software. In other cases, the architectures will support all of them. Let’s be clear here, though: I believe the original concept of this category is all built around the hypervisor, hence the term “hyperconverged.”
I don’t believe it involves a compute/storage environment, but without the hypervisor. So, for example, in the backup space, Rubrik and Cohesity, with no disrespect, are converged but not hyperconverged. And, believe me, there are many advantages in the converged arena as well, but by my definition, this isn’t that. I lay no claim, by the way, to the veracity of my definition.
The history of such an architecture goes back to the launch of the EMC/Cisco product, the vBlock. The idea when this was created was of a compute environment powered by VMware and Cisco servers (UCS), a switched environment powered by Cisco Nexus, and, of course, storage by EMC. The product was chosen by size requirements. Your compute engagement would be built around supporting the VMware load, and the storage would involve all your storage requirements. Seems easy, right? It wasn’t. These were first-generation builds and required much in the way of fine-tuning and technical support. At the same time, NetApp introduced their answer to this with the FlexPod. These were first-generation products, and though they were built quite robustly, they were tougher to manage than ever intended.
Soon came the launch of products from Nutanix and SimpliVity designed around industry standard x86, and initially a shared spinning-disc storage environment with a virtual SAN architecture spread across nodes. This became a far more viable build, with sizing around three or four node x86 clusters. Scalability was initially difficult, as once you outgrow your sizing or your storage, the requirement would be to spend on a full cluster once again.
Alternative builds arrived on the scene from brands like Datrium, and NetApp, VMware VxRail, as well as others, which had the idea of using storage nodes and compute nodes as separate components. This gave the customer far friendlier ways in which to grow the architecture. No longer were you limited by the storage/compute limits. If you needed more storage, you’d place a storage node into the cluster, and if you needed compute, well, that was easy as well. I find these architectures compelling.
As you can see, there are many approaches to resolve a converged architecture, with varying approaches designed to solve a variety of inherent issues. With so many options to draw from when pursuing this option, your data center needs will be likely resolved by one of these.
I’d also like to stress, as has always been my opinion, that the idea of convergence may not be appropriate for some scenarios. Orchestration elements have become far more sophisticated, such that “pools” of resources can be provisioned from the whole using a variety of methods, depending on the hardware to be leveraged. Sizing, needs, scalability, and other variables can be used to achieve either the same or similar goals. The build of servers, fabric, storage and network are still viable options. Also, a potential need can be solved by using a newer version of the converged architectures available, as HPE has done with the fully managed Synergy architecture.
Before endeavoring to implement an approach, be sure that your goals are being met by the solutions you pursue.