Disaggregating network, compute and storage allocation demystified

Hyper-convergence and disaggregation

One of the key knocks against hyper-convergence has been the requirement to buy measured, predefined doses of compute and storage allocation in the form of a node, even when all you need is one or the other. Initial offerings from pioneers like Nutanix offered no choice. But in response to demand, Nutanix, Pivot3 and others now sell storage-heavy and compute-heavy models that mitigate, but don't eliminate, this issue.

Nutanix offers all its models with minimum disk purchases of zero -- no disk at all. Also, to meet the needs of a range of applications, you can build a cluster with a variety of nodes, which is a key aspect of hyper-convergence. This way the purchase of a node is appropriate for the application for which it will be used, but the entire cluster is managed as one entity.

Ideally, disaggregation demands the separation of compute and storage so you can purchase 100% of one and none of the other. But in a Nutanix environment, this only works for 100% compute, not 100% storage. Nutanix solves this problem by using minimal compute for a storage-heavy node. It's not pure disaggregation, but it gets the job done.

Pivot3 takes a different approach. Like Nutanix, it has a compute-only node with no storage and a storage node with minimal compute power. The storage node can be used in the classic hyper-converged sense, where the focus is on running virtual machines, and the presence of a hypervisor is assumed. But the node can also be used without requiring a hypervisor -- essentially, bare-metal support. Customers can run applications not yet virtualized in a physical infrastructure as in the past, while still taking advantage of storage pools created in hyper-converged clusters managed from a single console.

With its acquisition of NexGen Storage, a purveyor of external storage arrays with fine quality of service, Pivot3 has made it possible to integrate an external, "disaggregated" NexGen storage array as part of the hyper-converged pool. Pivot3 also lets physical and virtual applications running off cluster use storage resources from clusters presented as an iSCSI target. All applications, internal and external to the hyper-converged cluster, can use NexGen's policy-based quality of service capability.

Neither Nutanix nor Pivot3 subscribe to pure disaggregation. But they are trying to deliver its advantages to customers.

Disaggregation and Datrium

A storage-only product, Datrium expands the meaning of disaggregation by separating many functions that we normally associate with storage arrays. Simply put, Datrium implements snapshots, compression, deduplication, replication, encryption and more as software in servers in a scale-out fashion, but leaves certain functions, such as a mirrored nonvolatile RAM and a simplified dual controller, in the storage array. This makes storage boxes more than JBOD, but simpler than traditional arrays. Datrium calls this the DVX Data Node.

Datrium uses software-defined principles to implement these functions in a server that takes full advantage of scale-out; you can add another server to improve deduplication or encryption performance, for example. At the same time, Datrium uses a smarter but simplified storage box and claims to gain significant performance advantages over hyper-converged and other 100% software-defined products from other vendors, such as Hedvig and SwiftStack. Unlike traditional dual-controller storage arrays, Datrium's Data Node creates no silos and delivers scale-out performance and capacity independent of each other. The server can also run physical, virtual and container applications.

Datrium calls this "open convergence," not pure disaggregation, but another example of how the concept can be implemented.

HPE Synergy disaggregation

Hewlett Packard Enterprise's Synergy is the first platform in the industry architected as what HPE calls composable infrastructure. It's the purest form of disaggregation available. Start with individual resource pools of compute, storage and network fabric, and combine them as needed under software control for each application. Administering all three layers as one using a single, high-level unified API to compose, decompose, manage, update and scale infrastructure, Synergy is equally comfortable with virtualization, hybrid cloud and DevOps operational models.

Done correctly, disaggregation enables standing up and breaking down infrastructures almost instantaneously,

Unlike traditional hyper-converged, with its sweet spot in virtualization, Synergy covers all types of physical and virtual applications -- traditional, mobile and cloud-native. And while hyper-convergence brought compute and storage allocation together in a scale-out model, for the most part, it has left fabric alone. Composable infrastructure, designed from the ground up to deal with all the above, fabric included, is disaggregation in its rawest form.

Synergy is made up of three basic elements:

Fluid resource pools. Fluid pools of compute, storage and fabric resources are created on demand for each application and its specific service-level needs. You can configure compute capacity for physical, virtual and container workloads and internal storage capacity as direct-attached file, object or block storage, as needed by applications. Given the important place 3PAR storage holds in HPE's portfolio, it can be configured as external direct-attached storage and made part of the fluid pool. Fabric can deal with multiple protocols, and its bandwidth is nondisruptively scalable and adjustable. Add more compute, storage and fabric resources at any time with no impact on operations. These resources automatically become part of the fluid resource pool and immediately available to applications. Scaling doesn't increase the management burden.

Software-defined intelligence. HPE built Synergy as hardware with built-in software-defined intelligence. Provisioning, scaling, deprovisioning and more, are all done using templates, and infrastructures are composed and recomposed at near-real-time speeds. Think of Synergy as infrastructure as code, where all mundane functions that once took hours and days now occur almost instantly. Compute, storage and fabric are provisioned together with the proper firmware, BIOS, drivers and OS images and without operator intervention. Synergy uses templates for these purposes and, therefore, requires no knowledge of internals for the hardware and software underneath. This makes infrastructure easy to use, not only for IT but for DevOps and test-dev personnel as well. The differences between development, testing and production environments disappear and all use the same interface.

