Since the release of XenApp and XenDesktop 7.0, it has been possible to use a pool of multi-session server OS VDAs in a delivery group to supply app and desktop sessions to end users. The system will load balance when choosing which of the VDAs in the pool to use to run a new end user session on, and by default that load balancing choice is based entirely on the number of sessions that the different VDAs are running. By default, each VDA in the delivery group is expected to be equivalent in terms of performance and capable of running the same number of end user sessions. In some deployments, however, this may not be the case.

How Load is evaluated

One of the documentation pages for the 7.5 release describes the basics of the VDA load management mechanism, but there are some useful less-obvious aspects to this area of the product. Each multi-session server OS VDA machine has a calculated ‘load index’ value, and this load index can range from 0 to 10000, indicating a completely unloaded machine to a fully loaded machine that cannot run any more new sessions.

The load index calculation is based on a number of factors. By default this is just the number of user sessions that are currently running on the machine, in relation to the configured maximum number of sessions, which in turn defaults to 250. However, other load measurements can be added in to this calculation by use of the HDX policy settings such as ‘CPU Usage’, ‘Disk Usage’ (disk queue length) and ‘Memory Usage’; in each of these cases the load factor is related to performance counter measurements on the VDA machine and their relationship to a target/threshold value for the counter as defined in the policy. Each of the active factors (number of sessions, CPU load, disk load and memory load) calculate a load value between 0 and 10000, and then the overall load is calculated from these such that the largest load value is taken and then an extra adjustment which is a proportion (defaults to 5%) of the average of the other load values is added.

On top of this calculated result, a padding bias is added to account for sessions that have already been brokered to that VDA machine but have not yet started (and so don’t yet show up in the measured load). This bias is equal to the current per-session load value (calculated load value divided by the number of currently present sessions) and this bias is added for each brokered but not yet running session.

The end result of this calculation is an effective load index between 0 and 10000, and this value can be seen in the ‘LoadIndex’ property of the machine objects returned from the Get-BrokerMachine PowerShell SDK Cmdlet. This effecitive index is then used in brokering decisions that are made to route new end user apps and desktop sessions to run on the lowest loaded available VDA machine.

Other Factors

Other settings are taken into consideration when making a brokering decision as to which VDA machine to use, and these include:

• Concurrent logons tolerance
  • This policy settings specifies a limit (defaults to 2) for the number of simultaneous session start sequences for end users that the VDA machine can handle, because the demands on the VDA machine are typically higher during a session start then during the subsequent normal operation of the user’s session. The load balancing decision will not violate this limit where possible, but will exceed this limit if the alternative is to refuse an end user an app or desktop launch.
•  Maintenance mode settings for the machine
  • If the VDA machine is affected by any maintenance mode, including Windows OS settings of RDS maintenance mode, hypervisor maintenance mode etc., then this typically precludes the machine being chosen by the brokering logic to host a new end user app or desktop session.
• Zone preference
  • If a zone preference has been configured (since release 7.11) that relates to a particular user’s launch, then the lowest loaded VDA machine that matches the expressed preference is chosen and only if there are no available (not fully loaded) machines in the preferred zone are machines from other zones considered.
• Launch Tag filtering
  • If an application or desktop has been configured with a tag filter (since release 7.12), this means that only VDA machines that have been marked with that same tag are considered when choosing a machine to run a session for that application or desktop. The lowest loaded available machine with the required tag is chosen for a new end user session.

Using Policy Filters

As can be seen above the calculated load index can be controlled by settings that are applied via the HDX policy. The HDX policy itself can be controlled through various filters being applied to the policy rules, and these filters can indicate that some policy settings collections only apply to machines in particular delivery groups, or even more specifically to machine with particular tags applied to them.

The filtering of policy settings by tag is different to the tag filtering of VDA machines when choosing a machine to host a new session as described earlier. Using the policy tag filtering mechanism with policy settings for different load thresholds, you can configure a delivery group which contains machines of different performance capabilities such that sessions are load balanced among them in a helpful way.

For example, if a delivery group contains some machines that are capable of hosting 80 sessions and some other machines that are more performant and capable of hosting 150 sessions, then you can create two separate policies; one policy would set the ‘Maximum Number of Sessions’ setting to 80 and have an ’80sessions’ policy tag filter applied to the policy and the other would set the ‘Maximum Number of Sessions’ setting to 150 and have an ‘150Sessions’ policy tag filter applied. The machines in the group would then have either the ’80sessions’ tag or the ‘150Sessions’ tag associated with them as appropriate.

The per-delivery group policy filter can be useful in this context rather than using the per-tag policy filter if, for example, an application group is configured to span multiple delivery groups and the two or more groups have machines in them of differing performance capabilities.