Autoscale

Autoscale is a feature exclusive to Citrix Virtual Apps and Desktops service that provides a consistent, high-performance solution to proactively power manage your machines. It aims to balance costs and user experience. Autoscale incorporates the deprecated Smart Scale technology into the Studio power management solution.

About Autoscale

Autoscale enables proactive power management of all registered Server and Desktop OS machines in a Delivery Group.

Supported VDA hosting platforms

Autoscale supports all the platforms that Virtual Apps and Desktops service supports. This includes a variety of infrastructure platforms including Citrix Hypervisor, Amazon Web Services, Google Cloud Platform, Microsoft Azure Resource Manager, VMware vSphere, and many more. For a complete list of supported platforms, see System requirements for Virtual Apps and Desktops service.

Supported workloads

Autoscale works with both Remote Desktop Service (RDS) and Virtual Desktop Infrastructure (VDI). There are three user interfaces to be aware of:

  • Autoscale user interface for RDS Delivery Groups

  • Autoscale user interface for pooled VDI Delivery Groups

  • Autoscale user interface for static VDI Delivery Groups

For more information about the user interfaces for different Delivery Groups, see Three types of Autoscale user interfaces.

Benefits

The Autoscale feature delivers the following benefits:

  • Provide you with a single, consistent mechanism to power manage machines in a Delivery Group.

  • Ensure availability and control costs by powering machines with load-based or schedule-based power management, or a combination of both.

  • To monitor metrics such as cost savings and capacity utilization, and to enable notifications, use Director, available on the Monitor tab.

Watch a 2-minute video

The following video provides a quick tour of Autoscale.

Video icon

Migration

Migration from Smart Scale to Autoscale is supported. Migrating includes exporting configuration data from Smart Scale and then importing it to Autoscale. For more information, see Smart Scale to Autoscale migration.

Three types of Autoscale user interfaces

There are three types of Autoscale user interfaces to be aware of. See below for details.

Autoscale user interface for RDS Delivery Groups:

Autoscale RDS UI

Autoscale user interface for pooled VDI Delivery Groups:

Autoscale pooled VDI UI

Autoscale user interface for static VDI Delivery Groups:

Autoscale static VDI UI

Enable or disable Autoscale for a Delivery Group

Note:

By default, Autoscale is enabled when you create a Delivery Group.

  1. On the Manage tab, select Delivery Groups in the Studio navigation pane.

  2. In the Actions pane, select the Delivery Group you want to manage and then click Edit Delivery Group.

  3. On the Autoscale page, select the Autoscale check box to enable Autoscale. After you enable Autoscale, the options on the page are enabled.

  4. To disable Autoscale, clear the Autoscale check box. The options on the page turn gray to indicate that Autoscale is disabled for the selected Delivery Group.

Important:

  • If you disable Autoscale, all machines managed by Autoscale will remain in the state they are in at the time of disabling.
  • After you disable Autoscale, the machines in drain state are taken out of drain state. For more information about drain state, see Drain state.

How Autoscale power manages machines

Autoscale powers machines on and off based on the selected schedule. Autoscale lets you set multiple schedules that include specific days of the week and adjust the number of machines available during those times. If you expect a set of users to consume the machine resources at a specific time on specific days, Autoscale helps provide an optimized experience. Note that those machines will be powered on during the schedule, irrespective of whether there are sessions running on them.

The schedule is based on the time zone of the Delivery Group. To change the time zone, you can change user settings in a Delivery Group. For more information, see Manage Delivery Groups.

By default, Autoscale has two schedules: Weekdays (Monday through Friday) and Weekend (Saturday and Sunday). Autoscale powers on a certain number of machines during weekdays (07:00 AM to 07:00 PM) and none on weekends. The number ranges from 1 (minimum) to 50 (maximum), depending on the configured capacity buffer and the number of machines in the Delivery Group. For more information about how many machines are powered on by default, see How capacity buffer works.

Note:

Autoscale treats only those machines that are registered with the Site as part of the available capacity in the calculations it makes. “Registered” means that the machine is available for use or already in use. Doing so ensures that only machines that can accept user sessions are included in the capacity for the Delivery Group.

Schedule-based settings

Autoscale schedule. Lets you add, edit, select, and delete schedules.

Days applied. Highlights the days you applied to the selected schedule. The remaining days are grayed out.

Edit. Lets you assign the machines against each hour. You can assign the machines by numbers and by percentages.

