Hyper-Converged is the Right Approach, Except When it Isn’t

In my role I often get in to conversations about the pros and cons of hyper-converged versus a separate storage array approach. This is a difficult discussion and one where the big picture often gets lost in the technical details.

Hyper-converged solutions place all the storage capacity as close to the application as possible. They have the storage in the hypervisor server that host the application or database. All storage management workloads happen on the same CPUs as the applications.

The alternative approach for enterprise storage is to put all the storage resources together in a single “array” and connect them to the compute layer via a network link. This gives you advantages that all the performance available from the storage can be accessed by any client and capacity distributed exactly as required. Among other advantages is that the parts that fail most often are all in the same place and can be maintained with minimal impact to an environment.

 

Technically both approaches can deliver a solution with all the resiliency and performance businesses require.

Both are capable of providing all the storage features that businesses need, like encryption, replication, snapshotting, RAID protection, de-duplication.

Overall the physical hardware required for both approaches is similar. HCI can help you avoid buying a SAN network from storage array to compute nodes.  However, you have to deploy some very high bandwidth network links to connect the HCI nodes together, this cost can be just as high as the SAN network.

 

So why has the hyper-converged had a significant increase in take up over the last few years?

I believe it is because of the massive improvements in storage hardware performance and density provided by flash and other storage media. Traditional array designs simply have not been able to keep up with the 10-100X performance improvement that flash can provide compared to disk. Better performance has been possible by putting the media directly in the compute layer and sharing the application CPU. In this way the amount of CPU performance for your data management is only limited by the number of servers you have.

Fortunately, the scale up and scale out design of the K2 is specifically built to solve this issue of matching the right amount of storage compute to the performance of new types within a storage array.

There are cautions, however, that you need to be aware of with the hyper-converged approach. One of the biggest downsides is the problem around licensing. Sharing the CPU being used for storage management with the database or application layer will require you to license that CPU resource for any layer in the stack that uses CPU based licensing. This can include the database, an application, the hypervisor, the HCI vendor. Overall these licenses will be a far larger expense than the hardware they are running on.

Often the increase on an application or database layer costs gets missed in a comparison TCO analysis.

If I am pushed on the technical detail in a comparison, I recommend customers ask potential HCI vendors questions like –

  • Is the deduplication global across all data, or per server or even disk? Non-global dedupe can multiply the amount of flash media required to store the data.
  • Do I need to take an entire node out of my hypervisor cluster to replace a SSD?
  • What is the impact of a drive rebuild on my application servers performance?
  • What is the impact of software encryption, RAID, erasure coding, deduplication, compression or snapshots on my application performance?
  • If there is a problem with media replacement or data corruption who is to blame? The HCI vendor, the hypervisor vendor, the hardware manufacture, the SSD manufacturer?

In my mind, technologies in this industry tend to become re-invented in cycles. A hyper-converged approach will work well for some organisations. However, for others the reasons that storage arrays became popular (consolidation, aggregation, separate failure domain and better functionality) still hold many attractions.

 

Bottom line:

It’s hard to deny the operational simplicity and benefits of a hyper-converged approach and it’d be futile to do so. But what if this simplicity of operational management came with the highest levels of cost-effectiveness and space utilization of storage area networks? What if this simplicity could intersect with the performance at scale; performance that a scale-up and scale-out all-flash array like Kaminario provides?

We see the natural evolution of shared storage infrastructure will include the automation and orchestration to simplify overall management while retaining the sheer performance and capacity efficiency of traditional all flash arrays.  Stay tuned for more discussion on this topic from us soon.

 

— —

New Call-to-action