It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×10,962
×7,476
×4,321
×3,952
×2,353
×1,381

question asked: Oct 10 '18, 1:35 p.m.
question was seen: 3,256 times
last updated: Oct 23 '18, 4:08 p.m.

Related questions

How to upgrade CLM on separate servers to RTC on single server?

0
long TRUONG (365●4●123●147) | asked Oct 10 '18, 1:35 p.m.
retagged Oct 23 '18, 4:08 p.m. by Ken Tessier (841●1●7)

We are upgrading RTC 4.0.5 to 6.0.4 via 5.0.2, as this is a 2-stage upgrade. 

We also change topology and drop RRC and RQM from CLM:
from CLM JTS/RRC, RTC, RQM on 3 separate servers (without proxy) and 3 JVMs to just RTC on single JTS server for 502 (then go on upgrading to 6.0.4 on single new RTC appServer) with 1 single JVM.

Second of 2 questions: How would the upgrade, on the old JTS server, pick up the 405 RTC teamservcer.properties from the now remote, old RTC server to upgrade?

Steps done so far
  • Installed 5.0.2 on Linux old JTS server
    • Forced to use the only install type available, silent install with (CL) OOTB response file, as IBMim GUI and web installs are off limit, and 5.0.2 cannot be installed via (CL) console install.
    • Hence the install 
      • included RRC and RQM unnecessary, 
      • included extra wars (qm, rm, converter) in .../server/tomcat/webapps
      • used  ccm for RTC context root
      • named RTC war ccm.war
    • Requiring post install modifications:
      • Only moved the required war files (ccm, jts, clmhelp) to .../server/webapps (this is cosmetic)
      • renamed ccm.war to jazz.war
      • Modified context root to jazz by renaming folder /server/conf/ccm to /server/conf/jazz
  • Reconfigured WAS for 502 with 1 JVM and 3 war files, from 405 with 3 JVMs and more war files

Hopefully we successfully execute:
  • Lights on test: launch JVM, login
  • Shut down JVM
  • Copy iFix27 into patching location
  • Lights on test: launch JVM, login
  • Upgrade

Or, otherwise, adopt the alternate steps:
  • have configured WAS first to ccm context root, ccm.war under .../server/tomcat/webapps
  • then lights on
  • then patch with ifix while JVM is off.
  • then re-configure WAS to jazz context root, jazz.war under .../server/webapps
  • then lights on
  • then upgrade
We are not installing and upgrading as root, but as hosting, a WAS serviceID, on both (all, including RQM server) servers. Note also that we use 2 distinct public URIs for JTS and RTC, respectively. For the upgrade: 
  • How would we access the RTC teamserver.properties from a remote host (hosting owns the file and the install area on both the old JTS and RTC hosts)?
  • Would we have to copy the properties files (and any other files) onto the install old JTS host?

2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Rosa Naranjo (2.9k●1●17●23) | answered Oct 10 '18, 3:10 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hello
There is alot here to cover for a forum post. But I will try to answer one of your questions. and in the process ask you if you have generated an Interactive Upgrade guide(IUG) for this upgrade. The IUG goes through the entire process after you provide inputs based on your specific environment.

Q: How would the upgrade, on the old JTS server, pick up the 405 RTC teamserver.properties from the now remote, old RTC server to upgrade?

A:  The upgrade script has a series of steps, the first of which is to copy the teamserver.properties from old(source) to new(target) directory.  The IUG will ask if you can mount network drives or not and advise accordingly.

Q: I think somewhere in there you have questions about how the iFix patch works or is applied. 

A:  All that is needed for example, for the server*.zip patch file to take effect is what is mentioned in the readme.  Put it in the server\patch folder and run repotools-<cr>.sh -clean where -cr is the context root of the various applications on that app server you are patching.


A word of advice on upgrade planning - keep it as simple as possible and minimize the amount of moving/changing parts.

For example, why upgrade RRC if you do not plan to use it or move forward with it in the end, v6.0.4?


Comments
long TRUONG commented Oct 10 '18, 7:16 p.m. | edited Oct 10 '18, 7:17 p.m.

 Thx Rosa,


