Showing results for 
Search instead for 
Did you mean: 
Create Post

Varying Approaches to Hyperconverged Infrastructure, or Why This Over That?

Level 13

In this third post on the subject, I’ll discuss hyperconverged architectural approaches. I want to share some of my experiences in how and why my customers have taken different choices, not to promote one solution over another, but to highlight why one approach may be better for your needs than another.

As I’ve alluded to in the past, there are two functional models to hyperconverged approach. The first is the appliance model, a single prebuilt design with a six or eight rack-unit box, comprised of X86 servers, each with their own storage, shared across the entire device housing an entire virtual infrastructure. In the other model, devices are dedicated to each purpose (both storage and compute), where one or the other is added as needed.

The differing approaches make for key financial elements in how to scale your architecture. Neither is wrong, but either could be right for the needs of the environment.

Scalability should be the first concern, and manageability should be the second when making these decisions. I’ll discuss both those issues, and how the choice of one over the other may affect how you build your infrastructure. As an independent reseller with no bias toward any vendor’s approach, these are the first questions I outline to my customers during the HCI conversation. I also get the opportunity to see how different approaches work in implementation and afterwards in day-to-day operations. Experience should be a very important element of the decision-making process. How do these work in the real world? After some time with the approach, is the customer satisfied they’ve made the correct decision? I hope to outline some of these experiences, give insight to the potential customer’s perspective, highlight some "gotchas," and aid in the decision-making process.

A word about management: the ability to manage all your nodes, ideally through vCenter or some other centralized platform through one interface, is table stakes. The ability to clone, replicate, and backup from one location to another is important. The capacity to deduplicate your data is not part and parcel of every architecture, but even more important is the ability to do so without degrading performance. Again, this is important for the decision-making process.

Scalability is handled very differently depending on your architecture. For example, if you run out of storage on your cluster, how do you expand it? In some cases, a full second cluster may be required. However, there are models in which you can add storage-related nodes without having to increase the processor capacity. Same holds true for the other side. If you have ample storage but your system is running slowly, you may need to add another cluster to expand. In those cases, the node-by-node expansion capacity can be increased by adding compute nodes. This may or may not be relevant to your environment, but if it is, this should be considered as an ROI part of the scalability you may require for your environment. I believe it’s a valuable consideration.

In my role as an architect for enterprise customers, I don’t like conversations in which the quote for the equipment is the only concern. I much prefer to ask probing questions along the lines I’ve discussed above to help the customer come to terms with their more important needs and make the recommendation based on those needs. Of course, the cost of the environment is valuable to the customer. However, when doing ROI valuation, one must account for the way the environment may be used over the course of time and the lifecycle of the environment.

In my next post, I’ll discuss a bit more about the storage considerations inherent to varying approaches. Data reduction, replication, and other architectural approaches must be considered. But how? Talk to you in a couple weeks, and of course, please feel free to give me your feedback.

Level 14

Thanks for the article.  Indeed, a mistake that's made far too often is neglecting the inevitable need to scale. 


Thanks for the article.

Level 12

"In my role as an architect for enterprise customers, I don’t like conversations in which the quote for the equipment is the only concern."

In my experience managers are far too concerned with price, often willing to sacrifice performance for cheap.

Level 13

I'm often quite clear. "You've decided that this is a 5 year depreciation, so lets figure out how the cost makes sense, in terms of scalability." Using this model, we can surely prove that cost will quite often go out the window on an annual amortization, with the potential need to add more to the cluster. Cost should be a concern, but not the initial driving factor. While there are other important concerns, the cost should take a back seat to the functionality. More often than not, this is part of a c-level conversation.


Scalability is important but can you support it as it scales ?

If it becomes unsupportable at large scale then scalability is out the window.  Supportability much be in parity with scale.

Level 13

Well said, and a very good point, @JFrazier

Level 13

Good post.  Thanks.  Totally agree. One of the things I've seen over and over is an over emphasis on cost without taking things like lifecycle, backups, maintenance, manageability and future expansion into account to the overall detriment of the enterprise

Level 12

thanks for the post

About the Author
Hi, I'm Matt Leib. I'm an old dude, with years on the customer side, years on the vendor side, and now, years on the channel side. Exist as a Pre-Sales Solutions Architect in the channel space. I specialize in virtualization, orchestration, storage and cloud. On my personal blog, I talk about anything from baseball and music to most technical things I enjoy including personal and enterprise tech. For the last few years, I've been a Tech Field Day delegate, and a blogger on Thwack's Geek Speak as well as a personal blog site at . Always learning, growing (though sometimes, that's the waistline) and striving to be as good as I can. I also like to sing, play guitar, and am a rabid Cubs and Blackhawks fan. I live in Evanston, IL, a suburb of Chicago, also grew up here. I work for Connection Enterprise Solutions, in a strategic solutions role, speaking to C Level on Corporate IT Initiatives