Re-Examining NAS vs SAN in Virtual Computing Environments

by Eric Burgener, VP Product Management

Posted Wednesday, October 26, 2011 in Technology          0 comments

Tags: excessive storage spending, VMware

I’ve been spending a lot of time at trade shows and with customers in the last couple of months talking about our upcoming vSphere product scheduled to ship by the end of calendar Q411.  From these conversations, a good number are considering NAS in their vSphere environments.  When asked about why they find NAS attractive from a storage point of view, I’ve heard the following:

• NAS is easier to manage than block-based storage
• NAS is by definition shared storage so I can support desired live migration and high availability capabilities
• NAS gives me thin provisioning to save on storage capacity without me having to consciously configure it, but this often evolves into a conversation about the ability to quickly provision high performance storage for new VMs
• I can use array-based snapshots, which offloads the host and can offer performance and scalability advantages over hypervisor-based snapshots

As I review the broad set of use cases in virtual computing, there’s no doubt that all of these features are desirable for various reasons.  But I’ve noticed an undercurrent in these conversations – an assumption that you can’t get these capabilities together - especially the ease of use one - with block-based storage.  Let’s look at a conversation I’ve had a lot recently.

First, let’s examine ease of use.  Administrators say that NAS (i.e. file) is easier to manage than block-based storage.  My end users care about files, not LUNs, and NAS lets me manage things at the file-level instead of at the LUN level.  It makes management VM-centric instead of storage-centric (after all, VMs are what I really care about) and has implications for live migrations and snapshots – I can save time, bandwidth, and space by just working with relevant VMDKs instead of entire LUNs that inevitably have multiple VMDKs on them, some of which I care about for a particular storage operation and some of which I don’t.  Also, NAS manages all the space reclamation issues for me when I’m deleting VMs, so that’s just one less thing I have to do if I’m spinning VMs up and down a lot (or even only sometimes).

Second, shared storage.  HA is a requirement in many production environments.  Shared storage is a pre-requisite for moving VMs around between hosts, regardless of whether you’re doing it for HA or for load balancing reasons.  FC SANs give me a shared storage capability, but they are block-based, and if I’m interested in making storage easier to manage that could be a knock against them.

Third, thin provisioning.  Thin provisioning allocates storage only as I need it, which in many virtual computing environments can save up to 90% on storage capacity consumption relative to the older approach of allocating all storage required for a particular VMDK up front.  And I can provision thin provisioned devices very quickly when I’m spinning up new VMs – much more quickly than fully allocated “thick” virtual disks.  But there’s that pesky issue of performance.  There’s no doubt that thin provisioned devices perform more slowly – in some cases as much as 90% slower – than thick disks, but they may perform fast enough that “performance” isn’t an issue in your environment.  What would be really interesting, though, is if you could provide a thin provisioned device that performed at the level of fully allocated devices right up front.  This would directly impact the VM density your storage configuration could support, and if this lets you deploy, let’s say, twice as many VMs per host while still meeting performance requirements, now that starts to become a lot more interesting.

Fourth, snapshots.  When people talk about NAS giving them access to great snapshot technology, they’re generally making a veiled reference to NetApp.  VMware provides a VMware API for Array Integration (VAAI) for both block and NAS-based devices, but until recently VAAI NAS was not accessible to any vendor other than NetApp.  vSphere 5 promises to open that up to other vendors.  VAAI NAS allowed snapshot/clone creation and usage to be offloaded to a NetApp array, which allowed VMs to access a more performant, more scalable snapshot technology than was available in the ESX hypervisor.

There’s a lot to like here.  But block-based FC storage has some nice advantages as well, particularly in the areas of performance and security.  A lot of folks already have FC SANs, and might just plan on expanding them as they roll out their virtual computing environments.  And frankly, buying NetApp NAS with all the trimmings for snapshots and performance isn’t cheap.  Can’t somebody give us an option that gives us the performance of FC with the generally recognized advantages of NAS?

For me, this is probably the core technical differentiator that Virsto brings to the table.  We run on block-based storage, and if its shared storage then we fully support capabilities like failover and vMotion.  Our logging architecture (implemented at the storage layer) ensures that you’ll get performance that exceeds that of fully provisioned “thick” virtual disks with storage objects (which we call Virsto vDisks) that are thin provisioned so they can be provisioned extremely rapidly - we're talking literally thousands of clones in seconds for tasks like, say, desktop provisioning.  You’ll get this same performance and rapid provisioning on any snapshot and clones you create, regardless of how many of them there are.  And we support a lot – you can realistically create and use tens of thousands of snapshots/clones without any performance degradation.  And finally, we give you the ability to manage storage operations at the level of granularity that you need for maximum efficiency – the VMDK level.

We’re working on getting this story out, but its an evangelical task.  Most folks I talk to have pre-conceived notions about what SAN and NAS give you, that SAN is hard to manage, that thin provisioned devices perform slowly, that you have to pay a lot to get scalable snapshot technology.  Are you operating under some of these same assumptions?  They were true in the past, but the times… they are a-changin’.