Loading

×Sorry to interrupt
Uncaught ReferenceError: addCTracking is not defined
throws at https://kb.vmware.com/resource/KM_TealiumTrackingJS?v=0.5:100:1

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

Horizon 8: Monitoring health of Horizon Connection Server using Load Balancer, timeout, Load Balancer persistence settings (56636)

Last Updated: 1/23/2024Categories: InformationalTotal Views: 78405Language:
Portuguese (Brazil)JapaneseSpanishEnglish

36 like this article

Subscribe to get an email
newsletter with new updates

36 people found this helpful Please provide article feedback:

Symptoms

Please reference the following KB article for legacy editions of Horizon: Horizon 7: Monitoring health of Horizon Connection Server using Load Balancer, timeout, Load Balancer persistence settings (94954)

Purpose

This article provides information about Horizon 8 timeout settings, supported health monitoring string and suitable Load balancer persistence values.

The intent of this article is to provide a reference point for both Horizon System Administrators and Network Administrators when deciding on appropriate configuration values for Horizon and equivalent persistence values for load balancers.

Resolution

Note: VMware recommends Source IP persistence.

Summary:

Horizon has a default heartbeat interval of 30 minutes if you do not configure optional settings within Horizon such as "Forcibly Disconnect Users" or "User Idle Timeout"

You can configure lower timeout values which are respected but the heartbeat interval cannot be extended beyond 30 minutes.

If a Horizon Client heartbeat is missed 3 times in a row, the session is terminated.

Loadbalancer persistence settings need to account for this with a persistence value of 90 minutes for a default configuration, or less if you have configured a lower timeout period.

Please find a legend and Sample Scenarios below along with guidance and caveats in terms of Health Monitoring.

Legend:

Value

Explanation

Forcibly Disconnect Users

This is a Global Setting in your Horizon Admin Console. In Horizon Console, you can configure global settings by navigating to Settings > Global Settings > General Settings (Global Settings for Client Sessions in Horizon Console )  | pae-MaxSessionTime

User Idle Timeout

This is a Global Setting in your Horizon Admin Console. Protects application sessions when there is no keyboard or mouse activity on the client device for a certain configured period | pae-UserIdleTimeout

Heartbeat Interval (set-last-user-activity)

This is a session keepalive sent from the Horizon Client machine.

The heartbeat interval (set-last-user-activity). If this interval expires, with no beat received & we miss three consecutive heartbeats, the session will end

You can see these being sent and received within the Horizon

2022-12-02T08:41:20.659-05:00 INFO (01) [libcdk] : CdkSetLastUserActivityTask_CreateRequest: Sending last user activity: 349.

A maximum interval of 30 minutes between heartbeats is enforced -  The period between heartbeat checks cannot be longer than 30 minutes. All larger idle timeout values, including never will be handled as a 30-minute interval

If configured with values below 30 minutes, a combination of the values set for "Forcibly Disconnect Users" & "User Idle Timeout" apply. See Configuration Scenarios below.

Example: This means for an idle timeout of one minute (the minimum value), heartbeats will be sent every 20 seconds, and this increases linearly to an idle timeout of 90 minutes (heartbeats every 30 minutes)

Load Balancer Persistence

Heartbeats will never be further apart than 30 minutes.
We allow the possibility of two consecutive heartbeats going astray but will tear down the connection if we miss three consecutive heartbeats.

Examples of Potential Configuration Scenarios:

Legend:
T  = "Forcibly Disconnect User's" value in minutes
Y = "User Idle Timeout" value in minutes
Z = Heartbeat Interval value in minutes.

Example

Forcibly Disconnect Users

User Idle Timeout

Heartbeat Interval (set-last-user-activity)

Load Balancer Persistence

1

Never

Never

Interval is capped at 30mins

90 minutes

2

T Minutes

Never

If  Z < 30 minutes, the Interval is Z

30 minutes if Z> 30

90 minutes or Z Minutes if <30

3

Never

Y Minutes

If  Z < 30 minutes, the Interval is Z

30 minutes if Z> 30

90 minutes or Z Minutes if <30

4

T Minutes

Y Minutes

If Z < 30 minutes, the Interval is T

30 minutes if Z > 30

90 minutes or Z Minutes if <30

Notes:

Note: As of 8.4 HTML5 access has a "Forcibly Disconnect Users" setting. This is calculated in ms and should not be set higher than 24hrs, higher values will cause the result to be out of range.

Deployment Options:

Option 1

Internal Users go through an Internal LB, by skipping the UAG.

Client --> External LB --> UAG --> Internal LB --> CS

