Skip to content

Workflow

High-level Steps for Working with Automatic Power Management

A brief introduction and the required configurations about Automatic Power management is provided in the Overview and Configurations. This section provides workflow details:

  1. Install HyWorks Controller and all the required services - scheduler and action processor

  2. Create a dynamically deployed Shared Hosted Desktop pool with the Capacity plan mode as enforced

  3. Create a Capacity plan as per the requirement and associate the deployed pool (team) with the Capacity plan

  4. All the components to start functioning and get automatic power management and on-demand deployment of the Session Host servers.

Create a Session Team with Automatic Power Management

To manage a member Session Host Server automatically and provision on demand, the Session Host Servers must be provisioned using a dynamic Shared Hosted Desktop pool.

Prerequisites

  1. The supporting providers are already added and configured

  2. The source gold master (Session Host Server) is installed and available on the provider

    1. Windows/Linux Servers with the Session Host Server v3.3-R2 or later is installed

    2. Appropriate Hypervisor tools are installed

    3. The Session Host Server is reachable through the HyWorks Controller

Steps

  1. In the Desktop Pool wizard > General screen

    1. Desktop Pool Type: Set as Shared Hosted Desktop or Non-persistent Shared Hosted Desktop

    2. Provisioning: Set as Dynamic

    3. Other configurations on the General screen can be done as per the requirement

  2. In Deployment screen

    1. Source VM: Select Gold VM prepared

    2. Desktop Creation: Set as Provision on-demand as per the Capacity plan. Enable the Capacity Plan Mode so that it is available on the Session Team page of the desktop pool.

    3. Set other options as per the requirements

  3. Configure Customization, Clients, Classification Rules, Advanced as per the requirement (these options do not affect automatic power management).

    1. In Advanced, by default pool is provisioned for local site.

    2. If the pool is created for remote site, it should be configured accordingly. Configuring pool for remote site enables some additional options for capacity plan in session team tab.

  4. In Session Team tab

    1. Capacity Plan Mode:

      1. Set as Enforce: On-demand desktop provisioning and power management will be applicable as per the Capacity plan.
      2. Set as Disabled: On-demand provisioning and power management is disabled.

    2. Force Server Shutdown: Select this option if you want to mark the server as cordoned and no new sessions are to be served from this server. The server will shutdown forcefully as per the shutdown timeout configured and all the user sessions will be ignored. The user will lose any unsaved changes. Set Force Shutdown Wait Time In Minutes i.e. the time to wait before shutting down the server, if you enable the Force Server Shutdown setting.

    3. Force User Logout: If set, then the user will be logged out forcefully from the server when the team scale logic has marked the server for shutdown.

    1. Idle capacity to manage when disaster recovery is not active: The configuration helps in managed pools to deploy and keep specified percentage of session servers ready, so that whenever disaster recovery is activated, the servers can be used initially and users do not face any delay due to server preparation at run time. Following two configuration can be set in percentage (%):

      1. Minimum powered on VM(%): Enter value for minimum number of VMs to be kept powered-on(in %) all the time (when disaster recovery is not active).

      2. Minimum provisioned on VM(%): Enter value for minimum number of VMs to be provisioned (in %), when disaster recovery is not active)

    Note

    • When DR is activated, the pool provisioning and server preparations will work as per capacity plan.

  5. Set other configurations as required and finish to save the desktop pool. Servers will be provisioned as per the capacity plan configurations.

Create a Capacity plan

Once all the required components are installed and the Administrator has decided the objectives, follow the steps listed below to create a Capacity plan:

  1. Go to Management Console > Session Servers > Capacity Plans
  2. Click Add New Plan to launch Create New Plan wizard
  3. On the Objective Details screen
    1. Provide an appropriate and logical Name and Description
    2. Add the objectives with appropriate values for Time, Max Running Capacity %, Min Running Capacity %, Min Provisioned Capacity %, Utilization Threshold for Scale Up %, Utilization Threshold for Scale Down %
  4. Click the Next to proceed. On the Schedule screen
    1. Enable the Capacity Plan
    2. Set a valid plan Start date and time
    3. Set a valid End date and time for the Capacity plan
    4. Select the days of the week when the plan should be applied
  5. Click the Next to proceed.
  6. On the Managed Session Teams screen, click Add, search and select the session teams that are to be associated with this Capacity plan

Refer to the Capacity Plan section for details Capacity plan and it's components.

Workflow and Component Interaction

Capacity planning implementation consists schedule based triggers, that are configured using the HyWorks Controller, but managed and executed by the Scheduler and Action Processor.

The Scheduler is responsible for scheduling the tasks at the specified intervals, which are required for capacity planning implementation. The Action Processor is responsible for executing those tasks with the help of the Controller.

Capacity planning execution depends on the following two tasks and each task has a schedule to trigger execution and action to perform on the trigger:

  1. Plan Implementation
  2. Dynamic scale

Plan Implementation

The term "Plan implementation" is used for the action of updating the team's server capacity based on the objective time and limits for the teams that are associated with the Capacity plan.

