If you’re like a lot of people, a few years ago you probably began consolidating your physical servers using a hypervisor. You then discovered that some of your applications were running slowly, or that moving a virtual machine (VM) from box to box was harder than you expected, requiring you to manually re-establish the routing between the virtual app and its data stored somewhere on the company SAN. In both cases, your hypervisor vendor likely told you that your legacy storage was the root of the problem. To solve the problem once and for all, your hypervisor maker said, you can abandon your old storage and jump on board with something called hyperconverged storage.
Your first reaction might have been to ask, “How could it be legacy storage, when I just deployed it?” The next question might have been “What the heck is hyperconverged storage?” A search of the Web for more information on hyperconverged storage probably turned up as many definitions for the term as vendors offering products.
Analysts claim hyperconverged storage is actually a subset of hyperconverged infrastructure. The term hyperconverged infrastructure typically refers to a cobbling together of server components with storage components via some sort of software-defined storage (SDS) software “glue.” This has usurped all those special features and functions that used to be operated from array controllers and instead placed them into a software uber-controller on the server side of the hyperconverged platform.
In reality, hyperconverged infrastructure has no single definition. There is more than one flavor, and each one is identified by its level of dependence on hypervisor software or storage hardware.
In some cases, hyperconverged storage is conceived as a nodal storage hardware appliance. The server component is simply a big storage controller, running SDS, usually under a specific hypervisor, to control the server’s direct-attached storage and possibly some internal DRAM or flash memory-based storage. This scenario offers an example of something that is hardware-dependent because only select hardware can be used as storage, and also typically hypervisor-dependent in that it supports only the workload data of the virtual machines (VMs) of a single hypervisor. VMware’s EVO:RAIL is an example. Hardware choices are fairly constrained and only data from VMware-hosted VMs can use the storage capacity.
There can be hardware dependency in hyperconverged storage infrastructures created using a server hypervisor’s SDS microkernel. If you have ever tried to set up a VMware Virtual SAN (VSAN), for example, or even a Microsoft Hyper-V Cluster Storage Spaces installation, you know what I mean. In each case, you have some flexibility with what hardware you join to the server, but not a lot. Only certain kinds of drives, flash components and interconnect protocols are supported or certified. This is quite a bit more flexible than EVO:RAIL in terms of hardware, but each one only supports a specific hypervisor’s workload; storage capacity cannot be shared between different hypervisor workloads.
Second category of hyperconverged infrastructure products
A second class of hyperconverged infrastructure products can have fixed or flexible hardware, but support the data of workloads running under different hypervisors. Let’s say you have Microsoft Hyper-V and VMware vSphere ESX, each running VMs. If you’re running out of capacity on the hyperconverged VSAN nodes behind the VMware server and have some room available on the Clustered Storage Spaces nodes running behind the Microsoft Hyper-V server, there is no simple way to allocate some of the available storage capacity where it is needed. Microsoft provides a converter that changes your VMware VMDK file into a VHD so it can be stored on the Clustered Storage Spaces storage, but that means VMware can no longer use it. (For its part, VMware offers no facility for using its VSAN storage with an alien hypervisor workload.) However, Nutanix makes a hardware-dependent appliance that can be used to host both VMware and Hyper-V workload data.
For hardware-independent/hypervisor-independent hyperconverged offerings, you typically need to look at third-party or independent software developers specializing in SDS products. While not all of them provide a universal storage platform that can be shared among different workloads, virtual SAN products like those from StarWind Software can be deployed as separate instances behind different hypervisors but managed using a single pane-of-glass management console.
Third category of hyperconverged infrastructure products
A hyperconverged nirvana would use third-party SDS software that creates commonly manageable storage behind any hypervisor and supports both virtual and non-virtual workload. This is a third class of hyperconverged storage architecture that requires an SDS software stack that includes storage virtualization. With storage virtualization, you can share virtual volumes from any collection of storage hardware, plus manage in common multiple hyperconverged storage implementations made behind different hypervisors. DataCore Software’s Virtual SAN has this remarkable capability and it is something that should be considered by IT planners.
According to industry analysts, approximately 75% of applications will be virtualized by next year. The other 25% are transaction-oriented, revenue-producing applications that no one wants to virtualize right now. Given this situation, you will need to provide data storage for both virtualized and non-virtualized workloads for the foreseeable future. That is at least two separate and discrete workload types.
If current survey data is correct, you will likely need to support data from workloads from at least two hypervisors, as companies are opting to diversify the hypervisor software they are currently using. That means you could have even more isolated islands of virtual and non-virtualized workload data to manage, segregated by hypervisor type and corresponding hyperconverged infrastructure. This could get very messy, very quickly. Having a hyperconverged option that supports flexible hardware and multiple workloads with a common management approach is the way to go.
Just about all vendors of hyperconverged storage appliances and hypervisor-centric hyperconverged infrastructure promise to provide application acceleration, simple scaling, high availability, and lower overall Capex and Opex costs. If these descriptions of hyperconverged infrastructure leave you feeling a bit dissatisfied, you’re not alone. Integral to each of these hyperconverged infrastructure approaches are a muddle of assumptions that are mostly left unstated, not to mention a number of half-truths or oversimplifications that will require more time and effort than you can spare to sort in a nuanced way. What you wish you had was a simple set of criteria you could use to guide your evaluation of hyperconverged infrastructure technology so you could find the one that best fits your needs.
Original article: Separate the ‘hype’ from hyper-converged storage
