• Host Risk: At the base level, we have a hypervisor host (XenServer, Hyper-V or vSphere). Depending on the hardware and user workload, I’ll be running somewhere between 50-100 virtual Windows 7 desktops on each host. If the host has a catastrophic failure, those desktops go offline. Users will try to reconnect and they will be sent to other hosts. This is why we recommend N+1 at a minimum. If you lose one host, you should have at least one extra one to take over. If you lose a host, you can expect most of those users to try to reconnect immediately. Trying to support 50-100 connections is easy.
• Pool/Cluster Risk: One level higher than the host is a group of hosts in a pool or cluster. You will probably have around 800 desktops in a pool/cluster if we assume you have 10 hosts in a cluster. What happens if we lose the cluster? Depending on the type of failure, you will have one of the following:
  • Connection Failure: If you have a failure where the pool/cluster controller fails, you won’t be able to launch new desktops, but currently active users will be unaware of any issues.
  • Pool/Cluster Failure: If you lose an entire pool/cluster, you have to find a place for those 800 desktop users. Again, if you have N+1 fault tolerance, you probably have spare capacity within your entire environment. You also need to make sure your infrastructure can support 800 users trying to connect simultaneously. This still isn’t that big of a connection storm.
• XenDesktop Site Risk: One level higher that the pool/cluster is a XenDesktop Site. A site could contain 20,000 desktops or more. But what happens if we lose an entire site for some unknown reason? This is rare, but anything can happen. Remember, once users are connected, they can work unless their host fails. But if the site experiences a catastrophic issue during the logon storm we should have an N+1 fault tolerant solution, which means we have to find a place within our environment to support 20,000 extra desktops that will only be used for fault tolerance.

Hopefully, this all makes sense so far. But 20,000 desktops is a huge number. The amount of hardware required to support an N+1 solution for 20,000 desktops is a lot. What if we create four XenDesktop sites with only 5,000 desktops? I’m still supporting 20,000 desktops, but because they are in different XenDesktop sites, the overall risk is greatly reduced. If something happens to one site, it shouldn’t impact the other three sites. Those 5,000 users in the failed site can be balanced across the other sites or into a 5^th site that is only used in the event of a major failure (active/passive deployment).

A comment I always hear with this approach is now I have to manage 4 or 5 XenDesktop sites. You do have to manage more sites, but you really aren’t managing additional components. With proper processes and scripts, many of these management tasks can be simplified.

Just because XenDesktop 5.x can support tens of thousands of desktops, you need to determine if that is indeed the best approach for your business.

Daniel – Lead Architect
XenDesktop Design Handbook

Let’s say you need 100 servers (192GB RAM) to host virtual desktops for 7500 users. Those 100 servers will reach maximum capacity (CPU and Memory) when they host 75 virtual desktops VMs (2.5GB RAM). For fault tolerance, you go with the N+10% formula where you will have 10% more servers than you need. That means you really have 110 servers.

As I spread the load across 110 servers, my server concurrency drops from 75 users per server to 68. That also lowers my RAM usage from 187GB to 170GB. I paid for the RAM, so I want to use the RAM.

In this example, being conservative, I will configure the upper memory threshold for the desktops to 2.8GB RAM each and the lower to be 2.5GB (which is what I determined these users must have).

Based on the example, during normal production mode, my desktops are not overcommitting RAM. However, during an outage (planned or unplanned), my servers will be required to host additional desktop VMs. As no RAM is free, the desktop VMs are overcommitting, although spread across the entire server and the entire environment, the impact is small and likely to go unnoticed. Additionally, the overcommitting only occurs during an outage. So day-to-day operations continue to run smoothly and provide a good user experience (at least from a RAM perspective).

What have you used on your deployments?

Daniel

XD Design Handbook

Unfortunately, trying to explain my point in 140 characters wouldn’t do it justice but a blog is a start.

