Skip to content

Server Team Load Balancing

Server Team in HyWorks is a team or group of session host servers. Applications or desktop sessions are given from session host servers based on load balancing mechanism used in session server team configuration.

Session host servers team are managed from VDI > Session Servers > Server Teams section.

HyWorks Session Team Load Balancing

HyWorks Controller starts load balancing the sessions among the member session host servers once multiple servers are added to a single session team.

HyWorks Controller supports following types of load balancing:

  • Weighted Round Robin

  • Weighted Least Connection

  • Adaptive

Weighted Round Robin

Round Robin refers to a mechanism where sessions are given one by one from all servers, but in HyWorks the Weighted Round Robin load balancing uses a unique formula, where the load balancing is done in following manner:

Weighted Round Robin Load Balancing Mechanism

  1. While adding session host servers to session team with Load Balancing Type as Weighted Round Robin, weight of each server is taken. The weight could be a number ranging from 2 to 100.

  2. Controller performs addition of weight of all servers and stores this number and assigns a range to each server e.g. three session host servers say srv1, srv2 and srv3 are added with weight 10, 50 and 100 respectively. Then number range for each server could be:

    1. Sum of weights = 10 + 50 + 100 = 160

    2. Srv1 (Weight = 10): Range 1 -- 10

    3. Srv2 (Weight = 50): Range 11 -- 60

    4. Srv3 (Weight = 100): Range 61 -- 160

  3. Whenever any session requests (Application/ Shared Hosted Desktop Session) comes to controller:

    1. Controller picks a random number between 1 to sum of weight of all servers (in above example number could be 1 to 160)

    2. Controller verifies, picked number falls in which range and that range belongs to which session host server.

    3. Session is given from session host server in whose range the picked number falls.

  4. On every session request, the same process is repeated..

  5. HyWorks will select a random server in case weight of 2 or more server is same.

Session Stickiness in Application Delivery in Remote App Mode

If applications are configured to be delivered in Remote Application mode, which means all the application sessions will be running in single RDS session, then controller stores the session host server details from where the application has been served.

If another application session request comes which can be delivered from the same server, then controller ignores the load balancing and provide the application sessions from the same server.

The phenomenon is called the session stickiness and is applicable only in application delivery in Remote App mode.

Reconnection (Shared Hosted Desktop Session and Application Sessions in Remote App Mode)

Another important phenomenon in HyWorks Controller, where controller will ignore load balancing mechanism is Reconnection.

In cases, when user's shared hosted desktop session or application sessions in Remote App mode is already lying in running or disconnected mode, then Controller ignores the load balancing and first provides the reconnection of same desktop or remote application sessions to the users.

Application Delivery in Shell Mode and True Load Balancing

As application delivery in Shell mode, launches each application session in new RDS session, HyWorks Controller does not consider session stickiness or reconnection phenomenon and calculates the most suitable session host server as per its Weighted Round Robin mechanism every time.

The application delivery in Shell mode is termed as True load balancing.

Cases in Which Controller Won't Provide Session from Eligible Session Host Servers

In few cases controller does not provide session from eligible session host server and recalculates the suitable session host server based on Weighted Round Robin load balancing mechanism, following is the list of such cases:

  1. Session Host Server is down: Controller monitors the availability of each session host server and if session host server goes unreachable, it does not give session from that server though, session may fall in the range of eligible server.

  2. Session Host Agent Service is down: If controller cannot communicate with session host server then also sessions from that server will not be given.

  3. Session Host Service is inactive: If session host server is made inactive then sessions from that server will not be given.

  4. CPU or RAM Threshold Reached: In session team if Limit session is enabled and memory or CPU or both resource utilization has crossed specified limit then, sessions from that respective session host server will not be given.

  5. Limit of No. of Application Instances Per Server Has Reached: If number of application instances per server is configured and number of application sessions from one session host server has already reached, while providing that application session, then the server which has ready reached the limit will be skipped and session from other servers will be given.

  6. Max Session Limit is reached: HyWorks controller will stop giving new sessions to session host server, if it has reached Max session count.

Weighted Least Connection

Weighted least connection in HyWorks provides sessions from session host servers using following mechanism:

