Windows Virtual Desktop (WVD) offers two flavours of Load balancing known as Breadth-First and Depth-First. In this article I cover both methods. Please note that load balancing is assigned and configured per Host pool, If you operate multiple host pools, you would need to deploy the load balancing configuration to each host pool required. This article provides an overview on how dynamic scaling works and the peak and off peak script behavior including parameters.
Breadth-first load-balancing method
The breadth-first load-balancing mechanism is essentially a method which uses an algorithm to determine the least number of sessions on a session host for placement of new sessions. For example, a user connects to a Windows Virtual Desktop (WVD) Host pool with Breadth-first configured. During the login process, a query is run against the available session hosts within the host pool. The load balancing method selects the session host with the least number of sessions. If there are two or more session hosts with the same number of sessions active, then the method selects the first session host identified in the query. The diagram below depicts this.
Powershell Cmdlet to configure Breadth-first per host pool:
Set-RdsHostPool <tenantname> <hostpoolname> -BreadthFirstLoadBalancer -MaxSessionLimit ###
Depth-first load-balancing method
The depth-first load-balancing method maximises session utilisation of a session host before loading sessions on to the next available session host. It is suggested that this algorithm is for organisations who want to operate an active/passive WVD Deployment or to reduce costs. The depth-first method queries the available session hosts to establish where to place new sessions. if a session host has exceeded the maximum session limit specified against the host pool, new sessions will be loaded on to the next available session host. Again if there are two session hosts with the same number of sessions, then the first is selected in the query. This process is depicted in the diagram below. Using Depth-first load balancing in conjunction with dynamic scale enables you power on session hosts when a session host reaches near session capacity thus enabling cost management based on actual utilisation of compute resource. Meaning additional Session hosts are powered on when needed and powered off outside peak times. Dynamic Scale is detailed below in the next section.
Powershell Cmdlet to configure Depth-first per host pool:
Set-RdsHostPool <tenantname> <hostpoolname> -DepthFirstLoadBalancer -MaxSessionLimit ###
Windows Virtual Desktop offers the ability to scale up and down session hosts on demand using scaling scripts. This offers the ability to manage WVD user demand during the specified peak and off peak business times. Microsoft provides an out of the box ready to go solution known as Dynamic Scale. This does not mean you should not create your own or adapt the provided script to your liking.
Overview of how Dynamic Scaling works:
During peak times:
The script will check the current number of active sessions and the remaining capacity (CPU (users per core). The script essentially calculates capacity of powered on active session hosts to assess if there is enough capacity to support existing sessions based on the (SessionThresholdPerCPU) parameter in the config json file. If there is not enougth capacity, then the script will start additional session host Virtual Machines within the Host pool. Please note (state the obvious) you will need to have powered off session hosts available to power-on additional compute resource.
Off Peak times:
The script will check which session hosts should be shutdown/deallocated based on the parameter (MiniumNumberOfRDSH) in the Json config file. The script will set the chosen session host(s) to drain mode to prevent new sessions connecting to the hosts flagged to be powered down. You can also configure the Parameter (LimitSecondsToForceLogOffUser). This will notify current signed on users on the drainhost session hosts via a message to save work etc. Once the time value is reached for example “120” seconds, all users will be force signed out of the flagged session hosts. Once all users are off the flagged session host(s), the script will then shutdown the Azure Virtual Machine(s) aka Session host(s). Point to note: if you set (LimitSecondsToForceLogOffUser) to (0), the script will maintain the session configuration setting in the host pool properties to handle signing off user sessions.
Important note: at the time of writing, Dynamic Scale consists of three files that need to be run on a Windows Virtual machine. The script should be run using the task Scheduler. The script can be run as many times as you like however the recommended time intervals is every 5-15 minutes dependent on the user behaviour within the organisation.
Configuration file parameters:
The following table details the parameters to be configured in the config json file.
|AADTenantId||Azure AD Tenant ID that associates the subscription where the session host VMs run|
|AADApplicationId||Service principal application ID|
|AADServicePrincipalSecret||This can be entered during the testing phase but is to be kept empty once you create credentials with Functions-PSStoredCredentials.ps1|
|currentAzureSubscriptionId||The ID of the Azure subscription where the session host VMs run|
|tenantName||Windows Virtual Desktop tenant name|
|hostPoolName||Windows Virtual Desktop host pool name|
|RDBroker||URL to the WVD service, default value https://rdbroker.wvd.microsoft.com|
|Username||The service principal application ID (it’s possible to have the same service principal as in AADApplicationId) or standard user without multi-factor authentication|
|isServicePrincipal||Accepted values are true or false. Indicates whether the second set of credentials being used is a service principal or a standard account.|
|BeginPeakTime||When peak usage time begins|
|EndPeakTime||When peak usage time ends|
|TimeDifferenceInHours||Time difference between local time and UTC, in hours|
|SessionThresholdPerCPU||Maximum number of sessions per CPU threshold used to determine when a new session host VM needs to be started during peak hours.|
|MinimumNumberOfRDSH||Minimum number of host pool VMs to keep running during off-peak usage time|
|LimitSecondsToForceLogOffUser||Number of seconds to wait before forcing users to sign out. If set to 0, users aren’t forced to sign out.|
|LogOffMessageTitle||Title of the message sent to a user before they’re forced to sign out|
|LogOffMessageBody||Body of the warning message sent to users before they’re signed out. For example, “This machine will shut down in X minutes. Please save your work and sign out.”|
Windows Virtual Desktop offers organisations two methods of load balancing catering for high availability and maximum utilisation of compute resource in Windows Azure. The ability to manage cost and control the allocation of user sessions is a great out of the box offering and is simple, removing the complexity of traditional load balancing technologies. This does not mean to say that third party load balancing integrations in the future should not be welcome or considered as it is suggested that there is a lot of potential for hybrid and the benefit of leveraging the global market’s wider range of load balancing algorithms for the more complex larger organisational deployments. Dynamic Scaling is a simple function which is a little clunky as it needs to be run on a Windows operating system using the task scheduler. However that’s not an issue if you are running a RDSH licensing server or have a Active Directory server in Azure. The ability to manage and control user demand in both on and off peak business hours is encouraging and allows organisations to meet business demand using basic automation. That being said, there is nothing stopping you adapting the Dynamic scaling script and adding further enhancements if the out of the box offering does not meet your requirement.