Can we set up a distributed topology without a reverse proxy server?
Accepted answer
Given your requirement, I would suggest you install a reverse proxy (Apache) on the existing server with JTS/RRC and move RTC to the spare server. Since the reverse proxy should listen on the port specified in the public URL (to avoid server rename), you need to change the port Tomcat is listening at. After that, all the configurations are done in the reverse proxy.
Ideally you should have a separate server for the reverse proxy. In this case, you need to map the FQDN in the public URL to this new server in the DNS. The rest should be the same as above.
(The doubling traffic concern mentioned in the other post may not be as significant, given that both Windows and Linux are smart enough to use the loopback interface for _some_ local traffic even an external IP address is used).
With the reverse proxy in place, you should be able to redirect traffic in a very flexible way, including the three domains that you mentioned (using virtual hosts in Apache).
I find this blog quite informative and worth a read.
https://rvdb.wordpress.com/2012/04/26/reverse-proxying-tomcat-webapps-behind-apache/
Comments
1/4
2/4
3/4 Pls comment our plan of attack from all infos and advises we received so far:
4/4
There seems to be some misunderstanding about what a public URI is and what "server rename" does. You have to understand these concepts correctly and go back to your plans.
When you run the /jts/setup, you should see a warning that says once a public URI is set, you cannot change it easily. The URI set for each application is called the "public URI" and it is unique - you cannot use a URI such as https://different-host-pointing-to-same-IP-address/jts to access CLM. If you want to change the public URI for some or all of the CLM applications, you have to do a "server rename", there is no negotiation here, as changing the public URI is not as simple as modifying the teamserver.properties file, and lots of content in the database have to be changed as well. You should see the "risky" bit now. Also, we have already discovered quite many defects linked to a post-server-rename configuration. That's why I suggest avoiding server rename if you can.
About the spoofing bit, it is basically a DIY thing and it is not well tested and verified. Not just IBM, I doubt any vendors would "officially support" it.
You should not confuse the spoofing with "server rename" either. If you think of the POC and TST as cold standby, it's probably easier to understand. Also, no matter how you spoof or split or modify, the CLM applications will insist on using the public URIs stored in the database. So if you force a URI change on the client side, you will only get some very unpredicted behavior.
Now go back, have a look at your plans and see if they are feasible (I'm not saying they are not).
1 of 4
Thx Don,
Indeed, we misunderstood the public URI in a big way:
We had painted the registration with JTS unconsciously as a way to set up a reverse proxy server within the JTS,
Thinking the public URI would be for access to the JTS, hence any access via the public URI will be converted to the registered address (discovery URL) through JTS.
Didn't realize that the registered discovery URL is also hardwired, as part of the public URI, into the DB's hence a simple edit or un-registration/re-registration to a new discovery URL alone won't work, while new/initial registration could be to any address/server in a distributed topology.
Perhaps un/re-registration would work in conjunction with a "server rename"? Though it is even riskier with a more complicated "server rename" of a common public URI into the public URI of only a specific application?
2 of 4
We have re-drawn our overall plan, trying to avoid "server rename" at the cost of having to be on our own with spoofing, hoping it would work, as "server rename" is only necessary otherwise on POC and TST but NOT on PRD. In the process, we would go directly to our final permanent distributed topology with Linux/WAS on PRD and periodically rebooting PRD as the interim solution for stability (to avoid weekly hangs & crashes) instead of splitting off RTC to its own Windows server.
3 of 4
POC env on non-PRD domain: Proof of concept first for the RTC split to its own Windows server, then for moving to Linux/WAS
1. RTC split
1.1 Setting up the reverse proxy server for Tomcat on current Window single server
1.2 Verify spoofing
1.3 Splitting the RTC off to its own Window server
1.4 Repointing reverse proxy server to the new RTC server
1.5 Verify spoofing
1.6 If spoofing does not work. Will have to "server rename" in POC (and later in TST). No need to do so in PRD
2. Linux servers provided for all env's: POC, TST, PRD or at least POC
3. DNS for all Linux servers
4. Move from Windows/Tomcat to Linux/WAS
4 of 4
TST environment on non-PRD domain: Prototype of the move from Tomcat/Window to Linux/WAS and of setting up current Windows single server as reverse proxy server for WAS
1 Move RTC from current Windows single server to its own Linux server, and switch from Tomcat to WAS.
2 Move JTS & RRC to their Linux server, leave the reverse proxy server on current Window single server. And switch from Tomcat to WAS.
3 Setting up the reverse proxy server on current Windows single server for WAS pointing to the new Linux AppServers
PRD environment on PRD domain: Implement from success and experience prototyping, on TST, the move from Tomcat/Window to Linux/WAS and setting up current Windows single server as reverse proxy server for WAS"
One other answer
Comments
Thx Ralph,
The key of the reverse proxy is that the reverse proxy hosts the public URI lets say
myserver.example.com
The Proxy delegates all calls to myserver.examle.com/[context] to where ever the application is installed. [Context] can be jts, ccm, qm, rm... The application, say ccm, only gets a request to myserver.examle.com/ccm/ and processes that. It does not know that it sits on a different machine. It requests some resource e.g. myserver.examle.com/ccm/com.ibm.team.....workitem/22 and sends that. It goes to the reverse proxy and goes right back, It is important that this happens, so that you can move the applications back and forth and the just don't even realize that.
Please read the Deployment Wiki around all those topics.
https://jazz.net/wiki/bin/view/Deployment/InstallProxyServers
https://jazz.net/wiki/bin/view/Deployment/DeploymentPlanningAndDesign
https://jazz.net/wiki/bin/view/Deployment/CLMArchitectureOverview
We created that so we don't have to answer these basic things over and over.
So with the proxy it is irrelevant, you won't have to change the public URI if you move to another server, as long as the proxy keeps its address.
You can not unregisert and register with e new URL.
You would have to do a server rename. The reverse proxy makes that unnecessary.
Reading your question again:
-
Install the proxy server on one machine (e.g. the one you don't use any more)
-
Make the machine hosting the public URI
-
Relocate JTS and RTC to other machines with whatever name (or make the machine not have the public URI
-
Redirect the proxy to the machines that host the JTS and CCM and the other apps under this public URI
Thx Ralph,
... continued
I would be interested in how to unregister and register again and keep the system working. When I tried that in the past, I always failed.
Guess that we would be too. And it is also what we worry about, as this is all new to us, including the distributed topology
The proxy is the means to keep the URI's stable to avoid having to do server renames and this is why it should be introduced in the beginning and that is why we emphasize this in the Deployment Wiki. That is its whole purpose.