Understanding the Basics of Hyperconverged Infrastructure

If you’re looking to grasp the fundamentals of hyperconverged infrastructure, or HCI, you’ve come to the right place! This is the first in a 10-article series that will provide the foundation needed to move forward with your HCI journey. Once you’ve finished this part, move on to the second article, the best use cases for HCI. For now, let’s begin at the beginning—why HCI became a thing in the first place.

A decade or so ago, ‘HCI’ entered the modern data center lexicon and turned legacy data center architecture on its head. Since the very first computers were invented, technological progression has been the norm, with organizations seeking to harness the raw power of these advancements to fuel their businesses, improve their bottom lines, and race ahead of their competitors. Unfortunately, even as technology became increasingly accessible for end users, it also became more complex, forcing companies to hire legions of expensive personnel to manage it.

In its most basic original form, HCI is a conglomeration of servers, storage, and a hypervisor. All of the workloads in an HCI environment run inside the hypervisor, although recent iterations of the technology have added native container support as well.

At its core, hyperconvergence began life as a solution to storage challenges. More recent iterations of the technology have sought to break out of this mold and embrace networking, security, and cloud services, all of which have become essential elements in IT organizations. The original focus on simplifying storage has not suffered, though, as hyperconverged solutions slurp up more aspects of enterprise IT.

One area that’s been particularly interesting in hyperconvergence is the impact that it’s had on the hypervisor market. The hypervisor formerly held the lofty distinction as a strategic differentiator in enterprise IT. Today, that formerly strategic piece of software has been commoditized and democratized as a number of HCI players in the market have taken to building their own hypervisors, often starting with the open source KVM.

The result for these vendors is that they are able to more easily build solutions that leverage these purpose-built hypervisors and design new services around them, without needing to worry about the development cycle for a proprietary hypervisor.

Replacing Traditional Infrastructure

The sad truth is that technology has often been the cause of business inaction, with costly upgrades and onerous complexity as the norm. Businesses have hired expensive staff to try to wrangle these complexities into submission, but there have often been underlying factors that prevented success in these endeavors. The technology itself was built in such a way that expecting simplicity was considered a fool’s errand.

Perhaps the most notorious data center element in this reality was storage. Plagued by arcane constructs that hampered growth, and anchored down by a lack of advancement in spinning disk performance characteristics, organizations yearned for a day when storage was no longer chaining the company to the past, but was reimagined in a way that would lead to a better future.

This is where HCI has its original roots. Hyperconvergence began life as an answer to the common storage and scaling complexities of the day in the data center, but it didn’t come to life by itself. In fact, there were a number of trends merging at the time that HCI hit the scene, including:

  • The beginnings of the rise of affordable flash-based storage
  • CPUs with cores and cycles to spare. This meant that commodity CPUs could begin to replace what once required dedicated hardware engineering. Between this and the rise of virtualization, the broader software-defined or software-led ecosystem was born
  • The rise of the public cloud, which shifted the perception of how IT should run, and unveiled to the business untold possibilities when no longer shackled by outdated technologies and practices

HCI Architecture

The sad truth is that technology has often been the cause of business inaction, with costly upgrades and onerous complexity as the norm. Businesses have hired expensive staff to try to wrangle these complexities into submission, but there have often been underlying factors that prevented success in these endeavors. The technology itself was built in such a way that expecting simplicity was considered a fool’s errand.

There are a couple of different methods by which HCI works its magic. Since storage was the original driver behind the development of hyperconvergence, the focus here is on how that storage is managed: either with or without a controller virtual machine (VM). See Figure 1.

Both approaches have associated pros and cons. The most visible benefit of using a controller VM is flexibility. The controller VM doesn’t have to care all that much about the underlying hypervisor; it independently manages the storage functions on the host, and is eminently portable between hypervisors.

Perhaps the biggest downside of these constructs is that they consume resources and add an additional element in the data path that isn’t always present in other architectures. But the impact now is largely negligible, particularly as CPUs have gotten beefier and more capable over the years.

Figure 1. Hyperconverged infrastructure with a controller virtual machine architecture.
Figure 1. Hyperconverged infrastructure with a controller virtual machine architecture.

It’s true that the controller VM approach is RAM-heavy and ties up CPU cores, but typically the benefits outweigh the costs. These VMs are often handling data deduplication tasks: this requires CPU cycles, and RAM is needed to hold a lot of metadata. The positive is the data reduction—if you can substantially reduce the amount of data that has to be stored on disk, trading off RAM is worth it.

It’s also true that hardware cost associated with these tasks is far less than just a few years ago, so the overhead as a part of the architecture is reduced. Also keep in mind that today’s CPUs have dozens of cores, so carving a few off to handle storage functions that replace complex dedicated hardware is more and more a no-brainer.

The second approach to storage management in hyperconvergence, shown in Figure 2, is to allow some kernel module or hypervisor kernel module to handle storage functions. While this method provides a small bit of extra performance, it also shackles you to a single hypervisor. You may end up stuck with an expense piece of software within an ecosystem that you’d prefer to leave, but can’t.

Moreover, some of these solutions still carry with them the need for RAM overhead for metadata tables related to data reduction; so, while you may save a few CPU cores, it won’t have a major impact on the amount of RAM needed.

Hyperconverged infrastructure built on a kernel module architecture.
Figure 2. Hyperconverged infrastructure built on a kernel module architecture.

Under the hood, both solutions have the same outcome. The storage made available via the HCI cluster can replace what used to be a completely dedicated resource, which often required dedicated personnel and skills to manage. The heavy lifting of features such as encryption and data reduction shifts from what used to be dedicated hardware constructs to software-centric ones that can leverage much less expensive commodity hardware and achieve the same, or, in many cases, even improved outcomes.

You make a decision as to whether you want to buy an appliance with the hyperconvergence software preinstalled, or a supported hardware platform on which you install the software. From there, you create a HCI cluster that provides redundancy and availability in the case of a failure.

When the time comes to grow, you simply add more nodes and join them to the cluster. The management network behind the scenes handles the really hard work of making sure that data is always available, and to the appropriate VMs. Redundancy is provided through a combination of local hardware features as well as software capabilities that make sure data exists on at least two nodes in the cluster.

That wraps up this high-level HCI overview. Move on to the next article, and find out the scenarios in which HCI makes the most sense.

Click here for Part 2