Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Can we set up a distributed topology without a reverse proxy server?

Questions
Tags
Users
Badges
long TRUONG
(365●4●123●147) edited
Nov 12 '15, 10:19 p.m.
 We are on Windows/Tomcat RTC/RRC 5.0.2, all on same server
IBM had recommended splitting RTC to its own server via a Reverse Proxy Server as a cure for our sluggish performance and frequent (sometimes more than once wkly) hangs, crashes.

We only have a spare server (old RRDI server now unused) in each of our 3 envs: from our question 210635, we have been advised not to cram both the reverse proxy server and CCM appServer onto the same host. We are now looking to split the RTC to its own server on the spare host without a reverse proxy server.

Can we just register the RTC with the JTS, and get this distributed 2-server (+ DB server) to work ?
If we can, then what would an extra reverse proxy server offer us above that 2-server setup ?


If we were to set up our 3 envs (POC, TST, PRD) with 3 distinct public URIs, can we use 1 reverse proxy server for all 3 envs ? across domains?

0 votes

2 answers
11,534 views
0 votes

Accepted answer

Permanent link
Donald Nong
(14.5k●6●14) Nov 15 '15, 8:26 p.m.
Server rename is a risky business so you should avoid it if possible.

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/
long TRUONG selected this answer as the correct answer

1 vote

Comments
long TRUONG
Nov 17 '15, 7:02 p.m.
 1/4 Thx Don, Kept getting into uncharted territories these days, just done with testing replacing a to-be expired SSL certificate for the first time to get back to this, uncharted territory too, RTC-split preparation. If by "server rename is risky" you meant "server rename" to modify the public URI, which I think you did, then: - If we had just the PRD env with one public URI or 3 separate envs (POC, TST, PRD) with 3 distinct public URI's (across 2 domains), then avoiding server rename as you suggested, or better yet as per Ralph's idea of splitting off both RRC and RTC to leave the old all-in-1 server as the rProxySvr, would have been perfect. - Unfortunately, we have been spoofing the PRD public URI (in PRD domain) in POC and TST (both in same non-PRD domain), so we can refresh their DBs with PRD clones. - And we have to start in POC, prove it in TST before we can go to PRD.

long TRUONG
Nov 17 '15, 7:03 p.m.
 2/4 - And this is IBM Support & SWAT recommended interim solution over our proposed interim solution to the frequent hangs and crashes in PRD, sometimes twice a week, of periodical reboots. An interim solution until we can implement our switch to a properly designed distributed topology with Linux/WAS. - We have to chose either spoofing or "server rename" in POC and TST. - We have no IBM official support for spoofing on the 2 separate rProxySvr on POC and TST, which, to us, may work. - And we have only 1 spare host in each env (our old RRDI server, never put into use), procuring an extra server is too expensive in time in our company (requiring approval of new design diagram) to serve as an interim solution. - Hence we were hoping that re-registering the split off app with the JTS would work: then we can do without a rProxySvr, as long as we keep spoofing as is. - We are now told that spoofing is not supported in this scenario either, not as we misunderstood that it was not supported only on rProxySvr.

long TRUONG
Nov 17 '15, 7:05 p.m.
 3/4 Pls comment our plan of attack from all infos and advises we received so far: 1. Re-register split RRC (not RTC, reason below) with JTS. Keep spoofing as is. 2. If that fails, plan B:  2.1 Server Rename to get a different public URI for each of the POC and TST env's, the new DNS alias for its all-in-1 server 2.2 Split off either the RTC or RRC from the all-in-1 server, which would serve as the rProxySvr, JTS server, and the remaining app server 2.2.1 The RRC would be split off if the come-back-again recommendation of increasing the JVM heapsize by support is more than compensating for the load put on by doubling the server as the rProxySvr: Memory for "all-in-1 server"/"spareserver" 8GB-Xmx4G/8GB-Xmx4G in POC, 12GB-Xmx6G/8GB-Xmx4G in TST, 16GB-Xmx8G/8GB-Xmx4G in PRD 2.2.2 Otherwise the RTC would be split off. 3. If we happen to get an extra server for each env, this would be same as 2. but for each env, the public URI would be the new DNS alias of the extra server, serving as its rProxySvr.

