The desktop is a unique beast within the data center. It is something different than what we’ve typically placed within the tightly controlled, highly-available environment. What happened so far is that the desktop has changed to better align with data center practices. That means having high levels of availability and utilizing shared storage. But is this the right approach? Should the desktop align with the data center or should the data center align with the desktop by developing a new service level?
I’ve seen many people apply high-availability requirements to the desktop, which often requires the use of shared storage. Personally, I think this is going too far. I don’t think it is needed, but as soon as I state something like this, I get a lot of pushback.
Let’s walk through the arguments I normally hear:
There is a belief that utilizing local storage will not provide enough performance to accommodate virtual desktops. Organizations have successfully used local storage. I’ve seen lab tests help back this up. The important thing is that you have enough performance (which is no different if you use shared storage). On the local storage side of things, your limiting factor will be how many drive bays you have. With a 8 core, dual processor server (16 total cores), you will need roughly eight 15,000 RPM spindles. It is also a good idea to utilize an array controller that can do caching of the writes to help reduce the peaks.
Once you finally believe that local storage can provide the required performance, the next roadblock is availability. What happens if the server has a catastrophic failure and everything is lost?
Truth be told, a server hosted virtual desktop has better availability than any traditional desktop I’ve ever seen. Think about all of the redundancies we apply to any data center workload:
• RAID: A server will most likely use RAID, allowing me to overcome a failure of a drive. My traditional desktop can’t do this.
• Power: A server will most likely have redundant power supplies. My traditional desktop doesn’t have this.
• Network: A server will most likely have redundant network connections. My traditional desktop has one.
• Monitoring: A server will most likely be constantly monitored by a team of admins. My traditional desktop is ignored.
Already, my server hosted virtual desktop will have better availability than my traditional desktop and I haven’t even made a requirement for shared storage.
Even with all of these redundancies at the local server level, what happens if the server still has a catastrophic failure and I’m using local storage?
• If I have a shared desktop (XenApp), and it fails, I simply start a new session. The impact is pretty minimal.
• If I have a pooled desktop and it fails, I simply start a new session. The impact is pretty minimal.
• If I have a personal desktop (Personal vDisk or dedicated desktop) and it fails. The user gets a fresh desktop with the standard, corporate image including the standard application set. The user completes the process by personalizing it as necessary. This isn’t as bad as it sounds. Think about what goes into personalization
○ Data: The user’s data should be stored somewhere besides locally (ShareFile or network share is optimal).
○ User Settings: Desktop and application settings are still part of the profile, which should be on a network share and configured as a roaming profile.
○ User Applications: If we are using local storage for the virtual desktop, then our user applications have been lost.
Is losing user applications a reason that would require us to use shared storage? I don’t think so.
Remember, by their very nature, user installed apps are not supported/managed/maintained by IT, they are user-managed. User apps are the user’s responsibility. It is the user’s responsibility to install the apps if they need them. It is the user’s responsibility to fix the apps if they break. The nature of user apps is that it is all up to the user.
This is the point many people forget to consider when debating about local vs. shared storage.
Your hardware platform will dictate whether you can even approach local storage. If you go with blades, local storage is not going to happen due to the limitations on drive bays.
What if you have 2000 or fewer users? Too many times, we focus squarely on the enterprise environments (10,000+ users) and ignore the small-to-medium business. So I ask you, does it make sense to go with blade servers with SMB? Will you even fill up a single chassis?
You will more than likely run rack-mounted servers where you will be able to fit at least 8 drive spindles within each server.
Remember, we are dealing with a desktop. In the traditional desktop model where we each have a physical PC sitting at our desk, what is the SLA to get that PC repaired if it fails? How long will it take to get a loaner device? What will be included within the loaner? I can guarantee you it will not include your user apps, and chances are it will be some outdated piece of hardware that no one wants.
Simply moving towards a server hosted model, even on local storage, will still have a better SLA than traditional desktop. I can simply access a fresh virtual desktop and start working. This is much faster than the traditional model.
I ask you, is local storage such a bad thing for virtual desktops within the data center?
Daniel – Lead Architect
If it wasn’t for the cost, I would…
Cost is one of the major barriers to doing almost anything. With enough money and resources, a person can do anything, but this makes a lot of things unfeasible because we don’t have an unlimited supply of money.
When we tried to create a solution to mobilize Windows applications for 500 users, cost was a major concern. How can we create this solution while keeping costs in check?
Let’s use local storage!
Of course anytime you talk about local storage, you get tons of negative reasons why it won’t work.
When it comes to storage, the fear is that you won’t have enough performance to keep up with user demands. This is understandable, especially as servers get faster and traditional disk spindles remain the same, spinning at 15,000 RPMs. However, XenDesktop App Edition (XenApp) is different. It is different because you don’t have a single OS for each user; you have a single OS for many users. And because of this one important point, storage performance is not what you would expect.
But this is mostly theory. Theory is good, but I like to see theory put to the test. As I’ve said before, we wanted to validate that this solution is in fact viable, which is why we had the Citrix Solutions Lab help us with the testing.
First, we need to understand our Read/Write ratio. For Machine Creation Services, we have typically said that for Windows 7 desktops, we have about a 40/60 ratio between reads/writes; Provisioning Services is 10/90. What about when doing a Windows Server 2012 workload? As we’ve seen in previous versions Provisioning Services has a similar R/W ratio regardless of the operating system. What about Machine Creation Services? This is the first release where Machine Creation Services can do Windows Server 2012. Will it resemble a Windows 7 desktop R/W ratio?
Not even close
I will be completely honest with you, this result completely shocked me. It surprised me so much that we ran the test 3 different times and got very similar results. I was still skeptical and had them re-run the test a 4th time roughly 3 weeks later. Same results (all using Windows Server 2012 with Hyper-V, by the way).
So the R/W ratios are very different between Windows 7 and Windows Server 2012. What about steady state IOPS per user? Just so you know, when trying to determine steady state IOPS, I prefer to look at the 95th percentile, instead of an average. That way we make sure we don’t under-allocate storage. If we look at the Windows Server 2012 test using Machine Creation Services, you get the following results
Regardless of which of the 4 tests I looked at, the numbers and graphs were almost identical. This is the highest of the 4 tests resulting in 6 IOPS per user at the 95th percentile (average is roughly 5 IOPS).
So what does this mean? It means that local storage, as we configured it within the Mobilizing Windows Applications design guide, is a viable, low-cost option.
Daniel – Lead Architect
In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.
Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. We ended up with the following:
A few interesting things:
- Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
- The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)
A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.
The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.
Daniel – Lead Architect Follow @djfeller
We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example…
We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that many users want to use the application on non-traditional devices (tablets) because it is more convenient. We’ve heard that VDI can help us with this. What will it take?
First, this is a good question, but unfortunately, the person has already decided on a solution without understanding what is possible. I can’t blame the person for already believing that VDI is the right answer because the marketing teams that are focused on VDI have done a great job blanketing us with the VDI message. And unless you are knowledgeable about the functionality with different products, you might miss the nuances and buy something you weren’t expecting.
If I were to make a recommendation with this particular customer, I would steer them to XenDesktop 7 App Edition (for those of us who have been around for some time, I’m referring to XenApp), which basically delivers an application to a user instead of the entire desktop. This solution aligns closely with what the user needs.
But what will it take for 500 users? Not much… just three physical servers using two Intel Xeon E5-2690 @2.9GHz with 192 GB of RAM.
Of course many will think this is all theoretical. But to prove this isn’t simply fairytales and unicorns, we built, tested and validated this Design guide to mobilize windows apps in the Citrix Solutions Lab (I will provide more gory details in a future blog).
When we go through the numbers and incorporate it into our 5-layer conceptual model, we get the following (Read about the XenDesktop 7 blueprint to better understand the 5-layer architecture).
This solution gets you the following:
- Delivery of almost any Windows-based application to any endpoint to any location without requiring the application to be rewritten for the numerous types of endpoint device types and form factors.
- Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
- An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
- Most importantly, the entire environment is using standard local storage. There is nothing special about the local storage as each physical server includes (8) 300GB SAS drives spinning at 15,000 RPMs configured with RAID 10.
Of course this is just conceptual, so what does the physical architecture look like?
- 3 physical servers required to support 500 users, with each RDS host supporting roughly 50 users. If more users are required, another server is added resembling the “Server 3″ config. We don’t have to worry about scaling the Access and Control layer components for some time as they have low utilization.
- Three different VLANs for DMZ, VM, and Management traffic. I know some of you will point out the risk with putting the NetScaler Gateway VPX on internal servers and having the VLAN for that VM go to the DMZ. Depending on the size and complexity of your infrastructure, this might be a non-issue as long as you have the proper configuration and lockdown procedures.
- Access Layer and Control Layer configured with N+1 availability in that if one component fails, a secondary component is available to take over the load.
When trying to decide what to do in your own environment, remember to look before you leap.
If you want to read the entire design, check out the Design guide to mobilize windows apps
Daniel – Lead Architect
Sometimes, the things we learn early in life teach us the basic fundamentals we need in the future. Many of us probably had toys like this growing up or have them for our own kids.
Of course there are some out there who will say that they can get the square peg into the round hole if the beat the hell out of it. This is true, but you waste a lot of energy as well as probably damaging the peg and hole.
This simple concept of properly matching objects together fits with the final layer of the XenDesktop 7 blueprint.
So far, the blueprint has been mostly conceptual. The hardware layer takes the conceptual and turns it into physical. The hardware layer has us think about the storage fabric, server footprint and VM allocations.
But just like the block toy, we have the same situation occurring within the hardware layer. We need to properly match hardware technologies together.
Think about storage fabric and server footprint for a moment.
With storage fabric, I can choose either local, direct attached or centralized storage, while server footprint lets me opt for either rack mounted servers or blade servers. These two decisions, although separate, are tightly coupled, just like our block toy.
The type of storage fabric you select will have a dramatic impact on the server footprint, and the server footprint you select will also have an impact of the storage fabric.
Let’s say you want to go with blade servers for some reason. Although at first glance it would seem like I can go with either local or centralized storage, this is not truly the case. Due to the physical space limitations with blade servers, I will most likely only be able to support two disk spindles per blade. So although I could use local storage for desktop virtualization when using blade servers, I’m trying to force a square peg into a round hole.
What if we go with rack mounted servers (round peg) and centralized storage (square hole)?
Guess what? You can fit a round peg into a square hole, but you have unused space. It doesn’t fit perfectly. And that is exactly what we have with rack mounted servers with centralized storage. You can do it. It does work. But it typically isn’t the optimal solution, whereas local storage with rack mounted servers seems like a much better fit.
Depending on what you choose might impact the hardware you are capable of running. For example, if you chose local storage, you will have problems trying to run your environment with blade servers. Why? Because you only get 2 disk spindles. Not enough to handle the storage requirements for a virtual desktop solution (unless you add on storage optimization technologies.)
These two decisions helps us adding details to our architecture:
Of course the next part of the hardware layer is to start calculating how many physical servers you need and how much storage is required, which is a discussion for another time. But for now, we have the framework for our complete solution.