XenDesktop 5 Reference Architecture


With the previous version of XenDesktop, we followed the modular approach to designing a scalable architecture. Now that XenDesktop 5, many are wondering if the same architecture still holds true. The answer is….

Most of it does.

We still recommend a 3-layer model consisting of the

  • Control Module
  • Desktop Module(s)
  • Imaging Module

When you put this all together, you end up with something like this conceptual architecture (Click on the figure and it will be easier to read):

It probably looks similar to the old modular architecture (except it is really, really small). So what changed?

  • Control Module: We aren’t recommending the creation of dedicated XenDesktop Controllers. Not needed. If you need a larger site, you add another controller. This is because all of the session information is now stored within the SQL Database
  • Imaging Module: Provisioning services is still a great enterprise option and will most likely still be used in numerous scenarios. But for certain deployments, Machine Creation Services might be enough. This will allow you to thin provision virtual machines while still having unique desktop identities without a sysprep-type routine.
  • Desktop Module: Within the hosted VDI model (you know that model where we have Windows XP and Windows 7 virtualized on a hypervisor in the data center), we have five options to choose from, each with their benefits and concerns. Will you select pooled, dedicated, streamed, installed, or existing?

To find out more, just access the XenDesktop 5 – Reference Architecture. It is located in the XenDesktop Design Handbook.

Advertisements

Designing for Diskless Virtual Desktops


I received a few interesting question related streaming desktop images via Provisioning Services. The question asks “What is the best option for storing the write cache when the target devices are disk-less?” One question asked about disk-less physical endpoints, while another question asked about virtual machines with no disks assigned.

This was a great question. In fact, we almost always talk about Provisioning Services from the standpoint of having a small, local disk assigned for the write cache and other log files, but you do not require this little disk. So what is the best option? As with all great questions, the answer is “It depends” J Let’s first look at our viable options

Option Benefits Concerns
Local cache on local storage Doesn’t require expensive SAN or shared storage

Doesn’t add network traffic to PVS server

Doesn’t impact PVS system cache

Supports PVS high-availability

Not possible in a diskless scenario

No live migration

Local disks might not support the IO load

Local cache on shared storage Doesn’t add network traffic to PVS server

Doesn’t impact PVS system cache

Live migration supported

Supports PVS high-availability

Requires a SAN or some type of shared storage

Not a good option for physical endpoints due to complexity in configuration

Local RAM Doesn’t require expensive SAN or shared storage

Doesn’t add network traffic to PVS server

Doesn’t impact PVS system cache

Works in diskless scenario

Easy to setup and configure

Supports PVS high-availability

RAM is not cheap

Need to estimate write cache size correctly or risk blue screen of target

No live migration

Server side on Provisioning services server Easy to setup and configure

Doesn’t require SAN or shared storage

Live migration supported

Adds network traffic for PVS server

Negatively impacts PVS scalability due to NIC utilization

No PVS high-availability

Impacts PVS system cache

Local disks might not support the IO load

Server side on shared storage Easy to setup and configure

Live migration supported

Supports PVS high-availability

Requires SAN, NAS or some type of shared storage

Potentially impacts PVS system cache

 

I probably missed some of the benefits and concerns with the options, but hopefully you get the idea. So which do you choose?

  • If you were in a smaller environment, I would end up using server side on Provisioning services. It is easy. It doesn’t cost much. And because the deployment is smaller, it shouldn’t have a major impact on the system cache settings on the Provisioning services server.
  • For larger implementations, you will most likely end up going with server side on shared storage. This will allow you to better optimize the PVS system cache and have a more enterprise-scalable architecture supporting thousands of desktops. Plus, the shared storage is going to be better able to support the IO load of the write cache for your massive numbers of desktops. However, server side on Provisioning services is still viable if you can support the IO load (maybe with SSDs).

Daniel – Lead Architect