Monthly Archives: February 2011

Scalability

XenDesktop 5 Scalability – XenDesktop Controller Capacity

5 Comments

Think about the architecture of XenDesktop 5. One of the core components responsible for an acceptable user experience during the initial authentication and launch of the virtual desktop are the controllers. If these controllers get overloaded, it will take users longer to launch their virtual desktops. What is acceptable is based on the users and their requirements. But for this example let’s say when we hit the icon for the virtual desktop we expect a response within 2 seconds. How many controllers do I need for 5,000, 10,000, 15,000 or even 20,000 users? It really boils down to the logon storm and the controller hardware. The more powerful your hardware is; the greater of a storm a single controller can tolerate.

But what is the bottleneck when you need to add a new Controller? CPU is the easy one. How heavily loaded are the CPUs. As the utilization increases, the time it takes to handle logon requests will slow down to a point where users notice. So what about the user experience? We want to make sure the system responds to user requests in a timely manner. How long are your users willing to wait for enumerations or launches? I typically see 2 to 2.5 seconds is a safe estimate. I suggest you track the following metrics:

Citrix XML Service

  • Enumerate Resources (Avg Transaction Time)
  • Launch Get Address (Avg Transaction Time)
  • Get Logon Ticket (Avg Transaction Time)

As this reaches your own threshold, it is time to think about adding a new controller, which will help offload the controller.

Adding a new controller to XenDesktop 5 is much easier than previous versions. In XenDesktop 5, each controller is identical (unlike XenDesktop 4 where we did all sorts of crazy things to get the most desktops per farm). So as your CPU increases and your response times slow, add a new controller into the site and the load is distributed evenly.

Estimates are always good, but as with all estimates, your own experiences will vary:

  • In one test, a single controller with 8 CPU cores was able to support 10,000 logons in the course of roughly 15 minutes (roughly 11 simulated users per second) averaging about 50-60% CPU utilization.
  • In another test, a single controller with 2 vCPUs was able to support 1,250 logons (roughly 40 users per minute) resulted in an average of 12% CPU utilization.

So what does this all mean? For XenDesktop controllers, the scalability is better than what we saw in XenDesktop 4. And because we are not constrained by a master controller like we were in XenDesktop 4, our XenDesktop 5 sites can be even larger than before.

But this isn’t the end of planning your capacity with XenDesktop 5. There is still much to discuss so stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

Advertisements
Uncategorized

PVS or MCS – Operations Is Important

6 Comments

As we continue to decide between using Provisioning Services or Machine Creation Services in an environment, we need to go beyond the Big Picture factor explained in a previous blog. The second thing we should look at is the operational aspect of the solution. Operational models are rather boring. Who cares about supporting the environment? Well, the users will care and so will you.

First, both models require you to have an operational model in place so you can maintain the base desktop images. We all know Windows 7 Service Pack 1 is coming. How will you update your virtual desktops? This is what the operational model should define.

With Machine Creation Services, the update model is fairly easy. You start your master VM. You install the updates. You shut down. And you use Desktop Studio to push the updates out to all of your pooled desktops.

Provisioning Services is a little different. With PVS you will want to make a copy of the vDisk image. You need to put it into Private Image mode. You need to boot and install the updates. Turn it back into standard image mode, and then run the update command within the console. It doesn’t sound too daunting and it really isn’t. The challenge comes into play when you have updates that impact the connectivity to the Provisioning Services server.

Think about what happens for a moment. You need to update your image. The update impacts the network connection, disabling it for a moment before enabling it again. This is really no big deal unless you NEED the network to continue processing desktop operations. With a PVS streamed desktop, if the network fails, the desktop pauses until the network is restored. If the update disables the network, the desktop pauses. The update will NEVER continue because the desktop is paused.

These types of updates can be done with Provisioning Services, but it requires the team to follow proper processes to prevent issues. Just another consideration to take into account when deciding between PVS and MCS. Stay tuned for more.

Daniel – Lead Architect
XenDesktop Design Handbook

Uncategorized

Provisioning Services or Machine Creation Services… Big Picture Matters

12 Comments

Note: this is the first part in a multi-part discussion on PVS and MCS

