Applies to: Nerdio Manager for MSP (NMM)
Auto-scale in NMM allows host pools to grow as necessary to serve current demand, then shrink again when additional capacity is no longer needed. For example, if a company has 300 virtual desktop users online during business hours, and only 50 users online during off-hours, the host pool serving those users can be configured to have more VMs powered on during business hours, and then shut down those VMs after hours when they're not needed. This allows businesses to save money while meeting demand seamlessly.
After creating a host pool, you will be presented with the option to configure Auto-scale settings for that host pool. Alternately, you can configure Auto-scale by navigating to an account's AVD->Host Pools section, and using the drop-down menu next to the host pool to select Auto-scale->Configure
Auto-scale settings will differ somewhat based on the Desktop Experience of the host pool. In this guide, we will be working with Auto-scale settings for a common type of host pool, Multi-user Shared Desktop
Host Pool Settings
At the top of the Auto-scale configuration page are settings that apply to the host pool generally, including its image, VM size, etc.
AUTO-SCALE: On the right side of the screen, you will see the toggle switch to enable Auto-scale. Turn this to On.
NAME PREFIX: Name prefix to be used when creating multiple session hosts. Name prefix limit is 10 valid, Windows computer name characters. When using a prefix, the system will automatically append “-xxxx” (with four random characters) to the name prefix to make a unique name.
DESKTOP IMAGE (TEMPLATE): The image that the host VMs will be cloned from.
VM SIZE (TEMPLATE): VM size of newly created session hosts.
OS DISK (TEMPLATE): OS Disk type and size of newly created session hosts. Must be equal to or larger than the size of the Desktop Image selected above.
RESOURCE GROUP: Resource group that the host VMs will be placed in.
Re-use host names: NMM will re-use names of previously destroyed hosts when creating new hosts.
Note that changes to these settings will only apply to host VMs created after the changes. You can force a host to be resized/re-imaged to apply the new settings.
Host Pool Sizing
This section determines how many hosts will be available for the host pool.
Active host defined as: When set to “VM Running”, the system will identify a session host VM as “active” as long as the VM is running in Azure. When set to “AVD agent Available”, the system will identify a session host VM as “active” only when AVD back-end is receiving heartbeats and sees the session host as “Available”.
Base host pool capacity: The number of session host VMs that will be provisioned for this host pool. These session hosts may be stopped or running.
Min active host capacity: Minimum number of running session hosts to be available at all times. The system will ensure that at least this many hosts are always running. When this value is set to 0, the system may stop all running hosts if they meet the scale-in criteria as defined in the next section.
Burst beyond base capacity: The system will automatically create up to this number of new session host VMs above the “host pool capacity”, when needed. These session hosts will be the first ones to be removed when system scales in after business hours, and will be destroyed rather than powered-off.
This section specifies the criteria used to determine when additional hosts will be powered on or created to service user login demand.
Select autoscale trigger: The metric that will be used to trigger scale-out/scale-in. There are four possible triggers: CPU usage, RAM usage, Average active sessions, Spare (available) desktop, Available sessions, and User-driven
CPU usage will scale out when the average CPU usage across all session hosts in the pool exceeds a pre-defined value for a pre-defined duration as shown below:
RAM usage will scale out when the average RAM usage across all session hosts in the pool exceeds a pre-defined value for a pre-defined duration as shown below:
Average active session will scale out when the average number of active sessions exceeds a predefined value (say X) and will scale in when the average number of active sessions exceeds a predefined value (say Y).
Available sessions will maintain the number of available sessions by scaling out and scaling in within the limits of Host Pool Sizing and the maximum number of sessions per host. The system will automatically calculate the available session desktop capacity and try to maintain up to the number of spare desktops specified. It is possible for the maximum number of desktop sessions to be constrained by the Host Pool Sizing parameters, which take precedence.
User-driven will scale out the host pool whenever a new user logs into the assigned session host. The host pool automatically scales in after a predefined amount of time, once all the users log off. You can configure the following settings:
- When all users log off, scale in hosts after X mins: Desktops will only be automatically stopped when there are no active or disconnected sessions. To automatically log off disconnected users after a certain time, use user session limits settings on host pool properties.
- Session limit per host: Specify the maximum number of sessions per host. Once this session limit is reached and there are no more available hosts, a new host will be started automatically, if it exists.
- Load balancing (LB): Breadth first LB algorithm spreads users evenly across available session hosts.
Depth-first LB algorithm places users on a single host until the session limit is reached at which point users start being placed on the next host until the session limit is reached again
- Burst hosts when available sessions are below a certain value: When burst capacity is specified, a new host will be automatically added (up to maximum burst capacity hosts) when the number of available sessions falls below the specified value. The default value =1.
Scale in restrictions:
Stop or remove (scale in) hosts only from: This setting restricts the time of day during which removing host VMs is allowed. For minimal disruption during scale-in events, set this to be after most users are done working for the day.
Scale in aggressiveness: Determines whether hosts with active or disconnected sessions will be targets for scale-in.
Scale in burst host selection: Determines which hosts to select for scaling in. When you select scale-in aggressiveness as HIGH, you need to select the type of "Scale in burst host selection" from the drop down:
- Host with fewest active sessions: When you select this option, auto-scale logic selects hosts without any sessions to scale-in first followed by hosts with the least number of active sessions. Select this option to minimize user impact.
- Oldest host: When you select this option, auto-scale logic selects hosts to scale-in based on the date they were created. Oldest hosts will be scaled in first, regardless of active user sessions.
This section allows you to specify times at which the determined number of hosts will be available to serve user logins. This allows you to ensure that hosts will be available to serve the anticipated user demand at the start of the work day. Use the slider at the right to enable the pre-stage behavior.
Use the other fields to specify which days are considered work days, what time of day the hosts should be available, and the number of hosts to enable at that time. The scale-in delay setting helps you restrict scaling in operations after the start of work hours. No session hosts will be removed from the duration between the start of work hours till the scale-in delay interval (i.e from 8am to 9am in the above example). NMM allows scale-in delay of 2.5 hours, 3 hours, 3.5 hours and 4 hours in addition to standard 15 min, 30 min, 45 min, 1 hour, 2 hours options:
You may also select multiple pre-stage schedules as per your business needs:
This section determines the message that end users will see if the host they're connected to has been selected for scale-in. The user will need to log out and log back in, at which point they will be assigned to another host not targeted for scale-in.
Auto-Heal Broken Hosts
This section determines which actions NMM will take to repair hosts that are not responding properly. The statuses are reported by the Azure AVD agent.
Use the setting to specify how many times NMM should try restarting the VMs, how long to wait between retries, and whether NMM will then remove and re-create hosts that are still not reporting healthy status to Azure.