Managing the Topology 12-9
12.6.1.3 Scale-up Procedure for SOA
Perform these steps for scaling up the SOA servers in the topology:
1. Using the Oracle WebLogic Server Administration Console, clone WLS_SOA1 to a
new managed server. The source managed server to clone should be one that already exists on the node where you want to run the new managed server.
Perform these steps to clone a managed server:
a. In the Domain Structure window of the Oracle WebLogic Server
Administration Console, expand the Environment node and then Servers. The Summary of Servers page opens.
b. Select the managed server that you want to clone WLS_SOA1.
c. Click Clone.
d. Name the new managed server WLS_SOAn, where n is a number that
identifies the new managed server.
2. For the listen address, assign the host name or IP to use for this new managed
server. If you are planning to use server migration for this server which Oracle recommends, this should be the VIP also called a floating IP to enable it to move
to another node. The VIP should be different from the one used by the managed server that is already running.
3. Create JMS servers for SOA and UMS on the new managed server:
a. Use the Oracle WebLogic Server Administration Console to create a new
persistent store for the new SOAJMSServer and name it, for example, SOAJMSFileStore_N. Specify the path for the store. This should be a directory
on shared storage as recommended in Section 2.3, Shared Storage and
Recommended Directory Structure :
ORACLE_BASE admindomain_namecluster_namejmsSOAJMSFileStore_N
b.
Create a new JMS server for SOA for example, SOAJMSServer_N. Use the SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N server to
the recently created managed server WLS_SOAn.
c.
Create a new persistence store for the new UMSJMSServer for example, UMSJMSFileStore_N. Specify the path for the store. This should be a directory
on shared storage as recommended in Section 2.3, Shared Storage and
Recommended Directory Structure :
ORACLE_BASE admindomain_namecluster_namejmsUMSJMSFileStore_N
Note: The remainder of the steps assume that you are adding a new
server to SOAHOST1, which is already running WLS_SOA1.
Note:
This directory must exist before the managed server is started or the start operation fails.
Note: This directory must exist before the managed server is started
or the start operation fails. You can also assign SOAJMSFileStore_N as the store for the new UMS JMS servers. For the purpose of clarity and
isolation, individual persistent stores are used in the following steps.
12-10 Oracle Fusion Middleware Enterprise Deployment Guide for Oracle ECM Suite
d.
Create a new JMS server for UMS for example, UMSJMSServer_N. Use the UMSJMSFileStore_N for this JMS server. Target the UMSJMSServer_N server
to the recently created managed server WLS_SOAn.
e.
Update the subdeployment targets for the SOA JMS Module to include the recently created SOA JMS server. To do this, expand the Services node in the
Oracle WebLogic Server Administration Console and then expand the Messaging
node. Choose JMS Modules in the Domain Structure window. The JMS Modules page appears. Click SOAJMSModule represented as a
hyperlink in the Names column of the table. The Settings page for SOAJMSModule appears. Click the SubDeployments tab. The subdeployment
module for SOAJMS appears.
Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS server for SOA called SOAJMSServer_N to this subdeployment. Click Save.
f.
Update the subdeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS server. To do this, expand the Services node in
the Oracle WebLogic Server Administration Console and then expand the Messaging
node. Choose JMS Modules in the Domain Structure window. The JMS Modules page appears. Click UMSJMSSystemResource represented as a
hyperlink in the Names column of the table. The Settings page for UMSJMSSystemResource appears. Click the SubDeployments tab. The
subdeployment module for UMSJMS appears.
Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS server for UMS called UMSJMSServer_N to this subdeployment. Click Save.
4.
Configure Oracle Coherence for deploying composites for the new server as described in
Section 6.5, Configuring Oracle Coherence for Deploying Composites.
5. Configure a TX persistent store for the new server. This should be a location
visible from other nodes as indicated in the recommendations about shared storage see
Section 2.3, Shared Storage and Recommended Directory Structure .
From the Administration Console, select the server name in the Services tab. Under Default Store, in Directory, enter the path to the folder where you want the
default persistent store to store its data files.
Note: This subdeployment module name is a random name in the
form of SOAJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers WLS_SOA1 and
WLS_SOA2.
Note: This subdeployment module name is a random name in the
form of UCMJMSServerXXXXXX resulting from the Configuration Wizard JMS configuration for the first two servers WLS_SOA1 and
WLS_SOA2.
Note: Only the localhost field needs to be changed for the server.
Replace the localhost with the listen address of the new server added: Dtangosol.coherence.localhost=SOAHOST1VHNn.
Managing the Topology 12-11
6.
Disable host name verification for the new managed server. Before you can start and verify the WLS_SOAn managed server, you must disable host name
verification. You can re-enable it after you have configured server certificates for the communication between the Oracle WebLogic Administration Server and
Node Manager in SOAHOSTn. If the source server from which the new one has been cloned had already disabled host name verification, these steps are not
required the host name verification settings is propagated to the cloned server.
Perform these steps to disable host name verification:
a.
In the Oracle Enterprise Manager Console, select Oracle WebLogic Server Administration Console, and log in.
b. Expand the Environment node in the Domain Structure window.
