Array Snapshots in the VDI Use Case and performance scaling

Phew - after all the politics and answering all the speculation with my own speculation, it's nice to get back to my comfort zone - a good technical topic. 

This is a question that comes up pretty often.   "OK - I want to save money on storage, accelerate image deployment and improve image management".   EMC and a few (and it really is a few) other vendors are looking at integrated VDI solutions leveraging VMware's capabilities and the array ability to take pointer-based writeable snapshots to save $$ on the backend (and that's "so far" - wait till you can see what we can do in the future :-)

You can see a video of what I'm talking about here:

and a whitepaper describing it here: http://www.vmware.com/files/pdf/partners/emc/emc_virtual_desktop_for_vmware_solutions_overview_wp.pdf

The inevitable question is - what about performance scaling?   All those VDI clients are hitting an original set of source blocks on the underlying storage subsystem.   So - what do we find?   Read on to find out.....

So - this is a topic that is under crazy amounts of research right now.   Everything to date shows that the array (and this is true of CX, DMX, NS, and I would bet NetApp also), the read response is very much a cache response - 90+%   The stuff that makes it through is crazy random.

So - empirical data is starting to come in from the RTP lab (interesting read on that here).   Here's the config we used in the test.  The number of ESX servers in the clustered varied throughout the tests.

 

The Celerra can take 1000 pointer-based snapshots of a source iSCSI LUN (and many times that across the platform).  It can also take 96 (16 of which can be writeable) pointer based snapshots of a source filesystems (CIFS and NFS - NFS can be used for datastores in the VDI use case, CIFS is used for re-directed user data).   The name of the game is simple - make the process as simple as we can, and reduce all the cost elements as dramatically as possible.   We can acheive a complete "deduplication" of the boot VMDKs - as they are 100% common - then apply the methods we've been using for a long time to eliminate redundant data in the user data.  Net - way cheaper, way faster, way easier to backup and do DR.

 

Case 5 - Open: Create doc, window exists, window activated; Writing random text to document not timed; Save&Close: Doc SaveAs random name, close document; Quit: Quit MSWord.  

As you can imagine - this is one case of hundreds, and the test harness includes all the other favorites (Mozilla and IE, PPT, Outlook, etc.)    The 128 client case was very much a "ok, let's get experience at the harness, and a quick result".    Net?  Quick results are showing pretty linear (notice the scale at the bottom isn't linear) response for most client use cases.

We also validated VMware's conclusions on users/ESX server here.   Below is what we found (this was a dual proc, single core, 16GB ESX server) - 40 XP VMs were happy as a clam.   For the formal testing, the standard is a much more modern host (dual proc, quad core, 64GB RAM) - with which we expect to be able to do well north of 100 clients per ESX host.   VMware's doc is also getting a bit long in the tooth and I know they are refreshing it, and so we'll both see what we get with more modern server platforms.

The esxtop command was used on all four ESX servers while tests were running to obtain server resource utilization statistics. The command line used was:

$ esxtop -s -b -d 30

Measur ements were collected and charted for the server’s:

• Total Processor Time
• I/O Rate with Celerra Storage
• Memory:
  • PShare<Savings, Shared, Common>
  • Swap<Target, Used, I/O rate>
  • Memctl<Current, Max, Target>

Here's the CPU results....   Interesting to see the steady decline over time as the workload ran - that's good.

What was interesting that you don't see in the CPU utilization data is that the client response was remarkably good even at the highest degrees of ESX CPU utilization.   The number of VMs were "the number of VMs on that single ESX server".

For VMworld - the EMC (and VMware - it's a joint project) goal will be to share what we call a "Reference Architecture" - i.e. a detailed doc explaining how to do this in various configurations and scaling points.   The  goals are 500 and 1000 user configs focused on entry-level configurations (both CLARiiON and Celerra), and to try to find more "real" ways to simulate client workloads through the VDM connection broker.    We've also gotten requests from our LARGEST joint enterprise customers, and also doing a MASSIVE one focused on DMX for boot VMDKs, Celerra for user data, ThinApp for streamed applications right now in Santa Clara.

To put it in perspective - the big configuration is designed for 5000 users to start, then up to 10K and 20K clients - with a storage consumption of a few hundred GB for all the boot images.

BTW - shout out to the Research Triangle Park Celerra team on this one - particularly Greg Smith.   You da man, Greg - and can't wait to see more!

To all of you - is this interesting?   Come by VMworld - while there is literally man-years of work here being crammed into months - I think we'll have the 500-10K client docs done and ready to share en masse.   Are you doing, or contemplating VDI?  What more would you want to see?   It's a great opportunity to influence our testing harness - please comment!

Comments

[Vaughn Stewart]

Can I ask for a point of clarification in your demo? Is each Virtual machine (desktop) running on its own LUN? I ask as in you video you clone LUNs which results in cloned VMs.

[Chad Sakac]

Thanks Vaughan! In the demo shown above, we have two VMs in the orginal LUN, and we are absolutely replicating at the LUN level.

This has several significant downsides:
1) You run into the LUN limits of the ESX cluster (255-number of nodes in the cluster)
2) You need to start with more gold-images per container to avoid being limited by the LUN count (the tool does automate this too)
3) While all the LUN handling is managed via the tool automatically, so there is no management overhead, it's not "pretty" to have so many LUNs per cluster.

We're (and I'll talk to you about this at VMworld next week) working on our next major update around VDI, based on the "not so secret" stuff coming from VMware to make this even simpler, and lower the cost (and also resolve the problem of the storage management model - for VMFS and NFS use cases.

We're also working on leveraging the longer term secret stuff (I know you guys are working on these too) to hook in VM-level operations for block devices at the ESX kernel level.

More on both next week!!!!!

BTW - congrats to Dan Baskette for winning the 3rd place award in the VMware PowerShell contest for the PowerVDI tool.... Wait until everyone sees what's next :-)

[How to facilitate the patch management of VMs by ONLY updating the Golden Image.]

Wow, fantastic solution to save time and storage when VM provision. I'm wondering how to facilitate the patch managemnt of all the VMs by only operate the Golden Image(for WindowsXP)? Is it possible to install patch into the Golden Image, then the patch can be available to all the VMs? since all VMs are based on the same Golden Image by snapshot mechanism.

Thank you.