The Basics of Hyper-convergence

In the customers I speak to, there seems to be some confusion about the hyper-converged story. Vendors are doing a great job in communicating the benefits that an HC platform can provide, but it seems that many people just don’t understand the requirements. As an example, I was speaking to a customer the other day who thought that implementing a specific HC solution would do away with the need for switching between the hosts. The assumption was that all storage and machine related activities would occur at a hardware level within the HC appliance. Sadly this is not the case.

Different Flavours of HC

All HC solutions are based on the principle of aggregating discrete storage across the hosts in the cluster. Most solutions recommend some flash and some spinning disks, usually in 1:10 capacity ratio, however there are quite a few all flash options out there now. It’s not ‘RAID for servers’, but the comparison is quite useful, and the concept of N+n for HA server environments is now carried across into the storage layer, so an N+1 solution would contain the CPU, RAM and Storage resources required to tolerate the loss of a single node with no impact to service.

An HC architecture is built around a core Software Defined Storage (SDS) platform, which manages the discrete storage layers. HC platforms fall into one of two categories, Kernel-embedded or VSA managed. Kernel (or OS) embedded systems such as VMware vSAN or Microsoft’s S2D mange the storage layer from within the Hypervisor, this functionality is built in and enabled if required, whereas VSA managed systems use virtual appliances to manage the platform.

Kernel-Embedded

The advantage of this type of deployment is that is can greatly reduce the resources required to run an HC platform, therefore maximising the resources in your HC estate. It could also be argued that adding the code required to run the platform to the Hypervisor itself makes the whole platform more stable, with less moving parts and therefore less variables.

However, using a hypervisor specific HC solution means that it can only be used with that vendor’s software. For example, vSAN can only be used to support a new or existing vSphere environment, not as the storage platform for a Hyper-V deployment, not that this would make sense anyway.

The below diagram shows how storage is managed for this type of deployment. Each host in this example would have circa 200GB of flash and 2TB of spinning disk.

VSA managed

This seems to be where most of the HC vendors play. Nutanix, Simplicity, Maxta and others can’t embed their storage aggregation service within the key player’s Hypervisors, so they use a Virtual Storage Appliance (VSA) to provide similar functionality. This adds a step to the previous diagram, whereby the VSA’s take the raw disks passed to the hypervisor from the hardware, and present them back to the hypervisor through the VSA. Generally, a VSA exists on each host and one is elected as the master, identified by red text in the below diagram. This master orchestrates the flow of data through each appliance, and provides a management console to users.

Once again, each host in this example would have circa 200GB of flash and 2TB of spinning disk.

The advantage of this type of deployment is that the VSA’s can be agnostic as to which hypervisor they are working with. VMware specific VSA’s can be deployed to manage storage in a VMware environment, or Hyper-V specific VSA for Hyper-V. Nutanix even provide their own hypervisor in Acropolis, which is based on KVM. There is also an argument that, if one of your storage appliances fails, it doesn’t take your hypervisor down with it. However, this does come at the cost of additional resources for the VSA’s, and an overall more complex environment.

Many of the features in this space are marketing driven, but some of the design decisions are really worthwhile. Nutanix’s ability to squeeze 4 servers into a 2u block for example makes a real difference to datacentre density.

Which Approach Is Best?

Both are valid, and it will often come down to requirements. Personally, I feel fundamentally more comfortable with ‘in-kernel’ solutions due to their low resource footprint, but they may not necessarily offer the best of breed solution. VMware don’t currently offer anything that will match the density of a Nutanix block, and the costs associated with purchasing vSAN are high. It should be remembered that, while HC solutions do offer a great alternative to 3 tier designs, hosts still need to communicate and move data via a switch fabric - there are no 'self contained' solutions that I am aware of, and such a design may cause problems when you want to scale out.

With Dell now committed to VMware and Microsoft offering S2D with datacentre licencing, I hope that we can soon buy a Dell branded, server-dense vSAN ‘block’, and that VMware see Microsoft as enough of a threat in the SDS space to significantly reduce their vSAN licencing costs, or drop them altogether.