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

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?