Migrate Collaborative Lifecycle Management applications to a cluster: Part 3. Upgrade CLM applications to new versions

This series explains how to effectively manage Rational solution for Collaborative Lifecycle Management (CLM) applications that are deployed in a high-availability environment that uses cold standby for the applications and an IBM® DB2® HADR implementation for databases. In Part 3, Murali Dhandapani and Nanda Sivanandam describe how to use the primary and standby database servers while upgrading IBM® Rational Team Concert™, Rational® Quality Manager, and Rational® Requirements Composer from one version to another. They also explain how to upgrade the CLM applications by using a cold standby setup and provide instructions for upgrading Version 4.0.1 to 4.0.2 when the CLM integration is hosted in a cluster environment.

Murali Dhandapani (muralindia@in.ibm.com), IT Specialist, IBM

author photoMurali Dhandapani is part of the Operations Software Engineering Services team at IBM Software Labs, in India. He is an IBM Certified IT Specialist in System Management and a technical lead for Rational Jazz-based products infrastructure deployment. He is a contributing author for developerWorks.


developerWorks Contributing author
        level

Nandakumar Sivanandam (nasivana@in.ibm.com), IT Specialist, IBM

Author1 photoNanda Sivanandam is part of the Operations Software Engineering Service team at IBM Software Labs, in India. He has a master's degree in computer science and 10 years of experience in code library management. Nanda works as a technical consultant for IBM Rational ClearCase, ClearCase MultiSite, Unified Change Management (UCM), and Jazz-based software, including Rational Team Concert, Rational Quality Manager, and Rational Requirements Composer.



14 May 2013

Introduction

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.

The 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 202.12.167.138. This alias is used for public URI configuration for the CLM applications.

Figure 1. Collaborative Lifecycle Management setup with cold standby and DB2 HADR
CLM setup

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 202.12.167.138, 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.

Notes:

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

Important:

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

  1. 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%
  1. 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

Important:

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
project area dashboard
  1. Log in to the islswestest14.in.ibm.com server.
  2. Stop and uninstall these applications from the WebSphere Application Server profile that was configured with the CLM 4.0.1:
    • jts_war
    • clmhelp_war
    • ccm_war
    • admin_war
    • qm_war
    • rm_war
  3. 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
  1. 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:
    • jts_war
    • clmhelp_war
    • ccm_war
    • admin_war
    • qm_war
    • rm_war
  2. 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:

  1. 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.
  2. 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
$ cd /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/JazzTeamServer402

$ upgrade/jts/jts_upgrade.sh -oldJTSHome 
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/JazzTeamServer401/server/conf
-updateTomcatFiles no $ upgrade/ccm/ccm_upgrade.sh -oldApplicationHome
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/JazzTeamServer401/server/conf
-updateTomcatFiles no $ upgrade/qm/qm_upgrade.sh -oldApplicationHome
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/JazzTeamServer401/server/conf
-updateTomcatFiles no $ upgrade/rm/rm_upgrade.sh -oldApplicationHome
/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/JazzTeamServer401/server/conf
-updateTomcatFiles no
  1. Start the WebSphere Application Server profile, and install WAR files for CLM 4.0.2 applications.
  2. Configure the security roles and groups as you choose.
  3. Ensure that the custom properties are pointing to the CLM 4.0.2 JazzTeamServer402.
  4. Install the RM license, and complete the RM online migration.
  5. After the RM online migration is finished, install all other licenses, and complete the upgrade.
  6. 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.

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

  1. After restoring all of the files, ensure that the JTS, CCM, and QM teamserver.properties file is pointing to the primary database server:
    islswestest5.in.ibm.com.
  2. Stop WebSphere Application Server on islswestest14.in.ibm.com, and remove the alias IP 202.12.167.138. Then add the alias IP on islswestest3.in.ibm.com, and start the WebSphere Application Server there.
  3. Access the CLM application using the public URI, and verify that the server and applications status summary shows Version 4.0.2.
  4. 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.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps
ArticleID=929414
ArticleTitle=Migrate Collaborative Lifecycle Management applications to a cluster: Part 3. Upgrade CLM applications to new versions
publish-date=05142013