Category Archives: XenApp

When is RDS/XenApp not enough?


When working on desktop transformation designs, many start with the VDI (personal) model. I tend to go for the RDS (Shared) model. There are many reasons why, but mainly it is because

  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

 

About these ads

XenApp Virtualization Best Practices


One of the first questions when virtualizing XenApp is how many VMs to put on a server. Well, that was discussed in the Virtualize XenApp blog. Once you figure out how you plan to carve up the physical server, one of the next common questions is deciding which features of the hypervisor to enable/disable. For example, if I use XenServer, should I use the “Optimize for XenApp” setting? What about vSphere’s Transparent Page Sharing feature? And the big whopper, how should I allocate memory to my virtualized XenApp servers? Is it safe to use dynamic memory or am I safer to stick with fixed memory?

The following table is what Citrix Consulting has seen and recommends. By the way, if you want the entire discussion on virtualizing XenApp, then go to the XenDesktop Design Handbook and look in the Planning Guide section for XenApp Virtualization Best Practices.

Decision Justification Hypervisor
Overcommit CPU:No It is advisable not to allocate more vCPU than there are logical cores on within the given hardware. Experience has shown that greater levels of scalability are achieved by not overcommitting CPU. Hyper-VXenServer

vSphere

Utilize Hyper-threading:Yes Newer processors have the ability to do hyper-threading, where each core is two logical cores. Utilizing hyper-threading in a XenApp environment has been shown to improve user density. Hyper-VXenServer

vSphere

Disable ASLR: No As many organizations try to protect their XenApp servers from viruses, malware and other OS exploits, it is advisable to keep Address Space Layout Randomization enabled, which is the default setting. The functionality is included with Windows 2008, Windows 2008 R2, Windows Vista and Windows 7. Hyper-VXenServer

vSphere

Enable Transparent Page Sharing:Depends on OS Enabling or disabling Transparent Page Sharing has not been shown to either help or hurt performance on newer systems (Windows 2008, Windows 2008 R2, Windows Vista and Windows 7). However, older systems (Windows 2003 and Windows XP) have benefited, mostly because the page sizes are smaller (4K), thus making it easier to share pages of memory. vSphere
Optimize for XenApp:N/A On systems utilizing pre-Nehalem processors, the XenServer setting “Optimize for XenApp” provided increased scalability. Since the release of the Nehalem processors, much of the functionality has been placed on the hardware so this particular XenServer setting can be ignored. XenServer
Disk Alignment: Yes As a host server will be running multiple instances of a server operating system, it is even more important to optimize the disk subsystem to improve performance and scalability as opposed to a system running a single operating system. Windows 2003 is misaligned with default installations. This should be corrected installation to help reduce storage impact. XenServerHyper-V

vSphere

Memory Allocation:Fixed As users are dynamically load balanced across XenApp servers, memory usage between different virtual machines should be similar, helping negate the need for dynamic memory allocation techniques. Also, if VM migration strategies are used, this could cause memory overcommit resulting in aggressive paging and poor performance across all XenApp virtual machines. It is advisable to set fixed values for memory reservations for XenApp virtual machines. XenServer
Hyper-V

vSphere

Host Swapping: No In most environments, all XenApp servers are actively hosting users at the same time. Swapping out memory from one XenApp host will degrade performance for all virtual machines as the memory keeps getting transferred to/from disk. vSphere

Daniel – Lead Architect
XenDesktop Design Handbook

Virtualize XenApp


Here is a pretty common question… I want to virtualize my XenApp servers, how should I carve the physical server up? Should I use a bunch of small VMs or a few massive VMs?

First, you have to look at a few decision points:

  1. OS Scalability: This is more of an issue in Windows 2003.
  2. Operations: More VMs means more to manage, unless you use a single image management solution like Provisioning Services.
  3. Application Requirements: The applications will dictate how many vCPUs and how much RAM you need to fully utilize the VM. Over allocate one and you waste resources. Under allocate one and you waste resources.
  4. Flexibility: How easy is it to migrate active VMs to another server (discussed in the Big or Small VMs for XenApp blog)
  5. Licensing Costs: More VMs means more Microsoft licensing costs. In fact, you might end up moving from Standard to Enterprise or even Data Center.

When we take all of this stuff together, we end up with the following:

