In our last installment we saw how Hyperconverged Infrastructure, emerged as a term, and market segment, to describe products that integrated storage, and storage management in the same server platform to run VMs.
As all too often happens with terms that didn’t start with rigorous definitions, the marketing elves have stretched, or shrunk their meaning to met their needs, and/or their product. I’ve lost count of the number of times vendor representatives have insisted to me that some feature of their system, and only their system, was crucial for a system to be called Hyper-Converged.
Today we’re going to further define HCI as an architecture with design precepts a system must follow for us to call it truly HCI.
Precept 1 – Shared Storage From Server
The one key element to HCI as an architecture is that HCI systems use software to transform SSDs and/or HDDs across multiple servers into a resilient, shared, distributed datastore. Storage services in an HCI system are provided by software running on the same server CPUs as user services. The storage software can run as part of the hypervisor or operating system, or as one or more virtual machines (Virtual Storage Appliances or VSAs). This software layer, typically a distributed file system/object store replicates or erasure codes data across multiple nodes, and provides whatever data services like snapshots the system has.
Are two servers running a simple VSA or a half dozen servers running Linux and Gluster to create a clustered file system for KVM an HCI cluster? They are, but they’re HCI the same way my Clariion CX-500 is a storage array. That is that the CX-500 is, an old busted storage array, the others are HCI architectures but not HCI architectures I’d recommend to anyone.
Precept 2 – Scale-Out Storage Makes Scaling Easier
The storage software in an HCI system should create a shared-nothing, scale-out storage system. Some proto-HCI VSAs were limited to mirrored pairs of nodes. While there are many ROBO use cases best served by a two node cluster HCI systems must scale bigger than that.
Systems must allow expansion by adding additional nodes to existing clusters expanding both the available storage and compute resources. Ideally, clusters should allow heterogeneous, storage only, and compute only nodes, but we’re not going to require it for our definition.
If Simplivity didn’t rely on a PCIe card in each server for data reduction, I would go so far as to say HCI solutions were defined as running a software–defined storage service across the same servers that run user workloads. Since the term hyperconverged was coined with Simplivity in mind <See the last blog post>, we can’t declare being software defined as a requirement and exclude Simplivity from our definition.
While we’re allowing the Simplivity accelerator card, HCI is at its very core a software concept. A vendor like Broadcom could add a 100gbps Ethernet port to their RAID controller then use them to cross–connect multiple RAID controllers and distribute data across nodes. While this would have many of the advantages of HCI, it would be something different, not quite HCI. We’ll talk about a few of these almost HCI solutions in later blog posts.
Precept 3 – Managed by a Hypervisor
Since the Hyper in hyperconverged, by at least one derivation, comes from hypervisor requiring that an HCI system is based on a hypervisor seems obvious. HCI systems use the same servers to run user workloads and storage management, and the first few generations of HCI solutions all used a hypervisor to run the user loads.
More recently vendors like Rubrik and Cohesity have built scale-out appliances where their data management services, rather than, user VMs, present the CPU load.
Were these vendors stretching the definition of HCI? A little, but the primary and secondary use cases are so different I don’t think there was significant confusion created. If the backup data mover is the only user workload is that HCI? I’m not sure it is, but I’m also not insisting it’s not.
Would a system that ran containerized workloads and storage services across a pool of servers without a traditional hypervisor be HCI? I would have to say yes, being managed by a hypervisor may not be an absolute requirement.
Precept 4 – Integrated Management
To truly be hyperconverged, and not just uberconverged or super converged, convergence must extend all to the management interfaces as well. Administrators must be able to manage both storage attributes like data protection levels and virtual machines.
Architecturally any system that scales-out storage across internal storage of VM hosts can properly be called HCI. Philosophically, HCI is all about simplicity, and separate management consoles for VMs and storage just isn’t simple.
HCI, however, isn’t primarily an architecture, but more a philosophy of simplicity and a series of promises made by that philosophy, but that’s a story for another blog post.
Disclosure: DellEMC, Rubrik, Cohesity, and Simplivity have all been clients of DeepStorage, LLC.
Like this series on HCI? Do you want a more? I’m presenting a six-hour deep dive webinar/class as part of my friend Ivan’s ipSpace.net site.
The first 2-hour session is December 11. Sign up here
This post was published at www.deepstorage.net if you are reading it anywhere else on the internet it has been stolen and the thief running the site you are reading it at was too stupid to edit this out.