It's all about the answers!

Ask a question

RTC 5.0.2 - Migrating from Single server to Enterprise topology


vishnudharan manivannan (1182641) | asked May 06 '15, 2:27 a.m.
 Hello All,

We have the below CLM setup

OS             : Suse Linux Enterprise Server 11 Sp3
CLM Apps : JTS+CCM 5.0.2
App Server: WAS 8.5.5 Base server (Single profile for both jts & ccm)
DB2 Server: IBM DB2 10.5

It is all in one single server topology.

Now we would like to move to CLM - E1 Enterprise - Distributed /Linux /DB2 as illustrated in Deployment/RecommendedCLMDeploymentTopologies5

Please let me know if my understanding is correct.

Migration Overview Steps:

*Setup 4 VM Servers
VM Server 1 for Reverse Proxy Server (IHS)
VM Server 2 for JTS +WAS
VM Server 3 for CCM +WAS
VM Server 4 for DB2 Server (JTS + CCM + DW)

*Install IHS & WAS 8.5.5 in VM Servers 1 , 2 & 3 (As JTS & CCM will require it's own profile in respective servers)

*Configure Reverse proxy settings

Now how do I move my DB2 server to the new location ? Do I install DB2 in the new VM Server 3 machine.. Backup the databases and restore them and if I update the teamserver.properties of jts ,ccm and dw later with the new location url for connection. Will they automatically pick up ?

and I know all my CLM artifacts will have my old server URLs. How do I change my public URI now?should I also do a server rename ?

Please advice.

Thanks in advance!
Vishnu M



Comments
Kevin Ramer commented May 06 '15, 11:38 a.m.

It has been our experience that db2 on a VM ( intel vcell) ( not an LPAR ) works poorly.

One answer



permanent link
Ralph Schoon (58.7k23642) | answered May 06 '15, 2:43 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
You can do that by introducing a reverse proxy at the machine that hosts the public URI and then moving and redirecting to the servers, where you put the applications. See Rational solution for Collaborative Lifecycle Management 2012 Administration Workshop where we describe this.

The Databases can be moved to other servers, you just have to change the connection strings in the teamserver.properties or during a setup. That is no problem.

In general you should always plan your initial deployment and pick a public URI that is fully qualified not machine dependent and does not have to change ever. I can only emphasize how important that is, especially because you end up having the URI's everywhere in external documents in web sites, in other tools.

If the public URI can't stay, you have to do a server rename. Please note that multiple server rename will have a performance impact. If you have to contact support to get a key and choose a public URI that can stay as it is.
 

Comments
Ralph Schoon commented May 06 '15, 2:47 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

If the reverse proxy is hosted with the old public URI, it does not matter where the applications are. They will be ignorant of the hardware they are installed on. They will always use the public URI which is hosted by the reverse proxy, which will forward the requests to the correct machine. Just to add this, in case you did not notice the detail. If the old public URI (DNS entry) can be associated to the machine that hots the reverse proxy, you don't need a server rename.


vishnudharan manivannan commented May 06 '15, 7:38 a.m.
Hello Ralph,

This is exactly what I was thinking to avoid the change in public URI. If I associate the old public URI (DNS entry) to the VM Server 1 machine which will host the reverse proxy then my public URI will still be the same. So I can avoid the server rename.

However I still feel suspicious.

Our Public URI is of format

https://host.my.company.net:9443/jts

We have the port number 9443 set as well in the public URI.

Will this still work in this scenario ?

Thanks
Vishnu M

Ralph Schoon commented May 06 '15, 8:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

The reverse proxy will have to listen to 9443, which can be done. No problem there.
If I would be asked to plan a deployment I would prefer 443 which would allow the port to be hidden in the public URI, but I would not necessarily do a server rename just to get rid of the port.

Your answer


Register or to post your answer.