It's all about the answers!

Ask a question

Any harm keeping 2 distinct URLs for JTS and RTC respectively on a single server?


Larry Short (112) | asked Sep 10 '18, 1:28 a.m.
edited Sep 10 '18, 1:41 a.m.

 We are tasked with upgrading RTC 4.0.7 to 6.0.6 via 5.0.2, as this is a 2-step upgrade.


Below are what have been either in place, or planned and procured, i.e. we are not allowed to change:
  • 6.0.6 will be on a new server, with topology changed to single host
    • on PRD: nCLMpFQN
    • on TST:  nCLMtFQN
  • MS SQLserver DBs are on Windows servers, and 6.0.6 DBs would also be on new servers.
We are to plan the upgrade through the shortest route possible, while keeping it transparent to users.

We are planning to use TST env as POC for PRD, and have cloned the PRD DBs over to TST, with DB backup synced to AppSide index backup.

Our proposed use of hosts file spoofing on TST was shot down by management for the risk of contamination of PRD, as PRD and TST are not on isolated networks. So we will have to recourse to  "server rename" on TST to be able to start the upgrade with PRD-cloned DBs.

Here is our current plan:
  • Create 2 DNS aliases for the new TST server nCLMtFQN:
    • JTStst.Ddom.com
    • JAZZtst.Ddom.com
  • "Server Rename" the 2 PRD public URIs to the 2 TST public URIs, constructed with the 2 new DNS aliases on TST
  • Flip the 2 DNS aliases JTStst and JAZZtst over to the old JTS server jtsTfqn and the old RTC server rtcTfqn respectively.
  • Validate the cloned DBs with 4.0.7
  • Install 5.0.2 JTS and RTC on the old JTS server jtsTfqn
  • Flip the DNS JAZZtst over to the old JTS server jtsTfqn (from the old RTC server rtcTfqn) to accommodate the change of topology to single host for 5.0.2
  • Upgrade to 5.0.2
  • Light on test of 5.0.2 with existing TST DBserver (SQLserver 2008)
  • Copy the DBs to the new TST DBserver (SQLserver 2012)
  • Validate 5.0.2
  • Flip back the 2 DNS aliases to the new TST appServer nCLMtFQN
  • Install and upgrade to 6.0.6
  • Validate 6.0.6
We will proceed same on PRD without any "server rename" as the start-from DBs are the same existing ones on PRD.

There are worries about the unusual use of 2 distinct public URIs for single host topology for JTS and RTC respectively.
We couldn't think of or google for any harm using the same 2 public URIs on a single host topology. We have also validated the use of 2 distinct public URIs on POC with a fresh install of 6.0.6. Pls let us know if we miss any consequences serious enough having to:
  • Add a topology conversion step on 4.0.7 to consolidate to 1 public URI, requiring
    • The addition of a "server rename" on PRD, which is in Production, and clearly outside of the supported cases, against the severe warnings from IBM on the use of "server rename" below.
    • An install of 4.0.7 to bring RTC to the JTS server on both TST and PRD 
  • Be considered unworkable that "server rename" on PRD has to be used as last resort.
  • IBM warnings on using "server rename" *** Important: Server rename is a complex and potentially disruptive operation because correcting the stored links to the server from other applications and systems may be difficult or impossible. Server rename is only supported for a specific set of scenarios and requires careful planning. Use server rename only as a last resort when other approaches are unworkable.". 



Comments
Larry Short commented Sep 10 '18, 9:02 a.m. | edited Sep 10 '18, 9:05 a.m.

 PRD upgrade

  • Shut down RTC and JTS.
  • Install 5.0.2 JTS and RTC on the old JTS server jtsPfqn
  • Flip the DNS rtc over to the old JTS server jtsPfqn (from the old RTC server rtcPfqn) to accommodate the change of topology to single host for 5.0.2
  • Upgrade to 5.0.2
  • Light on test of 5.0.2 with existing PRD DBserver (SQLserver 2008) 
  • ... continued 


Larry Short commented Sep 10 '18, 9:04 a.m.

 

  • cont'd ...
  • Copy the DBs to the new PRD DBserver (SQLserver 2012)
  • Validate 5.0.2
  • Flip the 2 DNS aliases jts and rtc to the new PRD appServer nCLMpFQN
  • Install and upgrade to 6.0.6
  • Validate 6.0.6

Be the first one to answer this question!


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.