EditAttachPrintable
r17 - 2014-11-09 - 09:42:07 - Main.sbeardYou are here: TWiki >  Deployment Web > DeploymentInstallingUpgradingAndMigrating > InstallProxyServers > ConfiguringEnterpriseCLMReverseProxiesWebSphere85NDProxy

Configuring enterprise CLM reverse proxies: WebSphere 8.5 ND Proxy

Authors: IndradriBasu, SudhakarFrederick
Build basis: Rational solution for Collaborative Lifecycle Management (CLM) 4.0.3, WebSphere Application Server - Network Deployment 8.5.0.2

This guide explains how to setup and configure a CLM environment using WebSphere Application Server - Network Deployment (WAS ND) and WebSphere Proxy Server, such that users will be able to access the various CLM applications by changing the context root of a central URL which is processed by WebSphere Proxy Server. The Proxy Server will then route the requests to the appropriate application server nodes where the CLM applications (JTS, CCM, QM, RM) reside.

Other topics in this series

Introduction

In this deployment scenario you will setup a CLM environment and a proxy server, with each of the applications in a separate WAS profile in a single physical server environment. The user accessible Public URIs will be different as the Proxy Server will route the requests to respective application server nodes. The topology is described in detailed in the CLM Infocentre topic Standard single-server departmental topology while the use of Proxy Servers in CLM topologies is described in Reverse proxy servers in topologies.

This topology is typically useful for deployments where the initial volume of users is low or in deployments where only a single CLM application (CCM, RM or QM) is initially used. As the volume of users increases or additional applications are added, a distributed enterprise topology should be considered.

As described in the Infocentre - in addition to being able to redeploy the applications at a later stage - using a proxy server has the following additional benefits:

  • Server rename can be avoided, unless there is a change in domain name itself.
  • For security and user friendliness, port numbers are not visible (not required) in the public URIs

WARNING: All of the setup and configuration documented here MUST be done before running the JTS setup wizard to ensure that the public URIs are set correctly to the external URIs.

An example of what you should have at the end of this article is provided in this sketch: clm-rp-overview.png

Prerequisites and Assumptions

Procedure

1 Setup the ND Deployment Manager

1.1 Create a Deployment Manager profile

Launch a the WebSphere Profile Management Tool (PMT) which comes along with the WebSphere ND installation. You can also launch it from:

<WAS_ND_Install_Dir>/bin/ProfileManagement/pmt.(sh|bat)

Once the Profile Management Tool has launched, click the "Create..." button. In the dialog window that opens:

  1. Select "WebSphere Application Server > Management" , click "Next >"
  2. Select "Deployment manager", click "Next >"
  3. Select "Advanced profile creation", click "Next >"
  4. Ensure the Deploy the administrative console (recommended) option is checked. Click "Next >"
  5. Leave the defaults, click "Next >"
  6. Change the following (as per the DNS Alias):
    Node Name: clmCellManager01
    Host Name: clm.example.org
    Cell Name: clmCell01
  7. Keep "Enable administrative security" enabled and choose an administrative user name and password. For Example:
    User name: admin
    Password: admin
    Click "Next >"
  8. Leave the defaults, click "Next >" twice.
  9. Make a note of the SOAP port as you will need that while federating application server and proxy server nodes (The default value is 8879).
    Leave the default ports, click "Next >"
  10. Choose whether to run dmgr as a service, click "Next >"
  11. Click "Create" to create the Deployment Manager profile.
  12. Once finished, launch the First Step Console and Start the Deployment Manager

Alternatively, you can use the command line to create a deployment manager profile.
To do so, Open a command window and navigate to WebSphere_Install_Folder/bin and execute the following commands:

<WAS_ND_Install_Dir>/bin/manageprofiles.(sh|bat) -create -templatePath <WAS_ND_Install_Dir>/profileTemplates/management -profileName Dmgr01 -profilePath <WAS_ND_Install_Dir>/profiles/Dmgr01 -enableAdminSecurity true -adminUserName admin -adminPassword admin]

Start the Deployment manager profile.

