r11 - 2019-01-22 - 11:52:10 - ShubjitNaikYou are here: TWiki >  Deployment Web > DeploymentInstallingUpgradingAndMigrating > InstallProxyServers > CompareProxyServers

Reverse Proxies and Load Balancers in CLM Deployment todo.png

Authors: ShubjitNaik, DineshKumar, JimRuehlin
Build basis: CLM 6.0.6

This article focuses on the benefits and limitations of different Reverse Proxy Servers and Load Balancers used in standard deployment topologies of IBM Collaborative Lifecycle Management and Continuous Engineering Solutions.

Reverse Proxy

A Reverse Proxy is a gateway for servers, and enables one web server to provide content from other servers transparently. It can redirect the traffic to specific applications based on the configuration related to the context root in the URL. Example /ccm, /rm etc. For a distributed deployment, where each application from the stack within the CLM/CE deployment is deployed on its own server, to maintain a single Public URL and hide the underlying deployment you should use a Reverse proxy server.

For more Information visit Understanding Reverse Proxy

The only supported and tested Reverse Proxy server with CLM and CE Deployment is :

However, we have customers who have worked with other Proxy Servers for CLM and CE Deployment and we have listed them below :

Load Balancer

A Web server that takes cares of redirecting and balancing incoming traffic, based on configured algorithms, between different nodes in a Clustered Setup.

A load balancer is a requirement for a clustered setup: multiple instances of the same application are running connecting to the same database. As of the publication date, RTC is the only application that can be setup in clustered mode.

The supported and tested Load Balancers with Rational Team Concert Clustered Setup are:

The following tables lists the key differences between IHS and HAProxy

As a Reverse Proxy Supported and Tested
- The major advantage of using IBM HTTP Server is that a single server can be used as a Reverse Proxy and as the Load Balancer
Not Tested or Supported as a Reverse Proxy
- HAProxy is tested as a Load Balancer ONLY for RTC clustered setup in combination with IBM HTTP Server as a Reverse proxy
Support IBM Support Forum Support (Community Edition), IBM Support Policy on Third party and Open Source software

IBM has documented instructions on installation and configuration of HAProxy in the context of deploying a Clustered Setup of RTC
Operating Systems Can be installed on Windows, Linux and AIX Platforms Can be installed on Linux Platforms Only
CLM Versions Supported as a Load Balancer from CLM/CE version 6.0.5 Onwards Supported as a Load Balancer from CLM/CE 6.0.4 Onwards
Load Balancing The following Load Balancing Policies are supported by IHS, the default load balancing type is Round Robin.

Round Robin
The Round Robin implementation has a random starting point. The first application server is picked randomly. Round Robin is then used to pick application servers from that point forward. This implementation ensures that in multiple process-based web servers, all of the processes do not start by sending the first request to the same Application Server.

The Random implementation also has a random starting point. However with this implementation all subsequent servers are also randomly selected. Therefore, the same server might get selected repeatedly while other servers remain idle.
HAProxy supports a rich set of Load Balancing algorithms and the default is Leastconn. Following are a few examples:

Round Robin
Each server is used in turns, according to their weights. This algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts for instance. Note that in some large farms, when a server goes up after having been down for a very short time, it may sometimes take a few hundreds requests for it to be re-integrated into the farm and start receiving traffic. This is normal, though very rare. It is indicated here in case you would have the chance to observe it, so that you don't worry.

Static Round Robin
Each server is used in turns, according to their weights. This algorithm is as similar to roundrobin except that it is static, which means that changing a server's weight on the fly will have no effect. On the other hand, when a server goes up, it is always immediately reintroduced into the farm, once the full map is recomputed. It also uses slightly less CPU to run (around -1%).

The server with the lowest number of connections receives the connection. Round-robin is performed within groups of servers of the same load to ensure that all servers will be used. This algorithm is dynamic, which means that server weights may be adjusted on the fly for slow starts for instance.

The source IP address is hashed and divided by the total weight of the running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. This algorithm is static by default, which means that changing a server's weight on the fly will have no effect, but this can be changed using "hash-type".
High Availability YES YES
Monitoring External Tools can be used Statistics Reports is Bundled with HAProxy UI. External Tools can be used as well

  • HAProxy's additional options for load balancing makes it an attractive option for deployments in which the admin team value this flexibility and can accept the cost of another proxy specifically for load balancing.

Content Caching Proxy

It is possible to cache files managed by RTC SCM to improve the performance of remote SCM access and build servers. For more information about using the Squid Caching proxy, see

Additionally we have reports of some customers using Apache Traffic Server as content caching proxies for RTC SCM.

Related topics: Deployment web home, Installing Proxy Servers

External links:

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r17 | r13 < r12 < r11 < r10 | More topic actions...
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.