Note:

  • This option is available only in the Autoscale user interfaces for RDS and pooled VDI Delivery Groups.
  • The histogram next to Edit plots the number or percentage of machines that are running in different time slots.
  • You can assign machines against each time slot by clicking Edit above Peak times. Depending on the option you selected from the dropdown in the Machines to start window, you can assign the machines by numbers or by percentages.
  • For RDS Delivery Groups, you can set the minimum number of running machines separately for each half-hour of the day. For pooled VDI Delivery Groups, you can set the minimum number of running machines separately for each hour of the day.

To define your own schedules, follow the steps below.

  1. Select Edit schedules from the dropdown and then click Add schedule.

  2. In the Edit Autoscale Schedules window, select the days you want to apply to each schedule. You can also delete schedules where applicable.

  3. Click Apply to save the schedules and to return to the Autoscale page.

  4. Select the applicable schedule from the dropdown and set the applicable options for that schedule.

Important:

  • Autoscale does not allow the same day to overlap in different schedules. For example, if you select Monday in schedule2 after selecting Monday in schedule1, Monday is automatically cleared in schedule1.
  • A schedule name is not case sensitive.
  • A schedule name must not be blank or contain only spaces.
  • Autoscale allows blank spaces between characters.
  • A schedule name must not contain the following characters: \ / ; : # . * ? = < > | [ ] ( ) { } “ ‘ `.
  • Autoscale does not support duplicate schedule names. Enter a different name for each schedule.
  • Autoscale does not support empty schedules. This means that schedules without days selected are not saved.

Note:

On the Autoscale page, the days included in the selected schedule are highlighted, while those not included are grayed out.

Load-based settings

Peak times. Lets you define the peak times for the days you applied in the selected schedule. You can do so by right-clicking the horizontal bar graph. After you define the peak times, the remaining, undefined times default to off-peak times. By default, the 7:00 AM to 7:00 PM time slot is defined as peak times for the days included in the selected schedule.

Important:

  • For RDS Delivery Groups, the peak times bar graph is used for the capacity buffer.
  • For VDI Delivery Groups, the peak times bar graph is used for the capacity buffer and controls the actions to be triggered after logoff and/or disconnection.

Capacity buffer. Lets you keep a buffer of powered-on machines. A lesser value decreases the cost. A greater value ensures an optimized user experience so that when launching sessions, users do not have to wait for additional machines to power on. By default, the capacity buffer is 10% for peak and off-peak times. If you set the capacity buffer to 0 (zero), users might have to wait for additional machines to power on when launching sessions. Autoscale lets you determine the capacity buffer separately for peak and off-peak times.

Miscellaneous settings

When disconnected. Lets you specify how long a disconnected, locked machine remains powered on after session disconnection before it is suspended or shut down. If a time value is specified, the machine is suspended or shut down when the specified disconnection time is elapsed, depending on the actions you configured. By default, no action is assigned to disconnected machines. You can define options separately for peak and off-peak times. To do so, click the down arrow and then select one of the following options from the menu:

  • No action. If selected, the machine after session disconnection remains powered on and Autoscale does not act on it.
  • Suspend. If selected, Autoscale pauses the machine without shutting it down when the specified disconnection time is elapsed.
  • Shut down. If selected, Autoscale shuts down the machine when the specified disconnection time is elapsed.

Note:

This option is available only in the Autoscale user interfaces for pooled and static VDI Delivery Groups.

When logged off. Lets you specify how long a machine remains powered on after session logoff before it is suspended or shut down. If a time value is specified, the machine is suspended or shut down when the specified logoff time is elapsed, depending on the actions you configured. By default, no action is assigned to logged off machines. You can define options separately for peak and off-peak times. To do so, click the down arrow and then select one of the following options from the menu:

  • No action. If selected, the machine after session logoff remains powered on and Autoscale does not act on it.
  • Suspend. If selected, Autoscale pauses the machine without shutting it down when the specified logoff time is elapsed.
  • Shut down. If selected, Autoscale shuts down the machine when the specified logoff time is elapsed.

Note:

This option is available only in the Autoscale user interface for static VDI Delivery Groups.

Power-off delay. Lets you specify the minimum number of minutes that must elapse after a machine is powered on before Autoscale powers it off. Doing so keeps machines from “flip-flopping” on and off during volatile session demands. By default, the power-off delay is 30 minutes. You can set it in a range of 0–60 minutes.

Note:

This option is available only in the Autoscale user interface for RDS Delivery Groups.

