Skip to content

Workflow

High-level Steps for Working with Automatic Power Management

In Overview and Configurations sections, the brief introduction and required configurations are explained. In this section, high-level steps and workflow will be provided:

  1. HyWorks Controller and all required services (Scheduler/ Action Processor) are installed and configured
  2. Create a dynamically deployed shared hosted desktop pool with capacity plan mode as enforced
  3. Create a capacity plan as per requirement and associate the deployed pool (team) with capacity plan
  4. All components will start functioning and will get the automatic power management and on-demand deployment of session host servers.

Creating Session Team with Automatic Power Management

To manage member session host server automatically and also provision on demand, session host servers must be provisioned using dynamic shared hosted desktop pool. In below section information to create and enable automatic power management will be provided:

Prerequisites:

  1. Supporting providers are already added and configured
  2. Source gold master (session host server) is installed and available on provider
    1. Windows/ Linux Servers with Session Host Server v3.3-R2 is installed
    2. Appropriate hypervisor tools are installed
    3. Session host server is reachable from HyWorks Controller

Steps:

  1. In Desktop Pool wizard -> General Screen,
    1. Desktop Pool Type: Set as Shared Hosted Desktop
    2. Provisioning: Set as Dynamic
    3. Other configurations in General screen can be done as per requirements

  1. In Deployment screen,
    1. Source VM: Select gold VM prepared
    2. Desktop Creation: Set as Provision on-demand as per capacity plan, this is an important configuration, enabling this option makes Capacity Plan Mode available in Session Team page of the desktop pool
    3. Other options can be chosen as per requirements

  1. Configure other options in Customization, Clients, Client Groups, Advanced screens as per requirement (These options will not affect automatic power management)
  2. In Session Team screen,
    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: If set, server will be marked as cordoned and no new sessions will be given from this server. Server will be forcefully shutdown as per shutdown timeout configured. Shutdown operation will ignore any user-sessions. User will lose any unsaved changes.
        • Force Shutdown Wait Time In Minutes: Time to wait to shutdown the server, if the force server shutdown setting is enabled.
    3. Force User Logout: If set, then the user will be forcefully logged-out from server, when team scale logic has marked the server for shutdown.

  1. Check other configurations and finish to save desktop pool. Servers will be provisioned as per next objective.

Create capacity plan

Considering all required components are installed and administrator has decided the objectives, below steps can be followed to create a capacity plan:

  1. Go to management console -> Server -> Capacity Plans
  2. Click on Add New Plan to launch Create New Plan wizard:
  3. Objective Details screen:
    1. Provide appropriate logical Name, Description
    2. Add 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 on Next button to proceed, on Schedule screen
    1. Enable Capacity Plan
    2. Set a valid plan start date and time
    3. Set a valid end date and time for capacity plan
    4. Select the days of the weeks, on which plan will be applied
  5. Click on Next button to proceed, on Managed Session Teams screen,
    1. Click on Add button, search and select session teams to be associated with this capacity plan

Refer section Capacity Plan for detailed information of capacity plan and it's components.

Workflow and Component Interaction

Capacity planning implementation is the schedule based triggers, which are configured from HyWorks controller, but managed and executed by Scheduler and Action Processor. The scheduler is responsible for scheduling the tasks on specified intervals, which are required for capacity planning implementation and the action processor is responsible for executing those tasks with the help of the controller.

Capacity planning execution depends on the following two tasks, every 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 activity to update the team's server capacity, based on objective time and objective limits for the teams, which are associated with the capacity plan. Each capacity plan has an individual schedule to trigger a task at a specified interval to execute the action. Plan implementation is triggered as per schedules and then appropriate capacity recommendations are updated in database for dynamic scaling to occur.

Plan Implementation Schedule

Schedule for capacity plan gets created on "Add or Update operation of the capacity plan". The default interval for the schedule is 15 minutes and other parameters can be set by admin as below.

  • 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 will get triggered every 15 min on selected weekdays. The action processor will perform the action on every trigger to update the team's server capacity.

