Configuring RDSH Load Balancing on VMware Horizon 6 Version 6.2

VMware Horizon 6 version 6.2 was released with key enhancements to RDSH Farm features. (RDSH: Remote Desktop Session Host). Until version 6.2, VMware Horizon 6 had only one method to establish a new remote app session. This method, uses the ‘current session count’ and a specified ‘Limit value’, to determine which RDSH agent to place a new session. Based on this, a server with highest capacity for each new session is identified. The newly introduced method, referred as RDSH Load Balancing, uses either of two following approaches for establishing new sessions.

  1. Perfmon based new-session load balancing
  2. App Count based new-session placement

Both these approaches can be independently applied or together it can make a hybrid way of efficient session placement. This article provides a detailed procedure on how configure and monitor RDSH load balancing using these approaches, along with brief section about its implications & considerations.

Perfmon based new session load balancing

This method internally uses Microsoft® Windows™ Perfmon tool to collect resource utilization matrices from RDSH Agent VMs of a Farm; and then report a ‘Preference Value’ to Load Balancing module of the Horizon Server, to take appropriate action while receiving new session requests. The load value can be measured against CPU utilization, MEMORY utilization or any other matrices that can be collected via custom scripts, that you can defined your own according to your organizational needs. Using this script, the load values has to be collected from all the RDSH Agent VMs of a Farm, and the script has to be of same type. In other words within an RDSH Farm, you should neither mix load values among CPU and MEMORY (and/or any other custom made script), nor leave one or more RDSH Agent VMs without having the load-script configured.

Load Value scripts

VMware Horizon Agent installer, by default provides two sample scripts  which can be used to collect CPU and MEMORY load values, . After installing or upgrading Horizon Agent on RDSH Agent VMs, these scripts will be available for configuration under ‘C:\Program Files\VMware\VMware View\Agent\scripts’. As an administrator, you need configure all RDSH Agent VMs of a given Farm to pick one identical the script. Once hooked, these ‘Load Values’ scripts are used to calculate machine load and then report a ‘Load Value’ from each RDSH Agent VMs.

CPU Load Script : Load Value based on CPU load can be  collected using the script “cpuutilization.vbs”. This script  returns an average percentage value of  CPU utilization (for last 5 minutes).

Load Value = Average (% CPU Utilization for last 5 minutes)

The Perfmon tool has no dedicated counters that average ‘%Utilization’ over a period of time. Therefore the script  read this from a registry value updated by Horizon View Agent by ‘sampling instantaneous values and averaging over a period of time’. (Instantaneous CPU numbers are not leveraged here as these fluctuate wildly over time.)

Memory Load Script: To configure load balancing based on memory load, you can use memoryutilization.vbs script. This script reads the available bytes and total bytes; and works out a ‘used %’ which is then mapped to load value.

Load Value =  %Committed Bytes in Use

Setting up Load Balancing for an RDSH Farm

Load Balancing on a Farm is done by configuring each and every Agent VM in the Farm, to hook and run the load scrip. In order to run this script, a service called ‘Host Script Service’ has to be running in the background. Therefore two configurations are required to setup in each RDSH Agent VMs such as ‘Script Service Configuration’ and ‘Script Hookup Configuration’

Configure VMware Horizon Host Script Service

Load script is executed by VMware Host script service and has to be configured to start automatically every time VM boots up. For this you can open Windows Service manager by running ‘services.msc’ and edit properties of ‘VMware View script host service’, and set the startup type as ‘automatic’ and click OK. Now from next reboot onward, the service will be started automatically. You may also right click on the service, and click ‘Start’ so that the service will be started immediately to avoid reboot. This entire configuration is also explained in detail at Horizon 6.2 Administration Guide

Configure Load Value Script

As explained earlier, you can define your own script to measure load value according to your choice. In this article I am referring to one of the sample script provided by VMware that measures CPU Utilization. This configuration has to be done at RDSH Agent VMs’ registry level. To perform this configuration, open HKEY_LOCAL_MACHINE registry hive through the registry editor and navigate to below key:

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\ScriptEvents\RdshLoad]