Machine instance cost per hour. Lets you specify the machine instance cost per hour that matches with your cost basis. Machine instance cost per hour is the cost per hour, in US$, of the computing capacity being used. This setting is used to calculate the cost savings of the Autoscale settings above. To view the savings, go to Monitor > Trends > Machine Usage. For more information, see Monitor Autoscale-managed machines.

Note:

Autoscale does not support changing the currency unit for your cost basis.

How capacity buffer works

Capacity buffer is used to add spare capacity to the current demand to account for dynamic load increases. There are two scenarios to be aware of:

  • For RDS Delivery Groups, the capacity buffer is defined as a percentage of the total capacity of the Delivery Group in terms of load index. For more information about load index, see Load index.

  • For VDI Delivery Groups, the capacity buffer is defined as a percentage of the total capacity of the Delivery Group in terms of the number of machines.

Autoscale lets you set the capacity buffer separately for peak and off-peak times. A lesser value in the capacity buffer field decreases the cost because Autoscale powers on less spare capacity. A greater value ensures an optimized user experience so that users do not have to wait for additional machines to power on when launching sessions. By default, the capacity buffer is 10%. Note that Autoscale powers on 50 machines at most, irrespective of the configured capacity buffer and the number of machines in the Delivery Group.

Important:

The capacity buffer results in machines being powered on when the total spare capacity drops to a level below “X” percent of the total capacity of the Delivery Group. Doing so reserves the required percentage of spare capacity.

RDS Delivery Groups

When are machines powered on?

Important:

If a schedule is selected, Autoscale powers on all machines configured to be powered on in the schedule. Autoscale keeps this specified number of machines powered on during the schedule, irrespective of the load.

When the number of powered-on machines (including the capacity buffer) in the Delivery Group no longer meets the targeted demand in terms of load index, Autoscale powers on extra machines. This case might occur during peak times, increased load on machines, and new session launches, and when you add new machines to the Delivery Group. Note that Autoscale powers on only the machines that meet the following criteria:

  • The machines are not in maintenance mode.

  • The hypervisor on which the machines are running is not in maintenance mode.

  • The machines are currently powered off.

  • The machines have no pending power actions.

When are machines powered off?

Important:

  • If a schedule is selected, Autoscale powers off the machines based on the schedule.
  • Autoscale does not power off the machines configured in the schedule to be powered on during the schedule.

When there are more than enough machines to support the targeted number of powered-on machines (including the buffer) for the Delivery Group, Autoscale powers off extra machines. This case might occur during off-peak times, decreased load on machines, and session logoffs, and when you remove machines from the Delivery Group. Autoscale powers off only the machines that meet the following criteria:

  • The machines and the hypervisor on which the machines are running are not in maintenance mode.

  • The machines are currently powered on.

  • The machines are registered as available or waiting to register after start-up.

  • The machines have no active sessions.

  • The machines have no pending power actions.

  • The machines satisfy the specified power-off delay. This means that the machines have been powered on for at least “X” minutes, where “X” is the power-off delay specified for the Delivery Group.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The Delivery Group that you want Autoscale to power manage contains 10 machines (M1 to M10).

  • Autoscale configuration

    • Capacity buffer is set to 10%.
    • No machine is included in the selected schedule.

The scenario is executed in the following sequence:

  1. No user logs on.

  2. User sessions increase.

  3. More user sessions start.

  4. User session load decreases because of session termination.

  5. User session load decreases further until the session load is handled only by on-premises resources.

