In Part 1 of this series I discussed the changes we made to control the load placed on the hypervisor by the XenDesktop pool management service.

In part 2 I describe the changes we made to lock down certain roles within the XenDesktop farm to provide a more stable and predictable farm.

Our first focus was the DDC that sends the VM commands to the hypervisor.  The DDC in the farm that performs this role is called the farm master server.  The farm master server is whichever DDC is the Zone Data Collector for the farm.  It is the pool management service (cdspoolmgr.exe) that sends the VM power commands to the hypervisor.

As we looked at the roles being performed in the farm we saw that the farm master server was also the first XML broker for the web interface, and was also registering VDAs and brokering connections.  To maximise the stability of the environment we carried out the following changes:

  • Edited the properties of the Web Interface so that the farm master was no longer listed as an XML broker
  • Fixed the farm master roles so that we had a dedicated master and dedicated backup server
  • Stopped the farm master from registering VDAs

XML Broker changes

The customer used Web Interface 5.3 and we carried out a simple change to the config of the web interface so that the farm master server was no longer listed.  This ensures that the authentication and application enumeration load was no longer being performed by the farm master server.

Fixed Farm Roles

By default the first DDC in the farm assumes the role of farm master and acts as the zone data collector and communicates with the hypervisor.  In a small XenDesktop deployment it is perfectly acceptable to make no changes to the roles in the farm.  However for larger environments it is recommended to create some hierarchy in the farm.

 Any of the DDCs in the farm could become the farm master if an election is triggered.  In a XenApp farm we use the XenApp Advanced Configuration tool to set the election preference.  In a XenDesktop environment we control election preferences through the registry.  A DDC can have 1 of 4 preferences set (sound familiar?):

  • Master – servers with this setting are preferentially chosen as the farm master
  • Backup – servers with this setting are chosen when the Master is unavailable
  • Member – servers with this setting can become the farm master if the Master and Backup are unavailable
  • Slave Only – servers with this setting will not become the farm master

We used the instructions at http://support.citrix.com/article/CTX117477 to edit the registry on the farm master and backup server.  We opted for a dedicated Master server, a fixed but non-dedicated Backup server and the remaining 6 DDCs were set as Members.

Stopping the Farm Master Registering VDAs

Having made the changes listed in part 1 of this series we had stopped heavy loads of the hypervisor and storage from bringing the infrastructure down.  Changing the XML broker settings had reduced the CPU utilisation on the farm master from an average of 90% to around 70%.  This was moving in the right direction, but we felt we could get this down further.

 Our next task was to stop the farm master server from registering VDAs.  This can be done via a registry key HKLM\Software\Citrix\DesktopServer\MaxWorkers.  We set the value of this key to 0, meaning that the farm master DDC would no longer register VDAs

Having made this change we saw a further drop in the CPU utilisation on the farm master server and now felt confident that the infrastructure would be far more stable during period of peak user load.  We also felt that the infrastructure would now be able to handle the planned additional 500 VDAs.

That is it for this post.  In the final part of this series I will cover some of the other items that we changed or highlighted that completed this piece of work.

You can view part 1 of this series here

You can view part 3 of this series here