We know how crucial it is that your staff and students have continuous access to their applications. When designing the infrastructure that will run your services, we make the following recommendations for high availability.
In order to add a level of resilience and to share the workload it is necessary to load balance particular parts of the 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.
The following configuration templates and guides are available:
If you require further information or your load balancer is not listed above, the information below contains details of the required configuration.
The following default configuration is required:
A load balanced DNS record should be created (e.g. https://demo.appsanywhere.com)
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.
The load balancer should use equal weighting so all servers used
Service health checks should be performed (every 30 seconds)
Using the provided service health check URLs
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
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
We recommend a minimum 30 minute IP persistence
Redirection should be setup so that http traffic is redirected to https
Redirection should preserve the URI
X-Forwarded-For should be enabled so the client IP is presented to AppsAnywhere
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.
To ensure the load balancer can check the health of the backend servers, the following health check URL's are available:
Cloudpaging Admin/License: https://<Server_FQDN>/jukeboxserver/do/license/token/renew.tok?msid=ping
Token service is ready.
Parallels RAS Gateway: https://<Server_FQDN>/RASHTML5Gateway
HTTP 200 (the portal page loads)
For legacy customers using the Cloudpaging Enterprise Portal:
Enterprise Portal: https://<Server_FQDN>/jukeboxdrm/ping.do
Enterprise service is ready.
Although load balancing is not required for the Cloudpaging paging service, you can use the following health check URL to monitor the service on each server if required:
Paging Service: http://<Server_FQDN>/jukeboxserver/stream/client.do?msid=ping
Stream service is ready.
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.
In some situations we have seen that additional configuration is required for particular load balancers.
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.
Any additional considerations or configurations for load balancers that are listed in the templates section are included within the specific template documentation.