See below for details about how Autoscale works in the scenario above.

  • No user load (initial state)
    • One machine (for example, M1) is powered on. The machine is powered on because of the configured capacity buffer. In this case, 10 (number of machines) x 10,000 (load index) x 10% (configured capacity buffer) equals 10,000. Therefore, one machine is powered on.
    • The load index value of the powered-on machine (M1) is at a baseline load (load index equals 0).
  • The first user logs on
    • The session is directed to be hosted on machine M1.
    • The load index of the powered-on machine M1 increases and machine M1 is no longer at a baseline load.
    • Autoscale starts to power on an additional machine (M2) to meet the demand because of the configured capacity buffer.
    • The load index value of machine M2 is at a baseline load.
  • Users increase load
    • The sessions are load-balanced across machines M1 and M2. As a result, the load index of the powered-on machines (M1 and M2) increases.
    • The total spare capacity is still at a level above 10,000 in terms of load index.
    • The load index value of machine M2 is no longer at a baseline load.
  • More user sessions start
    • The sessions are load-balanced across machines (M1 and M2). As a result, the load index of the powered-on machines (M1 and M2) increases further.
    • When the total spare capacity drops to a level below 10,000 in terms of load index, Autoscale starts to power on an additional machine (M3) to meet the demand because of the configured capacity buffer.
    • The load index value of machine M3 is at a baseline load.
  • Even more user sessions start
    • The sessions are load-balanced across machines (M1 to M3). As a result, the load index of the powered-on machines (M1 to M3) increases.
    • The total spare capacity is at a level above 10,000 in terms of load index.
    • The load index value of machine M3 is no longer at a baseline load.
  • User session load decreases because of session termination
    • After users log off their sessions or idle sessions time out, the freed-up capacity on machines M1 to M3 is reused to host sessions started by other users.
    • When the total spare capacity increases to a level above 10,000 in terms of load index, Autoscale puts one of the machines (for example, M3) into drain state. As a result, sessions started by other users are no longer directed to that machine unless new changes occur; for example, end-user load increases again or other machines become least loaded.
  • User session load continues to decrease
    • After all sessions on machine M3 are terminated and the specified power-off delay times out, Autoscale powers off machine M3.
    • After more users terminate their sessions, the freed-up capacity on powered-on machines (M1 and M2) is reused to host sessions started by other users.
    • When the total spare capacity increases to a level above 10,000 in terms of load index, Autoscale puts one of the machines (for example, M2) into drain state. As a result, sessions started by other users are no longer directed to that machine.
  • User session load continues to decrease until there are no sessions
    • After all sessions on machine M2 are terminated and the specified power-off delay times out, Autoscale powers off machine M2.
    • The load index value of the powered-on machine (M1) is at a baseline load. Autoscale does not put machine M1 into drain state because of the configured capacity buffer.

Note:

For RDS Delivery Groups, all changes to the desktop are lost when users log off sessions. However, if configured, user-specific settings are roamed along with the user profile.

Pooled VDI Delivery Groups

Capacity buffer is used to accommodate sudden spikes in demand by keeping a buffer of machines powered on based on the total number of machines in the Delivery Group. By default, the capacity buffer is 10% of the total number of machines in the Delivery Group.

If the number of machines (including the capacity buffer) exceeds the total number of currently powered-on machines, additional machines are powered on to meet the demand. If the number of machines (including the capacity buffer) is less than the total number of currently powered-on machines, the excess machines are shut down or suspended, depending on the actions you configured.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The Delivery Group that you want Autoscale to power manage contains 10 machines (M1 to M10).
  • Autoscale configuration
    • Capacity buffer is set to 10%.
    • No machine is included in the selected schedule.

The scenario is executed in the following sequence:

  1. No user logs on.

  2. User sessions increase.

  3. More user sessions start.

  4. User session load decreases because of session termination.

  5. User session load decreases further until the session load is handled only by on-premises resources.

See below for details about how Autoscale works in the scenario above.

  • No user load (initial state)
    • One machine (M1) is powered on. The machine is powered on because of the configured capacity buffer. In this case, 10 (number of machines) x 10% (configured capacity buffer) equals 1. Therefore, one machine is powered on.
  • A first user logs on
    • The first time a user logs on to use a desktop, the user is assigned a desktop from a pool of desktops hosted on powered-on machines. In this case, the user is assigned a desktop from machine M1.
    • Autoscale starts to power on an additional machine (M2) to meet the demand because of the configured capacity buffer.
  • A second user logs on
    • The user is assigned a desktop from machine M2.
    • Autoscale starts to power on an additional machine (M3) to meet the demand because of the configured capacity buffer.
  • A third user logs on
    • The user is assigned a desktop from machine M3.
    • Autoscale starts to power on an additional machine (M4) to meet the demand because of the configured capacity buffer.
  • A user logs off
    • After a user logs off or the user’s desktop times out, the freed-up capacity (for example, M3) is available as buffer. As a result, Autoscale starts to power off machine M4 because the capacity buffer is configured as 10%.
  • More users log off until there are no users
    • After more users log off, Autoscale powers off machines (for example, M2 or M3).
    • Even though there are no users left, Autoscale does not power off the remaining one machine (for example, M1) because that machine is reserved as a spare capacity.

Note:

For pooled VDI Delivery Groups, all changes to the desktop are lost when users log off sessions. However, if configured, user-specific settings are roamed along with the user profile.

Static VDI Delivery Groups

Capacity buffer is used to accommodate sudden spikes in demand by keeping a buffer of unassigned machines powered on based on the total number of unassigned machines in the Delivery Group. By default, the capacity buffer is 10% of the total number of unassigned machines in the Delivery Group.

