alternate-routeConvergence is aiming to change the data center with the promise of simplifying overall IT operations. We’ve seen tightly engineered solutions from VMware, Cisco and EMC in the form of vBlocks from VCE. More recently we’ve seen hyper-converged systems from the likes of Scale Computing and Nutanix. The appeal of these systems from a CIO perspective is the reduction of operating expenses related to the virtualization and storage administrator roles. With proprietary management interfaces, the systems promise single panes of glass administrator of storage, virtualization and to a more limited extent networking. However, convergence isn’t the only way to obtain simplified operations. Software-defined solutions are also available.

Why Not Hyper-Convergence
A good to starting question is why not just leverage a hyper-converged platform, which offers one of the best management experiences available. In addition to the management ease, hyper-converged systems allow for easy expansion. If you are constrained on either performance or capacity you just add an additional storage/compute module to the cluster for an almost linear capacity and performance increase.

There are two primary reasons for not choosing hyper-converged systems. The first is purchasing cycles. Organizations would have to “rip and replace” existing infrastructure to get the benefits of hyper-convergence across the entire IT enterprise. Having a combination of non-converged infrastructure and converged infrastructure doesn’t give the benefits of ease of management. If the storage and compute buying cycles are not in line then the proposition of replacing the existing infrastructure with hyper-converged appliances is highly unlikely from a budgetary perspective.

The other challenge is the linear approach to scale. Infrastructure groups trade granularity for simplicity when choosing hyper-converged systems over individual infrastructure components. If the storage and compute requirements do not grow hand and hand then waste occurs when adding both components at the same time. For example, if cluster workloads are CPU and memory intensive adding a module means upgrading both storage and compute. This may result in unnecessary storage investment.

Other Converged Options
A strong approach to gaining the efficiencies of hyper-convergence without some of the drawbacks is to leverage solutions integrated at the software level. The VCE vBlock solution is an example of an approach that leverages best of breed solutions that are tightly coupled via engineering and software. This is a good approach that provides the business one “throat to choke” for support. However, lock-in maybe a resulting challenge. The VCE architecture is built on VMware, Cisco and EMC infrastructure components. There aren’t options for switching out subcomponents if a different vendor is preferred. This makes sense of course because the goal is to deliver a highly engineered solution with strong integration and support.

The Software-Defined route
A 3rd option is a software-defined or open architecture approach. This approach requires varying levels of engineering on the customer side. The level of engineering is proportionate to the level of openness required. The key is to rely on storage that supports RESTful API’s and a management layer that can take full advantage of the APIs. A couple of examples is SolidFire and X-IO to varying levels. X-IO provides a low maintenance storage solution that integrates extremely well with VMware. The idea behind their storage design is to provide highly available storage that requires little to no management after installation. A great use case for X-IO storage is a VMware environment that all available storage is provisioned to a VMware cluster and managed via vCenter. Once X-IO introduces a full set of REST API’s then this same use case could be extended to other platforms including OpenStack.

SolidFire, which is an all-flash storage array already supports a full REST API. This means an organization can take a solution such as OpenStack and build the management layer needed to completely manage the storage. This of course is at a very early stage of maturity and isn’t very turnkey. It does provide an integrated solution that gives a single point of administration for storage and compute, but isn’t as simple as the proprietary solution from VMware powered by X-IO storage.

The primary design consideration for the software defined approach is to use simple hardware and provide the provisioning and management capability at the management layer. Today, this is done by managing storage via the hypervisor. In the future, as solutions such as VMware’s vCloud Automation Center and OpenStack mature, experiences closer to the hyper-converged solutions will begin to materialize.

Disclaimer: Gestalt IT hosted me at Storage Field Day 5. They provided airfare and lodging for the 3 days I attended the event. No consideration was given to me for mentioning any of the event sponsors (EMC, SolidFire, X-IO) in this post.

Software-Define alternative to Hyper-Convergence
Tagged on:     

2 thoughts on “Software-Define alternative to Hyper-Convergence

  • Pingback:Software-Define alternative to Hyper-Convergence

  • May 19, 2014 at 10:30 am
    Permalink

    Hey Keith! Great article and great meeting you a few weeks ago. I know we didn’t get a chance to discuss our REST implementation at SFD5, but X-IO has had a fully implemented and open ReSTful interface and was probably the first array on the market to offer it as an open API. You can see some of this @ cortexdeveloper.com. We are happy to review this with you if you’d like. It is the basis for ALL of our applications and telemetry/phone-home support.

    Reply

Leave a Reply

%d bloggers like this: