Follow on Twitter
Post to Twitter
On August 11, 12, and 13 we delivered a Ask the Architect TechTalk series focused on desktop virtualization and VDI. The three part series focused on:
- Deciding between VDI and Terminal Services
- Designing a desktop virtualization solution with XenDesktop
- Migrating users from physical devices to virtual desktops
During the TechTalk webinar, we received many great questions but were unable to answer them in the time allotted. This blog post will attempt to provide those answers. But first, I wanted to let you know where you can get access to the recorded webinars and the PowerPoints.
Part I: Deciding between virtual desktops (VDI) and virtual applications (Terminal Services)
Part II: Designing a desktop virtualization solution with XenDesktop
Part III: Migrating users from physical devices to virtual desktops
And as always, you can follow me on Twitter @djfeller. And now to the Q/A session...
Part I: Deciding Between VDI and Terminal Services:
Q: What would be your recommended platform if streaming video or audio is needed to be delivered to a structured user environment?
A: For structured users, we typically recommend the shared, server-based desktop but you bring up an interesting design requirement. Typically when you hear people talk about some of the value-adds with XenDesktop, the focus is on the multimedia experience. Well, many of those multimedia optimizations are also present within XenApp. Now, if you have used XenApp in the past, multimedia was a little sketchy, but I encourage you to take a look again. There have been some impressive enhancements made, which you can see as part of the XenApp MythBusters series (http://community.citrix.com/display/xa/XenApp+Myth+Busters)\\
Q: We want to get away from running around the entire building updating all of our different applications constantly. So we don't want anything local. How do I do this?
A: For those users who require desktops, you would want to stream the entire desktop to the end point device or use a desktop appliance and connect to a hosted virtual desktop. This would eliminate the need to install items locally and allow you to manage everything centrally.
Q: How do we prevent users from updating their streamed desktops?
A: This is a challenge for any desktop operations environment. When users install applications onto their desktop (this could be new apps, windows updates, IE updates/plugins, etc), the support costs climb quickly because these apps have not been validated by the IT team. With XenDesktop, we have users receive their desktop from a single streamed image. If a users makes changes to the desktop, those changes will NOT remain with the desktop after a reboot. Rebooting the XenDesktop desktop results in a brand new, clean desktop environment.
Part II: Designing a Virtual Desktop Solution with XenDesktop
Q: I've been considering VDI for a while but our branch environment only has 512kb circuits. How could this possibly work in this environment?
A: The branch office situation will have an impact on the type of virtual desktop you can deliver. For example, I would not recommend using a streamed desktop for those devices unless you install a local Provisioning Services server within the branch. If that is not an option, you also have the ability to allow the branch users to utilize a hosted virtual desktop that runs within the data center. The branch office users would connect to the hosted virtual desktop over Citrix's transport protocol, which is extremely lightweight. The latest scalability numbers I saw were around 15kbps (average per user). This is only an average. If you are doing a lot of multimedia operations, then I would expect that number to increase, but if you are only doing textual operations that number would likely decrease.
Q: What is best faster processors or more memory
A: Depends on the component. # The XenServer that delivers the hosted virtual desktops needs both in equal amounts. If your virtual desktops are 2GB RAM, then on a 128GB XenServer you would only get about 50-60 virtual desktops (all because you will run out of RAM). You need to select your processors so that they are fully utilized at the same time RAM is fully utilized.
- XenDesktop Controller: CPU intensive during logons and hosted virtual desktop startup (RAM and Network underutilized)
- Provisioning Services: Network intensive. RAM is also used for file caching the vDisk images so more read requests are services by RAM instead of by disk. CPU is underutilized
Q: What's the best way to handle printing services for mobile and remote users.
A: As we are unsure what type of printers a remote/mobile user will have mapped on their local device, it is typically best to utilize the auto-creation of the user's printer and to use the universal print driver This allows the user to see their local printer within their hosted virtual desktop and to not be required to install the actual print driver.
Q: We package software with Wise Package Studio....what kind of support/compatibility will we get if we go to VDI
A: If you want to install the applications within the virtual desktops, the Wise packages are still viable options. However, if you are wanted to stream the applications into the desktop, then you need to create an application profile with the XenApp tools, as application streaming is different than application installing (which Wise does).
Q: Isn't it more efficient to allow the networking devices to compress the data stream rather than utilize CPU resources?
A: In general it is. Depending on your environment and design, there is defiantly an option to integrate a network compression solution to compress the traffic, thereby offloading these processes from the server's CPU. The Citrix Branch Repeater is able to do this for many different protocols, thereby helping to improve the overall user experience.
Q: What is the best way to handle print traffic, I am thinking of things like should this be included in base build, should you use a specialist application to throttle bandwidth usage etc.
A: XenDesktop actually contains a policy that allows you to throttle bandwidth for different types of communication, including printing. So for slower connections, you can tighten the screws on the printing traffic so this doesn't disrupt the user experience.
Part III: Migrating Users from Physical Desktops to Virtual Desktops
Q: What type of profiles do you recommend.
A: You will need some type of profile that is capable of storing the user personalization settings across many different devices. This means you will need a roaming profile solution as the basis of the environment. In XenDesktop (if using pooled desktops), a user will use a different virtual desktop everyday. Also, any changes made to the actual desktop are lost upon reboot. During logoff, we need to upload all user settings to a centralized location that all virtual desktops can access. When the user logs back into another virtual desktop, their settings are copied from the central site to the virtual desktop, thus personalizing it. Unfortunately, roaming profiles have their own issues/challenges that can be mitigated by using a profile management solution like the Citrix Profile Management.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Take a moment and do a Google or Bing search on VDI vs TS. How many hits do you get? I get quite a few. Some from Brian Madden, many from Vmware, and more from other VDI providers. It's an important topic, or at least that is what some people want you to believe. I've heard about these debates, I've attended conferences where there were sessions specifically dedicated to this topic and the room was packed. I've attended these discussions and sessions before but I've left most of them thinking, "That was entertaining, but I just don't get it".
I've been doing the TS thing for more than 10 years. Over the last few years I've also been spending a lot of time focused on VDI. Throughout all of this time, I've interacted with desktop groups as well as more users than I could count. And being a TS and VDI user myself (Yes, I use both), I feel comfortable giving you my thoughts on this debate.
The debate is flawed!!!
The debate doesn't make sense!!!
If you really understand the underlying premise of both solutions you will quickly see why. It's like asking someone if they want wine or lobster for dinner. They are two different things. One is a food, the other is a drink. When you put them together, you have a very nice meal.
So what is my take besides saying the debate is flawed? Well, for that I need a little more of your time (about 1 hour). I'll be spending 1 hour talking about this exact topic during Part 1 of the XenDesktop Ask the Architect TechTalk series on August 11. If you want the full story, I recommend you attend.
This is part 1 of a 3 part Ask the Architect TechTalk Series
- Part I: VDI or TS: Selecting the Best Solution
- Part II: Designing a VDI Solution with XenDesktop
- Part III: Migrating Users from Physical to Virtual Desktops
Note: This blog was brought to you from a hosted XenDesktop virtual desktop with a XenApp-streamed Firefox browser.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
I am very excited to announce the release of a Reference Architecture for an enterprise XenDesktop environment. Many times when you see reference architectures, the paper is very high-level and provides minimal details. Well, this document is completely different. It is based on a customer environment with 10,000 users spread across four data centers. It includes many of the challenges we architects must design around including, multiple data centers, worldwide design, thousands of users, remote users, etc.
The design focuses on the following topics:
• Virtualization Infrastructure
• OS Delivery
• Application Delivery
• Desktop Delivery
• Desktop Design
• Business Continuity
Within the subsections, you can read about the environment design, capacity planning, hardware design and storage design as well as a host of other items. As this is based on a customer environment, some details had to be removed and generalized.
As you read through the document, you might think "Why did they do it that way?" Where possible, we tried to follow best practices, but with any environment, the nuances required we deviate from the preferred path to alternate paths. You will probably have questions, comments and challenges with the way we designed the environment, which is why I'm going to start a blog series around the key design areas so all of you can comment and we can discuss. Should be an interesting series. Make sure you grab the design document (CTX121478), and Stay Tuned...
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
In Provisioning Services for XenApp Best Practice #5, I wrote about application streaming integration. I talked about two different options:
1. Stream on-the-fly: which results in the vDisk write cache growing as the application is streamed
2. Pre-cache: which stores the application cache within the vDisk, but helps to reduce the size of the vDisk
Both of these options had their issues. Option 1 would grow your write cache quickly, especially on XenApp servers hosting tons of applications. Option 2 creates a link between the vDisk and applications, which adds another step to application updates.
I received many suggestions and alternatives, some were quite interesting 
. The one that resonated the most was to store the application streaming cache on another disk that is not delivered via Provisioning services.
- Physical Servers: You would use the physical disks installed into the physical servers
- Virtual Servers: You would use a virtual disk assigned to the virtual machine (preferably shared storage so you can still do XenMotion).
This setup doesn't really change our architecture in that many implementations have a non-Provisioning Services disk associated with each server to store items like event logs, local databases, write cache and pagefile (as explained in BP 8?).
Honestly, I haven't had the opportunity to set up an environment like this in a large environment, so I didn't want to offer it as a best practice yet. But I've had many of you say that this is about the only way you deliver XenApp images with Provisioning Services and have had no issues with the environment from configuration or maintenance. I've always thought this provided the best solution as it overcomes many of the lingering challenges of option 1 and option2. So, how do you do this? It is actually pretty easy:
- Make sure you have an NTFS disk associated with the physical server (physical disk) or virtual server (virtual disk)
- With the Provisioning Services image in private-image mode, change the location of the Application streaming cache location
- Launch C:\Program Files\Citrix\Streaming Client\ClientCache.exe
- Change the client cache directory to the virtual or physical disk
- Shut down and place vDisk back into standard image mode
When you boot, and launch your applications, your application cache is now stored on the physical/virtual disk that is not erased during reboot. What does this get you?
- Faster application launch after server reboots because the application cache is not erased
- Easier application maintenance because the application cache is not included within the vDisk
But this configuration does come at a price. You have to have a persistent disk associated with each physical and virtual server. Although this cost is pretty small as most Provisioning Services/XenApp implementations already have a local disk to store local monitoring databases, event logs, etc.
My list is now empty, but will post new topics as they come in. Feel free to tweet me some ideas on Twitter.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drive
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
One of my biggest gripes about Terminal Services and XenApp was that once I disconnected from the network, I could no longer use my applications. This was a major pain as I spent a lot of time on airplanes. During my 3-4 hours flights as well as 1-3 hrs sitting in the terminal, I was unable to get any work done (although I did get a lot of reading done). My problems with XenApp wasn't just limited to airports and airplanes, but also included remote connectivity. As I'm a remote employee, I spend most of my time working from my home office. There were many cases where I just wanted to spend 1 minute to look something up in a local file. But because my applications are hosted from XenApp, that 1 minute actually took 3-5 minutes (authenticate to employee portal, launch XenApp application, open file and wait for the file to be transferred from local workstation to XenApp server).
I got frustrated and installed my applications locally. This was wonderful. All of the frustrations I've had were almost gone. But this now caused new challenges. I now had to manage and maintain my applications. I had to install appropriate hotfixes/service packs. I also had to troubleshoot application issues, not something I enjoy doing. (Why does it always seem like your applications fail when you need to use them the most?) Well, believe it or not, XenApp actually allows offline access to your applications. You get to use your XenApp applications while your network is not connected, while you have absolutely no connection to the XenApp infrastructure. This sounds like a good deal. I get local usage and I don't have to worry about maintenance.
How does it work? How do you implement it? What best practices should be followed? All of these questions are the basis for an upcoming TechTalk on offline mobility with XenApp. In this TechTalk session, you'll learn about:
• How XenApp users can take their applications with them, disconnected
• How offline XenApp users are kept current
• How to eliminate app conflicts without stress
• How to follow the best practices while delivering offline applications
• How application streaming can help simplify your Vista and Windows 7 migration
Hope to see you at this TechTalk on Friday, June 5th at 1PM Eastern time.
Daniel - Lead Architect - Worldwide Consulting Solutions
You can follow Daniel at http://twitter.com/djfeller
You can read Daniel's blogs at http://community.citrix.com/blogs/citrite/danielf
XenApp admins are a creative group of people. I used to be a XenApp admin and I remember having to do tons of things to an application to get it working correctly on XenApp (but back then it was called WinFrame and MetaFrame, not even MetaFrame XP). Back in the day, applications were not built to execute on a multi-user system like XenApp. In fact, many applications today, especially those home-grown applications, are problematic on XenApp. This is where the creative XenApp admins come in. They developed numerous tweaks, configurations, hacks and custom solutions in order to get an application functioning properly. Of course this made the environment much more complex to build and maintain.
But just getting applications functioning on XenApp is just part of the problem. I remember hearing people ask about running different high-graphics or video applications on XenApp and thought, ARE YOU NUTS? ICA was built to only send those screen changes down to your video display, but with video the entire screen is changing. Talk about chaos.
THAT WAS THEN. THIS IS NOW. Things have changed for the better. Application issues are more of a myth nowadays. With new XenApp features, many of the application challenges that plagued XenApp environments are being eradicated. But unfortunately, many of you have experienced application issues years ago and haven't looked at those applications since. So I'm asking that we spend an hour going through the XenApp features focused on application compatibility in an upcoming TechTalk session.
I plan to discuss the technologies that make application compatibility easier, which will also help simplify your XenApp architectures. We will go through many of the challenges you all have experienced and talk about how these are now easily overcome. So I encourage you to attend this TechTalk session called: Fact vs. Fiction - The Truth About Application Compatibility and XenApp.
Can't wait to see you there on Wednesday, May 27, 2009 at 1PM eastern time.
Daniel - Lead Architect - Worldwide Consulting Solutions
"Learn from the past, live in the moment, and plan for the future"
Follow me in the blogs: http://community.citrix.com/blogs/citrite/danielf
Follow me in Twitter: http://www.twitter.com/djfeller
The whole concept of a standard image used across multiple end points is a great idea. Think about it, 1 image for hundreds/thousands of servers. Talk about simplicity. I only have to make updates once and every server has the same update. Every server is identical. This makes scaling up the environment easy. Of course there are some challenges, as many of you have pointed out after my very first blog posting where we spoke about vDisk type. That challenge is that the "write cache" is destroyed upon server reboot.
For the most part, this is a good thing. Those changes gives each XenApp server a personality. I don't want my XenApp server to have personalities. Its kind of like running Microsoft Word one day and it is using United States English and then the next day it uses United Kingdom English. This little personality change doesn't seem to be a big deal, but it is. For example, I like my words to use the letter Z. I believe you spell color without the letter U. I believe neighborhood is spelled without the letter U too. Of course this is a simple change for a user, but we shouldn't make our users do this. But there are some changes on XenApp servers which are valuable (many of you have pointed them out to me) like event logs and performance metrics.
So how do I use a standard image but still allow these important items to remain persistent across server reboots? Some of you have raised good points on this, especially around the use of differential disks, but the problem with differential disks is that the differential cache will go away if the base vDisk is changed. So, differential disks do not really help us out that much. What we can do instead, which again some of you alluded to, is to use a local disk.
Now I bet some of you have alarms going off in your head and are thinking, "Hey, I thought the benefit of Provisioning Services is that I don't need local disk". Well, you are 100% correct, that is one of the benefits, but there are more like standardization and synchronization but will leave that for a marketing-type blog. But with standard images you do lose some items like persistent storage of event logs, metric databases, etc. But if we allocate a local disk to the server, we can redirect the storage of the persistent data. BTW, this works when XenApp is virtualized on XenServer and when XenApp is on bare-metal.
You do this by doing the following:
- Your virtual machine must have 2 virtual disks assigned. Remember if you want to do XenMotion, the second virtual disk must be on shared storage. How large you might ask? For XenApp, a 4GB partition is a good starting recommendation, but with most decisions, it depends.
- Build XenApp on the first disk and format the second disk NTFS so it shows up in your system (use basic disk and not dynamic).
- Change the storage paths of your persistent databases, event logs and anything else to the second virtual disk.
- Build your vDisk from the C drive, but not the second drive. When done, shut down the virtual machine.
- Detach the OS virtual disk from the virtual machine, but leave the second virtual disk attached.
- Clone the virtual machine including the virtual disk.
- Now stream the vDisk image to this new virtual machine. Your event log should be stored on the virtual disk instead of within the write cache.
So now we are using a base vDisk for our image and still allowing persistent data storage. And what's more, you can also use that persistent disk to be the write cache storage location as well. Just tell Provisioning Services to store the write cache on local storage, and the persistent disk will hold that information for the server's session.
My list is now empty, but will post new topics as they come in. Feel free to tweet me some ideas on Twitter.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers. Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit). How do we keep control over these images and make sure you don't break your entire environment with a new update?
Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly. High-level process overview is in the following figure:
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:
- When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library. The library is just that, a location where you keep the current and old revisions of vDisk images.
- When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.
- Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
- Tell the production Provisioning Services server to auto-update vDisks. This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot. How can you tell which target device will be updated? By the Class information. Each target device and vDisk file has a Class field. The class fields are the link for auto-updates. Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number). Provisioning Services then checks the Class of the vDisk. Any target device with the same Class will receive the new vDisk upon next reboot. This is a great way to simplify the management of your XenApp farms.
Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates? Have you ever installed a hotfix to find out it broke other things? I bet so. If you followed the process outlined above, you have a build in rollback feature by doing the following:
- You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.
- You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
- You implement the auto-update feature of Provisioning Services
- Reboot the XenApp servers
As you can see, the processes for updates and rollbacks are very similar and it works great. Stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly. I'm a little biased, but I think it is a good one.
Daniel - Sr. Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Pagefiles, partitions and drives are an interesting combination of items to talk about regarding Provisioning Services and XenApp. Each one will have a direct impact on your environment. First, let's be clear, Provisioning Services does support many of these items, but when I design a Provisioning Services solution (or any solution for that matter), I'm always reminded of a message a professor told me once. The professor was a fan of the group KISS and he always wanted you to follow the KISS motto... "Keep It Simple Stupid", but I'll be a little more polite and say "Keep it Short and Simple". Keeping it simple is how we will design the following items.
Pagefile
The first area deals with the page file. Before we got into provisioning and virtualization, I would see many people put the page file on a different drive letter than their OS or applications. At first glance you would think, OK, they want the page file to respond fast. But the page file was only on a different drive letter at the logical layer. At the physical layer, the page file was still on the same physical disk as the other partitions. So, my question was "Why are you moving the page file? You are causing yourself more work for no benefit." The same holds true in Provisioning Services.
The pagefile is undergoing constant modification by the operating system. As physical memory is paged, it is stored in the pagefile. Upon reboot, the contents of the pagefile are not important, and it is overwritten on subsequent startups. In a Provisioning Services environment, the pagefile will be located on the vDisk, but any change made to the file will be recorded in the write cache, because the vDisk image is read-only. Assigning the pagefile to a different partition within the vDisk is not recommended, because there is no speed benefit. You are just causing yourself more work.
Multiple Partitions
On the heels of the page file decision is whether to use multiple partitions. Does this look familiar?
- One Partition Server
- Partition 1: Operating System, Pagefile, Applications
- Two Partition Server:
- Partition 1: Operating System, Pagefile
- Partition 2: Applications
- Three Partition Server
- Partition 1: Operating System
- Partition 2: Applications
- Partition 3: Pagefile
Provisioning Services can deliver an image with one or two partitions, but not three. Plus, based on the Pagefile section above, there is no gain from having a separate pagefile partition on a provisioned XenApp server as the pagefile changes will be stored in the write cache.
Although two partitions are supported, it does increase the complexity of the environment and does not offer any performance benefit to the environment. There is a Citrix article (CTX116698) that explains how to provision a server with multiple partitions, but why go through the hassle. Keep It Simple.
Drive Remapping
Finally we get to remapping XenApp server drives. Remember, this is when you change the C drive of the XenApp server to the M Drive. D becomes N and so on. Why would you do this you might ask? Well, the most common justification for this design consideration was for users to have their client drives mapped within their XenApp sessions as C and D. However, this approach should be re-examined. Remapping server drives is not considered a best practice for XenApp environments because:
- Drive remapping is no longer an option in XenApp 5 running on Windows 2008 Server.
- Giving users access to their local C and D drives within a XenApp session is considered a security risk. If the applications are hosted on the XenApp servers, the data should be in the data center for best application performance.
- It makes the environment more difficult to setup, maintain and troubleshoot
So remember, Keep it Short and Simple (KISS):
- Page file: don't create a special vDisk partition
- Partitions: Use a single partition
- Drive Remapping: Don't do it.
What do you think? Agree or disagree? BTW, we will be revisiting the page file topic again in an upcoming blog when we discuss Local Database Storage. How does the page file fit with local databases? Well, you will just have to stay tuned.
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
As we continue to discuss Provisioning Services best practices for XenApp, I want to talk about a question I hear a lot, especially when people see the value of Provisioning Services and XenApp Application streaming "Should I pre-deploy my streamed applications into the Provisioning Services vDisk?" If Provisioning Services wasn't in the picture, I would say let the streaming infrastructure manage the application streaming delivery, but Provisioning Services must be taken into account because the act of application streaming has a direct impact on the provisioned server.
The streamed application is a change to the base vDisk image. These changes are stored within the write cache for each provisioned XenApp server. Depending on the size of the application, the simple process of delivering an application on top of a Provisioning Services' streamed XenApp server can make the write cache grow by many gigabytes as shown in the following diagram:
Using a provisioned XenApp server will generate the typical swap and temp files, which will be added into the write cache. When a streamed application is requested the first time, the application profile is delivered to the XenApp server from the Application Hub in a compressed format (.CAB files). The application profile is delivered and then decompressed so it can be utilized. This process adds information to the write cache.
Depending on the write cache option selected, this could have a significant impact on the usability and speed of the XenApp server. If the write cache size is a concern, then a pre-delivery option exists that will reduce the size of the write cache. This process is shown in the following figure.
In this example, the vDisk image has a pre-delivery of the streamed applications. Users still have to access the applications as before, but the applications are already on the vDisk so the application stream process is complete. This removes the application CAB files and the decompressed application cache from the write cache. This also speeds up the application stream process because the application is already present on the vDisk, although this is a minor concern due to the XenApp servers and Application Hub server residing on the same high-speed network.
The challenge with doing the pre-cache of the streamed application is that each time a streamed application is updated (which could be often), the application cache within vDisk image should also be updated (at least that is the assumption). This adds more steps into the application update process. But I don't believe every application update requires an update to the application cache on the vDisk, only major updates are a concern.
For example, if an application has a new patch or a new file update, simply updating the application profile will be adequate. When a user tries to start the application on a provisioned XenApp server, most of the application cache is correct except for a file or two. Those two items will be updated from the application hub, and will only slightly increase the size of the write cache. However, if a large update to an application is performed, like adding a service pack to Microsoft Office, then it would be advantageous to refresh the application cache on the vDisk because these updates impact a large percentage of the files in the cache. When the application is executed, all of the updated files will be streamed down and placed in the write cache.
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
Here we are again, for another Provisioning Services for XenApp Best Practice. This best practice focuses on integrating applications into the vDisk image. Pretty simple Yes or No answer.
But this is one of the major challenges with creating a base XenApp image is determining what to include and what not to include. Of course, you need the operating system and XenApp and Provisioning Services tools, but beyond that what is recommended and why? Take the following scenario: due to business reasons, an environment has three sets of XenApp servers hosting different line-of-business applications. All three line-of-business applications are dependent on Microsoft Excel for viewing and editing integrated spreadsheets. Should Microsoft Excel be part of the base image or should it be a streamed application? There answer is... there is no right or wrong answer; it is all dependent on other factors within the environment. Don't you just love answers like that?
The decision to include core applications is oftentimes a result in the belief that the base image should contain the greatest number of items that are common between XenApp servers. If every server requires the same application, more network bandwidth will be used when the application is streamed to every server as part of the application streaming process. Also, application streaming, in the default configuration, does not initially start as fast as a previously installed application because the application must be sent across the wire. Thus, users will experience latency while the application is streamed for the first time (this latency can be overcome with application pre-caching, as explained in the Application Cache section).
There is also a business aspect to this decision. In some organizations, one set of administrators is responsible for applications and another set is responsible for the XenApp configuration. By separating the applications from the base image, the technical solution can align more closely with the organizational structure of the business.
| Base Image Application Inclusion |
Base Image Application Exclusion |
|
|---|---|---|
| Benefits |
|
|
| Concerns |
|
|
Regardless of the decision on which applications to include and exclude in the base image, the following are general best practices for the base image:
- All relevant operating system and XenApp hotfixes and service packs should be included in the base image.
- The most common operating system and XenApp configuration should be used for the base image. If 80% of the servers require a specific setting while another 20% do not, the base image should include the special setting.
- The base image should include all appropriate XenApp plugins. If application streaming will be used, the streaming plugin should be installed as part of the base image.
- Depending on the usage of server certificates, the appropriate root certificate should be part of the base image.
What do all of you think? Do you install the common applications into the base vDisk, or do you rely on XenApp application streaming? How many unique XenApp images do you have in your environments?
As always, stay tuned for more best practices regarding Provisioning Services and XenApp.
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf
We are moving down the best practices road and now we come up to Active Directory. This, of course, is just a recommendation as I know everyone's AD structure will be different. But let's start out with a long-standing best practice... XenApp servers have warranted their own organizational unit within Active Directory for organizational and policy enforcement purposes. The recommendation has also included breaking out specific XenApp roles or locations into their own OU. Each identical group of servers would have the same policies applied. Typically, this creates an Active Directory structure like the following:
With the inclusion of Provisioning Services into the XenApp architecture, this recommendation does not change. In fact, this best practice becomes even more important because there will probably be special policy settings specifically for provisioned servers. Depending on how Provisioning Services is integrated with XenApp will help to determine if new OUs are required.
- If the OU contains a set of XenApp servers all provisioned with the same vDisk, then any Provisioning Services related policies can be applied to the entire OU.
- If the OU contains provisioned and non-provisioned XenApp servers, all hosting the same applications, then a new OU should be created that contains only the provisioned XenApp servers.
- If the OU contains provisioned and non-provisioned XenApp servers hosting different applications, then multiple OUs should be created containing only identical servers.
With Provisioning Services, the XenApp OU structure might resemble something like the following:
Each OU contains:
- Similar servers: Applications, infrastructure components, XenApp components
- Similar delivery processes: Provisioned or not provisioned
Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Many of you tuned into the TechTalk webinar over a month ago when I spoke about how to integrate applications into a virtual desktop. If you didn't attend the live event, you can still listen in to the recorded version of it. It sounds like an easy topic, right? "Just install them stupid!" Of course that approach does work, but is it the best approach? Many of us are long-time XenApp people. We see the value with virtualizing applications in XenApp. We've already spent lots of time, money and sanity to get our XenApp environments tricked out so it is running smooth. So I'm here to tell you, leverage it. Just because you are going to do a virtual desktop solution does NOT mean you have to throw away your XenApp environment. That is just crazy.
Before you start on the XenDesktop build out, take a look at the just released Reference Architecture. You can share and streamline your XenDesktop environment by using and sharing your XenApp environment. Some of the XenDesktop components can be shared with XenApp components. Which ones? How about the license server, data store or Web Interface?
Also, the integration must be streamlined. You don't want to make your users jump through 20 hoops before they get to their applications. They will be tired and hate the solution, resulting in your project failing. Make it look like the following diagram... Simplified user perspective
The user authenticates once, and they get a standard desktop image that is personalized with their unique set of applications, automatically.
Next, which apps go where? This is a big question. Do I let my XenDesktop users simply connect to hosted XenApp applications? If that is your objective, then why are you using XenDesktop? Truth be told, some applications work better on a desktop OS. But these applications can still be delivered via XenApp. Focus on application categories of Base, Anomalous, Resource Intensive and Technically Challenging. These categories will guide you to the best solution.
Click for larger image
Interested in building the XenDesktop/XenApp solution? Then grab the Implementation Guide. Step-by-step instructions (with pictures) that shows you how to leverage your XenApp environment for XenDesktop. If you are really good and just need a high-level guide, then grab the Getting Started Guide
The important thing to remember is don't throw away your past successes to build something new. Leverage your past success to make your future success easier.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
In the previous Provisioning Services with XenApp best practice blog, I spoke about the type of vDisk to use (the feedback was great. So much so that I've added new items for future best practices discussions). If you are going down the route of using a standard image, you must make another decision. This is probably one of the most commonly asked questions regarding Provisioning Services for XenApp environments, where do I place the write cache? The goal is to select a location that gives you the best performance without sacrificing other important items like fault tolerance or scalability. What makes this such a challenging discussion is the number of options we get.
- Target Device (Physical XenApp or Virtual XenApp) - RAM
- Target Device (Physical XenApp or Virtual XenApp) - Local Storage
- Target Device (Physical XenApp or Virtual XenApp) - Shared Storage
- Provisioning Services - Local Storage
- Provisioning Services - Shared Storage
Each write cache storage option has many different benefits and concerns, especially for the XenApp workload. For most XenApp environments, the best solution will be the one that takes on the following characteristics:
- Fast: XenApp requires a solution that responds quickly as XenApp is maintaining live, interactive user sessions. Any delays in the write cache might be noticeable to the users.
- Dynamic: XenApp servers are delivering many different applications and supporting many different users. Each user and application will have an impact on the write cache. The amount consumed will change day-to-day. The risks of exhausting write cache space would be detrimental to the success of a XenApp environment.
- Available: XenApp servers must be protected from environment failures, because each server is supporting many users simultaneously. The write cache solution selected should be one that does not impact high-availability options from functioning.
Target Device - RAM
Definition: The first option for write cache storage location is the target device's RAM. A portion of the target device's RAM is set aside and used for the write cache.
Benefits: The main benefit for using the target device's RAM is it provides the fastest type of write cache.
Concerns:
- A portion of the RAM cannot be used for the server workload. RAM is often better used for XenApp applications or user sessions than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
- Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Services can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned server. When available write cache is exhausted, the server can no longer make changes, which results in a server failure. If the write cache size is not estimated correctly, using a Target Device's RAM might pose detrimental to the stability of the environment.
Target Device - Local Storage
Definition: The second option for write cache storage location is the target device's local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server
Benefits:
- This solution does not require additional resources, in that most physical servers being provisioned already have local disks installed and unused.
- Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
- Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in server failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.
Concerns: If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer.
Target Device - Shared Storage
Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.
Benefits:
- Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
- Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
- Because the target device's storage is accessible from multiple virtual machines, virtual server live migration, like XenServer XenMotion, is viable.
Concerns: This solution requires the setup and configuration of a shared storage solution. However, if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage.
Provisioning Services - Local Storage
Definition: The fourth option for write cache storage location is on the Provisioning Services' local storage. This storage uses the physical disks installed within the Provisioning Services.
Benefits: This solution is extremely easy to setup and requires no additional resources or configuration within the environment.
Concerns:
- Requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. Because the write cache is across the network, servicing write cache requests will be slower than the previously mentioned options.
- The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Services server will negatively impact the server's scalability because the streaming service must also service the write cache requests.
- Provisioning Services includes a high-availability option, but in order for this solution to function, all Provisioning Services servers must have access to the vDisk and the target device's write cache. When the write cache is stored on one Provisioning Services server's local storage, this makes it impossible for other Provisioning Services servers to gain access, thus denying the ability to enable Provisioning Services high-availability.
- Although disk space is fairly inexpensive, chances are the Provisioning Services does not have an extensive supply of storage space. With each Provisioning Services server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Services server causing a server failure.
Provisioning Services - Shared Storage
Definition: The fifth option for write cache storage location is on the Provisioning Services server's shared storage. This option utilizes a share storage solution that is connected to the Provisioning Services server.
Benefits:
- The shared storage solution allows for Provisioning Services high-availability as each server can access the vDisks and the write cache.
- Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.
Concerns:
- This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. The Provisioning Services server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
- Provisioning Services scalability is impacted as the streaming service is responsible for handling Provisioning Services write cache requests and forwarding them onto the shared storage.
- The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated.
Best Practice:
Based on the aforementioned criteria and the explanation of the different options for write cache, XenApp servers provisioned with Provisioning Services are best suited for
- Virtual XenApp Server: Target Device - Shared Storage
- Physical XenApp Servers: Target Device - Local Storage
Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:
- vDisk Type
- vDisk Cache
- Active Directory
- Application Integration
- Application Streaming Cache
- System-level settings: Page file, drive remapping and multiple drives
- Image Management
- Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
- Plus more if we get some good ideas on other areas of focus.
Daniel
Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf
Follow Daniel on Twitter: http://www.twitter.com/djfeller