14 Configuring Application Servers for Community-Gadgets

This chapter contains procedures for configuring application servers to support non-clustered and clustered deployments of the Community-Gadgets application.

This chapter contains the following sections:

• Section 14.1, "Overview of Community-Gadgets Deployment"

• Section 14.2, "Configuring Application Servers for Non-Clustered Deployments"

• Section 14.3, "Configuring Application Servers for Clustered Deployments"

14.1 Overview of Community-Gadgets Deployment

The Community-Gadgets application can be deployed in many ways. For illustration purposes, we use a dual-server configuration, as follows:

• Non-clustered deployments

  In this guide, we deploy Community-Gadgets on two servers. Management Community-Gadgets is deployed on <ServerA> and production Community-Gadgets is deployed on <ServerB>.

• Clustered deployments

  Community-Gadgets can be deployed as either a vertically or horizontally clustered application. In this guide, we vertically cluster Community-Gadgets as follows: management Community-Gadgets is deployed as a cluster on <ServerA>, and production Community-Gadgets is deployed as a cluster on <ServerB>. Horizontal clustering can be achieved by replicating the above configuration on as many additional servers as needed.

14.2 Configuring Application Servers for Non-Clustered Deployments

This section provides steps for configuring selected application servers to support the deployment of a non-clustered Community-Gadgets application.

This section covers the following configurations:

• Section 14.2.1, "Configuring Apache Tomcat"

• Section 14.2.2, "Configuring Oracle WebLogic Application Server"

• Section 14.2.3, "Configuring IBM WebSphere Application Server"

  Note:

  In this section, you will configure an application server to support a non-clustered Community-Gadgets. As discussed in Chapter 12, "Overview of Community-Gadgets," you have multiple ways to configure such a non-clustered system. For illustration purposes, the steps in this section describe the deployment of the Community-Gadgets application on two servers, as explained in Section 14.1, "Overview of Community-Gadgets Deployment."

This section contains the following topics:

• Section 14.2.1, "Configuring Apache Tomcat"

• Section 14.2.2, "Configuring Oracle WebLogic Application Server"

• Section 14.2.3, "Configuring IBM WebSphere Application Server"

14.2.1 Configuring Apache Tomcat

In this section, you will configure Apache Tomcat to support deployment of a non-clustered Community-Gadgets application, as follows:

1. On <ServerA>:

   1. Create a Tomcat instance (<cgA_M1>) on which to deploy the management Community-Gadgets application.

   2. Edit catalina.sh in <cgA_M1>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgA_M1>
      

2. On <ServerB>:

   1. Create a Tomcat instance (<cgB_P1>) on which to deploy the production Community-Gadgets application.

   2. Edit catalina.sh in <cgB_P1>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgB_P1>
      

3. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."

14.2.2 Configuring Oracle WebLogic Application Server

In this section, you will configure WebLogic Application Server to support deployment of non-clustered Community-Gadgets.

Note:

Machines and managed servers can be created as a part of the WebLogic domain configuration utility, or they can be created separately from the WebLogic Administration Console of the corresponding domain. If you need detailed steps on configuring WebLogic domains, refer to the Oracle WebLogic Application Server documentation.

To support the deployment of a non-clustered, management Community-Gadgets application, complete the following steps:

1. On <ServerA>, use the domain configuration utility to create a domain, a new machine, and a new managed server.

   For example, if you are using Linux:

   cd <WL_HOME>/wlserver_10.3/common/bin
   ./config.sh
   

   For reference, this guide uses the configurations described in Table 14-1, Table 14-2, and Table 14-3.

   Table 14-1 WebLogic Domain Configuration Example for Management Community-Gadgets

   Property	Value
   Domain Name	<cgMgmt>
   Admin Server	<ServerA>
   Admin Server Port	For example: 7001 Or use your own value as appropriate for your configuration.

   
   

   Table 14-2 WebLogic Machine Configuration Example for Management Community-Gadgets

   Property	Value
   Machine Name	<wlcgA_M>
   Listen Address	<ServerA>
   Listen Port	For example: 5556 Or use your own value as appropriate for your configuration.

   
   

   Table 14-3 WebLogic Managed Server Configuration Example for Management Community-Gadgets

   Property	Value
   Managed Server	<cgA_M1>
   Domain	<cgMgmt>
   Listen Address	<ServerA>
   Listen Port	For example: 7003 Or use your own value as appropriate for your configuration.
   Machine	<wlcgA_M>

   
   

