Home > netapp, VMware > NetApp and VMware View 5,000-Seat Performance Report

NetApp and VMware View 5,000-Seat Performance Report

September 28, 2011 Leave a comment Go to comments

This report is a follow up to the 50,000-Seat VMware View Deployment white paper where NetApp analyzed a single pod of 5,000 virtual desktops.  This report is an in depth storage performance analysis of what VDI really is.  VDI is not only about steady state, login, or boot.  It’s about all phases, in the life span of the virtual desktop.  Below is one of the many charts and graphs that helps to demonstrates this fact.  The chart demonstrates that each phase has its own unique characteristics and such impacts storage very differently.

Lifecycle.png

For simplicity NetApp takes a unique approach in this document and overlay the performance tests on top of a calendar.  This way each of the different events in a “2 weeks in the life” of a virtual desktop can be easily analyzed and explained.

NetApp measured the deployment of 2500 virtual desktops using the NetApp Virtual Storage Console. We then look at first login where the user has never logged into this virtual machine before.  This simulates a scenario where the desktop has been re-provisioned after patching or something similar.  We look at a cached login for example “a Tuesday” where the user has already logged onto the desktop and this is the second time they log in.  Here the user logs in and starts working, which is probably the most common login workload.  We then look at a boot storm where the environment has to be shutdown and rebooted to demonstrate that with NetApp and VST, rebooting an entire VDI environment can be done quite rapidly (5,000 VMs in 18 minutes to be exact).  This demonstrates that the workload of booting or rebooting an entire environment doesn’t have to take forever!

Screen Shot 2011-08-29 at 3.10.58 PM.png

So what does all this mean and what do we look at in this paper?  We  dive deep into read write ratios, IO sizes, Sequential Randomness, and demonstrate that its not just all about IOPS.

Customers are often asked by their partners, virtualization vendors and storage vendors, “how many IOPS are your desktops doing”, they often reply with a number like 16 IOPS or maybe even more generic response like “we have a percentage of task workers, a percentage of power users, and a percentage of developers”.  If the response is along these lines, it will be sized wrong, almost guaranteed.

Lets take the simplest sizing approach…

Vendor: “Mr Customer, how many IOPS do you need each of your desktops to do?”

Customer: “Great question, I need my desktops to each do 16IOPS!”

Vendor: “Thanks for the info!  I’ll get you a sizing right away!”

Ok, does anyone else see the significant flaw in this methodology of sizing?  Lets do some simple math to figure out how this could go wrong…

If my IO size is 4K then: 16IOPS x 4K / IO = 64K/sec

If my IO size is 32K then:  16IOPS x 32K / IO = 512K/sec

So 16 IOPS != 16IOPS  There is a difference of 440Kb/sec in the two calculation

Why does everyone then size for only IOPS and not ask more difficult questions?  There are so many other questions that MUST BE ASKED!!!!

Are the IOPS 4K or 32K or a blend of all sizes? Are these reads or writes? Are they sequential or random?  Each of these has a SIGNIFICANT impact on storage as you can see by the example above!

This is why it is so important to perform an assessment with a product like Liquidware Labs Stratusphere Fit .  Then and only then are you able to get it sized right the first time!

Here are a couple of key takeaways from the paper!

  1. Assessments are the only way to get VDI right!
  2. VDI is not all small block random reads
  3. Theres more to VDI then steady state
  4. Login storms are the hardest workloads as it is reads and writes
  5. IOPS is only one part of the much larger story.
    1. Saying my desktops NEED 16 IOPS is useless!!!
    2. Saying 16 IOPS, 80%r/20%w, 20K reads / 8K write sizes, 50% sequential / 50% random reads gets you correct sizing’s!!!!!
  6. Memory overcommitment hurts really bad… The answer, buy more memory for your host or buy more storage!

http://media.netapp.com/documents/tr-3949.pdf

Advertisements
Categories: netapp, VMware Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: