Problems with Managing LUNs and Volumes

Problems with Managing LUNs and Volumes

January 25, 2018 0

Virtualization introduces an element of simplicity and agility lacking in the physical world, providing administrators with a single view of resources under hypervisor control (CPU, memory, and networking).

Virtualization owes its success in transforming data centers to the power of abstraction; unhinging operating systems and their components from the confines and limitations of what is possible within the traditional physical world. An application within a virtual machine is, for the first time, a truly logical object. These objects can then be copied, reconfigured, redeployed, analyzed, and managed in ways that have been, and still are, very difficult for physical machines and infrastructure.

Virtualization not only provides the benefits of server and desktop consolidation, but also simplifies data center management, deployment, and maintenance. Unfortunately, there is still a language barrier in today’s modern data center. Most existing IT infrastructure and tools, including storage, don’t “speak” virtualization as their native language. This has the adverse side effect of obscuring the relationship between the virtualized application and the underlying infrastructure.

The entire industry has had to re-think traditional functions like monitoring and troubleshooting to account for virtualization, but not every element of the infrastructure has adapted. Virtualization has improved the cost and efficiency of managing servers, but significantly increased the time and complexity of managing, diagnosing, and fixing performance problems with storage.

No other component in a data center does a better job of illustrating this disconnect than shared storage systems.

Legacy shared storage systems that were designed well before the adoption of virtualization provide little help resolving performance problems with individual VMs. The result is a suboptimal infrastructure dominated by ever-escalating storage costs due to over-provisioning. According to VMware’s own estimates in 2010, storage accounted for up to 60% of virtualization deployment costs. Unfortunately, the situation hasn’t improved much since then.

In fact, traditional shared storage tends to amplify troubleshooting issues, via multiple opaque layers hidden from the VM administrator. Most shared storage systems operate with their own logical constructs, such as LUNs or volumes, which are mismatched with virtual resources like VMs and vDisks.

Additionally, migration technologies like vMotion drove the adoption of shared storage systems in the early days, as it was a basic requirement of VMware vSphere to have hosts that shared access to the same datastore (e.g., LUN or Volume) to be able to take advantage of this defining capability. Because of this requirement of virtualization, adoption of shared storage, both SAN (Fibre Channel or iSCSI) and NAS (NFS), accelerated.

However, traditional shared storage products present barriers to virtualization:

  • They manage objects such as LUNs, volumes, or tiers, which have no intrinsic meaning for a VM.
  • Legacy storage struggles to monitor, snapshot, set policies or replicate individual VMs.

This mismatch typically increases cost and complexity of the deployment as well as day-to-day operations. For example, each new VM must be assigned a specific storage LUN or volume upon creation. When IO requirements and VM behavior are not well understood, this becomes a painful trial-and-error process. Storage and VM administrators must coordinate with each other to ensure each application not only has the space it needs, but also sufficient IO performance for the expected load.

In most cases, multiple VMs occupy the same volume or LUN to reduce mapping complexity and take advantage of space-saving technologies like deduplication. However, this can lead to IO performance problems. A storage-centric view of performance data leaves out the details of the application or workload, and causes administrators to work backwards to determine which VMs are affected and which VMs are generating load.

Even more modern technologies like auto-tiering operate at the wrong level. Without the ability to report behavior on a per-VM or per-vDisk level, all the “advanced” storage technology seems to do is increase complexity and risk. Instead of the unvarnished VM model provided by hypervisors, legacy storage responds with a blizzard of options and interfaces.

In these situations, the complexity of configuring, managing, and tuning traditional storage for VMs is costly and ultimately limits the adoption of virtualization. In fact, many applications cannot be cost-effectively virtualized with legacy shared storage.