The key point is that we need to focus on the users. When you look at how users work with these systems, you understand what they need in order to work effectively. We look at the applications as a way to get to the data. We decide if the user needs access to the application, and it is either granted or denied. If we ignored the desktop interface, things would be much easier. I already have a desktop interface, so why do I need another. My local desktop interface has my own applications, so simply let me subscribe to virtual applications. This would alleviate the user-installed application challenge. If you only focus on the applications, you are missing an important aspect because this model doesn’t work for everyone. Let me give you some examples for and against having the desktop interface delivered:

• iPad: I don’t want to use the Windows desktop interface on my iPad as it doesn’t feel natural (Windows 8 might change this, but will wait before deciding). On the iPad, I just want to get to one or two of my applications. So in this case, I want to ignore the desktop interface.
• Work-shifting: I work remotely on my company-owned laptop (Windows 7). If IT only gave me applications, things would feel unnatural. They could populate my start menu with my apps, but it wouldn’t feel right. I would need 2 Windows Explorers (one on my personal desktop and one for my virtualized environment). I would need two browsers (one for my personal and one for my virtual). Which one do I use? I’m not on the internal network, so I need to make sure I use the right one. Not user friendly and very unnatural. In this case, the Windows desktop is a requirement as it makes the user experience better.
• BYO: A user brings their device and uses it at work. From a technical perspective, delivering virtualized applications would work fine. Unfortunately, we aren’t looking at the user perspective. A user will not want corporate applications on there. They don’t want those applications to consume hard drive space, nor do they want it polluting their start menu. Virtualizing the applications could overcome these issues, but the user’s perception is that the applications are local. Even training the users about application virtualization would not be enough as many users believe big brother is still watching. Plus, there will be confusion of having the corporate web browser and your local web browser (I hope you are using the right one, or you might get into trouble). Users in a BYO program want to use their own device, but still be given a “Corporate” environment to work on.
• Local Corporate Device: You have a physical desktop (running Windows 7) located on the corporate WAN, so why do I want to deliver another desktop interface on the one I already have? You probably don’t, so simply deliver applications.

We love to talk about being able to do all of these cool things with virtualization and what the future will hold, but people tend to ignore the typical user and their perspective. This perspective and the comfort of using the system are what makes things succeed or fail. If the solution doesn’t feel natural, it won’t work. And I say that only focusing on applications and ignoring the desktop interface, you are ignoring the user and only thinking about some pie in the sky utopia.

If we treat the desktop interface (XP, Windows 7, RDS) as an application, you must assess the need for the interface using the same criteria you use for applications (end point device, user usage requirements, location, etc). If you treat the desktop as a desktop, you will surely go down the road believing the desktop interface is irrelevant only to find that users are unhappy with the application virtualization solution, thus killing user acceptance.

Not everyone requires a corporate-delivered desktop interface, but many do and we cannot ignore this need.

Daniel – Lead Architect
XenDesktop Design Handbook

1. Scalability: Most agree that a shared desktop environment achieves better scalability than personal desktop environments.
2. Storage: Due to the shared operating system, the impact on storage is mostly a non-issue
3. Security: Although a desktop can be secured, I typically find that people do a better job securing desktops in the shared model

Like I said, I usually start with the XenApp model, but as we all know, one size does not fit all. There are occasions where the personal desktop model is required. Every time I say this, I get many questions asking what for the user requirements that XenApp cannot provide. Here is a start:

1. Reboot control: Can you imagine if you let users reboot a XenApp server. Talk about a great way to tick off your coworkers
2. Admin rights: I hate to say it, but some users require admin rights. Doing this on a shared desktop will cause many issues.
3. Specialized hardware: Some users need powerful graphics cards or sound cards. It is often easier to do this in a personal (VDI) model
4. Backgrounds: Many users want a picture of Homer Simpson on their desktop background. Silly, that can be done with shared or personal. This is NOT a valid requirement to go to a personal desktop.

Of course, I’ll save the most common one for last…

