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:
- Install HyWorks Controller and all the required services - scheduler and action processor
- Create a dynamically deployed Shared Hosted Desktop pool with the Capacity plan mode as enforced
- Create a Capacity plan as per the requirement and associate the deployed pool (team) with the Capacity plan
- 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
- The supporting providers are already added and configured
- The source gold master (Session Host Server) is installed and available on the provider
- Windows/Linux Servers with the Session Host Server v3.3-R2 is installed
- Appropriate Hypervisor tools are installed
- The Session Host Server is reachable through the HyWorks Controller
Steps
-
In the Desktop Pool wizard > General screen
- Desktop Pool Type: Set as Shared Hosted Desktop
- Provisioning: Set as Dynamic
- Other configurations on the General screen can be done as per the requirement
-
In Deployment screen
- Source VM: Select Gold VM prepared
- 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.
- Set other options as per the requirements
-
Configure Customization, Clients, Client Groups, Advanced as per the requirement (these options do not affect automatic power management).
-
In Session Team screen
- Capacity Plan Mode:
- Set as Enforce: On-demand desktop provisioning and power management will be applicable as per the Capacity plan.
- Set as Disabled: On-demand provisioning and power management is disabled.
- 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.
- 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.
- Capacity Plan Mode:
-
Set other configurations as required and finish to save the desktop pool. Servers will be provisioned as per the next objective.
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:
- Go to Management Console > Server > Capacity Plans
- Click Add New Plan to launch Create New Plan wizard
- On the Objective Details screen
- Provide an appropriate and logical Name and Description
- 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 %
- Click the Next to proceed. On the Schedule screen
- Enable the Capacity Plan
- Set a valid plan Start date and time
- Set a valid End date and time for the Capacity plan
- Select the days of the week when the plan should be applied
- Click the Next to proceed.
- 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:
- Plan Implementation
- 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 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 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.
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: 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.