Skip to main content

Load Balancing Requirements

As a Hubble customer, you may provide and use your own preferred load balancer for Hubble, provided you have IT staff who are knowledgeable regarding load balancing and proxy functions generally, and in how to configure your specific solution to meet Hubble's needs.

We have provided some generic instructions in this chapter, but cannot provide support for your choice of the load balancer, so it is essential that the troubleshooting steps described below are followed if there are any problems.

Requirements

  1. HTTP or HTTPS traffic should be routed to port 80 of web servers.
  2. Session persistence (sticky sessions) must be configured in order that any single user session stays routed to the same web server. This may be either a cookie-based or IP address/port based mechanism. Session persistence allows Hubble to leverage session-specific caches on the web server that improves performance for users and utilizes the resources of each web server more effectively.

    Note: Session persistence has been successfully tested with several types of load balancer using a cookie insert persistence method.

  1. Storage service traffic must be routed from port 591 (or port 592 in case of TLS/HTTPS) to port 591 of the Hubble application server.

Encryption

Traffic between your user's web browsers and the load balancer should be encrypted as it will likely travel across your entire corporate network and possibly even the internet, if you choose to expose Hubble that way.

Traffic between the load balancer and application server is not normally encrypted as it should only travel within your relatively secure data center network. However, you can configure encryption between the load balancer and the web servers if you need to. This should be transparent to Hubble, but it is not something we have tried, or tested, or can provide support for. It could have an impact on performance. If a change to the Hubble product is required to make it work for your environment, you will have to make an enhancement request which Hubble will consider as we would any other enhancement requests.

Checks

IIS

Depending on the mechanism used by the load balancer you can check the functioning of web request routing in the following ways:

  1. When cookie manipulation method is being used on the load balancer (cookie insert, cookie prefix, cookie rewrite), you will usually find that the server that serves a session directly in cookies.

    Press F12 while in the browser, select Network, click any element, select Cookies, then find cookies that may contain server IP/FQDN/server ID.

    By checking the chain of elements you can ensure that all of them are served by the same server.

  2. When some other method is used and cookies do not hold the IP/FQDN/server ID (when the load balancer maintains in-memory session-server mapping), the following techniques may be used: a custom distinct HTTP header may be added at every web server (node restart not required).
    1. To do that, on every server open IIS Management Console, select the server node, and in the right pane choose the HTTP Response Headers feature.

    2. Click Add. Enter the header name. It should be the same for each web server, and the value should contain a unique ID that enables each server to be identified.

    3. Similar to the tracing of cookies described above, such a custom header can be traced in the browser debugging console.

In order to ensure that every web server is reachable through the load balancer, you can stop the web service and application pools on every server except one and check that the web application operates correctly. This procedure has to be repeated for each server.

It’s also advisable to check that the same user session is still routed to the same web server after 10-15 minutes. If that's not the case, please check that session timeout configurations on the load balancer are either based on the user's web browser session or that the time-out value is greater than 45 minutes of inactivity.

S3 Storage

Try to open in a web browser one of the following URLs, depending on whether you have configured HTTPS or not:

  • TLS/HTTPS:    https://<load_balancer_IP>:592/click-once/ RepositorySelection.xml
  • No TLS/HTTPS: http://<load_balancer_IP>:591/click-once/ RepositorySelection.xml

    You should see the contents of the RepositorySelection.xml file in the browser.

Security Token Service

Routing

The Security Token Service is necessary for Single sign-on support. Therefore, if your Hubble installation provides Single sign-on capabilities, and:

  • if you configure Hubble web to be http, configure the load balancer to allow connections on port 7000, or
  • if you configure Hubble web to be https, configure the load balancer to allow connections on port 7001.

The Security Token Service will be listening on each web server on port 7000, whether the load balancer frontend is 7000 or 7001. The load balancer should therefore be routing the Security Token Service traffic from 7000 or 7001 (http or https) to the web servers on port 7000, as illustrated below:

Session Stickiness

Unlike Hubble Web on port 80/81, there should be no session affinity or session stickiness for Security Token Service routing.

SSL Certificates

If you are providing https support, you could configure the Security Token Service to use the same certificates that you are using for the Hubble Web frontend on port 81.

Troubleshooting

First, you should ensure that all the web servers and S3 storage are running by opening http://<web_server_IP> for each web server one by one, or using http://localhost from each web server itself. Usually this step is performed after every web server instance deployment. You can check the storage service availability by directly opening http://<application_server_IP>:591/ click-once/RepositorySelection.xml.

If those services are working but not available via the load balancer, your load balancer or firewall configuration requires revision. If either of those services is not available, then the problem is not with the load balancer and you may need assistance from the Hubble Support Team.

AspNet ApplicationCookie

If the load balancer relies on modified/hashed .AspNet.ApplicationCookie cookie and session persistence fails, please note that the .AspNet.ApplicationCookie value changes over time during the session, but it should not cause session redirection to another web server. The user's browser always sends requests with the latest known session cookie, which should cause routing to the same server.

Was this article helpful?

We're sorry to hear that.

Powered by Zendesk