Option 2

One-to-one mapping of UAG with Connection Broker is recommended to have a fair distribution of load

Client --> LB --> UAG --> CS

Option 3

Horizon Security Server Security Server Topologies

Client --> LB --> Security Server --> CS

Monitoring the Health of the Connection Server:

To monitor load balancing health for a Horizon Connection Server, follow these best practices. The response received will allow the load balancer to determine where to route traffic.

Polling Interval:

30 secs (default recommended)

Recommended Range:

30 - 9000 seconds.

Response Timeout:

3 times the Polling Interval + 1

The Polling Interval recommendation of  30 seconds is to not flood the connection server with a high number of health check requests. Setting too low a value like 5 seconds or less is going to cause a higher load on the Connection Server and can lead to unexpected results.

With a polling interval of the default 30 seconds, the Response Timeout would be 91 seconds. Example Calculation: 30 * 3 = 90 + 1 = 91 secs.

Reference: Configuring Load Balancers for Horizon Connection Server Health Monitoring

Load Balancer Limits:

When multiple load balancers are configured to monitor the health of a server simultaneously, they can occupy a significant number of open threads on the connection server.

This can lead to resource contention and potentially impact the server's ability to handle incoming requests.

For example:

In a scenario where 15 load balancers are set up to poll a single connection server every 30 seconds, it results in 15 requests being sent to the server within that time frame. If the server takes 2 to 3 seconds to respond, the remaining free thread count on the Tomcat server would be 85. This is a crucial consideration in a scaled environment.

Essentially, try not to have more than two load balancers engaged in monitoring the health of a connection server.

favicon.ico is the only supported configuration for monitoring connection server health from load balancers

HTTP Response with monitoring strings:

200 OK

The Connection server is responsive to brokering requests.

500 Internal Server Error

The Connection server is not responsive to brokering requests.

Monitoring String

Usage Description

GET /favicon.ico HTTP/1.0

or

GET /favicon.ico HTTP/1.1

Supports the broker disable status. Sends back 500 status code when it cannot broker end-user sessions.

Monitoring the Health of Unified Access Gateway (UAG)

Configure Unified Access Gateway System Settings

UAG has a Maximum number of TCP connections allowed per TLS session / Maximum Connections per Session

The default value is 16

From Unified Access Gateway Load Balancing Topologies in the UAG Deployment Documentation :

A load balancer monitors the health of each Unified Access Gateway appliance by periodically sending an HTTPS GET /favicon.ico request. For example, https://uag1.myco-dmz.com/favicon.ico. This monitoring is configured on the load balancer. It will perform this HTTPS GET and expect a "HTTP/1.1 200 OK" response from Unified Access Gateway to know that it is "healthy". If it gets a response other than "HTTP/1.1 200 OK" response or does not get any response, it will mark the particular Unified Access Gateway appliance as down and will not attempt to route client requests to it. It will continue to poll so that it can detect when it is available again.

Samples:

These  example configurations are provided 'as-is'

Please refer to UAG documentation and Load Balancer Vendor documentation for your particular release for the most current and relevant settings

Incorrectly crafted health checks and excess frequent health checks do lead to unexpected outcomes. Verification against the latest available documentation for the various devices involved is encouraged.

Please engage VMware Support in parallel with your Load Balancer vendor when encountering issues to ensure optimum resolution times.

Sample Health Monitor Configuration for an Avi Vantage Load Balancer:
Reference: Configure Avi Vantage for VMware Horizon

Health Monitor Port: 443
Client Request Data: GET /favicon.ico HTTP/1.1
Response Code: 2XX
SSL Attributes: Enabled
SSL Profile: System-Standard
Maintenance Response Code: 503

Sample Health Monitor Configuration for Health Monitor for an F5 Load Balancer:
Reference: F5 Deployment Guides

Interval: 30
Timeout: 91
Send String: GET /favicon.ico HTTP/1.1\r\nHost: VIP.FQDN\r\nConnection: Close\r\n\r\n
Receive String: 200 OK

Page last reviewed: October 2023
Next review due: December 2023

Related Information

Legacy release details are available here: Horizon 7: Monitoring health of Horizon Connection Server using Load Balancer, timeout, Load Balancer persistence settings (94954)

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Portuguese (Brazil)JapaneseSpanishEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware Unified Access Gateway

VMware Horizon

Related Versions:

VMware Horizon 8

VMware Horizon 7.x

VMware Horizon 7

Unified Access Gateway 2111.x

Unified Access Gateway 2106.x

Take Our Survey

Support Assistant