For the quick response.
Saw only one topology option on IUG: Source and target topo both either single svr or multiple. Is there 1 for many svrs source topo to 1 host target topo?

Brought in to complete a plan which has gone far enough w new hosts already procured to upgrade to new SS topo, yet not far enough for compatibility of SQL, TLS, and RHEL OS.
UAT used as POC for PRD upgrade, with DBs cloned from PRD (Current PAs on old DEV and UAT servers are all play PAs with no relation to anything on PRD).

This is actually an upgrade on UAT, using existing UAT DBs, after:
  • The risk of forwarding address (hosts file spooing) is not acceptable
  • We are bogged down with server rename, can't yet generate a mappings file successfully
We will only use UAT as POC for the upgrade process, not for PRD DBs, nor for the estimate of downtime required; as the delay, efforts, and risk associated with server rename became too expensive for last two.

0
permanent link
Jim Ruehlin (791●1●4) | answered Oct 10 '18, 3:48 p.m.
JAZZ DEVELOPER

Hi Long,

You're planning a significant upgrade and you'll want to make sure you've covered everything. There are some best practices that you should keep in mind:

Upgrade to a staging environment and test before moving your users to a new version.
Upgrade incrementally and stabilize. For example, you'll probably need to upgrade your database as you upgrade CLM. Upgrade one, then the other, rather than doing them both at the same time.
Upgrade to 5.0.2, stabilize and get your users comfortable, then upgrade to 6.x.
Be aware of the system requirements at each level. Things can get tricky with a double-upgrade. For example, if you're on SQL Server you'll probably need to upgrade your DB twice in order to get to 6.x. Understanding the version requirements for supporting software can get complex and can impact your upgrade plans.
Use the Interactive Upgrade Guide as Rosa mentioned. You can find it in the Knowledge Center.
Have a rollback strategy that's been tested. If you find a problem after you deploy an upgrade in a production environment, you'll want to be able to go back to the last stable place so your users can keep working.
It looks like you don't use reverse proxies. Consider adding a reverse proxy as part of the upgrade plan. This will make your CLM instance more flexible and supportable. Note that this might involve adding a server rename to your upgrade steps.
Create a complete and tested "run book" for each stage of the upgrade. When you upgrade your production environment you want to have done it successfully in your staging environment so you can easily repeat the success. Include EVERYTHING: The DB admin and their backup in case you need to have them restore the DB, the rollback plan, the person who has the passwords that you need, etc.
Give yourself plenty of time for the upgrade. You need to research, plan, test, update the Run Book, possibly roll back, etc. Trying to rush it will increase you risk.
Review the Deployment Wiki for Migrations and Upgrades. You can find system requirements and much more on that page.

You can leverage IBM Support for specific issues you come across. You can also engage us to discuss/review your overall upgrade plans. Go through the regular support channels and/or contact your account rep. If you need help engaging with us, please contact me at jruehlin@us.ibm.com.

You should also consider upgrading to the latest version of CLM rather than 6.0.4. It will save you potential upgrades in the future. It looks like your organization doesn't upgrade much so take advantage of this opportunity to get to 6.0.6 ifix3. It has significant quality improvements in it as well new features.

Good luck,
Jim

Comments
long TRUONG commented Oct 10 '18, 7:41 p.m.

Thx Jim,


For the quick response. Pls note the same comments to Rosa.

And the additional comments I cannot cram into the allotted comments space:
  • On DEV, a straight install of 6.0.4 was completed with brand new DBs, absolutely no upgrade from current env and servers. No choice but to do so to gain traction and buy in to the 2-stage upgrade, on UAT & eventually PRD, instead of an install of 6.0.4 on new servers with migration of PAs and only tip versions of Source Control.
  • If I had my choice I would have chosen upgrade of CLM (JTS/RRC. RTC, RQM) 405 to RTC 6.0.4 on 2 separate servers, JTS and RTC respectively. At least for as the first phase. 
  • I only started on the tail end of this remediation efforts, practically have only 4 mos, with only verbal plan & road map: so evrything is rush and rush, without any appreciation for the complex nature of CLM upgrade & of the inclusion of so many changes at once.
  • Going to 2-stage upgrade not easy, let alone a pause to settle down with 5.0.2 first.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.