EditAttachPrintable
r14 - 2019-03-29 - 09:33:38 - ShubjitNaikYou are here: TWiki >  Deployment Web > DeploymentInstallingUpgradingAndMigrating > InstallProxyServers > CompareProxyServers

Reverse Proxies and Load Balancers in CLM Deployment new.png

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

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

DNS Aliasing

URIs have an important role in Jazz architecture. When you plan your deployment and installation of the Rational solution for Collaborative Lifecycle Management (CLM), you must decide which URI to use for the server. This is referred to as the Public URI.

The standard deployment of CLM Solution has multiple application servers and in most production deployments each application runs on it own application server / host.

You can configure your deployment using DNS aliasing , however this will result in separate DNS name for each application, example jts.example.com, ccm.example.com etc. This could be an administrative overhead on a production deployment when they are to be scaled, migrated or replicated. From an end user perspective they will have to remember multiple URIs. Securing such a deployment will incur additional cost as each DNS Name would require a distinct SSL Certificates (CA) For more information visit this link

The recommended approach is to deploy a Reverse proxy. This way you can refactor the physical topology and still maintain the URIs. You can maintain a common source URL for example clm.example.com and reach each application via it context root, example /ccm, /rm etc. This will give much more flexibility during scenarios of scaling and migrations. With a reverse proxy in place, securing the deployment will be simpler with one SSL Certificate (CA) for the reverse proxy.

Reverse Proxy Server

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 and Reverse Proxy in Topologies

The only supported and tested Reverse Proxy Server for CLM/CE deployments is:

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


Load Balancer Server

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
  IBM HTTP SERVER HAPROXY
     
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.

Random
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%).

Leastconn
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.

Source
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".
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.

Related topics: Deployment web home, Installing Proxy Servers

External links:

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r17 < r16 < r15 < r14 < r13 | 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.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project