IBM Rational ClearCase 7.1 CM Server Load Balancing Guide with
WebSphere Application Server Edge Component
This document outlines the steps need to configure Rational ClearCase 7.1 Change Management (CM) server load balance support for ClearCase Remote Client (CCRC) using WebSphere Application Server
(WAS) Edge components.
Rational ClearCase and ClearQuest 7.1 releases introduce the Change Management (CM) Server, which provides server-side support for Wide Area Network (WAN) interfaces to Rational ClearCase and Rational
ClearQuest.CM Server is a unified application server for both CCRC and ClearQuest Web. It leverages the performance, security and scalability of WebSphere Application Server. For detailed information regarding
CM server architecture, deployment and administration, please refer to Rational ClearCase 7.1 information center at: http://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp
CM Server Load Balance Overview
WebSphere Application Server Edge component Load Balancer intercepts data requests from CCRC or
ClearQuest Web clients and forwards each request to the backend CM servers that are currently best able to fill the request. In other words, it balances the load of incoming requests among a defined set of machines that service the same type of requests.
To support CCRC load balancing, the same shared view storage path is needed for all backend CM servers so that a client request can be served on a backend CM server where the CCRC view was not registered to.
This can be achieved by setting two MBean attributes on CM servers:
ccrcViewStorage (a UNC path for Windows CM servers, or an NFS path for Unix/Linux CM servers to the shared view storage)
ccrcUseViewHostPathForGlobalPath (must be set to “true”)
CCRC clients must use the load balancer cluster address (a URL that goes through the load balancer).
Setting up the Edge Component Load Balancer
We will use Edge component running on Windows 2003 server as an example for step to step configuration guide to set up load balancing for CM server using the Dispatcher component with the default forwarding method (MAC forwarding method).
Please refer to the following WebSphere Application Server information center for the Edge component, including supported platforms, installation and administration guide. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.edge.doc/welc ome.html
After Edge component is successfully installed, start the load balancer from the Start button.
Start->All Programs->IBM WebSphere-> Edge Components->Load Balancer->Load Balance
Next, configure the Edge Component Load Balancer Dispatcher. In this example, the server used is
“alva2”. Right clicking on Dispatcher and choosing the “Connect to Host…” option.
CCRC0710LB Rev. 1.0
It should present the option to:
Connect to host <fully qualified hostname> via the dispatcher on port 10099
In this example, on alva2, it said:
Connect to host alva2.rationalswg.ibm.com via the dispatcher on port 10099
Select this option and click OK.
Start the Executor manually if it has not done so already by:
Right clicking on the Executor and selecting Start Executor
CCRC0710LB Rev. 1.0
Under the Configurations Settings tab, check the settings.
Nonforwarding address: 9.34.105.250
Client gateway address: 9.34.105.1
Default Sticky Time (seconds): 600
If they are not set properly, correct them and click Update Configuration.
CCRC0710LB Rev. 1.0
Note that the Executor is configured with alva2’s primary (Nonforwarding) IP address of 9.34.105.250 and not the cluster IP (9.34.105.248 in this case).
Right click on the Executor and select “Add Cluster …” to define a cluster name.
CCRC0710LB Rev. 1.0
In this example a Cluster called CCRC-LoadBalancer with Cluster address of 9.34.105.248 was defined.
9.34.105.248 is assigned to the second network card on alva2. Click the OK button to define the cluste.
Click on the Configuration Settings tab and review the settings.
Default Sticky Time (seconds): 600
Primary host for the Cluster: 9.34.105.250
If the settings are wrong, correct them here before proceeding.
CCRC0710LB Rev. 1.0
Click the Update Configuration button to save any corrections.
Add a port to the cluster next. To do this, right click on Cluster (Cluster: CCRC-LoadBalancer in this
example) and select “Add Port …”
Enter 12080 (or the port number that CM server is running on the back-end CM servers) for the Port number and click the OK button.
Next, define the servers on the cluster. Do this by right clicking on Port: 12080 and selecting “Add
Server …”.
CCRC0710LB Rev. 1.0
and enter the Server and Server address for each cluster member and clicking on the OK button. In this example, we added three CM servers named calcium-ngz1, calcium-ngz2, and calcium-ngz3 with IPs 9.34.105.60, 9.34.105.67, and
9.34.105.247, respectively.
CCRC0710LB Rev. 1.0
Check the Configuration Settings tab on all the servers added. Correct any mistakes and click on the
Update Configuration button to save any changes.
CCRC0710LB Rev. 1.0
Next, start the Dispatcher Manager by right clicking on the Host (in this example Host:
alva2.rationalswg.ibm.com) entry and selecting Start Manager.
CCRC0710LB Rev. 1.0
This should bring up a Start Manager popup.
Click OK to start the Manager. The Start Advisor should pop up next.
CCRC0710LB Rev. 1.0
Enter 12080 (or the port number that CM server is running on the back-end CM servers) for the Port number and click on the OK button.
The Advisor for port 12080 is now enabled under the Manager for the CCRC-LoadBalancer cluster. The
Current Statistics should be displayed on the right.
The Configuration Settings tab for the Manager look something like this.
CCRC0710LB Rev. 1.0
The Configuration Settings tab on the Advisor should look something like this.
CCRC0710LB Rev. 1.0
The last step - check the system Services to ensure that the appropriate services such as the Dispatcher have started on the system. The IBM Dispatcher Windows service status should show “Started”.
Setting up Back-end ClearCase CM servers
Please refer IBM Rational ClearCase 7.1 information center for details about CM server installation at: http://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp
By default, the loopback device on a system is set to 127.0.0.1 with a netmask of 255.0.0.0. The load balancer requires that the loopback device of its cluster members point to the cluster.
For CM server running on Sun Solaris platform other than Solaris 10 non-global zone, issue the following command as root to configure the loopback device:
# ifconfig lo0 plumb <cluster IP> netmask <cluster netmask> up
For CM server running on Solaris 10 non-global zone platform, from the global zone, issue an “ifconfig” command to change the loopback setting for each non-global zone that is a member of the cluster. The following is an example:
# ifconfig lo0:1 plumb <cluster IP> netmask <cluster netmask> up
# ifconfig lo0:2 plumb <cluster IP> netmask <cluster netmask> up
# ifconfig lo0:3 plumb <cluster IP> netmask <cluster netmask> up
This change is made from the global zone because the global zone owns the network interface and the nonglobal zone cannot make the changes.
CCRC0710LB Rev. 1.0
For Windows CM server, you will need to install the Microsoft Loopback Adapter and assign it the cluster
IP address using the following steps:
Open the Control Panel and double-click on Add Hardware
Click the Next button.
CCRC0710LB Rev. 1.0
Choose the “Yes, I have already connected the hardware option” and click the Next button.
Select the “Add a new hardware device” and click the Next button.
CCRC0710LB Rev. 1.0
Select the “Install the hardware that I manually selected from a list (Advanced)” option and click the
Next button.
Select “Network adapters” and click the Next button.
CCRC0710LB Rev. 1.0
Select the “Microsoft Loopback Adapter” and click the Next button.
Confirm that the Microsoft Loopback Adapter was added.
Now set the IP address and the netmask for the Microsoft Loopback Adapter to the cluster.
CCRC0710LB Rev. 1.0
For CM servers on Red Hat Enterprise Linux version 4 or later, the process for aliasing the loopback device to the cluster is slightly different than for Solaris.
Some versions of Linux systems issue ARP responses for any IP address configured on the machine on any interface present on the machine. It may also choose an ARP source IP address for ARP who-has queries based on all IP addresses present on the machine, regardless of the interfaces on which those addresses are configured. This causes all cluster traffic to be directed to a single server in an indeterminate manner.
When using Dispatcher's mac forwarding method, a mechanism must be employed to ensure that clusteraddressed traffic can be accepted by the stacks of the back-end servers.
In most cases, you must alias the cluster address on the loopback; therefore, back-end servers must have the cluster aliased on the loopback.
To ensure that Linux systems do not advertise addresses on the loopback, you can use the following solution to make Linux systems (assuming Linux kernel is 2.4.25 or 2.6.5 or higher) compatible with
Dispatcher's mac forwarding.
# ifconfig lo $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl –w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2
# ip addr add $CLUSTER_ADDRESS/32 scope host dev lo
Note: When using sysctl, ensure that these settings survive reboot by adding the settings to /etc/sysctl.conf.
Legal Notices
Copyright IBM Corporation 2008 All Rights Reserved
IBM, WebSphere, Rational, ClearCase and ClearQuest are trademarks of International Business Machines
Corporation in the United States, other countries or both.
Solaris is registered trademarks of Sun Microsystems Incorporated in the United States, other countries or both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries or both.
Red Hat is a registered trademark of Red Hat, Inc. in the United States, other countries or both.
Windows is registered trademark of Microsoft Corporation in the United States, other countries or both.
Other company, product or service names may be the trademarks or service marks of others.
CCRC0710LB Rev. 1.0
