Archive
Simplified VDI Architecture – #Citrix, #XenDesktop
This is a great start of a blog series from Citrix!
There’s a perception that VDI is complicated. I’m far from being a rocket scientist, and I’ve managed to implement many successful VDI projects over the past ten years. I truly believe that VDI is one of those things that is only as complicated as you make it.
It’s like saying that driving is complicated. You’d have to be crazy [or very brave] to take your first lesson in Manhattan…during rush hour. That’s why your driving instructor starts you off on a quiet street. You need to know your boundaries. Being successful with VDI is the same – keep things simple to start with and slowly increase complexity at your own pace, when you’re ready for it.
This raises the question – what’s the quiet street equivalent of a beginner’s VDI architecture? It might not be the most optimized and efficient solution, but it would be quick to implement, do the job well and wouldn’t require specialist knowledge or skills. I’ve been thinking about this a lot lately, and I’d like to share my thoughts.
There’s a lot to consider, so I’m going to break this up over four different blog posts:
- Simplified VDI Architecture – Introduction & FlexCast
- Simplified VDI Architecture – Storage
- Simplified VDI Architecture – Provisioning
- Simplified VDI Architecture – Reference Architecture
Martin Zugec will be helping me out with this blog series and will be referring to his experience on actual customer projects that followed many of these recommendations.
XenDesktop or VDI in a Box?
First up, you need to make a decision on VDI in a Box or XenDesktop. VDI in a Box is easier to setup but does have some limitations. Check out Allen Furmanski’s excellent blog post for guidance on how to make this decision. I’m going to concentrate on XenDesktop for this post.
FlexCast
Although each FlexCast model has its own unique advantages, each additional model included adds complexity to the overall project. There is a great table in the Virtual Desktop Handbook (FlexCast Model Selection – Table 11) that provides guidance on the capabilities of each model. The main thing to note is that all scenarios, apart from offline, can be accommodated using the Hosted VDI model (XenDesktop), either with or without a Personal vDisk. It may not be the optimal selection in every instance, but it is almost always a viable solution.
There are a number of reasons why I think that XenDesktop is simpler than XenApp, including:
- Desktop applications are developed to run on desktop operating systems such as Windows XP or Windows 7. There aren’t many developers that test their applications on Windows Server 2003 or 2008. Therefore, you’re far less likely to run into application issues with XenDesktop than you are with XenApp. Even if your applications run okay on 2008 with XenApp, you’re probably going to have issues getting support from the application vendors.
- Hosting applications on multi-user operating systems can introduce additional application compatibility challenges. Users may share the same configuration files and registry hives, especially if the applications are not multi-user aware. This means that one user may change a setting that affects all other users of that server. There are a ton of tips and tricks to get these apps working correctly but we want to keep things simple and choosing XenDesktop helps us achieve this goal.
- As multiple users are hosted on the same operating system, it is important that XenApp desktops are locked down to prevent security breaches and misconfiguration that could impact all users sharing the environment. Typically, this results in an extremely controlled and restricted user experience, hindering user satisfaction and acceptance.
- With XenApp desktops, a single user can consume a disproportionate amount of resources, impacting the performance of other users sharing the same XenApp server. XenDesktop, on the other hand, allows vCPU and RAM assignments to be controlled on a per-user basis. For this reason, I strongly recommend that heavy users are hosted on XenDesktop rather than XenApp.
- With XenDesktop, it is possible to provide users with fully personalized desktops. This includes the ability for users to install their own applications.
- Unlike XenApp, XenDesktop supports generic USB redirection:
I’m a huge fan of Remote PC, especially when you consider just how simple it is to deploy. However, there are some things Remote PC just can’t do, including:
- You don’t have the flexibility to quickly provision or de-provision desktops based on business demands.
- Image management is more complicated than a virtual desktop because you can’t use MCS and PVS can be challenging with desktops outside of the data center
- You need to have a good connection between your XenDesktop Controllers and the physical desktops. Something not always available for WAN users.
Regardless, Remote PC is a great solution in many scenarios. Consider deploying Remote PC at the very start of your project. It allows you to realize immediate value while you’re designing and implementing your full VDI solution.
If XenDesktop is so much simpler why do so many projects still standardize on XenApp? It all comes down to cost – XenApp offers significantly higher levels of scalability than XenDesktop (some sources quote 300% more users). Let’s take a look at this in more detail.
Processor
The Virtual Desktop Handbook provides us with guidelines on processor requirements for both XenApp and XenDesktop (Processor Requirements by Workload – Table 22):
If processor is the bottleneck, we can estimate the scalability of XenApp and XenDesktop for a fairly typical server configuration (2×8 cores):
As you can see, XenApp offers between 17% (heavy user) and 28% (light user) more users than XenDesktop – but nowhere near 300%! Let’s put this into context, if you had 1,000 concurrent normal users, you would need seven physical servers for ‘XenDesktop: Windows 7’ and six physical servers for ‘XenApp: 2008 R2’. Is one additional server per ~1,000 users enough to justify the additional complexity of XenApp?
RAM
For RAM, the Virtual Desktop Handbook table (Memory Requirements by Workload – Table 23) shows us that ‘XenDesktop: Windows 7’ requires significantly…
Continue reading here!
//Richard
Delivering #Citrix #XenApp on #Hyper-V with PVS and #McAfee – via @TonySanchez_CTX
Good Citrix blog post from Tony Sanchez!
Architectures—whether physical or virtual—should be flexible enough to adapt to different workloads, allowing them to support changing business needs. Although implementing a new IT architecture takes time and careful planning, the process to test and validate an architecture should be easy. In the case of a virtual desktop architecture, test engineers should be able to follow a repeatable pattern, step by step, simply changing out the workload to validate the architecture under different anticipated user densities, application workloads, and configuration assumptions. The procedure should be as easy as learning a new series of dance steps (think PSY’s Gangnam Style, the most watched dance video on YouTube). The point causes me as a test engineer to ask the question: in the case of VDI, why can’t a hypervisor simply learn a new workload just like I might learn a new sequence of dance steps?
Luckily for test engineers, Citrix FlexCast® provides the ability to learn and deliver any workload type by leveraging the power of the Citrix Provisioning Services® (PVS). Recently I worked with engineers from Citrix and Dell, collaborating to build a FlexCast reference architecture for deploying XenApp® and XenDesktop® on Hyper-V on a Dell infrastructure. Testing of this reference architecture looked at how XenApp and XenDesktop performed under various workloads, altering hypervisor configuration settings and examining the overall user experience and user densities. At the drop of dime, FlexCast and PVS enabled a simple switch of the architecture to a new workload.
Based on that reference architecture effort, we recently began a Single Server Scalability (SSS) test using the latest hardware and software releases available. This blog focuses on that effort — what I call the “XenApp dance step for FlexCast style” and how XenApp workloads perform on Hyper-V. (A follow-on blog article will focus on an alternate “dance” sequence for XenDesktop.) The focus of this blog is how the configuration of the McAfee virus scanning software can impact performance and scaling.
In previous blogs, I describe the testing process and methodology that leverages the Login VSI test harness, along with key tips for success. Since those same methods and recommendations apply here, let’s review the configurations we used for this scalability testing as well as the workloads and actual test results.
For background reading, I highly recommend that you review Frank Anderson’s post on XenApp physical versus virtual testing results with Hyper-V. Frank is my colleague and a great resource for insights about testing, including implementation tips and general best practices. In addition, the related Dell and Citrix white paper describing the FlexCast reference architecture for deploying XenApp and XenDesktop on Hyper-V is available here.
Continue reading here!
//Richard
Reference Architecture and Deployment Guide – Citrix XenDesktop 5.5 Built on Cisco UCS B-Series Blade Servers
For you that are thinking of looking at Cisco UCS and XenDesktop; have a look at this reference architecture document from Cisco…
“Citrix XenDesktop 5.5 Built on Cisco UCS B-Series Blade Servers, Cisco Nexus 5000 Series Switches, and VMware ESXi 5.0: Reference Architecture and Deployment Guide”
Download here!
//Richard
The IT Melting Pot! 