r2 - 2015-02-13 - 13:59:30 - Main.msdelargYou are here: TWiki >  Deployment Web > DeploymentInstallingUpgradingAndMigrating > ServerRename > Highleveloverviewofpublicuriandserverrename

High Level Overview of Public URIs and Server Rename todo.png

Authors: MikeDelargy
Build basis: 4.0.1 (and higher), 5.x

Public URIs, Proxy Servers, and Server Rename
*Understanding the communication in a CLM Deployment*

Server rename landing page

Accessing CLM

  • When a user accesses a CLM deployment, the user enters the Public URI for the application into a browser window .
  • Depending on the deployment architecture, the Public URIs may have the same ‘stem’ in the public URI and a different “context root” or the Public URIs could be completely different.

CLM application

Typical Enterprise Deployment

Typical Departmental Deployment

Jazz Team Server /jts

https://jts_server:9443/jts

https://clmserver:9443/jts

Rational Quality Manager/qm

https://rqm_server:9443/qm

https://clmserver:9443/qm

Rational Doors Next Generation/rm

https://rdng_server:9443/rm

https://clmserver:9443/rm

Rational Team Concert/ccm

https://rtc_server:9443/ccm

https://clmserver:9443/ccm

Departmental Deployment:

departmental_deployment.png

Enterprise Deployment:
enterprise_deployment.png

Here, my pubic URI’s are:

  • https://jtsserver:9443/jts Where jtsserver is the computer name (or virtual hostname configured in W.A.S.) The service is listening on port 9443 and the context root is jts

  • https://rtcserver:9443/ccm Where rtcserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is ccm

  • https://rqmserver:9443/rqm Where rqmserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is qm

  • https://rdngserver:9443/rm Where rdngsrver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is rm

Applications "communicating" with each other

The servers reference each other through their Public URIs
servers_communicate.png

  • When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
  • When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
  • When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm

  • When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
  • When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
  • When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts

This is true for each of the applications and each of the “artifacts” within the applications.

The Public URI’s are in each of the application configuration files and are embedded in the artifacts for each application stored in the database(s)

User communicating with the Applications

Here, the user talks directly to each application server but the application servers still “communicate” directly with each other.

users_and_serverscommunicate.png

  • When JTS application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
  • When RTC application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
  • When RQM application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm

  • When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
  • When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
  • When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm

  • When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
  • When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
  • When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts

This is true for each of the applications and each of the “artifacts” within the applications.

The Public URI’s are in each application’s configuration files and are embedded in the artifacts for each application stored in the database(s)

Introducing a Proxy Server

When you introduce a proxy server, all traffic gets routed through the proxy server which then redirects the traffic based upon the context root.

When a proxy server is configured, the applications still communicate with each other using the public URI, but the “stem” of the public URI always points to the proxy server.

Typically, if you are implementing a proxy server, then the “stem” of the public URI would not change but each application would still have a distinct context root.

The Proxy server looks at the context root of the traffic ( jts, ccm, rm, qm) and directs traffic accordingly. The proxy sends

  • /qm traffic to the RQM Application server
  • /jts traffic to the JTS application server
  • /ccm traffic to the RTC server
  • and /rm traffic to the RDNG server

In this case, the I.H.S. (Web Server) “takes over” the public URI. (clmserver) Meaning, either the I.H.S. server name has to be the same as the public URI OR, you configure a virtual host name on the I.H.S. server (httpd.conf file) to “spoof it” into thinking that its name is the public URI.

proxy_server_intro.png

Implementing a Proxy Server

Proxy Server

  • If you implemented / configured a proxy server into your environment on Day 1 (before you actually deployed) then your users and application server communicate to each of the applications through the proxy server.

  • If you want to move an application server with this proxy configuration, you do not need to do a server rename, you simply modify your proxy server to point to the new server.

  • If you did not implement a proxy server in your initial deployment, then all users and applications communicate with the application servers directly.

  • If you want to move an application to a new server with a different name, then you may* need to do a server rename.

More detailed information on Reverse Proxy can be found: Understanding reverse proxy

Server Rename

Server Rename

If you want to change your Public URI for whatever reason, you MUST do a server rename.

The Public URI is embedded deeply within each artifact of each application. Therefore, implementing a server rename is the only way to change the Public URI of a deployment.

Why do a Server Rename?

  • Company got bought by another company and the domain changes
  • Want to remove a port number from a Public URI
  • You want to create a test environment from a production system
  • You are moving from Test to Production and the original Public URI was “localhost” or contained an I P address.

Server Rename Best Practices

  • If you are going to change your Public URI consider creating a more “portable” URI that would not have to be changed again.
  • Try to avoid using real server names as they are less portable
  • Consider implementing a proxy server for easier portability and HA/DR

Server Rename Mapping File

In a server rename, we create a mapping file that defines each “original” Public URI and maps this to the new ‘desired’ Public URI.

  • #/context root
  • source=https://old_server:9443/context_root
  • target=https://new_server:port/jts

In the Target Public URI, we have omitted the PORT because we are going to configure a proxy server into our deployment. The Proxy Server (Web Server / I.H.S. server) will be configured to listen on the default ports 80 and 443 so no port number is necessary. If I wanted to, I could configure my proxy server to listen on ports 9080 and 9443 but if I did that, then I would have to include the port number in the Target URI

In this example, we are using an enterprise deployment and we want to implement a proxy server.

Clmserver is the virtual hostname for our proxy server

We are also configuring our proxy server to listen on the default ports of 80 and 443 so the new public URIs (target URIs) will not have to include a port number.

#/jts
source=https://jtserver:9443/jts
target=https://clmserver/jts

#/qm
source=https://rqmserver:9443/qm
target=https://https://clmserver/qm

#/rm
source=https://rdngserver:9443/rm
target=https://clmserver/rm

#/rtc
source=https://rtcserver:9443/ccm
target=https://clmserver/ccm

Back to the Server rename landing page

Related topics: Deployment web home, Deployment web home

External links:

Additional contributors: TWikiUser, TWikiUser

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r2 < r1 | More topic actions
 
This site is powered by the TWiki collaboration platformCopyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
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.