1. User Applications: Certain users need to install their own applications. Doing this on a shared model is scary, but on a personal model, makes a lot of sense.

What other areas do you see are viable user requirements that would dictate the need for a Personal (VDI) desktop instead of using the Shared (RDS) model?

Daniel – Lead Architect
XenDesktop Design Handbook

Honestly, when looking at the easiest use cases, it is a pretty safe bet to go with a shared desktop model (RDS/XenApp). Although many don’t talk about the shared desktop model much because everyone is so focused on VDI, it is an approach that is tried and tested. In fact, I remember working with an organization in 1998 that was doing desktops on the predecessor of RDS/XenApp, which was called Windows NT 4.0 Terminal Services Edition with MetaFrame 1.0. And guess what… It worked

Of course you can find loads of information talking about how the shared desktop model is more scalable than the personal desktop (VDI) model, but one aspect that is always missing is Comfort.

Oh my, one of these “marketing” words right? Yes, but here is what I mean.

If I do a personal desktop (VDI), I will get a Windows 7 desktop with applications and it will work. If I do a shared desktop (RDS/XenApp published desktop), I will get a “Windows 7″ desktop with applications and it will work. However, I also get something else. I can also access the applications seamlessly, where the desktop interface is hidden from the users view (some people call this a published application or seamless apps)

Many of you old-time XenApp users are thinking, big deal. We’ve done this for ages. Correct, we have, but now we have people trying to access the desktops/applications from tablets and phones. On my iPad or Android phone, I first had access to my Personal desktop (VDI). It worked, but it wasn’t comfortable and I’ve heard people say it was unnatural. I tend to agree. It was too hard to launch apps. If I’m trying to launch an app from the iPad, why do I want to first go to the Windows 7 desktop? Ummm, I don’t. I just want to launch an application. If I start with the shared desktop (RDS/XenApp), I get to choose between a full desktop and a single application, whereas the personal desktop (vdi) requires me to use the full desktop.

When starting desktop transformation, start with the shared desktop (RDS/XenApp). Work through the user groups that can work in a shared desktop environment. Once those groups are complete, we move onto the exceptions, which are probably fewer than you think. Stay tuned for more

Daniel – Lead Architect
XenDesktop Design Handbook

You have to learn to crawl before you can walk. You have to learn how to walk, before you can run. For those of you who are hosting applications via XenApp, you are already crawling. And learning to walk is pretty easy and takes little time.

Think about it, you have a hosted infrastructure built. You are using HDX. You already are managing your line of business applications. You have already started transforming your desktop; we just need to go a little further.

And those extra steps are what we will discuss during the next Ask the Architect TechTalk on November 9^th at 2PM Eastern Time.

Don’t forget to register and get it on your calendar. I’m looking forward to seeing you there.

Daniel – Lead Architect

As you might have seen, Citrix Consulting is presenting a 5-part series on desktop transformation. We are splitting the series up into the following concepts:

1. Desktop Transformation overview and user segmentation
2. Architecture design
3. Storage
4. User experience

The observant people reading will notice I only have 4 topics but it is a 5-part series. Unfortunately, most of the time at conferences you sit there listening with little time left to ask how things relate to you. Well in Barcelona, things are different. Part 5 (SYN310) is called “Ask the Architects”. We will have consulting storage experts, architecture experts, HDX experts and business experts on stage ready to answer your questions. Not only that, we will also be able to speak in English (UK), English (US), German, Spanish, Italian, and maybe a few others.

I hear some people already saying “But I can’t go to Synergy Barcelona because I went to Synergy San Francisco instead”. Well, you are not out of luck either. Feel free to post a question in the blog. If it ranks high enough, we will try to answer it in Barcelona and potentially future blogs. Hopefully, you are registered or are planning to register and I will see you there.

Daniel
Twitter: @djfeller
Blogs: VirtualFeller.com

The project I’ve been involved with is focused on delivering desktops for 200 concurrent users. We had three options: XenDesktop pooled desktops, XenApp hosted shared desktops, or Kaviza pooled desktops. Here is how we made our decision to go with Kaviza.

