Load Balancer Configuration

Overview

In a Production environment, it is crucial that staff and students have continuous access to their applications (AppsAnywhere) and the following recommendations are in place for high availability.

To add a level of resilience and to share the workload, it is necessary to load balance particular AppsAnywhere services that span multiple servers.

• Provision a minimum of 2 servers for each service, or 3 servers for each service with a site license 

• Ideally, these servers should sit in a high-availability server environment across multiple hypervisor hosts and data centers (where possible)

• Use a redundant, high availability Microsoft SQL Server environment to host the database(s)

• Use a third party load balancer (hardware or software), with a single DNS address for each service.

The only exception is the Cloudpaging Paging service.  This service does not require the use of a third party load balancer.  When a connection attempt is made by the Client (Cloudpaging Player), it will run a connection test on all known Paging services and use the one with the best connection results, regardless of the server locations.

Parallels provide a load balancer appliance for use with RAS (only).  This can be used if required and no other preferred solution is available.  However as mentioned this is only compatible with the Parallels RAS application/software only.  It cannot be used to load balancer the AppsAnywhere or Cloudpaging servers.

Load balancer setup, configuration and maintenance remains the responsibility of the customer. It is outside of the scope AppsAnywhere Support can provide as it is a third-party application.

Please refer to your load balancer vendor for support and further information.

Templates

The following configuration templates and guides are available:

1. Citrix Netscaler / ADC

2. HAProxy

If further information is required for any type of load balancer, please refer to the vendor for more information.

Default Configuration

The following default configuration is required:

1. A load balanced DNS record should be created (e.g. https://demo.appsanywhere.com)

   1. So, rather than pointing to one specific server to access the service, we point to the load balanced DNS which shares the load between servers.

   2. The load balancer should use equal weighting so all servers used

2. Service health checks should be performed (every 30 seconds)

   1. Using the provided service health check URLs

   2. This is necessary as opposed to checking the server IP to determine whether or not the service is active. The server could be running while the service is not

3. Persistence needs to be set so that the load balancer persists the session you have established on a server rather than opening a new session on another server

   1. We recommend a minimum 30 minute IP persistence

4. Redirection should be setup so that http traffic is redirected to https

5. Redirection should preserve the URI

6. X-Forwarded-For should be enabled so the client IP is presented to AppsAnywhere

SSL Offloading

By default, we will apply certificates to AppsAnywhere, Cloudpaging and Parallels RAS Gateway servers where applicable.

SSL offloading can be used if you wish to manage the SSL certificate for the service via the load balancer. 

All traffic sent to the backend servers from the load balancer MUST be over HTTPS/443. 

AppsAnywhere uses Kerberos (Windows Integrated Authentication) to sign in the user automatically via the Windows Pass Through Single Sign On authentication method.  If the Kerberos request is modified by the decryption of the traffic and transmission over HTTP, it will invalidate the request and prevent the user from being signed in automatically.

Health checks

To ensure the load balancer can check the health of the backend servers, the following health check URL's are available:

Load balancing is not required for the Paging service. Adding a load balancer in front of this service will impact end user performance.

For testing, the following health check URL can be used:

The response format for all health check URLs will be a HTTP response, e.g

• HTTP 200 = Success

• HTTP 403 = Forbidden

• HTTP 500 = Internal Server Error

• HTTP 503 = Unavailable

• HTTP 303 = Redirected

If the server is down or offline a timeout will be returned.

Additional Considerations

In some situations we have seen that additional configuration is required for particular load balancers. 

Further configuration may be required, please refer to the vendor for more information.

• Kemp Load Balancer

  • Add HTTP Headers should be configured to use 'X-Forward-For (No Via)'

  • A template is available for Parallels RAS via https://kemptechnologies.com/docs/
    

• F5 (BigIP) Load Balancer

  • Parallels RAS Only:  The HTTPS health check needs to check for a HEAD value of '/RASHTML5Gateway/' and expect a 200 response.

  • It is necessary to disable HTTP inspection on port 443 traffic as F5 load balancers do not process a response for '/'

  • When testing the load balancing rules, if you receive a 'Server sends too much data' error please see K42151600: Error Message: 011f0016:3: http_process_state_prepend - Invalid action:<code> Server sends too much data.

    • Note: AppsAnywhere traffic is RFC compliant.

      1. AppsAnywhere traffic is HTTPS and Choosing appropriate profiles for HTTP traffic (f5.com) states that “HTTP profiles are not compatible when applied to encrypted HTTP traffic such as SSL passthrough traffic.”

      2. The Content-Length response header is calculated from the size of the file to be downloaded.

  • OneConnect = None*

  • Web Acceleration (cache) = None*

*Caching on the load balancer will prevent session tokens from being renewed during heartbeats and authorization requests, resulting in users receiving a session expired message.