Can we set up a distributed topology without a reverse proxy server?
long TRUONG (365●4●111●141)
| asked Nov 09 '15, 11:59 p.m.
edited Nov 12 '15, 10:19 p.m. by Lisa Frankel (546●2)
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?
|
Accepted answer
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
Comments 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.
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.
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.
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.
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.
1 of 4
2 of 4
3 of 4
4 of 4
showing 5 of 9
show 4 more comments
|
One other answer
Ralph Schoon (62.0k●3●36●43)
| answered Nov 10 '15, 2:16 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Comments 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
commented Nov 10 '15, 10:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The key of the reverse proxy is that the reverse proxy hosts the public URI lets say
Ralph Schoon
commented Nov 10 '15, 10:55 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Ralph Schoon
commented Nov 10 '15, 11:54 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Reading your question again:
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
... 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)
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
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.
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
|