Each Capacity plan has an its own schedule to trigger a task at a specified interval to execute the action.

Plan implementation is triggered as per the schedule. For dynamic scaling appropriate capacity recommendations are updated in database after the plan is implemented.

Plan Implementation Schedule

The schedule for the Capacity plan gets created when "Add or Update operation of the Capacity plan" is enabled. The default interval for the schedule is 15 minutes while the other parameters can be set as per the requirement:

  • Enable Capacity Plan
  • Plan Valid From
  • Plan Valid Till
  • Plan Applicable on These Days

The Capacity plan schedule gets created from the Start date to the End date and is triggered every 15 min on the selected weekdays. The Action Processor performs the action at every trigger to update the team's server capacity.

Plan Implementation Action

When the Scheduler triggers the task for the Capacity plan schedule, Action Processor performs the action for plan implementation, with the help of the Controller. The Capacity plan objective values are updated for the teams for the current time. It attempts to pick up the latest objective available before the current time, for example, for an objective that is configured for 13:00 hrs and the current time is 13:05 hrs, then the Action Processor will pick the objective at 13:00.

Following session teams fields are updated at the time plan implementation if changed:

  • Max Server

  • Min server

  • Provisioned server

  • Scale Up utilization %

  • Scale Down utilization %

Dynamic Scale

The Dynamic scale task is for the team to scale up or scale down based on the server capacity and their threshold.

Each team for which capacity planning is enabled has its own schedule to trigger a task at a specified interval to execute the action.

Dynamic scale task runs continuously to check the scaling, irrespective of the day.

Plan implementation can run on specific days because it has different objectives on different days that are based on the load. However, Dynamic scaling needs to run 24/7 to scale the team capacity based on the current server capacity updates provided by the capacity plan.

Dynamic Scale Schedule

If the Administrator enables capacity planning by selecting the Desktop Creation setting as Provision On Demand as Per Capacity Plan, the schedule for the Managed Session Team is created when the Add or Update actions occur for the pool.

An Independent schedule will be created for each managed session team that is capable of capacity planning. The schedule life span is of 20 years from the day pool or team is added or updated and it gets triggered on all seven days of the week at an interval of 15 minutes.

Dynamic Scale Action

The Action Processor performs the Dynamic Scale action with the help of the Controller, when the Scheduler triggers the task as per the dynamic scaling schedule.

The Action Processor fetches the team details and calculates the desired servers to be Powered On and to be provisioned based upon team's server capacity and different operation's like Powered On, Powered Off, Cordon the VM, Un-cordon the VM, Provision the VM, Un-provision the VM are performing with the help of the Controller to match the desired capacity at the execution time. For every new run, it will attempt to match the desired capacity, irrespective of the executions during past runs.

The Action Processor takes actions based on the configurations given below. Some configurations are done at the team level and some configurations are done globally through the Action Processor's config file.

Conditional Scaling on User Connect

Other than usual periodic scaling, in following case HyWorks can scale servers out of the cycle:

Condition# 1: Capacity plan is having following configurations: Number of active session servers are 0, minimum running capacity is 0, and maximum running capacity is greater than 0
Condition# 2: Desktop connection request comes Condition# 3: No on-demand scaling operation is running.

On satisfying all above conditions, up-scaling of one session server will happen and user will be asked to wait for sometime using following messages:

If one VM to be powered-on: Desktop is getting prepared, just relax for min or two. If one VM to be provisioned: Desktop is getting provisioned, we may take around 20 minutes. You can grab a coffee.

Capacity Planning of Pools Provisioned for Remote Sites

There is a slight difference in the overall flow of events for shared hosted desktop pools, provisioned for remote sites.

The Shared hosted desktop pools provisioned for remote sites require two additional configurations:

  • Minimum powered on VM(%): Enter value for minimum number of VMs to be kept powered-on(in %) all the time (when disaster recovery is not active).

  • Minimum provisioned on VM(%): Enter value for minimum number of VMs to be provisioned (in %), when disaster recovery is not active)

Hence, by default HyWorks will maintain number of servers provisioned and powered-on as per configurations done for above two attributes till the time DR is kept inactive.

As soon as DR is activated, HyWorks will start managing this pool using associated capacity plan(s) as normal and will provision/power-on session servers as per plan objectives.

Known Behaviors and Considerations

Behavior: Backend call for plan implementation will occur at a minimum of a 10 minute interval at 00, 10, 20, 30, 40, 50

Impact Any plan implementation or scaling will happen only after a minimum of 10 minutes at the specified time e.g. 12:00, 12:10, 12:20, 12:30 etc. Users will not able to connect and will have to wait for the scale to happen.

Behavior: The Action Processor has two calls i.e. 1. Plan implementation and 2. Dynamic scale, causing the scale to happen in the next cycle if the call to scale occurs first

Configurations:
Max capacity: 10 , Max session limit: 2 Plan implementation: 15 min, Dynamic Scale: 15 min

Result:
The Capacity plan is saved at 12:25 PM. As per the plan implementation trigger at 12.30PM, it will apply the max/min/min. provisioned servers to the session team. Dynamic scale may run at 12:30 PM or 12.45pm.