Since XenDesktop 5 came out, one of the biggest questions flying around is, “Should I use Provisioning Services (PVS) or Machine Creation Services (MCS)?” Both options work and both options provide single image management, but what is the right answer?  Is it shocking that this question is the wrong question to ask?

What you should be asking is “What is my desktop virtualization solution going to look like?” Are we only doing Hosted VDI desktops? Do we need Local VMs? Are Hosted Shared Desktops in the mix? (Note: look at the Citrix FlexCast site for a description of each option). Each organization’s desktop transformation roadmap plays an important role in picking the right option. The following diagram was taken from the XenDesktop 5 Reference Architecture, which can be found in the XenDesktop Design Handbook.

One thing you should be able to see is that if you select Machine Creation Services, you can only do the Hosted VDI desktop model on a hypervisor (XenServer, Hyper-V or vSphere) in the data center ONLY. That means no Blade PCs. It means no Hosted Shared Desktops. It means no streamed VHDs. If this is your roadmap, then Machine Creation Services is still a viable option, but the decision cannot be made yet. You still need to look at a few other considerations like SAN requirements, storm impacts, imaging team expertise, etc. before you can make a proper decision, which will be discussed in future blogs.

But what if your design calls for some of these other FlexCast options? Then Provisioning Services will definitely play a major role. However, there still might be a need for a mixed imaging solution based on a few other decision factors. For example, what if you need a desktop where users have complete control of the desktop to install applications or make operating system-level changes that are not captured in profile management tools? I can still do Existing, Physical, Dedicated and Streamed desktops. However, would you use PVS for this (streamed desktops)? It does work, but you probably won’t go with this option. In my experience, using a private desktop model with Provisioning Services is not efficient. It requires complete copies of the base image, configured for private (read/write) mode. You still have to manage these images in a 1:1 fashion (or use an enterprise desktop management tool). You are essentially adding too many layers where other options might be a better fit.

Why not use an Existing, Physical or Dedicated desktop, which relies on either installed images or MCS? If I go with installed images, I need to either install them one-by-one or use cloning solutions like SysPrep. If I use MCS, unique identities are built into the solution. MCS makes the deployment easier than the Existing or Physical desktop model, but they both work. What does this all mean? If you use multiple FlexCast options with private desktops, you will end up using [PVS + (MCS or Installed)]

You don’t want to focus on which technology to use, you want to focus on the overall architecture, which will help guide your decision. But the decision is based on more than the big picture. You need to stay tuned for more on this topic as this isn’t the end yet. We still need to dive deeper into the Hosted VDI Desktop model only scenario to align our business requirements with the appropriate solution.

Daniel – Lead Architect
XenDesktop Design Handbook

Power Management

Changing Power Management

Leave a comment

Previously, we went over how power management works with XenDesktop 5. Why? Was it because I have nothing else to talk about? No. I went over this because many people are wondering why they would need to change the settings. If you have no idea what I’m talking about with regards to power management, check out the previous blogs:

The question now comes down to why you would ever change the power management functionality. The function and the buffer levels are perfect for every situation right?

Wrong. In fact, I’ve already seen a few designs where these settings needed to be modified to fit in with the business climate. Here are a few examples:

  • A desktop group has exactly 750 users. To prevent a boot storm from impacting the environment, the available desktop count is set at 750 desktops 1 hour before the start of the workday. Because no more users are supposed to use the desktop group, this organization didn’t want to have a buffer. Power management was disabled for this group. Another recommendation would be to drop the buffer to 1% (7 desktops) so if a user’s virtual desktop crashed, they could immediately go to another pooled desktop.
  • A desktop group had 25 users. With the default buffer setting at 10%, only 2 desktops were added. The organization wanted a higher buffer to help reduce load during a change in shifts as well as unforeseen issues. The buffer setting was increased to 25% for this desktop group (6 desktops).

These are just two examples from two different scenarios. In some situations 10% equates to too many desktops, and in other scenarios 10% is too few. Adjusting these levels based on your desktop group and user behaviors helps provide an environment that can meet the user demands.

Daniel – Lead Architect
Get the XenDesktop Design Handbook

Power Management, Uncategorized

Power Management for Dedicated and Pooled-Static Desktops

1 Comment