Plan Implementation Action

Action Processor performs the action for plan implementation with the help of controller, when scheduler triggers the task for capacity plan schedule. Capacity plan objective values get updated on the teams for the current time. It always tries to pick up the latest objective available before the current time, e.g., for an objective is configured for 13:00 hrs and current time is 13:05 hrs, then it will pick objective at 13:00

Below fields of session team gets updated on every plan implementation if they have changed.

  • Max Server
  • Min server
  • Provisioned server
  • Scale Up utilization %
  • Scale Down utilization %

Dynamic Scale

Dynamic scale task is for the team to scale up or scale down based on server capacity and scale up and scale down threshold. Each team on which the capacity planning is enabled has one individual schedule to trigger a task at a specified interval to execute the action. Dynamic scale task should be continuously running to check for scale up or scale down irrespective of any day. Plan implementation can run on a specific day because it has different objectives on different days based on load, but Dynamic scale needs to run 24/7 to scale the team capacity base on current server capacity update by the capacity plan.

Dynamic Scale Schedule

Schedule for Managed Session Team get created on Add or Update of the pool if admin enables the capacity planning by selecting Desktop Creation setting as Provision On Demand as Per Capacity Plan. An Independent schedule will be created for each managed session team that is capable for capacity planning. The schedule life span is of 20 years from add or update of the pool or team and the schedule gets triggered on all seven days of the week with default of 15 minutes of interval.

Dynamic Scale Action

Action Processor performs the action for Dynamic Scale with the help of controller when scheduler triggers the task for dynamic scale schedule. Action processor fetch the team detail and calculate the desire servers to be powered on and desired servers to be provisioned base up team's server capacity and different operation's like Powered On, Powered Off, Cordon the VM, Uncordon the VM, Provision the VM, Unprovision the VM are performing with help of controller to match the desired capacity at the execution time. Every run it always tries to match the desired capacity irrespective of past execution.

Action processor takes the action based on the below configuration, some configurations are done at the team level and some configurations are done globally at Action Processor's config file.

Known Behaviors and Considerations

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

Impact: Any plan implementation or scaling will happen only after 10 minutes minimum at 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: Action processor is having two calls i.e. 1.Plan implementation 2.Dynamic scale, hence scale may happen in next cycle if call to scale occurs first

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

Result: 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 on session team. Dynamic scale may run at 12:30 PM or 12.45pm.

Impact: Administrator's confusion as why on given time, minimum number of servers are not ready. User on-boarding may get affected

Behavior: Action processor is always try to match the min.running capacity on 1st dynamic trigger and on 2nd trigger it will try 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 dynamic scale trigger, it will clone the 1 VM to match the min running capacity. At 5:15 AM on next trigger again it will try to match the min running capacity i.e. 2 In 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 gets affected. Administrator has to create logic of implementation for the same.

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

Virtual channel only work on Windows endpoints. Connection profile settings must be configured else users will not get notifications.

Behavior: In current build, notification settings need to configure through appsettings.json file and service restart is also required.Impact:

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

Behavior: Admin is not having control on dynamically managed teams.Impact:

Any automatically managed team, even if it requires to increase capacity for sudden rise of users, may get changed as per plan objectives. Administrator will be needed to manually remove team from plan or inactivate the plan for any such manual intervention.

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

Configurations: Force Shutdown Wait Time In Minutes: 5.

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

Behavior: CPU/ RAM thresholds (if applied) can conflict with capacity plan as it only considers max 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 above plan: At 5 AM, 1 server will be up and more server will be powered on if 4 or more users get connected. But if only 3 users, causes CPU of more than 75% or RAM of 75%, then controller will not give sessions. Eventually system is in need to power-on more servers, but it will not scale-up as minimum scale-up (80% = 4 users) has not reached.

Behavior: Overlapping of two objectives will result in implementation of current objective and thus the previous plan objective 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 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.