Challenges with Legacy Block Storage and Hyperconverged Infrastructure

There is no shortage of storage options at your disposal in today’s marketplace. These choices include legacy block storage systems and more modern hyperconverged infrastructure solutions. While these solutions have enjoyed a lot of positive feedback, they do come with some associated challenges that may not make them suitable for cloud requirements.

Physical-era Architecture

Although there are some people in the world who truly love managing storage and all the elements that come with it, the reality is that the constructs we’ve gotten used to are there due to inherent limitations that were present in legacy storage systems. We accept these constructs because that’s the way we’ve always done it—as poor an excuse as any.

There are two common constructs in use in legacy storage systems:

  • Logical Unit Numbers (LUNs). In the days of physical storage, LUNs represented physical devices that existed in the SCSI bus. Since then, however, LUNs have also become a bit virtualized themselves and can represent specific portions of carved up RAID groups as just one example. They have evolved to represent logical groupings of storage elements to hosts. LUNs are generally SAN-centric and are presented to hosts for the creation of volumes.
  • Volumes are areas of storage capacity carved out of one or more LUNs. Generally, volumes are created on host systems, such as vSphere hosts.

These terms are sometimes used a bit differently by different storage vendors, but these are the basic ideas. The end result is the same, though—they suffer from underlying fundamental architectural challenges.

In the modern data center, there are several needs that simply can’t be easily met with physical-era architectures. These include:

  • Simple scalability of both capacity and performance (addressed in another article)
  • Predictable performance as the environment grows—Physical-era infrastructure in a scale up environment or stuffing too many virtual machines inside too few LUNs, making them difficult to isolate, thus subjecting them all to unpredictable performance
  • Application of granular quality of service policies, for example, at the individual VM level to isolate VMs and eliminate conflict over resources
  • Quick and easy identification of performance problems, including root cause determination of the exact point in the stack (compute, network and/or storage) that is causing the poor performance

As storage systems grow to span multiple data centers and even multiple clouds, these problems become even more profound. While technologies such as VMware’s Virtual Volumes (VVols) have been developed to help address some of these challenges, VVols exhibits its own problems:

  • Extreme dependence on storage array vendors to implement the complete VVols specification, which is carried out with varying levels of success and attention
  • VVols doesn’t fundamentally change the underlying architecture; it just masks architectural issues to help vSphere associate virtual machines with disks, which does help to solve some problems; VVols can make it possible for your storage to provide more granular per-VM policy management instead of per-LUN management. For example, per-VM controls on performance and redundancy.
  • VVols only works in a complete way if you’re using Sphere 6 or higher; if you’re using an older version of vSphere or another hypervisor altogether, you’re out of luck

That last point is particularly important to understand. While VMware’s vSphere today enjoys a commanding market presence, ActualTech Media research shows a surge of interest in alternatives, most notably Microsoft Hyper-V. With the risk of VMware beginning to lose share, there are potential challenges for storage vendors that depend solely on VVols.

Storage is Not a Web Service

Storage is really important. In fact, of the resources in the data center, it’s the most important. Why? It holds the keys to the business kingdom. As a business, if a server completely fails or if your network crashes, you can recover, even if you haven’t done a good job building contingency plans. If your storage suffers catastrophic failure and you’ve not put into place contingency plans—e.g. backup systems—you’re essentially out of business.

As we look at some of the emerging storage systems on the market, the components responsible for managing storage are not always as robust as we might like. For example, although there are hyperconverged infrastructure systems on the market that are quite good, there are others that have bolted storage on to the platform. In a data-centric world, companies can’t afford to rely on systems that treat storage as “just another service.” Moreover, as the market continues to extend support for container-based workloads, new challenges emerge, such as the need to maintain storage persistence inside these ephemeral constructs. More robust storage layers that can provide a persistent storage layer for non-persistent containers will be an increasing need as container adoption accelerates.

APIs are Not Clean

Traditional storage arrays lack any programmatic management. They are managed by a proprietary interface and, other than storage protocols, interface with no other external services than perhaps logging and statistical gathering.

Policy-based management and automation are a critical piece of any cloud construct. As companies move to leverage enterprise cloud, they require storage systems that support the automation necessary in a cloud model.

By using modern storage that provides a RESTful API you’ll be able to integrate your storage with automation/orchestration tools, provisioning, chargeback, and more.

Infrastructure Components Must be Welded Together

When you look at a legacy data center environment, it quickly becomes clear just how much welding you must do to make things work in a reasonable way. Even when things are designed to interoperate, you still need to create all kinds of constructs—such as the aforementioned LUNs and volumes—to make it all work.

There are obvious seams around these welding points, too. These are the seams that create security concerns, but that is just a small part of the problem. Instead, each of these welding points results in additional friction in the data center. Each is a point that needs to be touched all the time.

Data center friction causes latency in achieving the goals of the business and drives business units into the waiting arms of outside providers that can move faster. The hybrid cloud storage environment requires a storage architecture that is a smoother and more flexible than traditional physical-era environments allow.

Hyperconverged Infrastructure Linear Scale and Lack of Choice

Hyperconverged infrastructure has emerged as a popular way for organizations to quickly implement data center environments. While hyperconvergence is a good solution for many, for others, it carries with it some inherent challenges.

First, the need to scale hyperconverged infrastructure node resources and software licenses in a linear way is a detriment. You’re adding more compute power than you probably need as you add more storage capacity. This scale methodology may sound like scale-out storage, but there’s a key difference: hyperconverged infrastructure nodes often have less overall capacity than storage arrays, so you’re adding way more compute than you probably need. In addition, every time you add a new node, you also have to pay for another processor license for your favorite hypervisor. Those costs can add up really fast.

Moreover, you don’t get choice in your storage. You have to use what you’re provided and may not have the flexibility to choose an optimal combination of compute and storage.

 Step Back

Read On