long TRUONG
Nov 17 '15, 7:06 p.m.
 4/4 Once we have POC and TST ready, we will verify if spoofing works with the final scenario: - If so, we keep POC and TST as are at that point till we refresh DB's with PRD clones. Then we will re-configure to reverse to prior spoofing of PRD public URI. - Otherwise, we will have to server rename at each refresh.

Donald Nong
Nov 18 '15, 10:30 p.m.
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).

long TRUONG
Dec 03 '15, 4:20 a.m.
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?

long TRUONG
Dec 03 '15, 4:22 a.m.
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.

long TRUONG
Dec 03 '15, 4:24 a.m.
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

long TRUONG
Dec 03 '15, 4:29 a.m.
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"

showing 5 of 9 show 4 more comments

One other answer

Permanent link
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (64.6k●3●36●49) Nov 10 '15, 2:16 a.m.
The basic answer to that is, that the reverse proxy basically hosts the common public URI and therefore you can't. You would have to change the public URI of one of the servers which you shouldn't.

0 votes

Comments
long TRUONG
Nov 10 '15, 10:44 a.m.
 Thx Ralph, So I read it all wrong on registering apps on separate servers with the JTS ? That way, each of the app actually has its own public URI ? i.e. we can't use the JTS server URL as the public URI for the apps registered with it ? In our case, if we split the RTC off the all in one server to its own server host, then new registration of the RTC in new location with the JTS will not lend the existing public URI to the RTC nor will it continue to work with RRC, left on same old host with JTS ?

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 10 '15, 10:53 a.m.
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.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 10 '15, 10:55 a.m.
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.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 10 '15, 11:54 a.m.
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

long TRUONG
Nov 12 '15, 5:40 a.m.
 Thx Ralph, For your extensive infos and advices on the subject.  Your splitting plan on last comment would take us out of our tunnel vision plan  of keeping JTS+rm on the old all-in-1 server,  and would save us from moving the DNS alias, currently serving as the public URI, to a new server -- this would be an expensive process in time at our company. Unfortunately, it is the rProxySvr that would force us into a "server rename"  to start proving the RTC splitting concept in our POC or TST env, as we have been spoofing  the PRD public URI for access on those 2 envs to allow frequent DB refresh from PRD clones. That and the fact that we will have to face delay in requesting an extra server for rProxy,  requiring internal newly approved design diagram, as we only have a spare server for ccm in each env:  Forced us to seek for an alternative without a rProxySvr.  .... to be continued on next comments

long TRUONG
Nov 12 '15, 5:40 a.m.
 ... continued We found that if we can re-register the split-off RTC with the JTS and we can still keep the current public URI then we can continue same spoofing and don't have to "server rename", nor have to wait for  an additional server. And note that this is only an interim, quick solution recommended by IBM support and SWAT in lieu of our suggested interim solution of periodical reboots to avoid hangs and crashes in PRD until the implementation of our big plan of going to distributed topology Linux/WAS (from all-in-1 server Windows/Tomcat)

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 12 '15, 5:50 a.m.
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.

long TRUONG
Nov 12 '15, 1:19 p.m.
 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 We're just hoping that the rProxySvr is the later born in response to the difficulty of setting up a distributed topology: And it was the JTS registration of apps with JTS, albeit difficult, but somehow can be managed. Support seems to concur with our concept and a high level plan is in SWAT hands to verify feasibility. We are keeping our fingers crossed that SWAT come across someone who has successfully re-register an app with the JTS and SWAT will be with us all the way thru this process.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Nov 13 '15, 2:47 a.m.
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.

showing 5 of 9 show 4 more comments

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 6,180
× 1,381

Question asked: Nov 09 '15, 11:59 p.m.

Question was seen: 11,534 times

Last updated: Dec 03 '15, 4:29 a.m.

Confirmation Cancel Confirm