Unified API. Unlike traditional infrastructures, where each device has its own unique low-level API you must configure to the device, Synergy has one high-level API across compute, storage and fabric. Granted, there are efforts by purveyors of converged infrastructures -- Dell EMC, IBM-Cisco, NetApp-Cisco and others -- to simplify provisioning and management across compute, storage and fabric. But they do that through a masking layer because, under the covers, the elements remain distinct and separate.

Synergy's unified API has two distinctions: It's much higher-level than typical command-line interface-level commands, and it's designed to cut across compute, storage and fabric. It also provides a single interface to discover, search, inventory, configure, provision, update and diagnose infrastructure. And it's a single vehicle to integrate Synergy into other management platforms, including Microsoft System Center, Red Hat and VMware vCenter, as well as other DevOps platforms, such as Chef, Docker, OpenStack, Puppet and Python.

HPE Synergy, the product

The first incarnation of HPE Synergy is the model 12000 Frame in a 10U format. You can configure several Frames in a ring and manage multiple rings, all from a single console. There are five elements of importance in a Frame -- Composer; Image Streamer; and the Composable Storage, Composable Compute and Composable Fabric modules -- that play together to create a fully disaggregated platform.

Composer. Composer is responsible for discovering, searching, inventorying, configuring, provisioning, updating and diagnosing infrastructure across compute, storage and fabric. It's a physical appliance that's based on HPE OneView and the unified API. Composer uses server profile templates developed by IT or the business user that automate the provisioning, updating and de-provisioning processes across computing resources. Many compute module profiles can be created from a single template

Image Streamer. A physical appliance that fits inside the Frame, Image Streamer serves as a repository of bootable, golden images for a variety of applications, loadable on compute modules in a matter of minutes. It can be used instead of building a server through physical provisioning and installation of the OS, hypervisor, I/O drivers, application stacks and so on, reducing hours and days of error-laden process to an automated, error-free one that takes minutes.

Composable Storage, Compute and Fabric: Individual modules provide a variety of storage, compute and fabric resources tightly integrated with all other system elements. You only add those resources in short supply. The architecture is scale-out across all three elements, and you can build massive infrastructures that are managed as one. Even fabric, the most static element of all in the past, is converted into code for programmatic provisioning and de-provisioning.

DriveScale disaggregation approach

DriveScale has applied compute and storage disaggregation to next-gen big data analytics-driven applications like Cassandra, Hadoop, Kafka, MongoDB and Spark. These applications love scale-out architectures, usually built with commodity servers and small nodes, consisting of compute and direct-attached internal storage. Hundreds, often thousands, of nodes are required to solve big data problems, each working on portions of the puzzle using relevant data local to that node, then consolidating the results to deliver answers. By keeping data local to compute, latency and east-west traffic are minimized.

This approach has taken over the big data world in the past five years. But as clusters have grown larger, sometimes to thousands or tens of thousands of nodes, several issues have surfaced. They include a lack of flexibility, cumbersome and expensive upgrades, the appearance of application silos due to having to maintain the same ratio of compute to storage allocation for a given application and limits on the number of drives a chassis can hold to maintain the level of airflow required to keep CPUs cool.

DriveScale disaggregates compute from storage to nondisruptively allow the creation and changing of any compute and storage ratio an application requires at any point in time. It calls for buying JBOD compute and storage separately from the one or many vendors. (Server vendors have commodity servers with compute-only that are often much denser than standard commodity servers because of improved airflow.) This way, you can replace compute on a different schedule than disk drives -- generally every two to three years for compute and five years for drives. Since a separate pool of compute and storage allocation are available, you can allocate resources at will across different applications, making resource utilization much higher than before.

DriveScale uses a SAS-to-Ethernet adapter that connects disk drives to a standard top-of-rack Ethernet switch, which in turn connects all compute elements in a cluster. The vendor's intellectual property is in the orchestration software, which programmatically provisions, manages and de-provisions resources to the right cluster. Its GUI is based on a RESTful API that can integrate upwards with customers' preferred management tools, including Chef, Puppet and more.

Disaggregation deserves a look

In the purest sense, disaggregation implies the breaking of something into its component pieces, then creating independent pools of each resource that can be combined under programmatic control to deliver the right combination of resources to applications. Some storage and hyper-convergence vendors have applied disaggregation principles to make their offerings more cost-effective. But DriveScale and HPE Synergy use them in novel, paradigm-shifting ways.

HPE Synergy is the purest and the widest ranging example of disaggregation, exemplifying how the concept can be used to solve a large variety of problems. HPE views composable architectures as the next phase of evolution beyond hyper-convergence. Other vendors, such as DriveScale, use disaggregation principles to solve a specific problem.

While details of the architectures used by public cloud vendors, such as Amazon Web Services and Google Cloud Platform, aren't well known, disaggregation is likely the underlying principle. It may be early days for disaggregation, but creating separate resource pools, combining them at the right time and in the right mix, and then making them available to an application is an idea that's too powerful to ignore. It's time to add the term "disaggregation" to your vocabulary.