It's all about the answers!

Ask a question

CLM(JTS & CCM) Migration from one server to another


0
1
varun ibm (611722) | asked Sep 28 '13, 2:13 a.m.
 Hello All,

We have an existing Instance on RTC 4.0 which is installed on a server and this server will be decommisioned soon.
Hence now we need to Install a new Instance of RTC 4.0 in another server and also migrate all the data from the old server to the new server.

Our configurations are
CLM 4.0 (CCM 4.0 & JTS 4.0)
DB2 9.7
Tomcat application server
Ldap authentication

Hence we want to move
RTC 4.0 (old server) -> RTC 4.0(new server)
Data from DB2 -> DB2
Tomcat -> Tomcat
Ldap -> Ldap (Use same existing repository groups)

Note : The hostnames are different for both servers hence I am quite concerned.

Please suggest what is the best approach to do this ?

6 answers



permanent link
DH Lee (25784146) | answered Sep 29 '13, 10:59 p.m.
JAZZ DEVELOPER
Hello Varun, I found some information which would be useful for server migration.




Once above steps are completed 

- run repotools -reindex
- run repotools -rebuildTextIndices
- run repotools -rebuildIndices

You can also run jts/setup at this stage to ensure there were no mistake during manual migration process.

- You can also run jts/setup at this stage to ensure there were no
mistake during manual migration process

As far as I am aware, different hostname for server should not matter, unless you have set your public URI as your hostname or IP address. You will need to be more concerned if they would be using same public URI.


Hope it Helps 
DH



permanent link
Antoinette Iacobo (650512) | answered Sep 30 '13, 1:56 p.m.
 Hi Varun,

As DH said, this is key: different hostname for server should not matter, unless you have set your public URI as your hostname or IP address.  

As an alternative to using repotools to move the database, you could use the DB2 vendor tools to backup the db and restore to the new db server.  You would need to update the teamserver.properties with the new connection information. 

For the rest of the CLM configuration files, the easiest approach is to use DH's idea to make a file system backup and restore to the new environment.  

If for some reason, that can't be done, the alternative is to think of this as an upgrade.  Install CLM into the new location and then replace all the configuration files with the ones from the source server, including the Tomcat LDAP files.  


permanent link
Antoinette Iacobo (650512) | answered Oct 02 '13, 10:18 a.m.
Varun,

The moving of the installation from one server to another is *not* going to change any of these URLs. 

If you are saying that the public URI for the source is "https://integration1:9443/<context>" and that this "integration1" is also the host name, you should open a PMR so Support can help you understand how to select a good public URI,  discuss the options of server rename or maybe its possible to keep things the same but reconfigure your network.

Until the issues are discussed, no one can just give you a step-by-step.

Toni

Comments
varun ibm commented Oct 15 '13, 3:01 a.m.

 Hello DH & Toni,

I discussed the issue with IBM support by opening a PMR and they suggested a server rename. Now the server rename operation was successfull and also we are able to see all the project areas with data. But here's the problem. When I go the ccm/admin > server > run diagnostics

I get an error with the JFS Index , below is the attached error


permanent link
varun ibm (611722) | answered Oct 02 '13, 2:11 a.m.
Hello DH & Antoinette,

Thank you for the links, they were helpful.

Can you please give me a road map of steps that I would need to perform??
Let's say now I have 2 servers. 

Integration1(old)
Integration2(new)

Integration1 has Jts & ccm 4.0 installed. Db2 is configured on a different server.Ldap on a different server.
Now all project areas,workitems,plans,artifacts etc will be as 
https://integration1:9443/jts/admin
https://integration1:9443/ccm/admin
https://integration1:9443/web/projects/project1#action=com.ibm.team.workitem.viewWorkItem&id=37895

Now when I migrate to the new server ,ie. Integration2

Will all the links be changed to 
https://integration2:9443/jts/admin
https://integration2:9443/ccm/admin
https://integration2:9443/web/projects/project1#action=com.ibm.team.workitem.viewWorkItem&id=37895

How do I achieve this ? Or is there a different approach ? Kindly provide me the step by step for the same if possible. It'll be really helpfull.

Thanks again

permanent link
varun ibm (611722) | answered Oct 14 '13, 11:33 a.m.

Hello Toni,

I discussed the issue with IBM support by opening a PMR and they suggested a server rename. Now the server rename operation was successfull and also we are able to see all the project areas with data. But here's the problem. When I go the ccm/admin > server > run diagnostics

I get an error with the JFS Index

 

ERRORS:

   CRJZS5758E The information in the index for private applications might be incorrect because the timestamp (2013-10-11T14:54:45.712Z) of the "triple live" index is ahead of the timestamp (2013-10-11T14:14:54.152Z) of the database. Stop the server and either restore the index that corresponds to the database or run the following command: "repotools-ccm -reindex" to recover the correct index. For more details, open the help system and search for CRJZS5758E.
   CRJZS5758E The information in the index for private applications might be incorrect because the timestamp (2013-10-11T14:54:45.712Z) of the "text live" index is ahead of the timestamp (2013-10-11T14:14:54.152Z) of the database. Stop the server and either restore the index that corresponds to the database or run the following command: "repotools-ccm -reindex" to recover the correct index. For more details, open the help system and search for CRJZS5758E.
So should I run the repotools reindex command ? I am a bit scared if I will loose the data. Please advice.

permanent link
Antoinette Iacobo (650512) | answered Oct 15 '13, 9:16 a.m.
Varun,

There are 2 causes for this message, system clock of the database is out of sync with that of the application server or
the upgrade had database data from a later time than the indexes.  So depending on the cause, you need to either correct the system clock or recreate the indexes.  You aren't going to lose data recreating the indexes.  You can always take a file system backup of them first if you want. 

Your answer


Register or to post your answer.