Important:

After all machines in the Delivery Group are assigned, the capacity buffer does not play a role in powering machines on or off.

If the number of machines (including the capacity buffer) exceeds the total number of currently powered-on machines, additional, unassigned machines are powered on to meet the demand. If the number of machines (including the capacity buffer) is less than the total number of currently powered-on machines, excess machines are powered off or suspended, depending on the actions you configured.

Example scenario

Suppose you have the following scenario:

  • Delivery Group configuration. The Delivery Group that you want Autoscale to power manage contains 10 machines (M1 to M10).
  • Autoscale configuration
    • Machines M1 to M3 are assigned, and machines M4 to M10 are unassigned.
    • Capacity buffer set to 10% for peak and off-peak times.
    • According to the selected schedule, Autoscale power manages machines between 09:00 AM and 06:00 PM.

See below for details about how Autoscale works in the scenario above.

  • Start of schedule – 09:00 AM
    • Autoscale powers on machines M1 to M3.
    • Autoscale powers on an additional machine (for example, M4) because of the configured capacity buffer. Machine M4 is unassigned.
  • A first user logs on
    • The first time a user logs on to use a desktop, the user is assigned a desktop from a pool of desktops hosted on unassigned powered-on machines. In this case, the user is assigned a desktop from machine M4. Subsequent logons from that user connect to the same desktop that was assigned on first use.
    • Autoscale starts to power on an additional machine (for example, M5) to meet the demand because of the configured capacity buffer.
  • A second user logs on
    • The user is assigned a desktop from the unassigned powered-on machines. In this case, the user is assigned a desktop from machine M5. Subsequent logons from that user connect to the same desktop that was assigned on first use.
    • Autoscale starts to power on an additional machine (for example, M6) to meet the demand because of the configured capacity buffer.
  • Users log off
    • As users log off their desktops or the desktops time out, Autoscale keeps the machines M1 to M5 powered on during 09:00 AM – 06:00 PM. When those users log on the next time, they connect to the same desktop that was assigned on first use.
    • The unassigned machine M6 is waiting to serve a desktop to an incoming, unassigned user.
  • End of schedule – 06:00 PM
    • At 06:00 PM, Autoscale powers off machines M1 to M5.
    • Autoscale keeps the unassigned machine M6 powered on because of the configured capacity buffer. That machine is waiting to serve a desktop to an incoming, unassigned user.
    • In the Delivery Group, machines M6 to M10 are unassigned machines.

Restrict Autoscale to certain machines in a Delivery Group

Autoscale provides the flexibility to power manage only a subset of machines in a Delivery Group. To achieve this, apply a tag to one or more machines and then configure Autoscale to power manage only tagged machines.

This feature can be useful in cloud bursting use cases, where you want to use on-premises resources to handle workloads before cloud-based resources address additional demand (that is, burst workloads). To let on-premises machines address workloads first, you must use tag restriction along with zone preference.

Tag restriction specifies machines to be power managed by Autoscale. Zone preference specifies machines in the preferred zone to handle user launch requests. For more information, see Tags and Zone preference.

How to restrict Autoscale to machines in a Delivery Group

There are two ways to restrict Autoscale to machines in a Delivery Group:

  • Using the PowerShell SDK directly
  • Using Studio along with the PowerShell SDK

To use the PowerShell SDK directly, complete the following steps:

  1. Create a tag. Use the New-Brokertag PowerShell command to create a tag.
  2. Apply the tag to machines. Use the Get-Brokermachine PowerShell command to apply the tag to machines in a catalog that you want Autoscale to power manage.

    Note:

    You might add new machines to the catalog after applying the tag. The tag is NOT automatically applied to those new machines.

  3. Add tagged machines to the Delivery Group that you want Autoscale to power manage. Use the Get-BrokerDesktopGroup PowerShell command to add a tag restriction to the Delivery Group that contains the machines (in other words, “restrict launches to machines with tag X”).

To use Studio along with the PowerShell SDK, complete the following steps:

  1. Create a tag. Use Studio to manually create a tag and to apply that tag to the applicable machines. For more information about how to use tags in Studio, see Tags.

  2. Fetch the tag. Open PowerShell and then enter the Get-BrokerTag PowerShell command. For example: $tag = Get-BrokerTag managed. In this case, the tag you want Autoscale to restrict to is named “managed.”

  3. Add tagged machines to the Delivery Group that you want Autoscale to power manage. In the PowerShell console window, enter the Get-BrokerDesktopGroup PowerShell command. For example: Get-BrokerDesktopGroup –Uid 1 | Set-BrokerDesktopGroup –RestrictAutoscaleTagUid $tag.Uid. In this case, the UID of the Delivery Group is 1.