Sockets Cores / Socket Hyper-Thread Logical Cores / Socket Logical Cores / Server VM Count vCPU per VM RAM per VM
32-bit Operating Systems  (Windows 2003, Windows 2008)
2 2 No 2 4 2 VMs 2 vCPU 4 GB
2 2 Yes 4 8 2 VMs 4 vCPU 4 GB
2 4 Yes 8 16 4 VMs 4 vCPU 4 GB
4 2 Yes 4 16 4 VMs 4 vCPU 4 GB
4 4 Yes 8 32 8 VMs 4 vCPU 4 GB
64-bit Operating Systems (Windows 2003, Windows 2008, Windows 2008 R2)
2 2 No 2 4 2 VMs 2 vCPU 8 GB
2 2 Yes 4 8 2 VMs 4 vCPU 16 GB
2 4 Yes 8 16 2 VMs 8 vCPU 32 GB
4 2 Yes 4 16 4 VMs 4 vCPU 16 GB
4 4 Yes 8 32 4 VMs 8 vCPU 32 GB

I’ll probably hear a lot of comments for the 64bit systems with using bigger VMs and fewer of them. And those comments would be true. Windows 2008 64bit overcomes many of the bottlenecks we experienced with Windows 2003 32bit. But we are trying to have greater flexibility. We are trying to limit the impact of a VM failure. Bigger VMs means bigger impact if there is a failure.

How closely does your virtualized XenApp environment align? Or how about your plans? Are they retty close?

Daniel – Lead Architect
XenDesktop Design Handbook

Big or Small VMs for XenApp


Many of us know that if we virtualize XenApp servers using a 32bit OS, we can more fully utilize the physical servers. This is possible because the 32bit OS will reach system limits before we reach physical hardware limits. By adding more VMs, we effectively increase the scalability of the physical hardware by more fully utilizing it. Nothing too Earth shattering there.

What about running XenApp on a 64bit OS? We don’t have the same system limitations. Do we want to virtualize it? How should we carve up the server?

There are many different aspects to look at but I’m only going to focus on flexibility at this point. If I didn’t virtualize one of the newer servers (4 sockets, 2 cores and hyperthreading enabled) I would have a XenApp server with 16 logical CPU cores. Windows Server 2008 R2 and XenApp can handle this, but do you want to? This one server will support hundreds of users. If I don’t virtualize it, how difficult will it be to maintain the one image? It might take a long time to siphon off all of the users so I can do maintenance. So the answer is to virtualize it… Right?

Sure. That way we can move the live VM to another host so we can do physical host maintenance. But moving the VM might be difficult. And by difficult I don’t mean from a hypervisor perspective as XenServer, Hyper-V and vSphere are truly capable of migrating VMs to other hosts. By difficult I mean that it might be a challenge to find a server that has that many resources available to host the VM. You could do an N+1 scenario and forget about the VM migration, but you still have to wait for the users to siphon off of the VM.

What happens if I use smaller VMs? It makes finding a home for the VM easier. I probably have more options finding a host for a 4 vCPU VM than a 16 vCPU VM. And even if I didn’t migrate, the time to siphon off users from a small VM should be a lot faster than from a large VM.

Flexibility is one aspect to consider when virtualizing XenApp servers.

Daniel – Lead Architect
XenDesktop Design Handbook

SMB Tuning for XenApp


Many of us who worked on XenApp servers with Windows 2000/2003 remember tuning the SMB settings of MaxMpxCt. In short, this allowed a XenApp server to make more simultaneous SMB connections to a file server. Think about it, on XenApp, you have 50-100 users making connections to a file server. The file server sees those connections coming from a single source, the XenApp server. The file server is trying to protect itself from getting slammed by a single system. Unfortunately, this slowed down user requests to the file server, thus impacting the user experience. To overcome, we would modify 4-5 different registry keys.

What should we do with Windows 2008R2 XenApp servers? What if the file server is 2003? What if it is 2008? Dan Allen, one of our Sr. Architects in Citrix Consulting, provides an awesome analysis and recommendation for these different scenarios in his post called SMB Tuning for XenApp and File Servers on Windows Server 2008. This is one you want to keep in your bag of optimizations for XenApp servers.

Daniel – Lead Architect

Follow

Get every new post delivered to your Inbox.

Join 460 other followers