Desktop Virtualization… The Right Way (Storms)


One of the questions you must ask yourself when designing a desktop virtualization solution is understanding the user patterns.  This has a direct impact on XenDesktop farm design and scalability with respects to boot up storms and logon storms. Let’s take two different examples so you can get a better idea for what I’m talking about:

Scenario 1: 9-5:
In this scenario, all users logon in the morning and logoff in the evening.  There might be some sporadic users working after hours, but for the most part users stay within these working hours.  This is a fairly easy scenario, which is why I’ve started with it.

To design your environment, you need to make sure that the boot up storm doesn’t overwhelm your environment.  You will be starting a large number of hosted virtual desktops and that has a direct impact on your hypervisor of choice, your storage solution and your network infrastructure.  You can easily overcome any challenges with a boot up storm in this scenario by using the XenDesktop idle desktops configuration to pre-boot desktops X minutes before the main rush begins (X is based on how many desktops you need up and running before users start connecting).  By the time users come online, the system should have calmed down from the boot up storm.

Each hypervisor limits the number of simultaneous bootups (XenServer being 3).  Although this helps limit the number of virtual desktops powering on at once, that process only requires a short amount of time as it does not include the actual OS loading.  If you have 1,000 desktops (across 10-20 hypervisors) that must be ready by 9AM, and you assume each desktop takes 30 second to fully boot, you want to start your bootup sequence by at least 8:30.

The second aspect is the logon storm.  There is little we can do to the environment to spread the storm over a greater amount of time as it is based solely on the user pattern.  The logon storm is going to have a direct impact on your farm design.  You need to look at the following:
1.    Number of user connections per minute
2.    The IOPS requirements per minute
3.    The logon times you require

As you add more users to the environment, you need to optimize your architecture and allocate additional resources in order to accommodate the storm.  This might require you to dedicate XenDesktop controllers as XML Brokers and Farm Masters.  By giving the controllers specific roles, you optimize those systems to be able to support greater numbers of simultaneously connecting users.

Scenario 2: 24/7 (3 shifts)
This scenario brings about a few more challenges in that users are always online.  The organization is running 100% of the time and as users are connecting, other users are logging off .  The cycle continues over and over again.  This architecture is really dependent on the environment in question. Even though the organization might be 24/7, those shifts might be located around the world in different locations connecting to different data centers (follow-the-sun model).  But if we have a unique scenario where we have 1 data center and all shifts connecting to that 1 site, this type of an environment would make us change our design as follows (safe to assume that all shifts are different sizes. In fact, many 24/7 models located in one site have one large shift and the remaining 2 shifts are significantly smaller):

In the 9-5 scenario, a boot storm wouldn’t impact other users as no users were online before the start of the workday.  In the 24/7 scenario, we have active users.   If we sized our environment based on max concurrency for a single shift, we have little extra capacity to pre-boot desktops.

  • First, we start all available workstations ahead of time to build up our idle pool (without disrupting working users).
  • Second, we disable the reboot after logoff option for the shift immediately before the largest shift starts. This will allow the desktops to be ready to go even faster.  This can be done by creating a workstation group per shift. This does bring the risk of the users not receiving a clean desktop, but this is mitigated by the desktops being rebooted (cleaned) after the other 2 shifts end.
  • Third, when the logon storm begins, we can also expect a logoff storm to begin as well because one shift begins as a different one ends.  Disabling the reboot for one shift change will help overcome the boot storm impact. To accommodate the logon/logoffs, we need to optimize our environment, just like we did in the 9-5 operational model, dedicating controllers for XML brokering and farm master.  This type of configuration allows us to support the largest possible number of users within one farm, although at a certain point we will require a new farm.

Two different user pattern scenarios to think about during a desktop virtualization design. A few things to keep in mind:

  • Does it require and understanding of the user environment? Yes
  • Will it impact scalability of the underlying infrastructure? Yes
  • Can the environment be designed in such a way to support these usage patterns? Yes

