Overview

In a CAS deployment, itopia offers the Dynamic Uptime feature that will automatically start and stop Session Hosts instances based on the number of active users in the Collection Pool. By only keeping the required number of Session Host servers active, Dynamic Uptime helps reduce GCP compute costs for the Session Host VM instances.

Dynamic Uptime can be enabled and configured for the following Collection Pool types:

• RDS - Shared Collection Pool
• RDS - Dedicated Collection Pool
• Windows 10 - Pooled Collection
• Windows 10 - Dedicated Collection

The behavior of Dynamic Uptime is different depending on the Collection Pool type: RDS - Shared Collection Pools leverage Dynamic Uptime Type I, and all remaining Collection Pools leverage Dynamic Uptime Type II.

The following sections and examples will describe each of these features in action.

Dynamic Uptime Type I

Dynamic Uptime Type I is used for Collection Pools that leverage Microsoft Remote Desktop Services (RDS) to support multiple concurrent users on each Session Host. In itopia CAS, this scenario is provided by the RDS Shared Collection Pool type.

Dynamic Uptime Type I relies on two user-defined values to perform its functions:

• The users per host (UPH) threshold defined in the Autoscale settings. This value defines the maximum number of active users that can be simultaneously connected to a single RD Session Host server. This setting applies only to RDS - Shared Collection Pools.
• The excluded servers per region (ESR) defines the number of Session Host VMs in each region of the Collection Pool that will not participate in Dynamic Uptime operations. That is, the number of RD Session Host servers that will always remain powered on (unless they are scheduled to be shut down using the Scheduled Uptime feature; more information on the behavior of these two features is provided below).

The EHR setting specifies the number of servers that are powered on in addition to the number of VMs that are required for Dynamic Uptime. For example, if a Collection Pool is configured with a ESR value of 2, this means that:

• The Collection Pool will have 2 Session Host VMs running at all times, even when there are no active users logged in
• As soon as the first user logs in to the environment, a Dynamic Uptime event starts a new Session Host VM, for a total of 3 hosts
• When the (UPH + 1) user logs in, a Dynamic Uptime event starts the next Session Host VM

In other words, Dynamic Uptime will calculate the number of Session Hosts needed for the active user count without including the capacity of the ESR hosts. This can be represented using the following basic formula:

It is important to note that the VM that remain powered on for ESR are not specific Session Hosts. Any Session Host may remain powered on to satisfy the ESR threshold, and any Session Host VM may be powered off if it has no active users and there are enough VMs to satisfy the ESR threshold.

Dynamic Uptime Type II

Dynamic Uptime Type II is used for Collection Pools that support a single concurrent user on each Session Host. In itopia CAS, this scenario is provided by the RDS Dedicated, Windows 10 Pooled, and Windows 10 Dedicated Collection Pool types.

Because Dynamic Uptime Type II is intended only for single-session Session Hosts, the service does not account for the number of active users on a Session Host; therefore, the users per host (UPH) threshold is always 1.

For Windows 10 Pooled Collections, administrators can still set an excluded hosts value; this value specifies the minimum number of Windows 10 Session Hosts that will always remain powered on and immediately available for new user connections. For RDS Dedicated and Windows 10 Dedicated Collection Pools, this setting does not apply because users can only connect to their assigned Session Host and, therefore, it is not beneficial to keep unused Session Hosts powered on.

Dynamic Uptime Type II primarily monitors user logoff from Session Hosts; when a user logs off a single-session Session Host, CAS schedules the host for shutdown within the next five minutes.

Dynamic Uptime Type II works in conjunction with the itopia Cloud VDI Portal; when users prepare to access their remote desktop, the Cloud VDI Portal will automatically power on their Session Host (if it is powered off) before allowing them to connect. This behavior is slightly different depending on the type of Collection Pool:

• Windows 10 Pooled Collections will ensure that the Collection Pool has at least one available host before allowing the user to connect. An available host is a Session Host VM that is powered on and unassigned to any user. Depending on the capacity of the Collection Pool and the number of simultaneous users logging on, the user may experience a slight delay before being able to connect to their remote desktop.
• Windows 10 Dedicated and RDS Dedicated Collections will wait until the user attempts to connect to their Session Host from within the portal. When the user initiates the connection, CAS will power on their assigned Session Host before allowing the user to connect with their RDP client. Users may experience a delay while their dedicated Session Host is powered on; the length of this delay can be between 30 seconds and several minutes and depends on several factors, including the OS image used for the Session Host and startup scripts or GPOs configured for the user.

NOTE: It is important that users access their remote desktops using the itopia Cloud VDI Portal each time they log in. For dedicated Collection Pool types, the Cloud VDI Portal ensures that users' Session Hosts are powered on before the user connects; for shared/pooled Collection types, the Cloud VDI Portal ensures that each user is assigned to an unused Session Host when they connect. More information on the itopia Cloud VDI Portal is available in the following article: Connection Options for CAS Deployments.

DynamicUptime Service

For both types of Dynamic Uptime, when a Collection Pool is configured to use the CAS Dynamic Uptime feature, the DynamicUptime agent is installed on each Session Host as a Windows service. This service polls the local Session Host every 60 seconds to determine the number of active (i.e. logged-on and connected) user sessions.

If it is the first time the agent has polled the server after a reboot, the number of active users is reported to the itopia CAS backend via TCP/443. On subsequent pollings, the agent will only report to the CAS backend if the number of active sessions has changed. If the number of active user sessions remains unchanged, the agent records the number locally for the next comparison.

