Time For LUN To Die

In virtualized environments, managing storage with LUNs isn't practical. With the upcoming arrival of VMware Virtual Volumes, we can shift to VM-centric data services.

Howard Marks

October 15, 2014

2 Min Read
Network Computing logo

While we may disagree about whether hyperconverged architectures will take over the data center and if there’s a future for dedicated storage arrays, the storage and virtualization chattering classes are in agreement that the LUN, as a unit of storage abstraction, needs to die. Now that VMware is actually preparing to release its long-awaited Virtual Volumes (VVOLs) technology, we can start managing storage one VM at a time.

Today’s SAN protocols and storage systems require a logical connection from a server to each volume that server will connect to and limit each server to 255 active connections. This limit seemed quite generous for physical servers with exclusive access to a volume. And as long as storage administrators were dealing with a handful of physical servers, requiring a few CLI commands or mouse clicks to provision a new volume was reasonable.

In a hypervisor environment, the only practical way to manage conventional storage is to create a relatively small number of shared datastores and put multiple VMs in each. That simplifies management and allows virtualization admins to create VMs without waiting for the storage team to provision LUNs.

When, as in most organizations, your storage team allocates a small number of fixed size LUNs to your hypervisor cluster, you’re left managing several datastores and several pools of free space. Since prudent administrators will leave some free space in each datastore, more datastores means more idle capacity. Thin provisioning helps quite a bit, but vSphere isn’t as aggressive as say Hyper-V with its use of the T10 UNMAP command to release unneeded capacity to the free pool, stranding capacity in individual datastores over time.

Even worse, since the storage array knows nothing about the data it holds other than a logical block address, any data services the array provides have to be provided for an entire LUN. That significantly reduces the value of these data services. If we want to replicate some VMs and not others, we need to segregate those VMs into replicated and non-replicated datastores.

Because applications can only be quiesced for a very short period of time, Windows VSS times out if the snapshot isn’t taken within 15 seconds and it’s not possible to take an application-consistent snapshot of the many VMs stored on an array LUN. This forces backup applications to use hypervisor snapshots, with their significant performance impact, as their data sources.

While a few storage systems such as those from Tintri and Nutanix have provided per-VM data services, they’ve acquired the context they need to identify a given VM’s data by maintaining their own file systems and delivering it via NFS. VMware VVOLs have long promised a more general solution that will work on block as well as file storage. While I’ve wondered whether VVOLs would ever come, their arrival is looking more imminent than ever.

In my next post,  I'll look at how VVOLs do their magic and how they change the storage planning equation.

About the Author(s)

Howard Marks

Network Computing Blogger

Howard Marks</strong>&nbsp;is founder and chief scientist at Deepstorage LLC, a storage consultancy and independent test lab based in Santa Fe, N.M. and concentrating on storage and data center networking. In more than 25 years of consulting, Marks has designed and implemented storage systems, networks, management systems and Internet strategies at organizations including American Express, J.P. Morgan, Borden Foods, U.S. Tobacco, BBDO Worldwide, Foxwoods Resort Casino and the State University of New York at Purchase. The testing at DeepStorage Labs is informed by that real world experience.</p><p>He has been a frequent contributor to <em>Network Computing</em>&nbsp;and&nbsp;<em>InformationWeek</em>&nbsp;since 1999 and a speaker at industry conferences including Comnet, PC Expo, Interop and Microsoft's TechEd since 1990. He is the author of&nbsp;<em>Networking Windows</em>&nbsp;and co-author of&nbsp;<em>Windows NT Unleashed</em>&nbsp;(Sams).</p><p>He is co-host, with Ray Lucchesi of the monthly Greybeards on Storage podcast where the voices of experience discuss the latest issues in the storage world with industry leaders.&nbsp; You can find the podcast at: http://www.deepstorage.net/NEW/GBoS

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like

More Insights