How to remove a tag restriction in a Delivery Group

After you apply the tag restriction, you might want to remove it from the Delivery Group later. To do so, use the Get-BrokerDesktopGroup PowerShell command.

Example: Get-BrokerDesktopGroup –Uid 1 | Set-BrokerDesktopGroup –RestrictAutoscaleTagUid $null. In this case, the UID of the Delivery Group is 1.

Example scenario

Suppose you have the following scenario:

  • Machine catalog configuration. There are two machine catalogs (C1 and C2).
    • Catalog C1 contains 5 machines (M1 to M5) that are local in the on-premises deployments.
    • Catalog C2 contains 5 machines (M6 to M10) that are remote in the cloud deployments.
  • Tag restriction. A tag named “Cloud” is created and applied to machines M6 to M10 in catalog C2.

  • Zone configuration. Two zones (Z1 and Z2) are created.
    • Zone Z1 containing catalog C1 corresponds to the on-premises deployments.
    • Zone Z2 containing catalog C2 corresponds to the cloud deployments.
  • Delivery Group configuration
    • The Delivery Group contains 10 machines (M1 to M10), 5 machines from catalogs C1 (M1 to M5) and 5 from catalog C2 (M6 to M10).
    • Machines M1 to M5 are powered on manually and remain powered on throughout the schedule.
  • Autoscale configuration
    • Capacity buffer is set to 10%.
    • Autoscale power manages only machines with the tag “Cloud.” In this case, Autoscale power manages cloud machines M6 to M10.
  • Published application or desktop configuration. Zone preferences are configured for the published desktops (for example), where Zone Z1 is preferred over Zone Z2 for a user launch request.
    • Zone Z1 is configured as the preferred zone (home zone) for the published desktops.

The scenario is executed in the following sequence:

  1. No user logs on.
  2. User sessions increase.
  3. User sessions increase further until all available on-premises machines are consumed.
  4. More user sessions start.
  5. User session decreases because of session termination.
  6. User session decreases further until the session load is handled only by on-premises machines.

See below for details about how Autoscale works in the scenario above.

  • No user load (initial state)
    • The on-premises machines M1 to M5 are all powered on.
    • One machine in the cloud (for example, M6) is powered on. The machine is powered on because of the configured capacity buffer. In this case, 10 (number of machines) x 10,000 (load index) x 10% (configured capacity buffer) equals 10,000. Therefore, one machine is powered on.
    • The load index value of all the powered-on machines (M1 to M6) is at a baseline load (load index equals 0).
  • Users log on
    • The sessions are directed to be hosted on machines M1 to M5 through the configured zone preference and are load-balanced across these on-premises machines.
    • The load index value of the powered-on machines (M1 to M5) increases.
    • The load index value of the powered-on machine M6 is at a baseline load.
  • Users increase load, consuming all on-premises resources
    • The sessions are directed to be hosted on machine M1 to M5 through the configured zone preference and are load-balanced across these on-premises machines.
    • The load index value of all the powered-on machines (M1 to M5) has reached 10,000.
    • The load index value of the powered-on machine M6 remains at a baseline load.
  • One more user logs on
    • The session overflows the zone preference and is directed to be hosted on cloud machine M6.
    • The load index value of all the powered-on machines (M1 to M5) has reached 10,000.
    • The load index value of the powered-on machine M6 increases, but the total spare capacity is still at a level above 10,000 in terms of load index.
  • More users log on
    • The sessions are directed to be hosted on machine M6.
    • The load index value of all the powered-on machines (M1 to M5) has reached 10,000.
    • The load index value of the powered-on machine M6 increases. When the total spare capacity drops to a level below 10,000 in terms of load index, Autoscale starts to power on an additional machine (M7) to meet the demand because of the configured capacity buffer. Note that it might take some time to power on machine M7. So there might be a delay until machine M7 is ready.
    • The load index value of the powered-on machine M7 remains at a baseline load.
  • Even more users log on
    • After machine M7 is ready, the sessions are directed to be hosted on machines M6 and M7 and are load-balanced across these machines.
    • The load index value of all the powered-on machines (M1 to M5) has reached 10,000.
    • The load index value of machine M7 is no longer at a baseline load.
    • The load index value of the powered-on machines (M6 and M7) increases.
    • The total spare capacity is at a level above 10,000 in terms of load index.
  • User session load decreases because of session termination
    • After users log off their sessions or idle sessions time out, the freed-up capacity on machines M1 to M7 is reused to host sessions started by other users.
    • When the total spare capacity increases to a level above 10,000 in terms of load index, Autoscale puts one of the cloud machines (M6 to M7) into drain state. As a result, sessions started by other users are no longer directed to that machine (for example, M7) unless new changes occur; for example, user load increases again or other cloud machines become least loaded.
  • User session load decreases further until one or more cloud machines are no longer needed
    • After all sessions on machine M7 are terminated and the specified power-off delay times out, Autoscale powers off machine M7.
    • The load index value of all the powered-on machines (M1 to M5) might drop to a level below 10,000.
    • The load index value of the powered-on machine (M6) decreases.
  • User session decreases further until no cloud machines are needed.
    • Even though there are no user sessions on machine M6, Autoscale does not power off it because it is reserved as a spare capacity.
    • Autoscale keeps the remaining cloud machine M6 powered on because of the configured capacity buffer. That machine is waiting to serve a desktop to an incoming user.
    • Sessions are not directed to be hosted on machine M6 as long as the on-premises machines have available capacity.