After my last blog on power management, I got a few questions from people who said their desktops were doing something completely different. Hopefully, we all have an understanding as to how XenDesktop 5 deals with power management. If not, I suggest you read the blog called “What is XenDesktop 5 Power Management Doing“. Basically, the question said something like the buffer settings weren’t working and neither was the peak load setting. As it turned out, these were assigned desktops and not pooled. Things work a little differently if you are working with assigned desktops. An assigned desktop belongs to a single user, whereas pooled is a free for all. Of course there are pooled-static desktops and dedicated desktops; both of which are considered assigned for this example.

With pooled desktops we try to anticipate loads and have an appropriate number of desktops idle before users request them. Because any user can use any pooled desktop, this approach works pretty well. But things are a little different if we are talking about assigned. We want to have the assigned desktops ready so the user doesn’t have to wait for the desktop to start, and we all know how users hate to wait.

In XenDesktop 5, power management for assigned desktops is slightly different. Because assigned is a 1:1 approach, we essentially want all desktops to be ready when we hit our morning rush (peak). This is what power management does. When you define the peak time, you are telling power management to start all assigned desktops at this time. When we hit offpeak time, those same desktops will be turned off if they are idle with no logged on users.

To see if this is enabled for the desktop group, loor the paramek foter AutomaticPowerOnForAssigned when you run the following PowerShell command and

Get-BrokerDesktopGroup 'groupname'

What if you don’t want to have power management do this? Then disable it via PowerShell

Set-BrokerDesktopGroup 'groupname' –AutomaticPowerOnForAssigned $false

Hopefully, that helps explain some of the oddities with power management.

Daniel – Lead Architect
XenDesktop Design Handbook

Power Management, Uncategorized

What Is XenDesktop 5 Power Management Doing?

5 Comments

Have you started using XenDesktop 5 yet?

Here’s something to look out for, as I know many people have been wondering. Remember in XenDesktop 4, we could specify our available desktop count (idle pool)?  First, we have a desktop group of 1,000 desktops. We might specify 800 desktops idle at 8:00AM, then at 11:00AM we drop down to 200 idle desktops, and so on. XenDesktop 5 does the same thing, but a little bit more. XenDesktop 5 will start 800 desktops at 8:00AM, just like XenDesktop 4, but that is where the similarities end. Here is what happens next:

  XenDesktop 4 XenDesktop 5
1 user logs on One new desktop starts to bring available desktop count back up to 800 Available desktop count stands at 799
49 more users log on 49 new desktops start to keep the available desktop count at 800 Available desktop count stands at 750
650 more users log on 650 new desktops try to start to keep the available desktop count at 800, but only 150 more are defined. Available desktop count drops to 400. Errors appear in event log. Available desktop count stands at 100
1 more user logs on 1 new desktop tries to start to keep the available desktop count at 800. No more desktops defined.Available desktop count drops to 299. Errors appear in event log One new desktop starts to keep available desktop count at 100
100 more users log on 100 new desktops try to start to keep the available desktop count at 800. No more desktops defined.Available desktop count drops to 199. Errors appear in event log 100 new desktops start to keep available desktop count at 100

What just happened? Why doesn’t XenDesktop 5 keep 800 desktops idle? Because XenDesktop 5 is smarter than XenDesktop 4. Think about it. If I have about 800 users arriving at 9:00AM, I want to have these desktops ready to go before they arrive, so I set the available desktop setting at 800 starting at 8:00AM. Why do I need to keep 800 desktops idle when users start logging in? I only have 1000 total users. This seems rather pointless to me. It’s a waste of resources. Even if you don’t have additional desktops defined, you won’t have resource waste, but you will end up with a polluted event log on the controller. That is why XenDesktop 5 is smarter. XenDesktop 5 includes a pool buffer setting applied to each desktop group. XenDesktop 5 won’t start new desktops until the buffer threshold is breached. By default, this buffer is 10% of the size of the desktop group, but it is configurable via PowerShell.

If you do a “Get-BrokerDesktopGroup” in PowerShell, you will see OffPeakBufferSizePercent and PeakBufferSizePercent. Two buffers for two timeframes (Peak and Off-Peak).

How do you change it? With the “Set-BrokerDesktopGroup” setting.

Hopefully, this explains one of the production-level differences I’ve seen between XenDesktop 4 and 5.

Daniel – Lead Architect
XenDesktop Design Handbook