So this is the Million Dollar Question, right? You, along with the executives sponsoring your particular VDI project wanna know: How many desktops can I run on that blade? It’s funny how such an “it depends” question becomes a benchmark for various vendors blades, including said vendor here.
Well, for the purpose of this discussion series, the goal here is not to reach some maximum number by spending hours in the lab tweaking various knobs and dials of the underlying infrastructure. The goal of this overall series is to see what happens to the number of sessions as we change various aspects of the compute: CPU Speed/Cores, Memory Speed and capacity. Our series posts are as follows:
But for the purpose of this question, let’s look simply at the scaling numbers at the appropriate amount of RAM for the the VDI count we will achieve (e.g. no memory overcommit) and maximum allowed memory speed (1600MHz).
As Doron already revealed in question 1, we did find some maximum numbers in our test environment. Other than the customized Cisco ESX build on the hosts, and tuning our Windows 7 template per VMware’s View Optimization Guide for Windows 7, the VMware View 5.1.1 environment was a fairly default build out designed for simplicity of testing, not massive scale. We kept unlogged VMs in reserve like you would in the real world to facilitate the ability for users to login in quickly…yes that may affect some theoretical maximum number you could get out of the system, but again…not the goal.
And the overall test results look a little something like this:
E5-2643 Virtual Desktops
E5-2665 Virtual Desktops
As explained in Question 1, cores really do matter…but even then, surprisingly the two CPUs are neck and neck in the race until around 40 VM mark. Then the 2 vCPU desktops on the quad core CPU really take a turn for the worse:
When a VM has two (or more) vCPUs, the hypervisor must find two (or more) physical cores to plant the VM on for execution within a fairly strict timeframe to keep that VM’s multiple vCPUs in sync.
MULTIPLE vCPU VMS ARE NOT FREE!
Multiple vCPUs create a constraint that takes time for the hypervisor to sort out every time it makes a scheduling decision, not to mention you simply have more cores allocated for hypervisor to schedule for the same number of sessions: DOUBLE that of the one vCPU VM. Only way to fix this issue is with more cores.
That said: the 2 vCPU VMs continue to scale consistently on the E5-2665 with its double core count to the E5-2643. At around the 85 session mark, the even the E5-2665 can no longer provide a consistent experience with 2vCPU VDI sessions running. I’ll stop here and jump off that soap box…we’ll dig more into the multiple vCPU virtual desktop configuration in a later question (hint hint hint)…
Now let’s take a look at the more traditional VDI desktop: the 1 vCPU VM:
With the quad-core E5-2643, performance holds strong until around the 60 session mark, then latency quickly builds as the 4000ms threshold is hit at 81 sessions. But look at the trooper that the E5-2665 is though! Follow its 1 vCPU scaling line in the chart and all those cores show a very consistent latency line up to around the 100 session mark, where then it becomes somewhat less consistent to the 4000ms VSImax of 130. 130 responsive systems on a single server! I remember when it was awesome to get 15 or so systems going on a dual socket box 10 or so years ago, and we are at 10x the quantity today!
Let’s say you want to impose harsher limits to your environment. You’ve got a pool of users that are a bit more sensitive to response time than others (like your executive sponsors!). 4000ms response time may be too much and you want to halve that to 2000ms. According to our test scenario, the E5-2665 can STILL sustain around 100 sessions before the scaling becomes a bit more erratic in this workload simulation.
Logic would suggest half the response time may mean half the sessions, but that simply isn’t the case as shown here. We reach Point of Chaos (POC!) where there is very inconsistent response times and behaviors as we continue to add sessions. In other words: It does not take many more desktop sessions in a well running environment that is close to the “compute cliff” before the latency doubles and your end users are not happy. But on the plus side, and assuming storage I/O latency isn’t an issue, our testing shows that you do not need to drop that many sessions from each individual server in your cluster to rapidly recover session response time as well.
So in conclusion, the E5-2643, with its high clock speed and lower core count, is best suited for smaller deployments of less than 80 desktops per blade. The E5-2665, with its moderate clock speed and higher core count, is best suited for larger deployments of greater than 100 desktops per blade.
Next up…what is the minimum amount of normalized CPU SPEC does a virtual desktop need?
Choosing the right compute platform for your VDI environment requires both science and art. You have to balance CPU and memory characteristics against your expected workload profile and your desired density. At the end of the day, VDI has to meet some cost criteria in order to go from a fun science project to a funded program in your company. That means you can’t just throw the top bin CPU at the problem; you have to pick the right CPU. This is further complicated by the fact that there is not one CPU that is ideal for all VDI workloads. There is no magical bill of materials at the end of this series of blogs, but we will attempt to make your VDI decisions based more on science than art.
Strength in numbers? Or strength in speed? As Tony said in his introduction, we had several involved questions related to VDI that we honestly couldn’t answer… so we decided to start testing. This will be a series of blogs that attempts to answer practical questions like “when is processor A better than processor B?” And of course you then have to ask “when is processor B better than processer A?” In this first installment in the series, I will tackle the question of whether the number of cores or the core speed is more important when the goal is to achieve the best desktop density per host. Here is a handy guide to the other posts in this series:
The usual suspects. Throughout this series, we will focus on two processors. We picked them because they are popular and cost effective, yet quite different from each other. They are not top bin processors. Take a look at the table below for a comparison.
Note: Prices in this table are recommended prices published by Intel at http://ark.intel.com and may vary from actual prices you pay for each processor. The SPEC performance numbers are an average of SPEC results published by many OEMs (at http://www.spec.org/) across many platforms. These are not Cisco-specific SPEC numbers.
Making sure your users don’t go to sleep (or worse) waiting to log-on
Hi Everyone! I am the team lead Technical Marketing Engineer for Cisco Virtual Desktop Infrastructure (VDI) solutions on UCS and Nexus. While I have done some blogging in my time – this is my first blog for Cisco. I have been in this space for over 22 years, before “virtualization” was called that, working with published applications and published desktops (MetaFrame and early RDP.)
With the Citrix and EMC teams, I have been focused for the past few months on validating what I think is a really exciting solution -- even if I say so myself. So recently not much time for blogging I am afraid.
Over the last couple of years we have seen desktop virtualization, specifically Hosted Virtual Desktops (HVD,) become increasingly more mainstream -- but today we are really experiencing an upsurge of deployments -- and not just pilots -- but full blown multi-thousand seat deployments.
As you are probably aware the worst nightmare is that you deploy the solution and the users don’t adopt it because it doesn’t provide them the user experience they need or want.
One of the key requirements for success is an infrastructure that won’t just provide the right experience for the first few hundred users -- but that will scale linearly as you grow into the many thousands.
You can rely on Cisco Validated Designs to deliver for you! We use real world test scenarios to insure that you can implement our designs in your environment and be successful.
The keys to a successful deployment of a large scale HVD environment start with:
Cisco Live Europe returns to London this year more precisely at the ICC Excel Conference Centre.
By focusing on “What You Make Possible”, attendees are invited to hear customer testimonials and see Cisco’s innovation solutions that showcase what is possible when partnering with Cisco.
As usual the event is divided between a series of educational programs, starting on Monday January 28 with a full day of technical seminars , followed on the 29, 30, 31 and even Feb 1st by a large range of opportunities
Keynotes sessions with CTO Padmasree Warrior (1/29) and Data Center SVP/GM David Yen (1/30 )
Break out sessions
Meet the Engineers
I will not detail all the activities. I encourage you to check the website. If you’re in London you want to attend directly – If not you may want to check www.ciscolive356.com to discover a large choice of sessions that you can attend on line .
The Nexus 1110 is the latest generation of appliances that started with the Nexus 1010. The Nexus 1110 helps customers that are virtualizing more of their application and security services and want to run them on a dedicated platform. For example, virtual firewalls, like our Virtual Security Gateway (VSG), complement physical firewall appliances to support virtual application deployments and VM mobility requirements. The Nexus 1110 appliance serves that need, running a range of virtual services on a platform that the networking and security teams can more directly control than the other application servers.
With Citrix NetScaler VPX integrated into the Nexus 1110 Cloud Services Platform, enterprise IT admins can scale-out deployments by enabling additional virtual NetScaler instances (VM’s) directly from the Nexus 1110. NetScaler VPX also provides feature and management consistency across physical and virtual ADC’s, as well as consistency across physical and virtual workloads that are being managed. The NetScaler portfolio includes two other physical appliances, MPX and SDX. The virtual VPX can also load balance across both physical and virtual servers, as well as multiple web servers, application servers and database servers.