2. Similarly, configure WebLogic Application Server as follows to support deployment of a non-clustered, production Community-Gadgets application:

   On <ServerB>, use the domain configuration utility to create a domain, a new machine, and a new managed server.

   For reference, this guide uses the configurations described in Table 14-4, Table 14-5, and Table 14-6.

   Table 14-4 WebLogic Domain Configuration Example for Production Community-Gadgets

   Property	Value
   Domain Name	<cgProd>
   Admin Server	<ServerB>
   Admin Server Port	For example: 7001 Or use your own value as appropriate for your configuration.

   
   

   Table 14-5 WebLogic Machine Configuration Example for Production Community-Gadgets

   Property	Value
   Machine Name	<wlcgB_P>
   Listen Address	<ServerB>
   Listen Port	For example: 5556 Or use your own value as appropriate for your configuration.

   
   

   Table 14-6 WebLogic Managed Server Configuration Example for Production Community-Gadgets

   Property	Value
   Managed Server	<cgB_P1>
   Domain	<cgProd>
   Listen Address	<ServerB>
   Listen Port	For example: 7003 Or use your own value as appropriate for your configuration.
   Machine	<wlcgB_P>

   
   

3. For each server in steps 1 and 2:

   1. Select Enable Tunneling.

   2. Select None for Hostname Verification.

4. For each domain, create a directory for staging the Community-Gadget application. In this guide, we created a directory named applications in the following paths:

   <WL_HOME>/user_projects/domains/cgMgmt/applications
   <WL_HOME>/user_projects/domains/cgProd/applications
   

5. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."

14.2.3 Configuring IBM WebSphere Application Server

In this section, you will configure IBM WebSphere Application Server to support deployment of a non-clustered Community-Gadgets application.

Note:

If you need detailed steps on configuring IBM WebSphere Application Server, refer to the vendor's documentation.

1. Create a node on which to deploy the management Community-Gadgets application, and federate that node to your Deployment Manager.

   If you do not have a Deployment Manager configured, then create a Deployment Manager and Application Server profile and federate the node to the Deployment Manager profile you just created.

   For reference, this guide uses the configurations described in Table 14-7 and Table 14-8.

   Table 14-7 WebSphere Profile Configuration Example for Management Community-Gadgets

   Property	Value
   Deployment Manager Profile	<Dmgr01>
   Host Server	<ServerA>
   Deployment Manager Admin Server Port	For example: 9060 Or use your own value as appropriate for your configuration.

   
   

   Table 14-8 WebSphere Application Server Configuration Example for Management Community-Gadgets

   Property	Value
   Application Server Name	<cgA_M1>
   Profile	<AppSrv01>
   Node	<ServerA_Node01>
   Listen Address	<ServerA>
   Listen Port	For example: 9080 Or use your own value as appropriate for your configuration.

   
   

2. Similarly, create a node on which to deploy the production Community-Gadgets application, and federate that node to your Deployment Manager.

   For reference, this guide uses the configurations described in Table 14-9 and Table 14-10.

   Table 14-9 WebSphere Profile Configuration Example for Production Community-Gadgets

   Property	Value
   Deployment Manager Profile	<Dmgr01>
   Host Server	<ServerA>
   Deployment Manager Admin Server Port	For example: 9060 Or use your own value as appropriate for your configuration.

   
   

   Table 14-10 WebApplication Server Profile Configuration Example for Production Community-Gadgets

   Property	Value
   Application Server Name	<cgB_P1>
   Profile	<AppSrv02>
   Node	<ServerB_Node02>
   Listen Address	<ServerB>
   Listen Port	For example: 9080 Or use your own value as appropriate for your configuration.

   
   

3. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."

14.3 Configuring Application Servers for Clustered Deployments

This section describes the configuration of supported application servers to support clustered deployments of the Community-Gadgets application.

This section covers these clustered deployment configurations:

• Section 14.3.1, "Configuring Apache Tomcat (Clustered)"

• Section 14.3.2, "Configuring Oracle WebLogic Application Server (Clustered)"

• Section 14.3.3, "Configuring IBM WebSphere Application Server (Clustered)"

Note:

In this section, you will configure an application server to support a clustered Community-Gadgets installation. As discussed in Chapter 12, "Overview of Community-Gadgets," you have multiple ways to configure a clustered system. For illustration purposes, the steps in this section describe vertical clustering of the Community-Gadgets application, as explained in Section 14.1, "Overview of Community-Gadgets Deployment."