Skillset

The first thing we quickly realized was that the IT staff has no experience with a XenApp infrastructure. XenApp isn’t rocket science, but it does require a different way of looking at the desktop and managing the desktop because your users share the same running instance of the OS. For those of you who work with XenApp, you know what I’m talking about. Because of the required skillset to implement XenApp, this was the first option we removed from consideration.

Resource Requirements

The organization isn’t sitting on piles of cash, so we wanted to pick either XenDesktop or Kaviza that would require the fewest number of servers. First, we assumed:

1. Expectations are that each user will required roughly 1.5GB of RAM
2. Each user will be granted 2 vCPUs, although utilization will remain minimal

But guess what? The hardware requirements didn’t change

For XenDesktop, we have 4 VMs dedicated for management activities. For Kaviza, we have 5 (one for each server). Remember, we have 5 servers because we need one extra server in the event of a server failure. Based on our estimates, XenDesktop and Kaviza will require the same hardware footprint for 200 users.

Infrastructure Requirements

The final aspect we focused on was the infrastructure requirements. This might sound similar to the previous, but it is slightly different. By infrastructure, we mean the systems required to support XenDesktop or Kaviza. For XenDesktop, we have to build a SQL database, XenDesktop controllers, license server and Web Interface servers. Many of these items are automated to make installing and configuring easier, but with Kaviza, this functionality is contained within the Kaviza Manager. That means fewer technologies to support. And for this particular organization, that was the key criteria for going with Kaviza.

Three different areas and I get the same result: Antivirus has a noticeable disk impact.

So what we have is a situation where we will double storage requirements for something that everyone believes is a requirement, but we take drastic steps to limit how much/how often it runs to try and reduce storage requirements. Does anyone see the problem here? People think they need it but take steps to limit it. Many believe that what was once good for the desktop is still good for the virtual desktop. Fortunately, things have changed and we have to question our old beliefs. Unfortunately, changing old beliefs, especially anything to do with security of IT systems in an enterprise, is a very big uphill battle. How many of you want to go into a financial company and say remove your antivirus software from you desktops. They would laugh at you while security threw you out the front door.

However, with the traditional desktop, the costs of using antivirus were minor. We just did it because it provided a sense of security. We never cared about storage optimization and performance on a traditional endpoint (at least I never did). With virtualization, things changed. We do care about storage performance. I know more about IOPS now than I really care to know. ProjectVRC Phase III tests show how to reduce and optimize IOPS. So why is no one asking the question if one of the biggest IOPS consumers is really a requirement? No one dares to ask the question because it is almost a forbidden topic.

Now let me make this clear… I do not have a virus scanner on my laptop, I do not have a virus scanner on my home desktop, I have never had a virus scanner on any of these devices, and somehow, I have never had a virus. Now the smart ones reading this are asking “But if you don’t have a virus scanner, how do you know you don’t have a virus?” Because every so often (maybe yearly or every ½ a year), I run a free scanner that doesn’t require an install just to see if everything is still clean (it always is)

How can I go so long without getting a virus? Is it because I don’t go online? Is it because I’m completely disconnected from the network? No. I work like anyone else. Being virus free used to be pretty hard to do, but it has gotten so much easier over the past few years. There are systems in place protecting me from doing very stupid things. As I see it, there are only a few places where I will get a virus, but systems protect me.

1. Email:
   1. The Citrix IT team is running virus protection on the Exchange email servers. I can feel pretty confident that I am safe with corporate email.
   2. Google, Yahoo and Microsoft have virus protection running on their email systems. When I receive attachments and try to open, each one scans the file first (although they are probably just reading my email and realize I lead a pretty boring life). This scan helps protect my personal email.
