Friday, February 4, 2011

Deploying Citrix XenDesktop with FlexCast

When I was reading about FlexCast delivery for desktop deployment  , I had following question in my mind.

  • When you classify user to use XenApp hosted desktop?
  • When you classify user to use VM hosted desktop ?
  • How do you classify IOPs requirement for write cache ? Is it good idea to go with RAID 10 or RAID 5 ?

First let me explain what exactly is XenApp hosted desktop and VM hosted desktop is .

XenApp hosted Desktop (SHD) is : when virtual machine installed with XenApp is published and used as a desktop. Of course there are  tweaks to be done on XenApp installed on  windows 2008 server to have end user get a feel of desktop. Jo Harder  blog talks about it.

VM hosted Desktop (VHD)  is : When virtual machine installed/Streamed  with windows 7 or XP  are presented to the end user by the means of broker.

Now as we understood what exactly is SHD and VHD is , we will try to understand when we choose which model and why .

When we choose XenApp hosted Desktop (SHD):

While choosing XenApp hosted desktop (SHD) , we should remember that it scales better, cost less and is  a lot more proven in the enterprise (Compare to XD).  In certain case we can eliminate the need for shared storage. Are you are wondering how ? . When SHD model us used, more user can be accommodate on single machine.
But while selecting SHD model you may face challenges like
1.    Unique VLAN requirement: Suppose you are proposing SHD model and end user can not share VLAN . At that point of time you will have to choose VM per user group, though you can have 7 VLAN seen by single VM. 
2.    Application which is not compatible with TS/RDS.
3.    Users demand their own user space.
4.    User requires high quality video/audio. It is recommended to go with XD.
5.    Technical requirements dictate a XD based solution. Something like VPN client which can’t work on SHD model.

With XA environment, over committing CPU is not something which is recommended.  While choosing hardware, choose correct CPU model.  CPU with HT enabled will get you more logical CPU. For example if  it is a dual quadcore processer then logically you will get 16CPU  ,whereas non HT CPU model will get 8 CPU. This will make difference to the consolidation ratio.  HT enabled CPU will help you getting mode SHD.

With newer bread of CPU like Nehalem /Westmere , we can leverage HT for performance improvement as we as high consolidation ratio. Prior to Nehalem /Westmere it was advisable to stick with pCore to vCore mapping.  More logical CPU means better CPU:RAM ratio and better overall utilization of hardware.
It’s probably the best trade-off between CPU and memory and still keeps the number of VMs per hardware low.


While choosing VHD:

There is much option like SHD . With VHD , overcommitting of CPU is acceptable. For memory overcommit  DMC can be enabled which will help to squeeze a few more VM’s on a hardware. let’s say you get 100 XP VMs/blade and 50 Win7 VMs/blade.  HSD’s via XA can give you 4-8x the amount of users/box!!!  Even if we say 50 users/box on each of those XA VMs (very conservative), XA still could support 200 users/box where XD could support 50-100…that’s still 2-4x more scalable and it’s not uncommon in the real world to see a 3-4:1 ratio in the real world between XA:XD

Third question was what IOPs requirement for write cache.  Write cache is write intensive which is around 80:20 write:read IOPs. Since it’s write intensive , RAID1/10 would  recommended RAID model compare to RAID 5. Then question raised how do I size wirte cache drive. This would usually pagefile + writecache. It is advisable to place pagefile on a write cache drive for better performance and optimization. 
For example if XenApp VM has been assigned 6GB of virtual memory , configure page file of size 4GB and leave other 6GB for write cache. So you will size storage for 10GB writecache.  For VDI kind of environment, 5GB of writecache (Pagefile + writecache) drive is idle.

Size of the Writecache also depends on integration of profile solution and reboot cycle.

All feedback will be incorporated in next release

No comments: