Designing a Citrix Desktop Infrastructure using a Pod Design Approach
If you start designing your envirioment and taking in account in which way this environment needs to scale in the near future. Although Citrix XenDesktop will scale to for large environments at some point you can take another approach. Maybe going to make your design modular like having Lego block stacked on top of each other.
This is approach would fit into design for the following:
- Large Enterprises
- 10K +users
- Mission Critical Environments
- Large number of thin client users
There are a lot of reason a XenDesktop environment could fail.
- DNS Failures
- Storage Outage
- Hypervisor Failure
- DHCP Outages
- PVS Stream hang
- SQL Failures
- No vDisk available
Just to name some of the top of my head…..
Citrix has some solutions out there to solve the availability issues. But you could the discuss if this is the righty solution, and even if this is a complete solution.
- SQL High Availability
- XenDesktop Connection Leasing
- NetScaler LoadBalancing
So lets think about this for a minute or so… For instance let take environment of 15.000 users. Just for this example. I know that this number of desktops in Dutch terms are really high. I never came across an environment with the numbers myself…
If you would design such an environment in a single site is this a could idea. Think about the following:
- How many VM’s could you run on a single host, being this (vSphere, Hyper-V or XenServer)
- How many VM’s could you assign to a LUN
- How many target devices per Provisioning Server
But even when you push the environment to its limit. You must take in account that for instance the consoles will get really slow an sluggish. Hypervisors will act slower.
So taking in account all of the above facts maybe a POD design with multiple sites would be an better option. And, yes, you need to manage multiple Pods. but you can overcome this if you build identical pods, and use PowerShell, and Desktop Director for multiple sites.
So lets start at looking deeper into the idea of a pod design. A pod is a fully independent XenDesktop/XenApp site in which al of the components to running the infrastructure are included;
- SQL Database
- Citrix Provisioning Servers
- Citrix Delivery Controllers
If we look at above picture there are some things we need to consider. For instance each of the pods act as a fully independent XenDesktop Site. High availability is gained by using multiple pods. The main goal is that each individual pod share as least as possible with other pods. Each pod uses separate hypervisors with its own management layer, being this vCenter, SCCVMM or Xen Server Pools. Every pod uses its own SQL High available database. Every pod uses it own local storage or SAN storage. Every pod uses it’s own VLAN. Every pod has it’s own Citrix Provisioning Server Farm. And it would be a good idea to separate each pod in its own rack or for instance blade chassis.
As you can see at the bottom of the picture you also need services that live outside the pod. We will go into this in a later stadium. It would be recommended to design each pod exactly the same.
So I hope the concept at this point makes any sense. Lets take it a step further.
Normally in an Citrix Desk Infrastructure environment we use a lot of components.
- Citrix Delivery Controllers
- Citrix Provisioning Servers
- Citrix StoreFront
- Citrix License Server
- Microsoft SQL Server
- Citrix Director
- And off course user specific data, such as profiles and home drives
The question is do you want to put this in the pod or outside the pod
Citrix Delivery Controllers & Citrix Provisioning Services
Both components are critical and essential to a VDI deployment. Citrix Delivery Controllers cant work without SQL. Citrix Provisioning Services can work without SQL with its offline database. But you need to take in account that some things don’t work with an offline database. You should design for 1 XenDesktop and Provisioning Service site per pod, each with its own SQL based database and server in the pod.
Citrix StoreFront servers a really stateless, and can aggregate desktop groups from multiple pods into single icons. No database is required. These StoreFront servers are not to be placed inside the pod. You need multiple StoreFront server. Pooled into a service group and use load balancing (NetScaler). You also can consider using GSLB (Global Server Load balancing). There is a good article written by Thomas Berger http://blogs.citrix.com/2013/09/10/building-modular-xendesktop-infrastructures-by-means-of-storefront-multi-site-configurations/
Citrix License Server
Citrix License Server needs to be placed outside the pod. It doesn’t use a SQL database. It is recommend to load balance the license server. You can read a good blog on this by Nick Rintalan. http://blogs.citrix.com/2015/02/12/making-the-citrix-license-server-truly-highly-available/
Microsoft SQL Server
As mentioned above, some of the components need SQL server. So this is an important component. The SQL environment needs to be placed within the pod. Use an HA solution like Mirroring or Always on. This SQL environment should also be used for other components within the pod. Such as SCVMM, PVS and/or vCenter. Do not share
the SQL between the pods, and also not for other enterprise services.
A few things to consider with the hypervisor. You need hypervisor connectivity for power management. If you are using Machine Creation Services hypervisor connectivity is also needed to place disk commands. If the hypervisor control/management goes down XenDesktop will go down…
So design the cluster/pools within the pod. Use a vCenter or SCMVMM per pod.
Citrix Director does not require an SQL database. It can integrate multiple XenDesktop Sites. And should be placed outside the pod. You should consider to scale to director accordantly and use load balancing with NetScaler.
User Profiles and Home Directories
User profiles & home directories should be placed outside the pod. You could consider using a Microsoft File cluster/NAS if design properly you can support 10k users.
No need to say that you also need to take a look at some profile management solutions, like:
- Citrix Profile Management
- Res One Workspace
- Appsense Desktop Now
- Norskale VUEM
- Microsoft GPO, GPPrefs
- Microsoft UE-V
Within a Citrix XenDesktop environment there are also some other services needed to keeps things running. For example:
- Active Directory
- Microsoft System Center Configuration Manager (Image deployment, vDisk creation)
- 2 Factor Authentication Solution (Radius)
- NetScaler Gateway
- NetScaler Load Balancers
- HDX Insight
Al off these components can and should be placed outside of the pod.
So what about management and ongoing maintenance. Consider the following within your design;
- Deploy Citrix updates in one single pod first.
- Use a naming convention that reflects the pod design
- Use unique service accounts for each pod
- Off course design with N+1
There are also some challenges with this approach. I would like to mention them and give a solution, as I can see at this point.
Aggregation from multiple pods. As from StoreFront version 2+ we can aggregate multiple sites. This is a feature build within the product.
Managing Multiple Pods. Use Microsoft GPO for Citrix HDX Policies, Use PowerShell, Use Desktop Director to manage multiple XenDesktop sites.
Persistent VM, so in my opinion , why use Persistent VM’s, because there is much to consider. ( use only on XenDesktop site, LUN’s , VLAN etc.), they consume more storage, use more IOPS. If for instance the one of the mentioned things are not available the desktop (VM) is not available.
There are so many tools/choices out there to provide a solution to remediate this.
- Put all of your apps into the golden/master image
- Virtualize the applications using App-V, FSLogix, ThinApp, Numecent, Spoon or Symantec.
- Host the application on MS Remote Desktop Server/ Citrix XenApp
- Use Personal vDisk
- Use application layering like Unidesk, Vmware App Volumes, Docker etc..
Reference materials used: Citrix.com, Support.citrix.com and the E-Docs website.