2. Internet: I usually stay on pretty well-known and safe sites (especially on my work computer), but sometimes I accidently hit a pop-up and next thing you know, I’m somewhere I don’t want to be. Luckily, the browsers are much smarter than they used to be
   1. Some will tell me if the site I’m going to isn’t safe
   2. Some will ask before downloading anything
   3. Some will scan downloaded files for viruses
   4. Even Windows 7 doesn’t install anything unless I tell it that it is ok
   5. Most run with user privileges and not administrative privileges
3. Sharing USB drives: I don’t. If someone wants a file from me, I usually just ask for email address. This doesn’t happen very often though as I have nothing of value on my laptop J And if you are running a virtual desktop, you can simply disable this functionality.
4. Network: If someone else gets a virus, there is a chance that the virus will worm itself across the network and infect other desktops. With my firewall enabled, this provides some level of protection.

Do these protect me completely? No, and I’m not so naive to believe that they do, but antivirus solutions don’t completely protect me either. My point is that these other solutions provide enough protection for the level of risk I can tolerate. Does this mean you should dump your antivirus from all of your virtual desktops? No. But I do encourage you to look to see if you need it on every desktop. Maybe you would be better off

1. Splitting your XenDesktop sites into security levels where only the most secure desktops have antivirus because they are dealing with your company’s secret recipe.
2. Setting up your environment in such a way that you have blocks of desktops where the one block cannot infect other blocks. That way, in case a virus does get through, the area to attack is much smaller and easier to contain.
3. Hosting mission critical applications as XenApp resources with antivirus enabled to a non-antivirus enabled virtual desktop. That way you still keep that warm fuzzy feeling of having an antivirus solution but it doesn’t have nearly as large of a resource hit as putting it on every desktop.

Whatever you do, think about the decision, the ramifications and your tolerance for risk. Citrix says one size doesn’t fit all for virtual desktops, and I say the same statement can be made for Antivirus.

With Machine Creation Services, we have a master virtual machine somewhere within our environment. This master is what is used to create all of our MCS-provisioned desktops. On a weekly or monthly basis, many organizations will want to update the master image to include the latest updates. Easy enough, you just go to the master VM, and update it like any other VM. Once the master image is updated, you go into Desktop Studio and run the Update option. Here is where things start to be unique.

With pooled-random and pooled-static desktops, a new complete clone is created from the master image (just like when we create new VMs in Part 1). During reboot of the pooled-random and pooled-static desktops, a switch is made to tell the VMs to start reading from the latest cloned image. As the difference disks are deleted during reboot, there is no issue with the swapping of the master image. However, dedicated desktops are different.

With dedicated desktops, the difference disk does not get deleted on each reboot. This gives the users greater ability to customize their desktop. When we update the master VM image, the dedicated desktops are NOT told to use the latest cloned version of the master. Instead, they continue to use the cloned image from which they were created from. Only newly created dedicated desktops will use the latest image.

This is a very important point. If you use pooled-static or pooled-random desktops, updating the master image will update all virtual desktops based on that master image. If you use dedicated desktops, once they are created, their link to the master VM is severed. If you want to update the desktops, without losing all user changes, you must use your enterprise desktop management tools.

This process is important to note as I’ve had many people ask me why they have a lot of space being used by the master images. Let’s think about this from a storage perspective. Let’s say we are in the middle of a rollout with dedicated desktops. During the rollout, I’ve had to keep updating the master VM. Each time I update and create new dedicated desktops, that image is fully cloned and placed on my storage. If the image is 30GB in size (10GB thin provisioned), that means each storage repository containing the dedicated desktops will utilize 150GB (50GB thin provisioned) of storage space for the 5 difference images. As you continue and add more desktops with more updates, you will continue to increase storage space needs.

With dedicated desktops, managing the updates should be done with desktop management tools to the actual VMs and not the master image. The master image is there to help you quickly build desktops. It is not there to help you maintain dedicated desktops. However, with Pooled-Random and Pooled-Static desktops, the master image is there to help you with desktop maintenance and management.

Daniel – Lead Architect
XenDesktop Design Handbook