startServer.(sh|bat) dmgr -profileName Dmgr01

1.2 Set up Global Security on the Deployment Manager

It is recommended to fully configure the deployment manager security before creating the nodes which will host the application servers. Each of the nodes uses authentication to communicate with the Deployment Manager and if authentication is not configured on the Deployment Manager before the nodes are deployed, the nodes will need to be manually resynchronized.

Follow the Configuring Global Security instructions to setup the parameters.

Set up the authentication mechanism, refer to Prerequisites and Assumptions section.

Additionally, configure the Single Sign-on for the Deployment Manager which will be followed by all the other nodes which you are about to create. This is to ensure that applications across different nodes can be accessed by users without having to re-authenticate.

  • In WebSphere Integrated Solutions Console, click Security > Global security.
  • Under Authentication section, expand the Web and SIP security and click Single sign-on (SSO)
  • Click the Requires SSL check box.
  • In the Domain Name text box, specify your domain name (e.g. example.org) for which the SSO is applicable.
  • Click OK and Save directly to the master configuration.

1.3 Restart the Deployment Manager Profile

To Stop the Deployment Manager profile:
<WAS_ND_Install_Dir>/bin/stopServer.(sh|bat) dmgr -profileName DMGR01 -username <admin username> -password <admin user password>
To Start the Deployment Manager profile:
<WAS_ND_Install_Dir>/bin/startServer.(sh|bat) dmgr -profileName DMGR01

1.4 Enable Automatic Node Synchronization