14.3.1 Configuring Apache Tomcat (Clustered)

In this section, you will configure Apache Tomcat to support deployment of a clustered Community-Gadgets application.

1. On <ServerA>:

   1. Create a Tomcat instance (<cgA_M1>) on which to deploy the management Community-Gadgets application. Edit catalina.sh in <cgA_M1>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgA_M1>
      

   2. Create a Tomcat instance (<cgA_M2>) on which to deploy the management Community-Gadgets application. Edit catalina.sh in <cgA_M2>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgA_M2>
      

   3. Edit the server.xml file ensure there are no port conflicts.

2. On <ServerB>:

   1. Create a Tomcat instance (<cgB_P1>) on which to deploy the production Community-Gadgets application. Edit catalina.sh in <cgB_P1>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgB_P1>
      

   2. Create a Tomcat instance (<cgB_P2>) on which to deploy the production Community-Gadgets application. Edit catalina.sh in <cgB_P2>/bin by adding the following line after the first comment block:

      CATALINA_HOME=<cgB_P2>
      

   3. Edit the server.xml file to ensure there are no port conflicts.

      After you complete the above steps, your Tomcat configurations should look something like the example in Table 14-11.

      Table 14-11 Tomcat Configuration Example for the Community-Gadgets Application

      Host	Tomcat Instance	Port Number
      <ServerA>	<cgA_M1>	8080
      <ServerA>	<cgA_M2>	8180
      <ServerB>	<cgB_P1>	8080
      <ServerB>	<cgB_P2>	8180

      
      

3. Configure the application server cluster by editing the server.xml file. Follow the steps below for <ServerA> and <ServerB>.

   1. For each cluster member, add clustering ability by adding the following code to the server.xml file (refer to Apache Tomcat documentation for information about the code):

      <Cluster className=
      "org.apache.catalina.ha.tcp.SimpleTcpCluster"
      channelSendOptions="8">
      <Manager className=
      "org.apache.catalina.ha.session.DeltaManager"
      expireSessionsOnShutdown="false"
      notifyListenersOnReplication="true"/>
      
      <Channel className=
      "org.apache.catalina.tribes.group.GroupChannel">
      <Membership className=
      "org.apache.catalina.tribes.membership.McastService"
      address="228.0.0.4"
      port="45564"
      frequency="500"
      dropTime="3000"/>
      
      <Receiver className=
      "org.apache.catalina.tribes.transport.nio.NioReceiver"
      address="auto"
      port="4000"
      autoBind="100"
      selectorTimeout="5000"
      maxThreads="6"/>
      
      <Sender className=
      "org.apache.catalina.tribes.transport.
      ReplicationTransmitter">
      <Transport className=
      "org.apache.catalina.tribes.transport.nio.
      PooledParallelSender"/>
      </Sender>
      
      <Interceptor className=
      "org.apache.catalina.tribes.group.interceptors.
      TcpFailureDetector"/>
      <Interceptor className=
      "org.apache.catalina.tribes.group.interceptors.
      MessageDispatch15Interceptor"/>
      </Channel>
      
      <Valve className=
      "org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
      <Valve className=
      "org.apache.catalina.ha.session.
      JvmRouteBinderValve"/>
      
      <Deployer className=
      "org.apache.catalina.ha.deploy.FarmWarDeployer"
      tempDir="/tmp/war-temp/"
      deployDir="/tmp/war-deploy/"
      watchDir="/tmp/war-listen/"
      watchEnabled="false"/>
      
      <ClusterListener className=
      "org.apache.catalina.ha.session.
      JvmRouteSessionIDBinderListener"/>
      <ClusterListener className=
      "org.apache.catalina.ha.session.
      ClusterSessionListener"/>
      </Cluster>
      

   2. To enable load balancing using AJP, locate the Engine line in the server.xml file, then add a jvmRoute for the server instance. For example, to include a jvmroute in the line <Engine name="Catalina" defaultHost="localhost"> and name the server jvm1, add jvmRoute="jvm1" as follows: <Engine name="Catalina" defaultHost="localhost" jvmRoute="jvm1">.

      Note that the each server must have a unique jvmRoute name.

   3. Verify that all Tomcat instances belonging to the same cluster have the same values for multicast address and port in the Membership tag. For example, <cgB_P1> and <cgB_P2> must have the same values for multicast address and port.

   4. Verify that all Tomcat instances belonging to the different cluster have a multicast address or port number (in the Membership tag) that is unique across clusters. For example, all Tomcat instances in the <cgA_M1>/<cgA_M2> cluster must have a multicast address or port number that differs from the multicast address or port number of Tomcat instances in the <cgB_P1>/<cgB_P2> cluster.

   5. For a vertical cluster, verify that all Tomcat instances located on the same server have different values for the port parameter in the Receiver tag.

   6. If you are using a multi-homed server, enter the exact IP address or host name (instead of auto) as the value for the address parameter in the Receiver tag.