Weighted Least Connection Load Balancing Mechanism

  1. While adding session host servers to session team with Load Balancing Type as Weighted Least Connection, weight of each server is taken. The weight could be a number ranging from 2 to 100.

  2. Score for each server is calculated using the following formula and server with least connection will be given the sessions:

    Score Calculation Formula: (No. of Sessions x 10000)/Weight

  3. Whenever any session requests (Application/ Shared Hosted Desktop Session) comes to controller

    1. With zero sessions, the score of session host server will also be zero (displayed as Hyphen "- ")

      1. If all session host servers are having zero (-) score, controller will pick any session host server randomly to provide session

      2. With one server is having zero sessions and zero (-) score, then that server will be used first

    2. Once at least one session from each of the session host server is provided, then controller will check the score to provide the next session.

      1. If servers are having same score, then again controller will randomly pick one of the session host server

      2. If not having same score, then session from server with least score will be provided.

  4. On every session request, the same process will be repeated.

Session Stickiness in Application Delivery in Remote App Mode

Session stickiness mechanism is same as the one specified for Weighted Round Robin and indicated in section Session Stickiness in Application Delivery in Remote App Mode

Reconnection (Shared Hosted Desktop Session and Application Sessions in Remote App Mode)

Reconnection mechanism in Weighted Least Connection will work in the same manner as being used in Weighted Round Robin load balancing mechanism. Refer Reconnection (Shared Hosted Desktop Session and Application Sessions in Remote App Mode)

Cases in Which Controller Won't Provide Session from Eligible Session Host Servers

  1. Controller skips providing sessions from session host server in specific cases mentioned in detail in section Cases in Which Controller Won't Provide Session from Eligible Session Host Servers

  2. Remote desktop throttling: It can enabled from Settings > General > Advance Config and it forces controller to give some breathing space to session host server between two consecutive sessions. This can also affect load balancing temporarily; where if two sessions can go to same server within throttling interval, then controller will skip the second session. Default value is 0, which means there will be no throttling by default.

Adaptive Load Balancing

Adaptive load balancing in HyWorks refers to mechanism for sessions from team of session host servers based on current load (CPU/Memory consumption.

In Adaptive load balancing controller continuously updates its database with CPU and memory consumption of session host servers using monitoring service running on session host servers.

Score of each session host server is calculated based on current CPU and memory consumption and session is provided from session host server with least score.

Important

Adaptive load balancing should not be configured for Linux Session Teams, as Linux session host server does not have monitoring service integration.

Score Calculation Formula: CPU (%) + Memory (%)

Note

Monitoring service on session host server sends an average of last 3 memory and CPU usage in every 30 seconds and then sends the data to controller in every 30 seconds. Which means the controller uses a little old data, but this also helps in avoiding intermittent spikes in CPU or memory usage.

Adaptive Load Balancing Mechanism

  1. Score for each server is calculated using the following formula and server with least connection will be given the sessions:

    Score Calculation Formula: CPU (%) + Memory (%)

  2. Whenever any session requests (Application/ Shared Hosted Desktop Session) comes to controller

    1. If servers are having same score, then controller will randomly pick one of the session host servers

    2. If not having same score, then session from server with least score i.e. server with least consumption will be provided.

  3. On every session request, the same process will be repeated.

Session Stickiness in Application Delivery in Remote App Mode

Session stickiness mechanism is same as specified in section Session Stickiness in Application Delivery in Remote App Mode

Reconnection (Shared Hosted Desktop Session and Application Sessions in Remote App Mode)

Reconnection mechanism in Adaptive Load Balancing will work in the same manner as being used in Weighted Round Robin load balancing mechanism. Refer Reconnection (Shared Hosted Desktop Session and Application Sessions in Remote App Mode)

Cases in Which Controller Won't Provide Session from Eligible Session Host Servers

Controller skips providing sessions from session host server in specific cases mentioned in detail in section Cases in Which Controller Won't Provide Session from Eligible Session Host Servers.

In addition to the cases mentioned above monitoring service (and resource consumption) becomes the critical and can affect session host server selection in following manger:

  1. Sessions will not be provided if Monitoring Service is down: Monitoring service is not considered in Weighted Round Robin and Weighted Least Connection load balancing types, but if session team is using Adaptive load balancing and monitoring service is not running on specific Session Host Server then sessions from that session host server will be skipped.