CLM(JTS & CCM) Migration from one server to another
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
Hello Varun, I found some information which would be useful for server migration.
Back up : https://jazz.net/library/article/547
Migrating database : http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/t_migrate_dbs.html&scope=null
Follow http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m3/index.jsp?re=1&topic=/com.ibm.jazz.install.doc/topics/t_manually_update_config_db2.html&scope=null to configure DB2 for new server if it has been done already.
Once above steps are completed
- run repotools -reindex
- run repotools -rebuildTextIndices
- run repotools -rebuildIndices
- 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
- 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
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.
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.
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
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
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
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
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.
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.
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.