Monitoring metrics

You can monitor the following metrics of Autoscale-managed machines from the Monitor tab.

  • Machine usage

  • Estimated savings

  • Alert notifications for machines and sessions

  • Machine status

  • Load evaluation trends

For more information about the metrics, see Monitor Autoscale-managed machines.

Broker PowerShell SDK commands

You can configure Autoscale for Delivery Groups using the Broker PowerShell SDK. To configure Autoscale using PowerShell commands, you must use Remote PowerShell SDK version 7.21.0.12 or later. For more information about the Remote PowerShell SDK, see SDKs and APIs.

Set-BrokerDesktopGroup

Disables or enables an existing BrokerDesktopGroup or alters its settings. For more information about this cmdlet, see https://citrix.github.io/delivery-controller-sdk/Broker/Set-BrokerDesktopGroup/.

New-BrokerPowerTimeScheme

Creates a new BrokerPowerTimeScheme for a Delivery Group. For more information about this cmdlet, see https://citrix.github.io/delivery-controller-sdk/Broker/New-BrokerPowerTimeScheme/.

Examples

See the following examples for details about how to use the PowerShell cmdlets.

Enable Autoscale

  • Suppose you want to enable Autoscale for the Delivery Group whose name is “MyDesktop.” Use the Set-BrokerDesktopGroup PowerShell command. For example:
    • C:\PS> Set-BrokerDesktopGroup "MyDesktop" -AutoscalingEnabled $true

Configure the capacity buffer separately for peak and off-peak times

  • Suppose you want to set the capacity buffer to 20% for peak times and 10% for off-peak times for a Delivery Group whose name is “MyDesktop.” Use the Set-BrokerDesktopGroup PowerShell command. For example:
    • C:\PS> Set-BrokerDesktopGroup "MyDesktop" -PeakBufferSizePercent 20-OffPeakBufferSizePercent 10

Configure the machine instance cost

  • Suppose you want to set the machine instance cost per hour to 0.2 dollars for a Delivery Group whose name is “MyDesktop.” Use the Set-BrokerDesktopGroup PowerShell command. For example:
    • C:\PS> Set-BrokerDesktopGroup "MyDesktop" -MachineCost 0.2

Configure power-off delay

  • Suppose you want to set the power-off delay to 15 minutes for a Delivery Group whose name is “MyDesktop.” Use the Set-BrokerDesktopGroup PowerShell command. For example:
    • C:\PS> Set-BrokerDesktopGroup "MyDesktop" -PowerOffDelay 15

Create a power time scheme

  • Suppose you want to create a new power time scheme for a Delivery Group whose UID value is 3. The new scheme covers weekend, Monday, and Tuesday. The 8:00 AM to 6:30 PM time slot is defined as peak times for the days included in the scheme. For peak times, the pool size (the number of machines kept powered on) is 20. For off-peak times, it is 5. You can use the Set-BrokerDesktopGroup PowerShell command. For example:
    • C:\PS> $ps48=(0..47 | %{ if ($_ -lt 16 -or $_ -gt 37) { 5 } else { 20 } } )
    • C:\PS> $pt48=(0..47 | %{ if ($_ -lt 16 -or $_ -gt 37) { $false } else { $true } } )
    • C:\PS> New-BrokerPowerTimeScheme -Name 'First Half Week' -DaysOfWeek Weekend,Monday,Tuesday -DesktopGroupUid 3 -PeakHalfHours $pt48 -PoolSize $ps48