4. On all Tomcat instances, add the <distributable/> tag in the <web-app> tag to the <TC_HOME>/conf/web.xml file.

5. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."

14.3.2 Configuring Oracle WebLogic Application Server (Clustered)

In this section, you will configure WebLogic Application Server to support deployment of a clustered Community-Gadgets application.

Note:

Machines and managed servers can be created as a part of the WebLogic domain configuration utility, or they can be created separately from the WebLogic Administration Console of the corresponding domain. If you need detailed steps on configuring WebLogic domains, refer to the Oracle WebLogic Application Server documentation.

1. To support the deployment of a clustered, management Community-Gadgets application, do the following:

   On <ServerA>, use the domain configuration utility to create a domain, a new machine, new managed servers, and the cluster.

   For example, if you are using Linux:

   cd <WL_HOME>/wlserver_10.3/common/bin
   ./config.sh
   

   For reference, this guide uses the configurations described in Table 14-12, Table 14-13, Table 14-14, and Table 14-15.

   Table 14-12 WebLogic Domain Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Domain Name	<cgMgmt>
   Admin Server	<ServerA>
   Admin Server Port	For example: 7001 Or use your own value as appropriate for your configuration.

   
   

   Table 14-13 WebLogic Machine Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Machine Name	<wlcgA_M>
   Listen Address	<ServerA>
   Listen Port	For example: 5556 Or use your own value as appropriate for your configuration.

   
   

   Table 14-14 WebLogic Managed Server Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Managed Server 1	<cgA_M1>
   Domain	<cgMgmt>
   Listen Address	<ServerA>
   Listen Port	For example: 7003 Or use your own value as appropriate for your configuration.
   Machine	<wlcgA_M>
   Managed Server 2	<cgA_M2>
   Domain	<cgMgmt>
   Listen Address	<ServerA>
   Listen Port	For example: 7005 Or use your own value as appropriate for your configuration.
   Machine	<wlcgA_M>

   
   

   Table 14-15 WebLogic Cluster Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Cluster Name	<wlcg_M>
   Cluster Address	<ServerA>
   Cluster Messaging Mode	Unicast (or Multicast depending on your environment)
   Managed Servers as part of Cluster	<cgA_M1>, <cgA_M2>

   
   

2. Similarly, configure WebLogic Application Server to support the deployment of a clustered production Community-Gadgets application.

   On <ServerB>, use the domain configuration utility to create a domain, a new machine, new managed servers, and the cluster.

   For reference, this guide uses the configurations described in Table 14-16, Table 14-17, Table 14-18, and Table 14-19.

   Table 14-16 WebLogic Domain Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Domain Name	<cgProd>
   Admin Server	<ServerB>
   Admin Server Port	For example: 7001 Or use your own value as appropriate for your configuration.

   
   

   Table 14-17 WebLogic Machine Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Machine Name	<wlcgB_P>
   Listen Address	<ServerB>
   Listen Port	For example: 5556 Or use your own value as appropriate for your configuration.

   
   

   Table 14-18 WebLogic Managed Server Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Managed Server 1	<cgB_P1>
   Domain	<cgProd>
   Listen Address	<ServerB>
   Listen Port	For example: 7003 Or use your own value as appropriate for your configuration.
   Machine	<wlcgB_P>
   Managed Server 2	<cgB_P2>
   Domain	<cgProd>
   Listen Address	<ServerB>
   Listen Port	For example: 7005 Or use your own value as appropriate for your configuration.
   Machine	<wlcgB_P>

   
   

   Table 14-19 WebLogic Cluster Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Cluster Name	<wlcg_P>
   Cluster Address	<ServerB>
   Cluster Messaging Mode	Unicast (or Multicast depending on your environment)
   Managed Servers as part of Cluster	<cgB_P1>, <cgB_P2>

   
   

