Easy Rider: get HCI platform efficiency

Generally HCI (Hyper Converged Infrastructure) means collapsing the traditional IT stack and replace a large number of physical devices with software, hence reducing power requirements and in some cases also reduce complexity. The typical HCI system is consumed as an appliance meaning server, software and support in one package. Combining several such appliances in a group, known as a cluster, renders a pool of resources that can easily be sliced up and presented as VM's (Virtual Machines) each of which is having a pre-defined set of attributes such as CPU, Memory, Disk and Network connections. The overarching task for any HCI system is to keep the VM's running at all times.

Typically, CPU resources in the physical HCI system is over-provisioned, meaning it is shared among multiple running VM's (Virtual Machines) often refereed to as "threads" or virtual CPU's. The underlying operating systems time sharing abilities manages these threads. You will not be able to run an unlimited number of VM's because of RAM limitations (see below). If each running VM is assigned one thread each (one vCPU), the total number of threads in the cluster (minus the threads needed for the HCI itself: efficiently coded HCI means less threads) defines how many VM's can run concurrently without competing or waiting for access to such a CPU resource.

Contrary to the threads situation above the quite costly physical memory resources (RAM) installed is typically not shared across VM's but instead "kept" by each individual running VM as its private space for the duration it is powered on. This means that the maximum number of VM's that the HCI system can have running at any one time is limited by the available amount of RAM. Now, that is almost true, and this is where different HCI systems based on their architecture behave quite differently from a cost efficiency standpoint.

For the scope of this discussion let's define Efficiency in the HCI system as the ratio of total RAM installed and total RAM available to customer VM's. Such efficiency is then logically expressed in a percentage (%). 

For example:

• An HCI system is built around three servers, or nodes, forming a highly available cluster and each of the servers have 256GB of physical RAM installed.
• The software, effectively the HCI, that delivers the high availability functionality underpinning the VM's, including data storage services is consuming 4GB of memory.
• This leaves 252GB on each server or a total of 756GB RAM available for the user VM's across the three nodes in the cluster.
• The base HCI efficiency in this HCI system example is therefor 252/256=98,4%
• If the software making HCI at all possible is instead consuming 128GB per node the base HCI efficiency becomes much less: 128/256=50%.

Of course this also means that having a more efficient HCI system consuming only 4GB as in the example above it is possible to run such HCI on smaller servers, having perhaps merely 64GB physical RAM installed, in which case the second 128GB example simply would not work at all. A use case for such a small HCI system would e.g. be in an retail store in a largely distributed enterprise.

This type of deployment is often refereed to as a ROBO -installation (Remote Office Branch Office) where highly available systems are required but fewer VM's are present and the cost of the system needs to be kept low as there are often many stores scattered across a very large geographical area.

The picture below shows an example of the GUI (Graphical User Interface) used by a 128GB Scale HC3 system where the HCI consumption of RAM is clearly displayed and also how much RAM memory is left for customer VM payload in each of the three nodes mentioned. In this example only four VM's are currently running (white rectangles) three of them have allocated 4GB each and one (running at the middle node below) requires 8GB of memory when powered on.

As for the three node example, it is important to point out that the customer will never fill up all the available RAM memory on all nodes with VM payload. This is because for whatever reason a node is down (either permanently broken, or simply rebooted as part of scheduled HCI software maintenance) there has to be room for the VM's running on that node to automatically migrate over to one of the two remaining nodes, in order to make the maintenance non-disruptive. Sorry, there is no magic to this. This is what the HCI does: keep the VM's running at all times.

Examining the lack of RAM memory efficiency, it is indeed compounded rendering real cost.

In this example and for this reason, we have to leave out 1/3 (252/3= 84GB per node) of the available RAM capacity leaving 504GB in total available for use by the customer VM payload in the three node HCI example in order to stay fully resilient. If we added another identical node we would have to set aside 1/4 (252/4=63GB per node), 1/5 (252/5=50.4GB per node) with five nodes and so on. More nodes in the HCI cluster (up to 8 nodes max) allows us to consume ever more RAM per node and still remain fully protected from a VM vantage point.

Scale HC3 is the UNDERDOG compared to the loud boys out there: Nutanix, Dell and HP is all you see, but this is such a beautiful K9: this Dawg is going places make no mistake about it!

So we conclude:

• It is clear that within the HCI architecture the efficiency of RAM usage matters greatly and will affect the total cost of your HCI system as RAM capacity does not come cheap.
• It is also quite clear that choosing a RAM efficient HCI platform allows the customer to deploy the same platform across the entire enterprise, be it on large or small physical server configurations. Keeping all sites identical saves human resources and mitigates risk of human errors.

Making the point of the Scale HC3 scalability in particular, the smallest node type sports merely 64GB of physical RAM per node, while the largest offers 2TB RAM per node allowing some 16TB RAM in a maxed out 8 node cluster. Such a large cluster also provide a massive persistent tiered storage pool capacity of 334TBu (that is TBu as in TB useable, meaning protected across the nodes in the cluster). HCI is no longer just for small deployments, these are getting to be real Enterprise size systems. The beauty with Scale HC3 is that there is zero difference in functionality or features between the smallest and the largest configuration, this journey is all-inclusive.

To get the best Return Of Investment when selecting your HCI system, choose wisely, by keeping an eye on overall RAM memory efficiency.

HCI is slowly and surely maturing, finding ever more customers and applications to host for ever larger customers. The Scale Computing offering, as its name implies, does indeed efficiently SCALE all the way from very small, low cost three-node ROBO configurations, up to very large clusters hosting thousands and thousands of VM's. Make sure you choose wisely and diligently when picking your HCI to get the most out of the money you spend.