When organizations evaluate options for hardware and software infrastructure, they must decide whether they would rather choose the emerging hyper-converged infrastructure category or build their own solution using handpicked vendors of their choice. A big driver for the former option is the “single throat to choke” argument, which has been heard and made so many times – and for good reason! Oftentimes enterprises that choose the latter option are left dealing with vendors that are playing the finger pointing game when an infrastructure goes down. The real value in hyper-converged infrastructure is more about the ease of deployment, central management, and hyper-optimization of the system. In other words, it’s about simplifying and streamlining the infrastructure, allowing administrators to refocus their energy on more important things. Performance is generally a lower-level concern when hyper-converged is being considered.
When organizations evaluate options for hardware and software infrastructure, they must decide whether they would rather choose the emerging hyper-converged infrastructure category or build their own solution using handpicked vendors of their choice. A big driver for the former option is the “single throat to choke” argument, which has been heard and made so many times – and for good reason! Oftentimes enterprises that choose the latter option are left dealing with vendors that are playing the finger pointing game when an infrastructure goes down. The real value in hyper-converged infrastructure is more about the ease of deployment, central management, and hyper-optimization of the system. In other words, it’s about simplifying and streamlining the infrastructure, allowing administrators to refocus their energy on more important things. Performance is generally a lower-level concern when hyper-converged is being considered.
How is this idea of simple infrastructure achieved? To understand this simplification, one must think about the evolution of infrastructure through recent years. Traditionally, engineers have managed the disparate components of the datacenter as the individual parts that they are. This results in a bit of a nightmare for IT staff; they have to maintain technicians that understand each component how they all work (and don’t work) together. This inefficient approach led to things like qualification guides, interoperability matrices, and giant headaches.
The goal of converged infrastructure is to minimize compatibility issues and align the components into a single form factor for centralized management, ultimately making things simpler. Converged infrastructure comes in many shapes and sizes, but they can generally be lumped into four pools.
| Reference Architecture | Converged Offerings | Hyper-Convergence | Rackscale | |
|---|---|---|---|---|
| Characteristics | Flexible, Predefined options, Qualified, Self-constructed | Vendor lock-in, Single support structure, Pre-built | Simple, Software layer, Aggregated resources | Flexible, Pooled and disaggregated resources, Modular |
| Examples | VSPEX, FlexPod | Vblock, Exadata | EVO: RAIL, Nutanix, SimpliVity, HP ConvergedSystem |
In a reference architecture someone has taken all the complex qualifications and interoperability out of the equation by doing the legwork ahead of time. It’s essentially a blueprint that can be followed to build a proven configuration. This is great because someone has done the most painful parts of building the infrastructure, although each component still has to be managed separately.
With a converged offering there are two subtypes: general use and purpose build. Either way, admins are using a complete system prebuilt by the vendor. Vblock is one of the most well known general use converged infrastructures, but purpose build offerings like Exadata fit nicely into this category as well. Generally options are limited to “how much” and “how fast,” which are unique to each enterprise.
Somewhat new to converged infrastructure is the hyper convergence space, which uses software to mask all of the individual components into a single management interface. These scale well, but generally computing and storage can’t be scaled separately.
That leaves Rackscale. This is where the sum of disaggregated resources are taken from various sources and pooled together. With Rackscale, an admin could take all of an enterprise’s storage from a hodgepodge of whitebox servers and chain them together as a single pool. This is different from hyper-convergence, because the servers and storage components do not have to match.
The key to infrastructure convergence is simplicity, and there are a myriad of ways to achieve it. This is sure to be an interesting time in infrastructure as more and more vendors seek to enter the equation. With larger storage arrays having a hypervisor built-in already, it may be just a matter of time before native applications can be run on traditional enterprise storage arrays.
About the Author
Mark May is a storage engineer in Cincinnati, OH. He has worked in Enterprise Storage and Backup for over 15 years. He is an EMC Elect, Cisco Champion, and avid technologist. In his free time he likes to help others understand the ins and outs of the ever changing storage industry. He can be found online in a variety of places, but the two most likely are his personal blog and twitter @cincystorage.
Discuss This Story
