The Part 1 and Part 2 of this series explained deploying the Rational Solution for Collaborative Lifecycle Management (CLM) applications in highly available and disaster recovery situations. This article provides instructions for upgrading CLM applications already deployed by using multiple servers.
This focus of this article is to illustrate the approach to upgrade the Rational solution for Collaborative Lifecycle Management applications when they are deployed in a cluster environment. CLM integrates IBM® Rational Team Concert™, Rational® Quality Manager, and Rational® Requirements Composer. In this setup, the applications are hosted on a cold standby cluster, and the databases are configured as primary (active) and standby by using separate servers for each of those states. Any change that takes place on the primary database server will be replicated to the standby database server automatically where as any changes, updates that take place for the applications in Active CLM server has to be manually done on the cold standby CLM server.
Collaborative Lifecycle Management upgrade setup example
The diagram in Figure 1 shows the setup used as the basis for this article. Two servers, islswestest14.in.ibm.com and islswestest3.in.ibm.com, were used for CLM active and cold standby setups, respectively. The islswestest14.in.ibm.com server has an additional alias name, islswestest4.in.ibm.com, which resolves to IP 18.104.22.168. This alias is used for public URI configuration for the CLM applications.
Figure 1. Collaborative Lifecycle Management setup with cold standby and DB2 HADR
For the CLM high-availability setup explained in Part 1 of this series: During any planned or unplanned downtime for the active CLM server, the alias IP address 22.214.171.124, which is resolving to islswestest4.in.ibm.com, must be configured in islswestest3.in.ibm.com to maintain the same public URI for the CLM application.
For the disaster recovery setup explained in Part 2:
- Either the alias IP of the cold standby server at Site B resolves to islswestest4.in.ibm.com by performing necessary DNS record changes to have the same Public URI of the CLM application.
- Or all of the CLM application client users must update the IP and hostname in the /etc/hosts files in their respective client machines, regardless of whether they use Linux or Microsoft Windows operating systems.
The steps to perform for a high-availability CLM environment having all four servers (active and cold standby CLM servers and primary and standby DB2 servers) in the same location. A disaster recovery CLM environment has Active CLM and primary DB2 database servers at one location and cold standby CLM and standby DB2 database servers are utmost similar.
Upgrade CLM with cold standby and the DB2 HADR implementation
This section illustrates the steps to follow while upgrading Collaborative Lifecycle Management applications in a cluster environment. It is based on the assumption that the active CLM server is connected with the primary database server and providing the service to CLM users. These are the high-availability disaster recovery (HADR) roles and States for all of the databases:
- Primary DB2 server
- Role = Primary
State = Peer
- Standby DB2 server, islrpbeipl112.in.ibm.com
- Role = Standby
State = Peer
Step 1. Run the HADR takeover command
Log in to the standby DB2 server (islrpbeipl112.in.ibm.com), and execute the HADR takeover command shown in Listing 1.
Listing 1. HADR takeover command on the standby DB2 server
$ su – clm401is $ db2 takeover hadr on database DW DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database JTS DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database CCM DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database QM DB20000I The TAKEOVER HADR ON DATABASE command completed successfully.
- Rather than upgrading the CLM applications by using the primary DB2 database server (islswestest5.in.ibm.com), we switch the HADR role of primary and standby between islswestest5.in.ibm.com and islrpbeipl112.in.ibm.com servers by using the HADR takeover command and perform the upgrade by using islrpbeipl112.in.ibm.com.
- You can directly use the primary DB2 database server, islswestest5.in.ibm.com for the upgrade instead, but ensure that you make a full backup copy for all of the databases before performing the upgrade.
If the alternate server hostname and port number are not configured as part of the HADR configuration, stop IBM® WebSphere® Application Server before executing the takeover commands on the standby database server.
Step 2. Verify the role and state of the databases
- Log in to islswestest5.in.ibm.com, and verify the role and state for all of the CLM databases (see Listing 2):
- Role = Standby
- State = Peer
Listing 2. Check the role and state of the database
$ db2pd -db JTS -HADR Database Partition 0 -- Database JTS -- Standby -- Up 7 days 21:00:56 -- Date 04/27/2013 15:00:23 HADR Information: Role State SyncMode HeartBeatsMissed LogGapRunAvg (bytes) Standby Peer Nearsync 0 2057 ConnectStatus ConnectTime Timeout Connected Thu Apr 25 17:13:30 2013 (1366890210) 120 LocalHost LocalService islswestest5.in.ibm.com 64006 RemoteHost RemoteService RemoteInstance islrpbeipl112.in.ibm.com 64007 clm401is PrimaryFile PrimaryPg PrimaryLSN S0000240.LOG 942 0x000000014AAEE756 StandByFile StandByPg StandByLSN StandByRcvBufUsed S0000240.LOG 942 0x000000014AAEE023 0%
- After the verification, deactivate all of the databases and stop the instance, as shown in Listing 3.
Listing 3. Deactivate databases
$ db2 deactivate db DW $ db2 deactivate db QM $ db2 deactivate db CCM $ db2 deactivate db JTS $ db2stop
By deactivating the databases and stopping the instance, you can ensure having one full backup for all the CLM databases. However, if you prefer to make a full backup for all of the databases from islswestest5.in.ibm.com, make it before executing the takeover command on the standby database server. Only the database with the primary role will allow the backup command to perform the backup successful.
Step 3. Verify access to the CLM applications
Because alternate server hostname and port number parameters are configured in the HADR configuration, even though the databases are deactivated and the clm401is instance is stopped on the islswestest5.in.ibm.com server, the CLM application must be still accessible by using the databases on islrpbepl112.in.ibm.com. You can verify CLM access as shown in Figure 2.
Figure 2. Access the project area by using the web client
- Log in to the islswestest14.in.ibm.com server.
- Stop and uninstall these applications from the WebSphere Application Server profile that was configured with the CLM 4.0.1:
- Stop the profile as shown in Listing 4.
Listing 4. Stop the WebSphere Application Server profile
$ cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/bin $ ./stopServer.sh server1
- Log in to the cold Standby CLM WebSphere Application Server, islswestest3.in.ibm.com, stop and uninstall the CLM 4.0.1 applications configured there, too:
- Stop the profile.
Step 4. Upgrade the CLM application
The commands in Listing 5 provide a high-level view of the upgrade commands used as examples for this article. See the link to "Upgrading to version 4.0.2" in Resources for an interactive upgrade guide with more detailed steps. What follows are the steps completed in working on this upgrade example:
- Empty the temp and wstemp folders, and remove CLM application logs from the WebSphere Application Server profile that was used for the CLM 4.0.1 configuration.
- Copy the CLM 4.0.2 JazzTeamServer folder to the WebSphere Application Server profile, and then execute the upgrade commands, one by one.
Listing 5. Run these upgrade commands, one by one
- Start the WebSphere Application Server profile, and install WAR files for CLM 4.0.2 applications.
- Configure the security roles and groups as you choose.
- Ensure that the custom properties are pointing to the CLM 4.0.2 JazzTeamServer402.
- Install the RM license, and complete the RM online migration.
- After the RM online migration is finished, install all other licenses, and complete the upgrade.
- After completing the upgrade, log in to the CLM applications, and verify that the status summary displays Version 4.0.2. Access project areas to ensure that the upgrade has completed successfully.
Step 5. Activate the database on islswestest5.in.ibm.com
Log in to the islswestest5.in.ibm.com server, start the clm401is instance, and start HADR as standby, as shown in the Listing 6.
Listing 6. Start the database and HADR in standby mode
$ su – clm401is $ db2start $ db2 start HADR on database DW as STANDBY DB20000I The START HADR ON DATABASE command completed successfully. $ db2 start HADR on database JTS as STANDBY DB20000I The START HADR ON DATABASE command completed successfully. $ db2 start HADR on database QM as STANDBY DB20000I The START HADR ON DATABASE command completed successfully. $ db2 start HADR on database CCM as STANDBY DB20000I The START HADR ON DATABASE command completed successfully.
Step 6. Synchronize all databases
Verify the role and state of all CLM databases, and ensure that the log files are in sync, as shown in Listing 7.
Listing 7. Check the database role and state
$ db2pd -db QM -HADR Database Partition 0 -- Database QM -- Standby -- Up 0 days 00:06:12 -- Date 04/27/2013 16:34:54 HADR Information: Role State SyncMode HeartBeatsMissed LogGapRunAvg (bytes) Standby Peer Nearsync 0 3144 ConnectStatus ConnectTime Timeout Connected Sat Apr 27 16:28:43 2013 (1367060323) 120 LocalHost LocalService islswestest5.in.ibm.com 64002 RemoteHost RemoteService RemoteInstance islrpbeipl112.in.ibm.com 64003 clm401is PrimaryFile PrimaryPg PrimaryLSN S0000287.LOG 2400 0x000000014A8A0BC1 StandByFile StandByPg StandByLSN StandByRcvBufUsed S0000287.LOG 2400 0x000000014A8A0443 0% bash-3.2$
After the state becomes Peer and the logs are in sync for all of the databases, you can change the role for all the databases on this database server (islswestest5.in.ibm.com) to primary. To do that, use the HADR takeover command shown in the Listing 8.
Listing 8. Run the HADR takeover command
$ db2 takeover hadr on database DW DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database JTS DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database CCM DB20000I The TAKEOVER HADR ON DATABASE command completed successfully. $ db2 takeover hadr on database QM DB20000I The TAKEOVER HADR ON DATABASE command completed successfully.
Verify the role and state again for all of the databases on islswestest5.in.ibm.com. They should have changed to Primary and Peer, respectively, as shown in the Listing 9.
Listing 9. Check the database role and state
$ db2pd -db QM -HADR Database Partition 0 -- Database QM -- Active -- Up 0 days 00:16:19 -- Date 04/27/2013 16:45:01 HADR Information: Role State SyncMode HeartBeatsMissed LogGapRunAvg (bytes) Primary Peer Nearsync 0 3042 ConnectStatus ConnectTime Timeout Connected Sat Apr 27 16:28:43 2013 (1367060323) 120 LocalHost LocalService islswestest5.in.ibm.com 64002 RemoteHost RemoteService RemoteInstance islrpbeipl112.in.ibm.com 64003 clm401is PrimaryFile PrimaryPg PrimaryLSN S0000287.LOG 2440 0x000000014A8C8E42 StandByFile StandByPg StandByLSN S0000287.LOG 2440 0x000000014A8C85E0
The CLM application server starts, using the databases from islswestest5.in.ibm.com without any interruption for the users. This completes the steps to perform while upgrading CLM from version 4.0.1 to 4.0.2 in the cluster environment with the DB2 HADR implementation.
Upgrade the cold standby CLM server
The WebSphere Application Server profile on the cold standby server is already in stop state, and the CLM 4.0.1 WAR files are uninstalled while uninstalling the same on islswestest14.in.ibm.com server.
- Copy the CLM 4.0.2 JazzTeamServer402 folder to the WebSphere Application Server profile path. Ensure that these files and folders are restored properly from the islswestest14.in.ibm.com server:
- friends.rdf files from the Admin folder
- friendsconfig.rdf and fronting.properties from the RM folder
- indices folder and fulltext.indexLocation folders for JTS, CCM, and QM
See the link in Resources to "Back up the Rational solution for Collaborative Lifecycle Management," which provides details about various folders that need to be backed up. This helps restore the CLM server to its original state. See the link to "Setting up WebSphere Application Server" in the Resources section for more configuration details.
- After restoring all of the files, ensure that the JTS, CCM, and QM teamserver.properties file is pointing to the primary database server:
- Stop WebSphere Application Server on islswestest14.in.ibm.com, and remove the alias IP 126.96.36.199. Then add the alias IP on islswestest3.in.ibm.com, and start the WebSphere Application Server there.
- Access the CLM application using the public URI, and verify that the server and applications status summary shows Version 4.0.2.
- Stop WebSphere Application Server on islswestest3.in.ibm.com, revert the alias IP to islswestest14.in.ibm.com, and then start WebSphere Application Server on islswestest14.in.ibm.com.
You have successfully upgraded Collaborative Lifecycle Management applications from Version 4.0.1 to 4.0.2 in your cluster environment.
- See these resources for more information related to this article:
- Upgrading to version 4.0.2 of the Rational solution for Collaborative Lifecycle Management (CLM)
- Setting up WebSphere Application Server for CLM
- Back up the Rational solution for Collaborative Lifecycle Management
- Read the previous parts of this series, Migrate Collaborative Lifecycle Management to a cluster:
- Learn more about CLM:
- IBM Rational solution for Collaborative Lifecycle Management 4.0 releases
- Installing the Rational Solution for CLM
- System requirements for CLM 2012
- IBM Rational solution for Collaborative Lifecycle Management 4.0 information center
- IBM Rational solution for Collaborative Lifecycle Management 4.0 sandboxes
- Backup the Rational solution for Collaborative Lifecycle Management
- Find out more about IBM DB2 High Availability Disaster Recovery (HADR) feature in the information center and by reading the IBM Redbooks publication, High Availability and Disaster Recovery Options for DB2 for Linux, UNIX, and Windows
- Explore the Rational software area on developerWorks for technical resources, best practices, and information about Rational collaborative and integrated solutions for software and systems delivery.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics. Watch developerWorks on-demand demos, ranging from product installation and setup demos for beginners to advanced functionality for experienced developers.
Get products and technologies
- Download a free trial version of Rational software.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment.
- Join the Rational software forums to ask questions and participate in discussions.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Join the Rational community to share your Rational software expertise and get connected with your peers.
- Rate or review Rational software. It's quick and easy.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.