Moving forward, all configuration changes you are about to perform, must be propagated and synchronized between all the nodes agents. The synchronization between nodes can be performed manually but enabling automatic synchronization is a more effective way and saves manual effort.

  1. Using a browser, open the WebSphere Administrative Console (For example: https://clm.example.org:9043/ibm/console and login using the username:admin and password:admin
  2. Navigate to "System Administration > Console Preferences" and select "Synchronize changes with Nodes"
  3. Click "Apply"

2 Setup the Application Server Nodes


2.1 Create and Federate Application Server Nodes

Launch the WebSphere Profile Management Tool (PMT). You can also launch it from the command line:

<WAS_ND_Install_Dir>/bin/ProfileManagement/pmt.(sh|bat)

Once the Profile Management Tool has launched, click the "Create..." button. In the dialog that opens:

  1. Select "WebSphere Application Server > Custom profile" , click "Next >"
  2. Select "Advanced profile creation" and click "Next>"
  3. Optionally change the Application Server profile name to something meaningful like JTSSrv. Change the profile directory path as well to <WAS_ND_Install_Dir>/profiles/JTSSrv. Click "Next >"
  4. Change the "Node name" to JTSNode to match the profile name and change the "Host name" to clm.example.org (as per your DNS alias) . Click "Next >"
  5. To federate this Node with the Deployment Manager, enter the FQDN (Fully Qualified Domain Name) of the server in the Deployment Manager Host name or IP address text box. In this case enter clm.example.org.
    Enter the correct Soap Port number of the Deployment Manager node.
    NOTE: The Soap Port number, can be found in the <WAS_ND_Install_Dir>/profiles/Dmgr01/logs/AboutThisProfile.txt file.

    Under Deployment Manager Authentication, enter the username and password of the Deployment Manager profile.
    Click "Next >"
  6. Leave the defaults and click "Next >" twice.
  7. In the Security Certificate (Part 2) page, ensure the certificate information matches the DNS alias name. Click "Next>"
  8. Leave the defaults and click "Next >"
  9. Click "Create"
  10. Once the profile creation finishes, uncheck the "Launch the First Step Console" box and click "Finish".
Repeat the above steps to create another profile. In Step 3 and 4, enter the profile Name as CCMSrv and Node name as CCMNode.

Alternatively, you can use the command line to create a custom profile and federate it with the Deployment Manager.
To do so, Open a command window and navigate to WebSphere_Install_Folder/bin and execute the following commands:

<WAS_ND_Install_Dir>/bin/manageprofiles.(bat|sh) -create -profileName CCMSrv -enableAdminSecurity true -adminUserName jtsadmin -adminPassword Passw0rd -templatePath <WAS_ND_Install_Dir>/profileTemplates/managed -profilePath <WAS_ND_Install_Dir>/profiles/CCMQMSrv -federateLater true
<WAS_ND_Install_Dir>/profiles/CCMSrv/bin/addNode.(bat|sh) clm.example.org 8879 -username jtsadmin -password Passw0rd

Verify that the newly created Nodes agents are started and their Status is running (as shown below).

  • In the WebSphere Administrative Console, navigate to System administration > Node Agents

2.2 Create Application Servers on the Federated Nodes

So far, you have created two managed nodes for application servers. Now, you will create and configure one application server (for the JTS application) and create an application server template from it, and then create the second application server (for the CCM application) from the template. This is more efficient than performing the same configuration for each and every application server definitions.

To create Application Server definitions, follow the steps below.

  1. Login to the WebSphere Administrative Console for the Deployment Manager. (For example: https://clm.example.org:9043/ibm/console)
  2. On the left panel, navigate to Servers > Server Types > WebSphere Application Servers
  3. On the right hand section, click the New button and Server creation wizard will come up.


  4. Select the Node name as JTSNode and type JTSServer in the Server name text box. Click Next.



  5. In Step 2, select default server template and click Next.

  6. In Step 3, leave the defaults and click Next.

  7. In the final Step, click Finish.
  8. Once you are back on the Application Server page, click Save directly to the master configuration.
  9. Once the Nodes are synchronized, click OK.

2.3 Configure the Application Server

Before deploying the CLM applications, you must configure each of the application servers.

Follow the CLM Infocenter topic Setting up WebSphere Application Server to configure the parameters for the application server created in the previous step.

2.4 Create an Application Server Template

Now that you finished configuring the first application server, you will create a template from it so that you can create the second server identical to the configuration of the first server.

  1. Navigate to Servers > Server Types > WebSphere application servers
  2. Select the JTSServer
  3. and click Templates....


  4. Click the New button.
  5. Select the JTSServer and click OK



  6. Give a Name to the template like clm_server_template and optionally, enter a Description. Click OK

  7. Click Save directly to master configuration.

  8. Once the Nodes are synchronized, click OK.

2.5 Create the second Application Server using the Template

Now that our custom application server template is created, we will proceed towards creating the second application server instance. This step is very similar to what you have done earlier except that you select the newly created clm_server_template instead of the default template.

  1. Navigate to Servers > Server Types > WebSphere application servers
  2. Click the New button.
  3. Select CCMNode as the node name and type the server name as CCMServer. Click Next.



  4. Select the clm_server_template template and click Next.



  5. Ensure the Generate Unique ports is checked. Click Next.
  6. Click Finish.
  7. Click Save directly to the master configuration.

2.6 Start the Application Servers on Federated Nodes

  1. Open the WebSphere Administrative Console in a browser. For example: https://clm.example.org:9043/ibm/console
  2. On the Left hand panel, navigate to Servers > Server Types > WebSphere Application Servers
  3. On the right hand section, select the Application Servers and click Start.


  4. Ensure the Status pane is showing that both the servers are running as indicated by a green arrow.

3 Setup the WAS ND Proxy Server

3.1 Create and federate a Node for the Proxy Server

To create a Proxy Server Profile

Launch a the WebSphere Profile Management Tool (PMT). You can also launch it from:

<WAS_ND_Install_Dir>/bin/ProfileManagement/pmt.(sh|bat)

Once the Profile Management Tool has launched, click the "Create..." button. In the dialog window that opens:

  1. Select "WebSphere Application Server > Custom profile" , click "Next >"
  2. Select "Advanced profile creation" and click "Next>"
  3. Change the profile name to ProxySrv. Accordingly, change the profile directory path as well to <WAS_ND_Install_Dir>/profiles/ProxySrv. Click "Next >"
  4. Change the "Node name" to ProxyNode to match the profile name and change the "Host name" to clm.example.org (as per your DNS alias) . Click "Next >"
  5. To federate this Node with the Deployment Manager, enter the FQDN (Fully Qualified Domain Name) of the server in the Deployment Manager Host name or IP address text box. In this case enter clm.example.org.
    Enter the correct Soap Port number of the Deployment Manager node.
    NOTE: The Soap Port number, can be found in the <WAS_ND_Install_Dir>/profiles/Dmgr01/logs/AboutThisProfile.txt file.

    Under Deployment Manager Authentication, enter the username and password of the Deployment Manager profile.
    Click "Next >"
  6. Leave the defaults and click "Next >" twice.
  7. In the Security Certificate (Part 2) page, ensure the certificate information matches the DNS alias name. Click "Next>"
  8. Leave the defaults and click "Next >"
  9. Click "Create"
  10. Once the profile creation finishes, uncheck the "Launch the First Step Console" box and click "Finish".

Alternatively, you can use the command line to create a custom profile and federate it with the Deployment Manager. To do so, Open a command window and navigate to WebSphere_Install_Folder/bin. Issue the following command:

<WAS_ND_Install_Dir>/bin/manageprofiles.(bat|sh) -create -profileName ProxySrv -enableAdminSecurity true -adminUserName jtsadmin -adminPassword Passw0rd -templatePath <WAS_ND_Install_Dir>/profileTemplates/managed -profilePath <WAS_ND_Install_Dir>/profiles/ProxySrv -federateLater true
<WAS_ND_Install_Dir>/profiles/ProxySrv/bin/addNode.(bat|sh) clm.example.org 8879 -username jtsadmin -password Passw0rd

3.2 Create the Proxy Server on the Federated Node

To create Proxy Server definitions, follow the steps below.

  1. First ensure if the Proxy Server Node that you have just created has Started.
    In the WebSphere Administrative Console, navigate to System administration > Node Agents

  2. Login to the WebSphere Administrative Console.
  3. On the Left hand panel, navigate to Servers > Server Types > WebSphere proxy servers
  4. On the right hand section, click the New button and Server creation wizard will come up.
  5. Select the Node name as ProxyNode and type CLMProxy in the Server name text box. Click Next.



  6. In Step 2, uncheck SIP check box and click Next.


  7. In Step 3, leave the defaults and click Next.


  8. In the final Step, click Finish.
  9. Click Save directly to the master configuration

  10. Once the Nodes are synchronized, click OK.

3.3 Configuring the Proxy Server

  1. Login to the WebSphere Administrative Console.
  2. On the Left hand panel, navigate to Servers > Server Types > WebSphere proxy servers
  3. On the right hand side, click the CLMProxy


  4. Under Communications section, expand the Ports and ensure that PROXY_HTTP_ADDRESS and PROXY_HTTPS_ADDRESS are set to 80 and 443 respectively.


  5. If they are not set to as shown above, then you may want to check if any other proceses are blocking port 80 or 443. Click the Details button and change them as needed.

  6. Under Server Infrastructure section, go to Java and Process Management > Process definition > Java Virtual Machine
  7. Under General Properties, ensure the Verbose garbage collection check box is unchecked.
  8. Under General Properties, set the Minimum heap size is set to 256MB.
  9. Under General Properties, set the Maximum heap size is set to 1024MB.
  10. In the Generic JVM arguments, add the following argument
    -Xgcpolicy:gencon
  11. Click Apply, and then click Save directly to the master configuration.

You will increase the persistent timeout value so that the connection between the application servers and the proxy server remains open for a little longer time.

  1. Navigate to Servers > Server Types > WebSphere proxy servers
  2. On the right hand side, click the CLMProxy
  3. Under Proxy Settings, expand the HTTP Proxy Server Settings tree.
  4. Click Proxy server transports.
  5. Click HTTPS_PROXY_CHAIN. It should be associated with port 443.
  6. Click HTTP inbound channel (HTTP 4).
  7. Under General Properties, set the Persistent timeout to 60 seconds.
  8. Click Apply, and then click Save directly to the master configuration.

Configure the Proxy server thread pools to match the same settings as the CLM application server nodes.

  1. Navigate to Servers > Server Types > WebSphere proxy servers
  2. On the right hand side, click the CLMProxy
  3. Under Additional Properties, click Thread pools
  4. Click Proxy
  5. Under General Properties make sure the Minimum Size and Maximum Size are both set to 200 threads
  6. Click Apply, and then click Save directly to the master configuration.

3.4 Configuring Virtual Hosts

You will be using the default_host virtual hosts in this setup to exchange all communications and as mentioned earlier and you may want the proxy server to resolve only to the DNS alias you have created earlier using the HTTPS port 443 only.

To ensure the web modules are associated with the virtual host:

  1. Open and login to the WebSphere Administrative Console in a browser.
  2. On the Left hand panel, navigate to Servers > Server Types > WebSphere application servers
  3. On the right hand side, click on JTSServer
  4. Under Communications section, expand the Ports and note down port number for the WC_defaulthost_secure (if you are using an unsecured communication use WC_defaulthost instead)
  5. Ensure the port number that you noted, exists in the list under Environment > Virtual Hosts > default_Host > Host Aliases. If not, add an entry by clicking on the New button on the above pane.
  6. Click Save directly to the master configuration.
  7. Once the Nodes are synchronized, click OK.

NOTE: Repeat the above steps for all application servers. As in this case for JTSServer and CCMServer

To configure the virtual host with DNS alias:

  1. Open and login to the WebSphere Administrative Console in a browser.
  2. On the Left hand panel, navigate to Environment > Virtual Hosts
  3. Click default_host > Host Aliases
  4. For port 443, click the * and replace with the DNS alias (clm.example.org) and click OK.
  5. Click Save directly to the master configuration.
  6. Once the Nodes are synchronized, click OK.

3.5 Starting the Proxy Server

  1. Navigate back to Servers > Server Types > WebSphere proxy servers
  2. Select CLMProxy and click Start button to start the proxy server.

Deploying CLM applications


Follow the Deploy CLM Applications on the Server instructions except follow the table below while Mapping Modules to the application servers.

Application
Node
Mapped Server
Context root
admin.war
JTSNode
cell=clmCell01,node=JTSNode,server=JTSServer
/admin
ccm.war
CCMNode
cell=clmCell01,node=CCMNode,server=CCMServer
/ccm
jts.war
JTSNode
cell=clmCell01,node=JTSNode,server=JTSServer
/jts
You are now ready to run the JTS/Setup.

Running the JTS Setup wizard

Now that you have URLs that are server agnostic, you can run the JTS setup wizard and use these URLs when registering the applications. Here are the discovery URLs that will be used:

Change and Configuration Management: https://clm.example.org/ccm/scr

Moving an application

Now suppose that you wish to redeploy the CCM application to it's own separate physical server (for example, ccmserver01.example.org) without affecting users' ability to access it through https://clm.example.org/ccm. Here is a summary of the steps, previously detailed, to be repeated:
  1. Create and federate a WAS profile as in Step 2.1 on the new server.
  2. Create an Application Server on the new node using the clm_server_template as in Step 2.5.
  3. Install the CCM application on the exact same location on the new server so that the template configuration remains effective.
    Follow the instructions in the CLM Infocenter, making sure to copy over the directory that contains the indexes and configuration files, located at <JazzInstallDir>/server/conf/ccm for the CCM application from the original server.
  4. From Applications > Enterprise Applications > ccm_war > Manage Modules, select both the new application server definition and the application.
  5. Click OK and Save directly to the master configuration.
  6. Restart all the application servers and the proxy server.


Related topics: Proxy server installation, Understanding reverse proxy, Configuring Enterprise CLM Reverse Proxies: WebSphere 8 and IHS 8, Configuring Enterprise CLM Reverse Proxies: Apache and mod_proxy

Additional contributors: RosaNaranjo

Questions and comments:

Warning: Can't find topic Deployment.ConfiguringEnterpriseCLMReverseProxiesWebSphere85NDProxyComments

Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r20 < r19 < r18 < r17 < r16 | 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.