Impact:
The Administrator's confusion as to why the minimum number of servers are not ready at the specified time. User on-boarding may be affected.

Behavior: The Action Processor always tries to match the min. running capacity on the 1st dynamic trigger and on the 2nd trigger, it tries to match the min. provisioned capacity.

Configurations:
Total capacity: 10 , Max session limit: 2 Plan implementation: 15 min, Dynamic Scale: 15 min.

5:00 AM - Max: 100%, Min: 10%, Min. Provision: 20% 5:15 AM - Max: 100%, Min: 20%, Min. Provision: 30% 5:30 AM - Max: 100%, Min: 30%, Min. Provision: 40%

Result:
As per the plan, at 5 AM on the dynamic scale trigger, it will clone 1 VM to match the min. running capacity. At 5:15 AM, on the next trigger, it will again try to match the min. running capacity, i.e. 2 In the above case, it will not clone the min. provisioned servers. and will happen only after next scale at 5:45 AM or later

Impact:
User on-boarding is affected. The Administrator has to create a logic of implementation for the same.

Behavior: On-demand scaling is not supported on App connect

Configurations: As specified in section Conditional Scaling on User Connect Impact: User on-boarding is affected for application sessions. Which works for shared hosted desktop connections.

Capacity planning checks the plan objective closest to 12:00 am/00:00 in the current plan only, even if multiple plans are applied to the single session team

Configurations:
Weekdays Plan for Mon to Friday 9:00 AM - Max: 100%, Min: 100%, Provision: 100% 23:42 PM - Max: 0%, Min: 0%, Provision: 0% Weekend plan for Saturday 9:00 AM - Max: 50%, Min: 25%, Provision: 50% 14:00 PM - Max: 80%, Min: 80%, Provision: 80% 18:00 PM - Max: 10%, Min: 10%, Provision: 10%

Result:
1. On Friday 25th feb at 23.45 0/0/0 plan was applied on session team 2. On sat 26th feb at 12.00 am dynamic scaling triggered and servers were marked cordon 3. On sat 26th feb at 12.00 am, plan implementation triggered and '18.00 plan objective from the weekend plan was applied Applied plan: 18:00 AM - Max: 10%, Min: 10%, Provision: 10% The plan objective closest to 12:00/0:00 in the current plan is checked and gets applied, in this case, 18:00 plan is closest to 12:00 and hence, applied. Impact:
Server provisioning or scaling will get affected and there can be more or less number of servers available. Workaround:
As a workaround, an objective must be defined closest to 12:00; e.g. 12:01.

Behavior: The Virtual channel used for displaying a notification to the user.

Virtual channel only works on Windows endpoints. The connection profile settings must be configured, otherwise the users will not get notifications.

Behavior: In the current build, the notification settings need to be configured through the appsettings.json file and a service restart is also required.

Impact:
Server access will be needed and the settings update from json or file is not user-friendly. Service start always requires considerations of the current time and plan implementations, leading to increased support calls.

Behavior: The Admin does not have control on the dynamically managed teams.

Impact:
Any automatically managed team, even if it requires that the capacity be increased for a sudden rise of users, may get changed as per the plan objectives. The Administrator will need to manually remove the team from the plan or inactivate the plan for any such manual interventions.

Behavior: Actual shutdown of the cordoned server may not happen on the notified time and will happen on the next dynamic scale trigger

Configurations:
Force Shutdown Wait Time In Minutes: 5.

Use case:
If user sessions are running and as per the plan, the server is marked for a cordon state, then the user will receive a notification as 'Logout from this desktop and re-login to get new desktop. This server is planned to shutdown at [DisplayEndTime]'. But the server will be un-provisioned on the next dynamic trigger, until which time, the user can work on it.

Behavior: CPU/RAM thresholds (if applied) can conflict with the Capacity plan as it only considers the max. number of sessions allowed per server.

Configurations:
Max Session Per Server: 5, Total Capacity: 5 server 5:00 AM - Max: 100%, Min: 20%, Min.Provision: 100%, scale-up: 80%, scale-down: 40% CPU Threshold: 75%, RAM threshold: 75%

Explanation:
As per the above plan: At 5 AM, 1 server will be up and more servers will be Powered On if 4 or more users get connected. But if only 3 users cause CPU of more than 75% or RAM of 75%, then the Controller will not give additional sessions. Eventually, the system will need to Power On more servers, but it will not scale-up as the minimum scale-up (80% = 4 users) has not been reached.

Behavior: Overlapping of two objectives will result in the implementation of the current objective and the previous plan objective that is in-progress may get affected

Example:
Total capacity: 10 , Max session limit: 2 Plan implementation: 15 min, Dynamic Scale: 15 min.

5:00 AM - Max: 100%, Min: 100%, Min.Provision: 100% 5:15 AM - Max: 100%, Min: 0%, Min.Provision: 100%

Explanation:
Here, the plan at 5:00 AM will trigger provisioning of 100% (10 VMs), but at 5:15 will start cordoning and shutdown of servers, which can affect provisioning, customizations etc.