It is possible to build a large monolithic XenDesktop infrastructure for 50,000 users. This has been proven in internal and customer-driven scalability tests multiple times. The only thing you need to make sure is that the controllers as well as the SQL servers are equipped with sufficient resources. But we have to ask ourselves if that is actually a good approach. Hosting virtual desktops or applications for 50,000 users in a single environment is nice from a management point of view, since all tasks can be performed from within a single admin console.
On the other hand this means that we have a huge single failure domain. So if something bad happens all users will be affected. Therefore it might be a good idea to split the environment into stand-alone entities (aka building blocks).
Splitting a XenDesktop site sounds easy but there was one big issue associated with it in the past: Session Reconnection.
Imagine the infrastructure outlined below:
Now let’s assume the infrastructure has been configured correctly and Web Interface shows a single icon for pooled virtual desktops from both XenDesktop sites. The user clicks on the icon and Web Interface will randomly select one of the sites and forward the request. The connection gets established and the user is happy. After a while the user moves to a meeting room and would like to reconnect to the session. Since Web Interface selects the XD site randomly and does not understand whether a user already has a session running, there is a 50% chance that the user will actually get a new session and is not happy anymore. There is a 3rd party tool available that enhances Web Interface respectively (check out XenDesktop – High Availability & Load Balancing Add On For Web Interface! if you’d like to learn more about it), but since Web Interface does not support XenDesktop 7 we can’t use this solution for newly build environments.
Fortunately a Storefront 2.0 introduced the Multi-Site Store feature, which can solve the aforementioned issue and provides some nice additional functionality. The official documentation can be found in eDocs –Example highly available multi-site store configurations, but I’d like to go a little deeper and provide a working sample configuration.
How do Multi-Site Stores work?
The workflow, which is outlined in the diagram below, is actually fairly simple:
- User enters username and password. This is sent to the StoreFront server.
- The authentication service of StoreFront fetches the user credentials, validates them with a domain controller and resolves all user group memberships.
- StoreFront checks the data store (local database) for existing user subscriptions and stores them in memory.
Furthermore StoreFront validates the user mapping configuration. In this step StoreFront will run thought the list of groups the user is member of and compare them with the user groups configured as part of the user mapping config in the web.config file. If the user is member of a pre-configured group StoreFront will forward the request to the respective sites only. In case the user is not member of a known group, StoreFront will forward the request to all sites which have been added to the store.
- In this case a single EquivalentFarmSet (sites with the same configuration) with Round-Robin Load Balancing and a stand-alone backup farm has been setup. Therefore the credentials are sent to the XenDesktop Controllers in Site 1 and 2. In case neither controller responds StoreFront forwards the request to the Failover site.
- The XenDesktop Controller validates the user credentials with a domain controller.
- After a successful validation the XenDesktop Controller checks which resources have been published to this user within its database.
- The XenDesktop Controller sends an XML response to StoreFront which contains all resources available for the user from the XenDesktop site.
- StoreFront consolidates the list of available resources (displaying a single icon for each resource only) and sends it including the existing subscriptions to the Citrix Receiver installed locally or displays them in Receiver for Web.
- Now the user clicks on an icon in order to connect to a resource.
- StoreFront checks with both XenDesktop Controllers whether the user already has a running session. Both Controllers will check their database and respond back to StoreFront.
- StoreFront computes the responses.
- A) If there is no existing session for the user, StoreFront will pick a XenDesktop Site based on the Round-Robin load balancing algorithm.
B) If the user already has a session StoreFront will ask the respective Controller for session details to enable the user to reconnect.
- StoreFront sends the .ica file to the client. Receiver will fetch the file and establish a session.
How to configure this?
The configuration is pretty straightforward but not very intuitive since it needs to be done by means of a text editor.
- Download a XML editor (such as Notepad++). Of course you can also use Notepad or Wordpad or any other text editor, but a proper XML editor makes your life easier.
- Download PSGetSID from Microsoft TechNet or use any other tool or script (such as PowerShell) to resolve the SIDs of the user groups.
- Locate the web.config file under C:\inetpub\wwwroot\Citrix\<Storename> and duplicate it to have a backup copy.
- Open the file and search for “<resourcesWingConfigurations>” (should be in line 231).
- Add your user mapping / multi-site configuration as outlined in eDocs – User mapping example.
- After saving the web.config file the new configuration becomes active immediately. In case you did a mistake StoreFront will stop working (Console and Receiver for Web show an error message / Receivers cannot connect to the Store). So you better validate the changes in a dedicated test environment before touching the production environment.
Tip: I had some issues with tags not closed properly. So verify that all tags that have been opened (e.g. <userFarmMappings>) are closed somewhere (e.g. </userFarmMapping>). Please note some tags are closed right away with a “ />” at the end of the line.
To simplify creating your own configuration, you can find the configuration I used in my lab environment below:
<resourcesWingConfiguration name=”Default” wingName=”Default”>
<group name=”Test_User” sid=”S-1-5-21-461323750-3098328222-1654375262-1109″ />
<equivalentFarmSet name=”DataCenter1″ loadBalanceMode=”LoadBalanced” aggregationGroup=”AggregationGroup1″>
<farm name=”Site1″ />
<farm name=”Site2″ />
<farm name=”DR” />
One more thing
Before you ask; no I don’t know why there is no GUI-based configuration for this, but I hope we will get it in the future.