3. For each managed server created on <ServerA> and <ServerB>:

   1. Select Enable Tunneling.

   2. Select None for Hostname Verification.

4. For each domain, create a directory for staging the Community application. In this guide, we created a directory named applications in the following paths:

   <WL_HOME>/user_projects/domains/cgMgmt/applications
   <WL_HOME>/user_projects/domains/cgProd/applications
   

5. For each cluster, go to its Advanced Cluster Configuration section and select the WebLogic Plug-In Enabled parameter.

6. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."

14.3.3 Configuring IBM WebSphere Application Server (Clustered)

In this section, you will configure WebSphere Application Server to support deployment of a clustered Community-Gadgets application.

Note:

If you need detailed steps on configuring IBM WebSphere Application Server, or details on creating profiles or federating nodes, refer to the vendor's documentation.

1. Create a node on which to deploy the management Community-Gadgets application, and federate that node to your Deployment Manager.

   If you do not have a Deployment Manager configured, then create a Deployment Manager and Application Server profile and federate the node to the Deployment Manager profile you just created.

   For reference, this guide uses the configurations described in Table 14-20 and Table 14-21.

   Table 14-20 WebSphere Profile Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Deployment Manager Profile	<Dmgr01>
   Host Server	<ServerA>
   Deployment Manager Admin Server Port	For example: 9060 Or use your own value as appropriate for your configuration.

   
   

   Table 14-21 WebSphere Application Server Configuration Example for Management Community-Gadgets (Clustered)

   Property	Value
   Application Server Name	<cgA_M1>
   Profile	<AppSrv01>
   Node	<ServerA_Node01>
   Listen Address	<ServerA>
   Listen Port	For example: 9080 Or use your own value as appropriate for your configuration.
   Application Server Name	<cgA_M2>
   Profile	<AppSrv01>
   Node	<ServerA_Node01>
   Listen Address	<ServerA>
   Listen Port	For example: 9081 Or use your own value as appropriate for your configuration.

   
   

2. Similarly, create a node on which to deploy the production Community-Gadgets application, and federate that node to your Deployment Manager.

   For reference, this guide uses the configurations described in Table 14-22 andTable 14-23.

   Table 14-22 WebSphere Profile Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Deployment Manager Profile	<Dmgr01>
   Host Server	<ServerA>
   Deployment Manager Admin Server Port	For example: 9060 Or use your own value as appropriate for your configuration.

   
   

   Table 14-23 WebSphere Application Server Configuration Example for Production Community-Gadgets (Clustered)

   Property	Value
   Application Server 1 Name	<cgB_P1>
   Profile	<AppSrv02>
   Node	<ServerB_Node02>
   Listen Address	<ServerB>
   Listen Port	For example: 9080 Or use your own value as appropriate for your configuration.
   Application Server 2 Name	<cgB_P2>
   Profile	<AppSrv02>
   Node	<ServerB_Node02>
   Listen Address	<ServerB>
   Listen Port	For example: 9081 Or use your own value as appropriate for your configuration.

   
   

3. Create two new clusters (see Table 14-24), using the WebSphere Administration Console.

   For example:

   http://<ServerA>:9060/ibm/console
   

   Table 14-24 WebSphere Cluster Configuration Examples for Community-Gadgets

   Configuration	Property	Value
   Cluster 1	Cluster Name	<wscg_M>
   Cluster 1	Configure HTTP memory-to-memory replication	Yes
   Cluster 1	Cluster Members	<cgA_M1>, <cgA_M2>
   Cluster 2	Cluster Name	<wscg_P>
   Cluster 2	Configure HTTP memory-to-memory replication	Yes
   Cluster 2	Cluster Members	<cgB_P1>, <cgB_P2>

   
   

4. For each managed server created on <ServerA> and <ServerB>, complete the following steps in the WebSphere Administration Console:

   1. Set memory-to-memory replication.

   2. Under Web Container Settings, add the following custom property:

      Name: HttpSessionCloneId
      Value: 11111111 (8-9 characters, unique for each managed server)
      

5. If you wish to customize replication domains, use the administrative console (select Environment, then select Replication domains in the left frame).

6. Add ports for all cluster members (go to Environment, then select Virtual hosts, then select default_host, then select Host Aliases and add the ports).

7. Continue to Chapter 15, "Generating Community-Gadgets Deployment Files."