On this registry hive, create a new String Value with any friendly name (for example “LoadScript”), and then right click the string Value and click modify.  In the ‘Value Data’ field provide the script execution path. Now to enable load balancing, update value data of the ‘String Value’ with one of the load script provided along with Horizon View agent . For example if you choose to pick CPU Load;

cscript.exe "C:\Program Files\VMware\VMware View\Agent\scripts\cpuutilisation.vbs”

Instead of leveraging existing scripts, you can also define your own script that measures specific load via Performance Monitor. The script’s return values should fall under 0 to 3, which would be mapped to corresponding load balancing status – I will explain this in detail at at the end.  Now restart the VMware Horizon Agent (or just reboot the Virtual Machine). You must ensure that both these configuration (the service and the script) are performed across all the VMs in the RDSH Farm. In case of an automated Farm, you may consider configuring this in its parent VM, prior to taking the snapshot.

Note: The name of the ‘string value’ can be anything but the ‘value data’ should be identical across all VMs in a Farm, by pointing to the same script. Also the key should contain only one ‘string value’ which will be picked for load balancing.

And that’s all you need to do as part of the configuration. The load balancing would be active automatically (approximately within 5 to 10 minutes).

Application Count Based New Session Placement

Certain greedy applications may not consume full resources while running without any content or data in it. For example, Auto CAD does not consume much CPU or MEMORY before you load a model. In such conditions, load balancing based on CPU/MEMORY utilization will not be so effective. Moreover, if the RDSH Agents are running inside Virtual Machines, then there is no way to control the number of instances of such greedy apps running per vSphere host. We can only control the number of RDSH VMs per vSphere host by taking appropriate administrative measures during deployment.

Therefore in order to control the number of instances of such greedy apps, VMware Horizon 6 version 6.2 introduces a mechanism through Pattern based app-counting. This mechanism counts the number of instances of an application per RDSH and provide a way to limit within a threshold; and then span the new connections within the Farm to maintain an acceptable application load in each RDSH Agent VM. This way, the Administrators can pre-allocate the capacity for specific greedy applications. However, setting this feature does not mean that Administrator can control the number of sessions, instead, it would be treated as a hint to the system.

Limiting the number of instances of an Application

Application count can be limited while creating or editing an application pool and is done via applying certain rules. To limit the number of app instances running on a server, Administrator must define an App Count policy on the Application Pool. This policy consists of  ‘One or more app-matching patterns, where each match represents one instance of the process‘ and a ‘maximum count‘. For example if you need to prevent more than two instance of Auto CAD per RDSH Agent, define following rule at AutoCAD Application pool level:

  • Pattern: “autocad.exe”
  • Count: 2

Pattern Definition: The Pattern string can consists one or more wild card characters like ‘Asterisk’ or ‘Question Mark’. For example ‘*’ character means zero or more characters. For example ‘notepad*’ would match notepad.exe, notpad.bat or just notepad. A ‘?’ character means one character. i.e. ‘notepad.?xe’ would match notpad.exe. In case of multiple patterns, it has to be in comma separated form.  If multiple patterns match for an application within a single terminal server session, then it will be could be counted as single match only.

Monitoring the Load Balancing Status

Once the Load Balancing setup is complete, as mentioned in the first section, it might take 5 to 10 minutes to reflect the corresponding results. This is because, the load values are being processed based on the realistic data measured from that point. Once the script configuration reflects in, then the values will be reported every 1 – 2 minutes (with async session notifications)

rds-lb
RDSH Health Status with Server Load