For each Collection Pool, the CAS backend executes a function every five minutes that uses the most recent active user count to calculate the number of required servers ( [Active Users / Users Per Host Setting] + Excluded Server Count ). It compares this with the number of active servers (i.e., powered on and accepting new connections) and performs the following:

• If additional Session Host capacity is required, CAS searches for hosts that are powered on but not accepting new connections (i.e. they are draining in anticipation of a shutdown). If a draining host is available, the drain is canceled and the host is permitted to accept new connections, making it an active host; if no draining hosts are found, CAS powers on a stopped host.
• If there is excess host capacity, CAS attempts to find a host with no active users (i.e. an idle host). If an idle host is available, it is powered off and becomes a stopped host; if no idle hosts are found, CAS picks an active host and configures it to prevent new user logons,  which makes it a draining host in anticipation of a shutdown.

Example Scenarios

The following scenarios will help illustrate Dynamic Uptime Type I in action. Note that Dynamic Uptime Type II has a direct 1:1 relation between active user sessions and powered-on Session Hosts; this mechanism does not have any examples to illustrate its behavior.

Dynamic Uptime Type I - Start of Work Day and End of Work Day

In this scenario, consider the following configuration for a Collection Pool at Company X:

• 90 users are assigned to an RDS Shared Collection Pool
• Dynamic Uptime is enabled
• The Users per Host (UPH) threshold is set to 10
• The Excluded Servers per Region (ESR) is set to 2

Company X offers flexible scheduling: users can work an eight-hour day from 7AM until 3PM, 8AM until 4PM, or 9AM until 5PM. Employees at Company X use the flexible scheduling fairly evenly, with about 1/3 of users in each schedule. Thus, the number of Session Hosts for Company X would resemble the following:

At the end of the day, users begin logging out of their sessions, and the process works in reverse:

In this scenario, Dynamic Uptime simply serves as a convenient alternative to Scheduled Uptime, allowing servers to power on based on demand and to remain powered on only as long as needed.

Dynamic Uptime Type I - Sporadic Use throughout the Day

In this scenario, consider the following configuration for a Collection Pool at Company Z:

• 100 users are assigned to a RDS Shared Collection Pool
• Dynamic Uptime is enabled
• The Users per Host (UPH) threshold is set to 25
• The Excluded Servers per Region (ESR) is set to 2

Company Z uses the Collection Pool only to provide a legacy application via RemoteApp that is accessed throughout the day by a large number of users, but for only a short period of time.

Company Z has configured 2 Session Hosts to be excluded (i.e., ESR is set to 2), to serve as a "buffer" if a large number of users log in at once and additional hosts need to be powered on quickly. In this example, Server 1 and Server 2 are considered the initial ESR servers, because Dynamic Update kept them powered on even after all users had logged off (i.e., they were the last servers to reach 0 active users).

When the first user logs in to either of these servers, the first "dynamic" server is started and accepts new connections. When the 26th user (UPH + 1) logs in, the next dynamic server is started.

As additional users log in, they are distributed across all available Session Host servers, including the "ESR" servers. When an individual server reaches the UPH threshold-- in this case, 25 active connections-- it is excluded from accepting new connections.

As the peak usage period elapses, users begin logging out of the environment. The servers that first reached the UPH threshold are typically the first to reach 0 active users and are shut down by the Dynamic Uptime service. The remaining servers continue to accept users that may log in, but when a server reaches 0 active users it may be shut down by the service. When the number of powered-on servers is equal to the ESR value, the remaining servers will not be shut down.

This is represented in the table below.

Enabling Dynamic Uptime

Dynamic Uptime can be configured when you first create a new Collection Pool. You simply enable the toggle for Dynamic Uptime and specify the number of Excluded servers (per region). When the Collection Pool is provisioned, Dynamic Uptime will be enabled.

To enable Dynamic Uptime on an existing Collection Pool, you must first power on all User Session Servers in the Collection Pool and then enable the feature in the Collection Pool settings. CAS will install the DynamicUptime service on the servers and begin monitoring them; a reboot is not required, but servers may be powered off if the Dynamic Uptime thresholds are met.

Dynamic Uptime and Scheduled Uptime

CAS also provides the Scheduled Uptime feature for starting and stopping VM instances based on a configurable schedule. As the name implies, Scheduled Uptime allows an administrator to define when to start and stop servers based on a schedule; the schedule can target a subset of servers and can be configured for unique times each day of the week. Unlike Dynamic Uptime, Scheduled Uptime can be applied to all servers in a CAS deployment, not only Session Hosts.

Scheduled Uptime is a useful feature for specific use cases. If, for example, an organization has offices around the world, Scheduled Uptime can help shut down unnecessary infrastructure in each region during off-peak times, which can significantly reduce GCP Compute costs.

Scheduled Uptime and Dynamic Uptime do not coordinate their actions. If a host is scheduled to shut down at a certain time, it will do so regardless of whether the server is needed to maintain the UPH defined in Dynamic Uptime; similarly, Dynamic Uptime may power on a Session Host immediately after Scheduled Uptime instructs it to shut down.

For this reason, we do not recommend using Scheduled Uptime on Session Hosts if Dynamic Uptime is enabled. Attempting to use both features on Session Hosts may lead to unpredictable and unexpected results, and you may not get the costs-savings that could be achieved by using either feature separately. The end-user experience may also be impacted by sessions being terminated as hosts are shut down according to their schedule. You may continue to use Scheduled Uptime for other server roles, such as RD Gateway servers and Domain Controllers.