In the first few posts in this series, we have hopefully shown that not all cores are created equal and that not all GHz are created equal. This generates challenges when comparing two CPUs within a processor family and even greater challenges when comparing CPUs from different processor families. If you read a blog or a study that showed 175 desktops on a blade with dual E7-2870 processor, how many desktops can you expect from the E7-2803 processor? Or an E5 processor? Our assertion is that SPECint is a reasonable metric for predicting VDI density, and in this blog I intend to show you how much SPECint is enough [for the workload we tested].
You are here. As a quick recap, this is a series of blogs covering the topic of VDI, and here are the posts in this series:
Addition and subtraction versus multiplication and division. Shawn already explained the concept of SPEC in question 2, so I won’t repeat it. You’ve probably noticed that Shawn talked about “blended” SPEC whereas I’m covering SPECint (integer). As it turns out, the majority of task workers really exercise the integer portion of a processor rather than the floating point portion of a processor. Therefore, I’ll focus on SPECint in this post. If you know more about your users’ workload, you can skew your emphasis more or less towards SPECint or SPECfp and create your own blend.
The method to the madness. Let me take you on a short mathematical journey using the figure below. Starting at the top, we know each E5-2665 processor has a SPECint of 305. It doesn’t matter how many cores it has or how fast those cores are clocked. It has a SPECint score of 305 (as compared to 187.5 for the E5-2643 processor). Continuing down the figure below, each blade we tested had two processors, so the E5-2665 based blade has a SPECint of 2 x 305… or 610. The E5-2665 blade has a much higher SPECint of 610 than the E5-2643 blade with just 375. And it produced many more desktops as you can see from the graph embedded in the figure (the graph should look familiar to you from the first “question” in this series).
And now comes the simple math to get the SPECint requirement for each virtual desktop in each test system:
Read More »
Tags: citrix, cpu, UCS, vdi, virtual desktop, virtualization, VMware, vxi
For everyone in the VMware Partner Community, next week marks the gathering of technologists to learn, train, and generally get together. Cisco has some great opportunities to do all of the above.
The easiest way to stay up to date? Follow us @CiscoDC. If you’re not on Twitter, find me, give me 5 minutes, and let’s see if I can convince you to join your community of peers.
Here are some VMware PEX highlights:
Boot Camp: Connect, Discover, Learn with Cisco
Monday, February 25, 8:30 a.m.–5:30 p.m.
Session ID: SPO2400
The Cisco Boot Camp is dedicated to educating and enabling partners to sell and deploy Cisco solutions successfully.
Breakout Session: Cisco Unified Data Center: From Server to Network
Wednesday, February 27, 12:30–1:30 p.m.
Speaker: Satinder Sethi, VP, Server Product Management and Data Center Solutions, Cisco
Demos: Cisco Booth 1015!
- VDI: Cisco UCS with VMware View
- Cisco Servers: Cisco Unified Computing System with VMware
- Cisco Nexus 1000V Family
- Cisco Unified Management
- Branch Office Consolidation with Cisco E-Series Server
- EMC VSPEX Proven Infrastructure
Also in Cisco Booth 1015, we’ll be shooting multiple episodes of Engineers Unplugged! Drop by to see some of the superstars of IT in full whiteboard action. Topics range from automation to virtualization to SDN. Send me a Tweet @CommsNinja if you’d like to participate!
But wait, there’s more, in addition to the fantastic official networking/social events at VMware PEX, we’re gathering as Geeks Without Borders to kick things off Sunday Night. Come out, meet your colleagues in person, say hello.
Speaking of community, be sure to sign up for our growing Data Center Virtualization Community, to hang out with the Cisco experts virtually.
Tags: cisco community, Cisco UCS, data center, engineers unplugged, nexus, pex2013, SDN, vdi, virtualization, vmware partner exchange, vmwarepex, vspex
Virtualization on the plant floor
“While IT networks already use virtualization extensively, its benefits are moving into industrial networks. Five diverse viewpoints on its advantages and implementation are offered.”
Great article in the recent Control Engineering magazine on the the topic of virtualization for manufacturing environments. Control Engineering states it is a major discussion, so they are approaching it from a variety of viewpoints. “Below are the stories written from industry professionals and their viewpoints on virtualization.”
The article can be linked to at Control Engineering by clicking on the following links…
- Getting more from less, Joel Conover, Cisco
- Virtualization lifecycle considerations, Paul Hodge, Honeywell Process Solutions
- Breaking chains to improve delivery, Grant LaSueur, Invensys Operations Management
- Building reusable engineering, Anthony Baker, Rockwell Automation
- Preparing your power distribution system, Jim Tessler, Eaton
Key Concepts Read More »
Tags: Control Engineering, Peter Granger, Plant floor virtualization, virtualization, Virtualization on the plant floor
Fabric-Based Infrastructure and Cisco UCS
A good segue to Fabric-Based Infrastructure is Gartner’s Magic Quadrant for Blade Servers (March 2012), by Andrew Butler and George Weiss. To fully understand the tie in with Fabric-Based Infrastructure I suggest reading the section on Cisco UCS. Their observations are important because they tie directly to the subject of this blog. You will also get a better feel for why Cisco UCS is having such rapid customer adoption worldwide.
The emphasis for Fabric-Based Infrastructure is delivering value-add functionality that enables data centers to operate more efficiently and cost effectively. A good place to start is by looking at this Gartner report by George Weiss and Donna Scott -- Fabric-Based Infrastructure Enablers and Inhibitors Through the Lens of User Experiences (April 2012). In this short research note, George and Donna go into the key drivers and reasons for the FBI architecture and the benefits that their clients have seen. My take away for the key benefits of Fabric-Based Infrastructure are:
- OpEx and CapEx savings
- Increased VM density
- Time-To-Deploy reduced from months to hours via automation and standards implementation;
- Reduce cost and complexity and improve agility;
- Improved resiliency by recreating servers and connectivity in minutes using profiles and templates
While reading about a technology innovation is helpful, actually listening to experts discuss the architecture and give their individual perspectives can be more so.
I suggest that you make time to listen to this 34 minute video with featured guest Donna Scott (a VP and Distinguished Analyst at Gartner) and Paul Perez (VP and CTO for the Data Center Business Group at Cisco Systems) -- Fabric-Based Infrastructure (FBI) in Today’s Data Center. Donna looks at the motivations and impact of customers moving to a Fabric Based Infrastructure with an eye toward what is important to adopters. Then Paul discusses Cisco UCS innovations and how they let FBI adopters achieve their goals. If you would like, you can download a podcast of the video from theCisco Analyst Reports page.
From my perspective the truly compelling part of this story is the extent to which Cisco UCS makes the promise of Fabric-Based Infrastructure a reality, while emphasizing safety, security and the risk reduction. These are critical considerations in today’s IT environment. Cisco continues to be a key innovator in data center technology and is continuing to grow from strength to strength, delivering value and benefit for your long term application solution needs.
Below is how I think a Fabric-Based Infrastructure should look. Of course I am predisposed. Cisco UCS architecture provides the ability to define and manage over 120 different server identity parameters via service profile templates, using a native tool with Roles Based Access Controls and across geographies. UCS enables you to have a distributed environment that is centrally managed. Your admins can also use CLI, custom designed tools / scripts, or third party tools as they choose to meet the needs of their current management structure.
Read More »
Tags: Cisco UCS, data center, data center management, Fabric computing, Fabric-Based Infrastructure, intelligent automation, network, Server Management, UCS, virtualization
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:
You are Invited! If you’ve been enjoying our blog series, please join us for a free webinar discussing the VDI Missing Questions, with Doron, Shawn and myself (Jason)! Access the webinar here!
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?
Tags: citrix, cpu, UCS, vdi, virtual desktop, virtualization, VMware, vxi