Advertisements

Desktop Virtualization… The Right Way (Applications)


Have you experienced this before? You need an application to help you with a project. You ask your manager if you can purchase the software and you get approval.  You go out and buy the software and install it onto your desktop and away you go to do your job.

This is a common situation, one I’ve done myself on many occasions. These applications make up the non-IT delivered application set of every organization, and it is a massive list.  This happens over and over again in every organization and in every department. So when you hear organizations say they have 10,000 or 20,000 applications, they are likely not exaggerating.  Out of that massive list, only 500-1,000 of those applications are IT-managed.

This brings about the main challenge with desktop virtualization, how do you deal with the non-IT delivered applications? With Citrix XenDesktop, if you use the recommended strategy of a single image for many users you lose the ability to install the application into the virtual desktop and have it persist across reboots.   This is a major issue that must be dealt with or users will not accept the virtual desktop.

First, you need an application assessment. You have a few options.

  • Entire site assessment: By using a tool or doing a manual assessment you can get a list of applications deployed throughout the organization.  This will give you the data points, but the amount of data might be overwhelming. Imagine looking at a list of 20,000 applications. How do you even start determining your optimal solution.  This is information overload
  • Department-by-Department assessment: By focusing at the departmental level, you get a better grasp of the applications without being overwhelmed from the start.  .  If you focus at a departmental or group level, your application list should be more manageable.
  • Survey: Leave it up to the departments to create a list of what their users NEED to effectively do their job and not what they HAVE.  Many of the applications are outdated and unused.  By identifying what is needed, the number of applications can be better managed.

Regardless of the approach taken, the following is needed for each application:

  1. User
  2. Application
  3. Dependencies
  4. Mobility requirements

Second, it’s time for layoffs but this time we need to layoff applications.  If you ask your users what applications they have installed, they will miss most of them.  In fact, many of the applications installed on a typical desktop are not needed anymore.  By laying off applications, we can start to get control of our application set and give our IT organizations an opportunity to succeed.

Third, develop an application delivery strategy.  We can either install, host or stream.  Do you need all three? Potentially.  The point to remember is you need to be flexible. Certain strategies will work better in certain situations.   Think about it this way.

  • Certain applications will be used by 100% of your users.  These applications are best served by installing into the virtual desktop image. Why add another process (streaming/hosting) for an application that will be used by everyone, everyday?
  • Certain applications have such a massive memory footprint. Executing the application within a virtual desktop will result in massive amounts of RAM being consumed.  However, if that application were hosted on XenApp, those DLLs and EXEs could be shared between users, thus reducing the overall memory footprint required.
  • Certain applications are used by a small group of users (1-2% of users).  These applications might best be served via the hosting model on XenApp or via application streaming into the virtual desktop.
  • Certain applications go through constant updates (daily/weekly).  It would appear to be easier to use a single application image that can be distributed to any device when needed. Instead of maintaining hundreds/thousands of installations, the single package model would appear to be easier.

The point of all of this is if you going to be successful, you must have a strategy for delivering the applications into the virtual desktop.  The strategy is also dependent on how well your IT group can service the user requests for all of these applications.  If it is just not possible, your other alternative is to go down the Bring Your Own Computer (BYOC) route.

In the BYOC model, my physical desktop is maintained and managed by myself.  I’m not part of the domain nor do I call support when I have an issue, I do it myself.  This also means that the non-IT delivered applications are installed on my own personal desktop.  So far, this model has worked for me but I’m a savvy user and know how to fix a lot of issues I run into to. This approach might be more difficult for those not used to self-supporting.  But if a user installed their own applications, then technically they are already self-supporting their non-IT delivered applications.

Remember, the desktop is the easy part.  Spend your time looking at your application set and remember the following:

  1. Application Assessment
  2. Application Layoffs
  3. Application Delivery Strategy

What other application characteristics have you seen that would help determine your application delivery strategy?

My virtual desktop journey