Autoscale API

The Autoscale API provides a set of REST APIs that you can use to configure Autoscale. For more information about the complete set of available APIs for Autoscale, see Citrix Cloud APIs.

Good to know

Autoscale works at a Delivery Group level. It is configured on a per-Delivery Group basis. It power manages only the machines in the selected Delivery Group.

Drain state

Autoscale always attempts to scale down the number of powered-on machines in the Delivery Group to the configured pool size and capacity buffer. It does so by putting the excess machines with the fewest sessions into “drain state” and powering them off when all sessions are logged off. This occurs when session demand lessens and the schedule requires fewer machines than are powered on.

Autoscale puts excess machines into “drain state” one by one. If two or more machines have the same number of active sessions, Autoscale drains the machine that has been powered on for the specified power-off delay. Doing so avoids putting recently powered-on machines into drain state because those machines are more likely to have the fewest sessions. If two or more machines have been powered on for the specified power-off delay, Autoscale drains those machines one by one at random.

Machines in drain state no longer host new session launches and are waiting for the existing sessions to be logged off. A machine becomes a candidate for shutdown only when all sessions are logged off. However, if there are no machines immediately available for session launches, Autoscale prefers directing the session launches to a machine in drain state over powering on a machine.

A machine is taken out of drain state when one of the following conditions is met:

  • The machine is powered off.
  • Autoscale is disabled for the Delivery Group to which the machine belongs.
  • Autoscale utilizes the machine to meet schedule or load demand requirements. This case occurs when the schedule (schedule-based scaling) or the current demand (load-based scaling) requires more machines than are currently powered on.

Important:

If no machines are immediately available for session launches, Autoscale prefers directing session launches to a machine in drain state over powering on a machine. A machine in drain state that hosts a session launch remains in drain state.

To find out which machines are in drain state, use the Get-BrokerMachine PowerShell command. For example: Get-BrokerMachine -DrainingUntilShutdown $true.

Load index

Important:

Load index does not apply to VDI Delivery Groups. It applies only to RDS Delivery Groups.

The load index value ranges from 0 to 10,000, which is calculated using the Citrix Load Management policy settings configured for concurrent logon, session, CPU, disk, and memory use. The digit “0” indicates a completely unloaded machine. A machine with a load index value of 0 is at a baseline load. The digit “10,000” indicates a fully loaded machine that cannot run any more sessions. The load index metric determines how likely a machine is to receive connections. By default, a machine is considered at full load when it is hosting 250 sessions.

Capacity and machine registration

To ensure that Autoscale has an accurate view of machines that can accept session requests, Autoscale includes only machines that are registered with the Site when determining the capacity for a given Delivery Group. Powered-on machines that are unregistered cannot accept session requests. As a result, they are not included in the overall capacity of the Delivery Group.

Scaling across multiple Machine Catalogs

In some Sites, multiple machine catalogs might be associated with a single Delivery Group. Autoscale randomly powers on machines from each catalog to meet schedule or session demand requirements.

For example, a Delivery Group has two machine catalogs: Catalog A has three machines powered on and Catalog B has one machine powered on. If Autoscale needs to power on an additional machine, it might power on a machine from either Catalog A or Catalog B.

Machine provisioning and session demand

The Machine Catalog associated with the Delivery Group must have enough machines to power on and off as demand increases and decreases. If session demand exceeds the total number of registered machines in the Delivery Group, Autoscale only ensures that all registered machines are powered on. Autoscale does not provision additional machines.

Availability of monitoring data

Monitoring data is available when Autoscale is enabled for the Delivery Group. Monitoring data continues to be available when Autoscale is enabled and then disabled for the Delivery Group. Autoscale collects monitoring data at 5-minute intervals.

Note:

When you initially enable Autoscale for a Delivery Group, it might take a few minutes to display monitoring data for that Delivery Group.

Instance size considerations

You can optimize your costs if you right size your instances in public clouds. Smaller instances host fewer user sessions than larger instances. Therefore, in the case of smaller instances, Autoscale puts machines into drain state much faster because it takes less time for the last user session to be logged off. As a result, Autoscale powers off smaller instances sooner, thereby reducing costs. Citrix recommends that you provision smaller instances as long as they match your workload performance and capacity requirements.