Hyperconverged Infrastructure

To Hyperconverge or Not To Hyperconverge?

Many IT managers are greatly interested in, and enthusiastic about, the benefits of hyperconvergence for their organizations. I know that because conversations with clients and people at industry events often include these discussions.

As with many tools, however, it’s best to know when it should be put to work and when it might not be the best choice. Managers need to be careful with their enthusiasm for a specific tool or approach. As Abraham Maslow once said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

I’ve observed managers picking a specific tool based only on their excitement for it, and not a clear understanding of the work that needed to be accomplished, the environment for the solution or even the staff expertise on hand. This often leads to significant issues they could have foreseen if they had been guided by facts instead of emotion or marketing fluff.

Here are some tips that can help you avoid that situation.

Know Your Environment

The IT infrastructure supporting many organizations’ applications and workloads are distributed, multi-tier, multi-site and multi-vendor; they were constructed over time using a plethora of tools, system architectures and approaches to development.

These folks often tell me that their organization “was seduced” into using every slick — and highly non-standard — function offered by a vendor. While that approach made it possible to quickly build something useful at the time, it also meant that the application or service would have to be totally rewritten if it was going to be eventually ported to another platform.

Uprooting some applications or application support functions can prove to be extremely painful. Often those applications and services were designed based on a then-popular fad, rather than with the idea that the work might need to be re-hosted or migrated somewhere else in the future.

These admins were often forced to move to a much less functional, commercial off-the-shelf or cloud service offering that sorta, kinda did the same thing in a generic way; all so that they could move to a new, more modern platform. But unless the underlying infrastructure of the hyperconverged system can support the vendor-in-question’s offerings, moving that application or service may not be wise.

Know Your Applications’ Performance Requirements

Some applications or functions aren’t easy to decompose to run in parallel. In that case, the performance of these monolithic applications can only be improved by hosting them on bigger and bigger processors. Adding other processors to the mix might be helpful to support other workloads living on the same server, but they won’t do anything for an application that doesn’t use them.

IT managers who ended up “holding the bag” with these pieces of software – i.e., they weren’t involved with the development or acquisition process for this software – learned that hard way that moving them to a multi-system platform, such as a hyperconverged system, didn’t have the intended effect.

They learned that it was wise to understand the maximum single-processor performance characteristics of a system, rather than just accepting the overall performance claims offered by the hyperconvergence vendor. If a system doesn’t have a large enough single processor, their monolithic applications won’t be happy regardless of how many other processors live in the same enclosure.

Know Your Applications’ Architecture

Hyperconverged systems are designed around an extremely fast internal network allowing processor-to-processor or processor-to-shared memory communications. Different hyperconvergence vendors offer products that support larger or smaller aggregations of processors, memory, network adapters and/or storage in their enclosures.

This can be a key difference between seeing strong, acceptable or even unacceptable performance. Selecting the wrong product can result in a serious performance hit; when that happens, managers often blame hyperconvergence itself, rather than understanding that they simply chose the wrong product.

Some applications are designed to require many separate, independent services operating at the same time to perform well. If all of them won’t fit into the hyperconverged system they’ve selected, the application will generate a great deal of network traffic into and out of the box; this is known as “East/West” traffic.  A single transaction might require many messages to go back and forth to functions that live somewhere else on the network, instead of staying on their home turf.

Don’t Lose When You Choose

In the end, my discussions with these IT managers often center on them knowing their environment, how their applications were designed, and a thorough understanding of the hyperconvergence offering they’re considering. Without that knowledge, it can be hard to make the right choice.