Multi-server environments

A single server may be sufficient for your PureWeb implementation. If you require multiple servers, you will need to take load balancing and reverse proxies into consideration.

While the current clustering mechanism is still supported for small multi-server environments (2 to 3 servers), it is recommended that a load balancer be used for such environments instead.

A solution to improve management and scalability of multi-server environments is currently being developed for a future release of PureWeb.


Load balancing

The PureWeb solution has a very strong server affinity requirement. All requests in a given session, including collaboration sessions, need to be directed to a single server.

Traffic can be routed in two different ways, either using unique hostnames, or using a load balancer.

Using unique hostnames

You can give each node of the server farm a unique hostname. (Do not have a single hostname point to a server farm.)

In this case, your setup should have the following characteristics:

  • Create a local hostname to each node of the farm.
  • Create a corresponding hostname on the load balancer for each node. For simplicity, the load balancer's host name can be the same as the node's hostname.
  • Configure the load balancer to direct all traffic from the same host to the same node in the farm. A secondary node may be set up as a backup. If the primary server goes down, bring the secondary node online.
  • If the node in the farm responds to a different URL than the load balancer, configure the load balancer as a reverse proxy.

Using a load balancer

You can use a load balancer to route all traffic, without making the servers directly accessible. Your setup should have the following characteristics:

  • Each server must have a unique hostname on the network that is internal to the load balancer.
  • The load balancer must be configured to route requests to one of the servers. Sticky sessions, or session affinity, must be used with the JSESSIONID cookie to ensure that all traffic for one session is directed to the same server.
  • The load balancer must be configured not to modify the headers of the request as they are forwarded to the server. It must also not modify the response. This requirement is to preserve hostnames in the request so URLs can be generated that are valid for the client.
  • The load balancer must be configured to add a header containing an identifier for the server that will handle the request when before it is passed on. This is used to embed a host identifier in collaboration URLs.
  • The load balancer must be configured to inspect GET requests for /pureweb/share URLs and use the embedded host identification information to route the request to the correct server.

Reverse proxies

All server status pages depend on relative URLs that point to the base directory. If you are using reverse proxies that modify the path location, you must translate all links in status pages.

First, perform an analysis on the body of certain responses and translate the URLs to the proxied URL, then translate the response to a POST request for the following URLs:

  • /pureweb/app
  • /pureweb/app/*/*/*
  • /pureweb/app/*/*/*/*
  • /pureweb/share

You must parse the body of these responses to find links to the instance URLs. It is enough to look for http://serverinstancehost:8080 for the host machine that is serving as a server instance.

All of the above URLs are of exact length. Do not translate any subdirectories below these URLs.

You only need to translate responses to POST requests, but you can translate others without problems.