Why choose a VNX over VMAX for VDI

A customer is looking to share his existing VMAX to also run his VDI workload. They want to run 3000 desktops concurrently and this can scale up. We are recommending a seperate VNX to them but they want to know why they can't use their existing VMAX instead.

We've spoken to them about all the different reasons:

-     The VDI workload is very different form the Server workload and should be isolated.

-     The ability of FAST Cache to let them size for average IOPs while letting them absorb all IO Storms without sizing for peak IOPs.

-     The Unified Storage aspect of the VMAX to host user date, profiles, etc.

-     And so on....

They are asking for specific data to back this up. Please take a look at what I copied and pasted from Itxik's blog. I need something similar for the VNX.

"

1. This came from one of our team members, a few months back.

1. A large financial did this for awhile on a DMX and then realized what a bad idea it was.  Their storage architect’s quote to me was “VDI is a nasty workload, I don’t want it on my enterprise storage.”  What he was saying: “we had VDI on our DMX along with other workloads and the spikes affected them so now we run it on its own NS.”

1. We can't lose sight of the $$ / User that is always factored into the VDI discussions.  It's a metric that works in the server world, but in the desktop world, it's not so clear cut.  Putting the workload on a VMAX, even if the customer already owns the Frame, will cost more to populate the disks and licenses than purchasing the VNX.

The other area that customers have been speaking to me about lately is the Failure domain.  The idea of hyper consolidation of the desktop environment is a very different risk profile than that of the server world.  Lose an infrastructure with servers, and your users can still function to some degree, but lose one with the desktops, and you just cut them off at the knees...which is why I've seen some customers lately opt for smaller configs and scale out...for price, performance isolation, and risk mitigation.

Anyways, if they still want to pursue the VMAX route….

Here is something that you can forward them and have them take a look at. I can’t stress enough to get the assessment done for their particular workloads, as their results could vary. But this should be a good starting point for them.

http://itzikr.wordpress.com/2011/05/25/designing-a-really-large-vdi-deployment-on-a-vblock-700mx/

Another POC we did for a customer resulted in this . …..

• Workload Profile:

• Average: 10 IOPS per desktop

• Peak: 30 IOPS per desktop

• Total number of virtual desktops: 1000

• 100% of the sessions running with 60% of the sessions in use

• 20 GB C: drive per desktop

• Expected response time: 10 ms

• Hardware:

• Storage Array: VMAX

• Servers: Dell PowerEdge R815 with (2 X 12 Core AMD processors & 128GB RAM): ESXi

• Software:

• ESXi 4.0 Update 2

• VMware vCenter 4.0 Update 2

• VMware View 4.5 (Beta)

• Windows XP Professional: desktop clients

• View Storage Layout:

• Parent VM: 1 x 122 GB EFD disk

• Replicas: 8 x 122 GB EFD disks

• Linked Clones (1 replica : 128 linked clones): 8 x 600 GB FC disks

Based on the above config, 1000 users (RAID1) consumed around 35% of the Cache Utilization (128GB) with two engines So following this logic, 100% / 35 = 3 (roughly) so you can probably put up to 3,000 per 2 engines and 128GB of Cache Now, following this logic, on a fully spec VMAX 20k (8 engines), you can put around 12,000 users (3,000 X 4) with no FASTP VP."