A Farm Dashboard will provide the basic health status of the Farm and each RDSH Agent VMs status. While expanding the Farm Dashboard’s inventory, you can check for individual RDSH Agent VM’s status and Server Load (Refer Figure). You can also monitor load-balancing status by referring the debug logs of the RDSH Agent VM, and searching  for a preference value named “LBPREFERENCE”. Once the load balancing is configured and active, and with little load on the RDSH Agent VM, all new sessions are allowed to it. Each RDSH Agent VM reports LBPREFERENCE value based on the exit code returned by the Load Script. The exit code represents the single digit output result of script, and based on this output, the preference value is updated in certain intervals.

In the above example, inside the RDSH Agent VM, the script for CPU load value has been executed with exit code = 3 and correspondingly the LBPREFERENCE has been updated to “HIGH” which means it can accept new connections.  As a reference, the log snip for corresponding state has given below:

DEBUG (0434-0510) <MessageFrameWorkDispatch> [ws_scripts] ScriptEventName 'RdshLoad', script 'LoadScript', starting cmdline 'cscript.exe "C:\Program Files\VMware\VMware View\Agent\scripts\cpuutilisation.vbs"'. DEBUG (0434-0F2C) <ScriptEventTimeoutThread> [ws_scripts] ScriptEventName 'RdshLoad', script 'LoadScript', exitCode=3.DEBUG (02B4-0154) <MessageFrameWorkShare> [wsnm_desktop] Using return code value of 3. DEBUG (02B4-0154) <MessageFrameWorkShare> [wsnm_desktop] New LBPREFERENCE value: HIGH

Below table explains the all possible return codes  along with its  corresponding preference value and load balancing action. Note that the default load value for any RDSH agent is set as ‘MED’

Return code Preference Health Dashboard Load Status
3 HIGH Light load, new sessions okay
2 MED Normal load, new sessions okay
1 LOW Heavy Load, new sessions avoided
0 BLOCK New sessions blocked

Restrictions and Implications of RDSH Load Balancing

  1. Rules for Limiting Application instances based on a Count value should be considered as a hint, as there is no 100% guarantee that instances of applications on an RDSH will be restricted to the configured number. Refer The Anti-Affinity rule constrains
    • There are scenarios and edge-cases where it is not possible to determine an exact instance count, especially if other applications for other pending sessions are in the process of being launched.
    • Also, ‘Inter App’ anti-affinity is not supported, i.e., where classes of applications are large. For example Auto CAD and Visual Studio instances counted in a single rule
  2. Anti-affinity support also depends on farm level multi-session support in Horizon Clients.
    • So it is mandatory requirement to upgrade the Horizon client to a version that support multiple sessions.
  3. Once an application session is created for a user on an RDSH, all subsequent applications for the user will be launched on that RDSH.
    • Load values on this RDSH will be ignored for existing user sessions. However an Anti-affinity rule could prevent a new application from being launched
  4. Multiple sessions for RDSH desktops is not supported. RDSH desktop users will always be reconnected to any existing session.
  5. RDSH load balancing is applicable only for new sessions.
  6. Applications will be launched on a RDSH where a user has a session which has run the application before. This is to ensure supporting client re-connection from mobile clients.
  7. Applications will be launched on an RDSH where a user already has an existing session, even of the RDSH reports a BLOCK load preference. However Anti Affinity rules may still prevent this.
  8. It will not be possible to restrict application launches from within a RDSH desktop session, even though a direct application launch may have been prevented by anti-affinity rules
  9. RDSH session limits will prevent applications sessions from being created regardless of reported load preference or anti-affinity rules
  10. The pre-packaged CPU utilization script uses rolling average data that is sampled every 5 minutes. This means that load preferences are updated every 5 minutes (approximately). So any short term high utilization events on the RDSH may not be reflected in returned load preferences
  11. Magnetic Sessions: RDSH containing sessions in which a user has previously run an application will always be reused for the same application. This will override load balancing and application counting
  12. The new session placement process enables the user to get application sessions from different RDSH hosts within the Farm. However, for this to work you should have a Horizon Client version that support multiple sessions.

 

Permalink to this article: https://incloudnet.com/?p=301