Any experience, advises in spoofing PRD public URI in non-PRD env with a reverse proxy server ?
Currently we have RTC/RRC 5.0.2 on a Windows single server with Tomcat. We are trying to split the RTC off to its own server with the current single server host doubling as a reverse proxy server, for stability (almost weekly crashes or hangs on PRD currently) and performance
We had been spoofing the PRD public URI on POC and TST with frequent DB refreshes on TST from PRD clones. TST is used to shadow PRD closely.
We are now facing a dilemma:
It is straight forwards on PRD, but we have to prove the concept on POC and TST before we can implement the split on PRD.
We have either have to continue using spoofing, which IBM does not officially support and IBM support does not think it could work with the reverse proxy server, or rely on the risky and involved "server rename" on POC and TST.
We have decided to go on our own to test spoofing as is (server rename both POC and TST to proof spoofing is safer but too costly and risky):
We are looking at continuing spoofing the single server, public URI pointing to itself in the ...\etc\hosts file, after installing Apache for the reverse proxy server on it. Then verify if spoofing continue to work on the server and from a spoofed client.
We will also spoof the new to-be home for the split RTC host, public URI pointing to the current single server in the ...\etc\hosts file, before we split off the RTC to it, and redirect the rProxySvr to it for ccm. Then spoofing is verified again.
We'd like to hear from you if you have ventured into similar implementation or if you care to comment, especially on any details we have overlooked, any pitfalls, or that it is an infeasible, futile effort.
|
2 answers
I have been using the same activation key over and over. It is really a method to get you to talk to support so that you don't do something that is not supported and that you understand the full implication of server rename I believe.
|