This chapter describes some operations that you can perform after you have set up the topology, including monitoring, scaling, and backing up your topology. It contains the following sections:
Section 16.1, "Overview of Managing the Oracle WebCenter Content Topology"
Section 16.2, "Defining an Optimal Input File Strategy for Oracle WebCenter Content: Imaging"
Section 16.4, "Managing Space in the SOA Infrastructure Database"
Section 16.5, "Configuring UMS Drivers for Oracle WebCenter Content: Imaging"
Section 16.6, "Scaling Up the Oracle WebCenter Content Topology"
Section 16.7, "Scaling Out the Oracle WebCenter Content Topology"
Section 16.8, "Performing Backups and Recoveries in Oracle WebCenter Content Enterprise Deployments"
Section 16.11, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology"
After configuring the Oracle WebCenter Content enterprise deployment, you can use the information in this chapter to manage the topology. Table 16-1 lists some tasks you can perform to manage the topology.
Table 16-1 Tasks for Managing the Oracle WebCenter Content Topology
| Task | Description | More Information |
|---|---|---|
|
Configure Imaging for high performance, scalability, and high availability in an Imaging cluster |
Define an optimal input file strategy |
Section 16.2, "Defining an Optimal Input File Strategy for Oracle WebCenter Content: Imaging" |
|
Manage the Oracle SOA Suite subsystem used by Imaging |
Deploy SOA composites to a server address, manage space in the Oracle SOA Suite infrastructure, and configure UMS drivers. |
Section 16.4, "Managing Space in the SOA Infrastructure Database" Section 16.5, "Configuring UMS Drivers for Oracle WebCenter Content: Imaging" |
|
Expand the topology by scaling it up, or out |
Add new managed servers to nodes, or add new nodes. |
Section 16.6, "Scaling Up the Oracle WebCenter Content Topology" Section 16.7, "Scaling Out the Oracle WebCenter Content Topology" |
|
Back up the topology before and after any configuration changes |
Back up directories and files to protect against failure as a result of configuration changes. |
Section 16.8, "Performing Backups and Recoveries in Oracle WebCenter Content Enterprise Deployments" |
|
Prevent connection timeouts |
Configure the firewall so that the database connection is not timed out. |
|
|
Configure Oracle Web Services Manager (Oracle WSM) security policies for Oracle WebCenter Content and Imaging web services |
Use the appropriate Oracle WSM policy enforcements instead of basic HTTP authentication. |
|
|
Troubleshoot problems |
Implement solutions for known issues that may occur after you have configured the topology. |
Section 16.11, "Troubleshooting the Oracle WebCenter Content Enterprise Deployment Topology" |
For more information about managing Oracle WebCenter Content, see the following documents:
The input file is the smallest unit of work that the input agent can schedule and process. There are multiple elements to be taken into consideration to achieve the highest performance, scalability, and high availability in an Imaging cluster:
All of the machines in an Imaging cluster share a common input directory.
Input files from this directory are distributed to each machine via a JMS queue.
The frequency with which the directory is polled for new files is configurable.
Each machine has multiple parsing agents that process the input files. The number of parsing agents is configured via the Work Manager created within the Oracle WebCenter Content: Imaging deployment.
Optimum performance will be achieved when:
Each Imaging cluster instance has the maximum affordable number of parsing agents configured via the Work Manager without compromising the performance of the other Imaging activities, such as the user interface and Web services.
The inbound flow of documents is partitioned into input files containing the appropriate number of documents. On average there should be two input files queued for every parsing agent within the cluster.
If one or more machines within a cluster fails, active machines will continue processing the input files. Input files from a failed machine will remain in limbo until the server is restarted. Smaller input files ensure that machine failures do not place large numbers of documents into this limbo state.
For example, consider 10,000 inbound documents per hour being processed by two servers. A configuration of two parsing agents per server produces acceptable overall performance and ingests two documents per second per agent. The four parsing agents at two documents per second is eight documents per second, or 28,800 documents per hour. Note that a single input file of 10,000 documents will not be processed in an hour since a single parsing agent working at 7,200 documents per hour will be unable to complete it. However, if you divide the single input file up into eight input files of 1,250 documents, this ensures that all four parsing agents are fully utilized, and the 10,000 documents are completed in the one hour period. Also, if a failure should occur in one of the servers, the other can continue processing the work remaining on its parsing agents until the work is successfully completed.
When deploying SOA composites to the Oracle SOA Suite subsystem used by Oracle WebCenter Content: Imaging, deploy to a specific server's address and not to the load balancer address (wcc.mycompany.com). Deploying to the load balancer address may require direct connection from the deployer nodes to the external load balancer address, which may require additional ports to be opened in the firewalls used by the system.
Although not all composites may use the database frequently, the service engines generate a considerable amount of data in the CUBE_INSTANCE and MEDIATOR_INSTANCE schemas. Lack of space in the database may prevent SOA composites from functioning. Watch for generic errors, such as oracle.fabric.common.FabricInvocationException, in the Oracle Enterprise Manager Fusion Middleware Control console (dashboard for instances). Search also in the Oracle SOA Suite server's logs for errors, such as:
Error Code: 1691 ... ORA-01691: unable to extend lob segment SOAINFRA.SYS_LOB0000108469C00017$$ by 128 in tablespace SOAINFRA
These messages are typically indicators of space issues in the database that may likely require adding more data files or more space to the existing files. The SOA database administrator should determine the extension policy and parameters to be used when adding space. Additionally, old composite instances can be purged to reduce the SOA infrastructure database size. Oracle does not recommend using Oracle Enterprise Manager Fusion Middleware Control for this type of operation as in most cases the operations cause a transaction timeout.
Refer to "Managing SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for more details on the possible operations included in the SQL packages provided. Always use the scripts provided for a correct purge. Deleting rows in just the composite_dn table may leave dangling references in other tables used by the Oracle Fusion Middleware SOA Infrastructure.
Note:
This step is required only if the Oracle SOA Suite system used by Oracle WebCenter Content: Imaging is using Unified Messaging System (UMS).
UMS driver configuration is not automatically propagated in an Oracle SOA Suite cluster. When UMS is used by the Oracle SOA Suite system that Oracle WebCenter Content: Imaging invokes, this implies that you need to do the following:
Apply the configuration of UMS drivers in each and every one of the servers in the EDG topology that is using the driver.
When server migration is used, servers are moved to a different node's domain directory. It is necessary to pre-create the UMS driver configuration in the failover node. The UMS driver configuration file location is:
ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml
(where * represents a directory whose name is randomly generated by Oracle WebLogic Server during deployment, for example, 3682yq).
To create the file in preparation for possible failovers, users can force a server migration and copy the file from the source node. For example:
Configure the driver for WLS_IMG1 in SOAHOST1.
Force a failover of WLS_IMG1 to SOAHOST2. Verify the directory structure for the UMS driver configuration in the failover node:
cd ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration
(where * represents a directory whose name is randomly generated by WLS during deployment, for example, 3682yq).
Run the following command on SOAHOST1 to do a remote copy of the driver configuration file from SOAHOST1 to SOAHOST2:
scp ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml oracle@SOAHOST2:ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/
(where * represents a directory whose name is randomly generated by Oracle WebLogic Server during deployment, for example, 3682yq).
It is required to restart the driver for these changes to take effect (that is, for the driver to consume the modified configuration):
Log in to the Oracle WebLogic Administration console.
Expand the environment node on the navigation tree.
Click Deployments.
Select the driver.
Click Stop and then When work completes and confirm the operation.
Wait for the driver to transition to the Prepared state (refresh the administration console page, if required).
Select the driver again, and click Start and then Servicing all requests and confirm the operation.
Make sure that you verify in Oracle Enterprise Manager Fusion Middleware Control that the properties for the driver have been preserved.
When you scale up the topology, you add new managed servers to nodes that are already running on one or more managed servers. You already have a node that runs a managed server that is configured with the necessary components. The node contains a WebLogic Server home and an Oracle Fusion Middleware home in shared storage. Use these existing installations (such as WebLogic Server home, Oracle Fusion Middleware home, and domain directories) when you create the new managed servers. You do not need to install WebLogic Server binaries at a new location or to run pack and unpack.
Note:
A shared domain directory for a managed server with Content Server does not work because certain files within the domain, such as intradoc.cfg, are specific to each node. To prevent issues with node-specific files, use a local (per node) domain directory for each Oracle WebCenter Content and Oracle WebCenter Content: Inbound Refinery managed server.
The scale-up procedure depends on the topology component:
Section 16.6.1, "Scale-Up Procedure for Oracle WebCenter Content"
Section 16.6.2, "Scale-Up Procedure for Oracle WebCenter Content: Imaging"
Only one Oracle WebCenter Content managed server per node per domain is supported by Oracle Fusion Middleware. To add additional Oracle WebCenter Content managed servers, follow the steps in Section 16.7.1, "Scale-Out Procedure for Oracle WebCenter Content" to add an Oracle WebCenter Content managed server to a new node.
To scale up the Imaging servers in the enterprise deployment topology:
Using the Oracle WebLogic Server Administration Console, clone WLS_IMG1 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.
To clone a managed server:
In the Domain Structure window of the WebLogic Server Administration Console, expand the Environment node and then Servers.
On the Summary of Servers page, click Lock & Edit and then select the managed server that you want to clone (WLS_IMG1).
Click Clone.
Name the new managed server WLS_IMGn, where n is a number that identifies the new managed server.
For the server 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 virtual host name for the server. This virtual host name should be different from the one used for the existing managed server.
For the server listen port, enter the listening port number for the Imaging cluster (IMG_Cluster). The reference topology in this book uses port number 16000.
Click OK and Activate Changes. You should now see the newly created server WLS_IMGn in the summary of servers.
The remainder of the steps that follow assume that you are adding a new server to WCCHOST1, which is already running WLS_IMG1.
Note:
You must enable a VIP on WCCHOST1 (say, WCCHOST1VHN2), and you must also correctly resolve the host names in the network system used by the topology (either by DNS server or host resolution). To enable the VIPs, follow the example described in Section 9.2, "Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2."
Configure a JMS persistence store and JMS servers for Oracle WebCenter Content: Imaging JMS.
Configure the location for the JMS persistence stores as a directory that is visible from both nodes. By default, the JMS servers used by Oracle WebCenter Content: Imaging are configured with no persistent store and use WebLogic Server's store (ORACLE_BASE/admin/domain_name/mserver/domain_name/servers/server_name/data/store/default). You must change Oracle's JMS server persistent store to use a shared base directory as follows:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node.
On the Summary of Persistence Stores page, click Lock & Edit.
Click New, and then Create FileStore.
On the Create a New File Store page, enter the following information:
- Name: IMGJMSServernStore (for example, IMGJMSServer3Store, which allows you identify the service it is created for)
- Target: WLS_IMGn (for example, WLS_IMG3).
- Directory: Specify a directory that is located in shared storage so that it is accessible from both WCCHOST1 and WCCHOST2 (ORACLE_BASE/admin/domain_name/img_cluster_name/jms).
Note:
This directory must exist before the managed server is started or the start operation will fail.
Click OK and activate the changes.
In the Domain Structure window, expand the Services node, then the Messages node, and then click JMS Servers.
On the Summary of JMS Servers page, click New and then enter the following information:
- Name: IpmJmsServern (for example, IpmJmsServer3)
- Persistent Store: select the persistence store that you created above: IMGJMSServernStore (for example, IMGJMSServer3Store).
Click Next and then specify WLS_IMGn (for example, WLS_IMG3) as the target. Click Finish and activate the changes.
Click the IpmJmsServer3 JMS server (represented as a hyperlink) in the Name column of the table.
On the settings page for the JMS server, click Lock & Edit.
In the Persistent Store drop-down list, select IMGJMSServernStore.
Click Save and activate the changes.
Configure a default persistence store for WLS_IMGn for transaction recovery:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click the Servers node.
On the Summary of Servers page, click WLS_IMGn (represented as a hyperlink) in the Name column of the table. The settings page for the WLS_IMGn server opens with the Configuration tab active.
Open the Services tab.
Click Lock & Edit.
In the Default Store section of the page, enter the path to the folder where the default persistent stores will store its data files. The directory structure of the path is as follows:
ORACLE_BASE/admin/domain_name/img_cluster_name/tlogs
Note:
This directory must exist before the managed server is started or the start operation will fail.
Click Save and activate the changes.
Disable host name verification for the new managed server. Before you can start and verify the WLS_IMGn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Administration Server and Node Manager in WCCHOSTn. 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).
To disable host name verification:
In the Oracle Enterprise Manager console, select WebLogic Server Administration Console, and log in.
In the Domain Structure window, expand the Environment node and click Servers.
On the Summary of Servers page, click WLS_IMGn (represented as a hyperlink) in the Name column of the table. The settings page for the WLS_IMGn server opens with the Configuration tab active.
Open the SSL tab.
Expand the Advanced section of the page.
Click Lock & Edit.
Set host name verification to None.
Click Save.
Start the newly created managed server (WLS_IMG):
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click Servers.
On the Summary of Servers page, open the Control tab, and shut down all existing WLS_IMGn managed servers in the cluster.
Ensure that the newly created managed server, WLS_IMGn, is running.
Add the host name of the WLS_IMGn managed server (WCCHOSTnVHN1) to the SocketHostNameSecurityFilter parameter list:
Open the file ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfg in a text editor.
Add the WLS_IMGn managed server to include listen addresses to the list of addresses that are allowed to connect to Oracle WebCenter Content: SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|WCCHOST1|WCCHOST2|WCCHOST1VHN1|WCCHOST1VHN2|WCCHOST2VHN1
Save the modified config.cfg file and restart the Oracle WebCenter Content servers for the changes to take effect.
Configure server migration for the new managed server.
Note:
Since this is a scale-up operation, the node should already contain a Node Manager and environment configured for server migration. The floating IP for the new managed Imaging server should also be already present.
To configure server migration:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click Servers.
On the Summary of Servers page, click the name of the new managed server (represented as a hyperlink) in Name column of the table for which you want to configure migration.
On the settings page for the selected server, open the Migration subtab.
In the Migration Configuration section, select the servers that participate in migration in the Available window and click the right arrow. Select the same migration targets as for the servers that already exist on the node.
For example, for new managed servers on WCCHOST1, which is already running WLS_IMG1, select WCCHOST2. For new managed servers on WCCHOST2, which is already running WLS_IMG2, select WCCHOST1.
Note:
The appropriate resources must be available to run the managed servers concurrently during migration.
Choose the Automatic Server Migration Enabled option. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, managed servers, and Node Manager.
Test server migration for the new server. To test migration, perform the following steps from the node where you added the new server:
Abruptly stop the WLS_IMGn managed server. To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using the following command:
ps -ef | grep WLS_IMGn
Watch the Node Manager Console for a message indicating that WLS_IMGn's floating IP has been disabled.
Wait for Node Manager to attempt a second restart of WLS_IMGn. Node Manager waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should log a message indicating that the server will not be restarted again locally.
Note:
After a server is migrated, to fail it back to its original node or machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.
To scale up the Oracle SOA Suite servers in the enterprise deployment topology:
Note:
To scale up the Oracle SOA Suite subsystem used by Oracle WebCenter Content: Imaging, refer to the Oracle SOA Suite enterprise deployment topology documentation.
Using the 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.
To clone a managed server:
In the Domain Structure window of the WebLogic Server Administration Console, expand the Environment node and then Servers.
On the Summary of Servers page, select the managed server that you want to clone (WLS_SOA1).
Click Clone.
Name the new managed server WLS_SOAn, where n is a number that identifies the new managed server.
Note:
The remainder of the steps assume that you are adding a new server to SOAHOST1, which is already running WLS_SOA1.
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.
Create JMS servers for Oracle SOA Suite and UMS on the new managed server:
Use the 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 4.3, "Recommended Locations for the Different Directories":
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
Note:
This directory must exist before the managed server is started or the start operation fails.
Create a new JMS server for Oracle SOA Suite (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).
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 4.3, "Recommended Locations for the Different Directories":
ORACLE_BASE/admin/domain_name/soa_cluster_name/jms
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.
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).
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 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. Open the SubDeployments tab. The subdeployment module for SOAJMS appears.
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).
Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS server for Oracle SOA Suite called SOAJMSServer_N to this subdeployment. Click Save.
Update the subdeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS server. To do this, expand the Services node in the 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. Open the SubDeployments tab. The subdeployment module for UMSJMS appears.
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).
Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS server for UMS called UMSJMSServer_N to this subdeployment. Click Save.
Configure Oracle Coherence for deploying composites for the new server as described in Section 9.4, "Configuring Oracle Coherence for Deploying Composites."
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.
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 4.3, "Recommended Locations for the Different Directories").
From the Administration Console, select the server name (WLS_SOAn) 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:
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
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 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).
To disable host name verification:
In the Oracle Enterprise Manager console, select WebLogic Server Administration Console, and log in.
Expand the Environment node in the Domain Structure window.
Click Servers.
On the Summary or Servers page, select WLS_SOAn in the Names column of the table.
On the settings page for the server, open the SSL tab.
Expand the Advanced section of the page.
Click Lock & Edit.
Set host name verification to None.
Click Save.
Start and test the new managed server from the WebLogic Server Administration Console:
Ensure that the newly created managed server, WLS_SOAn, is running.
Access the application on the LBR (http://soainternal.mycompany.com/soa-infra). The application should be functional.
Note:
The Oracle HTTP Servers in the topology should round-robin requests to the new added server (a few requests, depending on the number of servers in the cluster, may be required to hit the new server). Its is not required to add all servers in a cluster to the WebLogicCluster directive in Oracle HTTP Server's mod_wl_ohs.conf file. However routing to new servers in the cluster will take place only if at least one of the servers listed in the WebLogicCluster directive is running.
Configure server migration for the new managed server.
Note:
Since this is a scale-up operation, the node should already contain a Node Manager and environment configured for server migration. The floating IP for the new Oracle SOA Suite managed server should also be already present.
To configure server migration:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click Servers.
On the Summary of Servers page, click the name of the new managed server (represented as a hyperlink) in Name column of the table for which you want to configure migration.
On the settings page for the selected server, open the Migration subtab.
In the Migration Configuration section, select the servers that participate in migration in the Available window and click the right arrow. Select the same migration targets as for the servers that already exist on the node.
For example, for new managed servers on SOAHOST1, which is already running WLS_SOA1, select SOAHOST2. For new managed servers on SOAHOST2, which is already running WLS_SOA2, select SOAHOST1.
Note:
The appropriate resources must be available to run the managed servers concurrently during migration.
Choose the Automatic Server Migration Enabled option. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, managed servers, and Node Manager.
Test server migration for the new server. To test migration, perform the following steps from the node where you added the new server:
Abruptly stop the WLS_SOAn managed server. To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using the following command:
ps -ef | grep WLS_SOAn
Watch the Node Manager Console for a message indicating that WLS_SOA1's floating IP has been disabled.
Wait for Node Manager to attempt a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should log a message indicating that the server will not be restarted again locally.
Note:
After a server is migrated, to fail it back to its original node or machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.
When scaling out the topology, you add new managed servers configured to new nodes.
Before performing the steps in this section, check that you meet these requirements:
There must be existing nodes running managed servers configured with Oracle Fusion Middleware within the topology.
The new node can access the existing home directories for WebLogic Server and Fusion Middleware. (Use the existing installations in shared storage for creating a new managed server. You do not need to install WebLogic Server or Fusion Middleware binaries in a new location, but you do need to run pack and unpack to bootstrap the domain configuration in the new node.)
When an ORACLE_HOME or WL_HOME is shared by multiple servers in different nodes, it is recommended that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches. To update the oraInventory in a node and attach an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh.
To update the Middleware home list to add or remove a WL_HOME, edit the User_Home/bea/beahomelist file. See the following steps.
The new server can use a new individual domain directory or, if the other managed servers domain directories reside on shared storage, reuse the domain directories on those servers.
Note:
A shared domain directory for a managed server with Content Server does not work because certain files within the domain, such as intradoc.cfg, are specific to each node. To prevent issues with node-specific files, use a local (per node) domain directory for each Oracle WebCenter Content and Oracle WebCenter Content: Inbound Refinery managed server.
The scale-out procedure depends on the topology component:
Section 16.7.1, "Scale-Out Procedure for Oracle WebCenter Content"
Section 16.7.2, "Scale-Out Procedure for Oracle WebCenter Content: Imaging"
To scale out the Oracle WebCenter Content servers in the enterprise deployment topology:
Note:
These steps assume that you are adding a new WebCenter Content server to node n, where no managed server was running previously.
On the new node, mount the existing Middleware home, which should include the Oracle WebCenter Content installation and domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command on WCCHOSTn:
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager address to map the IP of the node that is being used for scale-out.
Use the WebLogic Server Administration Console to clone WLS_WCC1 into a new managed server. Name it WLS_WCCn, where n is a number.
Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the host name or IP of WCCHOSTn to use for the new managed server as the listen address of the managed server.
Run the pack command on SOAHOST1 to create a template pack:
Note:
If the domain directory for other managed servers resides on a shared directory, then steps 8, 9, and 10 are not required. Instead, the new nodes mount the already existing domain directory and use it for the new added managed server.
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleWCC.jar -template_name=edgdomain_templateScaleWCC
Run the following command on SOAHOST1 to copy the created template file to WCCHOSTn:
scp edgdomaintemplateScaleWCC.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
Run the unpack command on WCCHOSTn to unpack the template in the managed server domain directory:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=edgdomaintemplateScaleWCC.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Start Node Manager on the new node if it has not started already. To start Node Manager, use the installation in shared storage from the already existing nodes and then start Node Manager by passing the host name of the new node as a parameter as follows (on WCCHOSTn):
WL_HOME/server/bin/startNodeManager.sh New_Node_IP
Note:
If you used the paths shown in Section 6.3.1, "Installing Oracle WebLogic Server and Creating the Middleware Home," WL_HOME would be ORACLE_BASE/product/fmw/wlserver_10.3.
Disable host name verification for the new managed server. Before you can start and verify the WLS_WCCn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Administration Server and Node Manager in WCCHOSTn. 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 setting is propagated to the cloned server).
To disable host name verification:
In the Oracle Enterprise Manager console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers.
On the Summary of Servers page, select WLS_WCCn in the Names column of the table.
On the settings page for the server, open the SSL tab.
Expand the Advanced section of the page.
Click Lock & Edit.
Set host name verification to None.
Click Save.
Start the new managed server, WLS_WCCn, from the WebLogic Server Administration Console:
Expand the Environment node in the Domain Structure window.
Choose Servers.
On the Summary of Server page, open the Control tab.
Select the WLS_WCCn server and then click Start.
Verify that the server status is reported as Running in the Administration Console.
Configure the new managed server, WLS_WCCn:
Log in to WLS_WCCn at http://WCCHOSTn:16200/cs using your Oracle WebLogic Server administration user name and password. The WebCenter Content Configuration page opens.
Note:
At the end of page you should see this text: Since the Revisions table in the database is not empty, you are not able to configure this server as a new instance. You may only configure this server to be a node in an existing cluster.
Change the following values on the server configuration page. Make sure that Cluster Node Identifier is set to match your managed server ID, such as WLS_WCCn, and that the Is new Content Server Instance? checkbox is not selected.
- Content Server Instance Folder: Set this to ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs.
- Native File Repository Location: Set this to ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/vault.
- WebLayout Folder: Set this to ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/weblayout.
- User Profile: Set this to ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/data/users/profiles
Click Submit when finished and restart the new managed server using the WebLogic Server Administration Console.
Test the WLS_WCCn managed server by accessing the application on the LBR (https://wcc.mycompany.com/cs). The application should be functional.
Notes:
The HTTP Servers in the topology should round-robin requests to the new added server (a few requests, depending on the number of servers in the cluster, may be required to hit the new server). Its is not required to add all servers in a cluster to the WebLogicCluster directive in Oracle HTTP Server's mod_wl_ohs.conf file. However routing to new servers in the cluster will take place only if at least one of the servers listed in the WebLogicCluster directive is running.
If the scale-out procedure has been done to add a new WebCenter Content managed server, make sure that this newly added WCCHOSTn is added to the list of servers in the Content Server pool while you create a connection to Oracle WebCenter Content.
The servers to be added in the Content Server pool follow:
- WCCHOST1:4444
- WCCHOST2:4444
- WCCHOST3:4444
For more information, see Section 11.16, "Creating a Connection to Oracle WebCenter Content."
To scale out the Imaging servers in the enterprise deployment topology:
On the new node, mount the existing Middleware home, which should include the Oracle WebCenter Content installation and (optionally, if the domain directory for managed servers in other nodes resides on shared storage) the domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command on WCCHOSTn:
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager address to map the IP of the node that is being used for scale-out.
Use the WebLogic Server Administration Console to clone WLS_IMG1 into a new managed server. Name it WLS_IMGn, where n is a number.
Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the host name or IP to use for the new managed server for the listen address of the 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) for the server. This VIP should be different from the one used for the existing managed server.
Note:
You must enable a VIP on node n, and you must also correctly resolve the host names in the network system used by the topology (either by DNS server or host resolution). To enable the VIPs, follow the example described in Section 9.2, "Enabling SOAHOST1VHN1 on SOAHOST1 and SOAHOST2VHN1 on SOAHOST2."
Also, assign the newly created server to the machine you added in the step 4. Without this, the machine name of the cloned server will remain.
Create a JMS server for Oracle WebCenter Content: Imaging on the new managed server:
Use the WebLogic Server Administration Console to first create a new persistent store for the new IMGJMSServer (which will be created in a later step) and name it, for example, IMGJMSFileStore_N. Specify the path for the store as recommended in Section 4.3, "Recommended Locations for the Different Directories" as the directory for the JMS persistent stores:
ORACLE_BASE/admin/domain_name/cluster_name/jms/
Note:
This directory must exist before the managed server is started or the start operation will fail.
Create a new JMS server for; for example, IMGJMSServer_N. Use the IMGJMSFileStore_N created above for this JMS server. Target the IMGJMSServer_N server to the recently created managed server (WLS_IMGn).
Run the pack command on SOAHOST1 to create a template pack:
Note:
If the domain directory for other managed servers resides on a shared directory, this step is not required. Instead, the new nodes mount the already existing domain directory and use it for the newly added managed server.
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleIMG.jar -template_name=edgdomain_templateScaleIMG
Run the following command on SOAHOST1 to copy the created template file to WCCHOSTn:
Note:
If the new host, WCCHOSTn or SOAHOSTn, will use the same MW_HOME as SOAHOST1, then this step is not required.
scp edgdomaintemplateScaleIMG.jar oracle@WCCHOSTn:/ORACLE_COMMON_HOME/common/bin
Run the unpack command on WCCHOSTn to unpack the template in the managed server domain directory:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleIMG.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Disable host name verification for the new managed server. Before you can start and verify the WLS_IMGn managed server, you must disable host name verification. You can re-enable it after you have configured server certificates for the communication between the Administration Server and Node Manager in WCCHOSTn. 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 setting is propagated to the cloned server).
To disable host name verification:
In the Oracle Enterprise Manager console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers.
On the Summary of Servers page, select WLS_IMGn in the Names column of the table.
On the settings page for the server, open the SSL tab.
Expand the Advanced section of the page.
Click Lock & Edit.
Set host name verification to None.
Click Save.
Start Node Manager on the new node. To start Node Manager, use the installation in shared storage from the already existing nodes and then start Node Manager by passing the host name of the new node as a parameter as follows (on WCCHOSTn):
WL_HOME/server/bin/startNodeManager.sh New_Node_IP
Note:
If you used the paths shown in Chapter 6, "Installing Oracle WebLogic Server and Creating the Middleware Home," WL_HOME would be ORACLE_BASE/product/fmw/wlserver_10.3.
Start the new managed server, WLS_IMGn, from the WebLogic Server Administration Console and make sure it is running.
Add the new Imaging server listen addresses to the list of allowed hosts in Oracle WebCenter Content Server. Follow the steps in Section 11.15, "Adding the Imaging Server Listen Addresses to the List of Allowed Hosts in Oracle WebCenter Content" to add the new server to the SocketHostNameSecurityFilter configuration for Oracle WebCenter Content.
Restart all Oracle WebCenter Content managed servers.
Note:
Make sure that the host names of all Imaging managed servers have been added to the SocketHostNameSecurityFilter parameter list in the ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfg file.
Test the WLS_IMGn managed server by accessing the application on the LBR (https://wcc.mycompany.com/imaging). The application should be functional.
Note:
The HTTP Servers in the topology should round-robin requests to the new added server (a few requests, depending on the number of servers in the cluster, may be required to hit the new server). Its is not required to add all servers in a cluster to the WebLogicCluster directive in Oracle HTTP Server's mod_wl_ohs.conf file. However routing to new servers in the cluster will take place only if at least one of the servers listed in the WebLogicCluster directive is running.
Configure server migration for the newly added server.
Note:
Since this new node uses an existing shared storage installation, the node already is using a Node Manager and an environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges, and so on. Verify the privileges defined in the new node to make sure server migration will work. Refer to Chapter 14, "Configuring Server Migration for an Enterprise Deployment" for more details on privilege requirements.
To configure server migration:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click Servers.
On the Summary of Servers page, click the name of the server (represented as a hyperlink) in the Name column of the table for which you want to configure migration.
On the settings page for the selected server, open the Migration subtab.
In the Available field of the Migration Configuration section, select the machines to which to allow migration and click the right arrow.
Note:
Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.
Choose the Automatic Server Migration Enabled option. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, managed servers, and Node Manager.
Test server migration for the new server. To test migration, perform the following steps from the node where you added the new server:
Abruptly stop the WLS_IMGn managed server. To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using the following command:
ps -ef | grep WLS_IMGn
Watch the Node Manager Console for a message indicating that WLS_IMGn's floating IP has been disabled.
Wait for Node Manager to attempt a second restart of WLS_IMGn. Node Manager waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should log a message indicating that the server will not be restarted again locally.
Note:
After a server is migrated, to fail it back to its original node or machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.
To scale out the Oracle SOA Suite servers in the topology:
Note:
To scale out the Oracle SOA Suite subsystem used by Oracle WebCenter Content: Imaging, refer to the Oracle SOA Suite enterprise deployment topology documentation.
On the new node, mount the existing Middleware home, which should include the Oracle SOA Suite installation and domain directory, and ensure that the new node has access to this directory, just like the rest of the nodes in the domain.
To attach ORACLE_HOME in shared storage to the local Oracle Inventory, execute the following command on SOAHOSTn:
cd ORACLE_COMMON_HOME/oui/bin/ ./attachHome.sh -jreLoc ORACLE_BASE/product/fmw/jrockit_160_version
To update the Middleware home list, create (or edit, if another WebLogic installation exists in the node) the MW_HOME/bea/beahomelist file and add ORACLE_BASE/product/fmw to it.
Log in to the Oracle WebLogic Administration Console.
Create a new machine for the new node that will be used, and add the machine to the domain.
Update the machine's Node Manager address to map the IP of the node that is being used for scale-out.
Use the WebLogic Server Administration Console to clone WLS_SOA1 into a new managed server. Name it WLS_SOAn, where n is a number.
Note:
These steps assume that you are adding a new server to node n, where no managed server was running previously.
Assign the host name or IP to use for the new managed server for the listen address of the 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) for the server. This VIP should be different from the one used for the existing managed server.
Run the pack command on SOAHOST1 to create a template pack:
Note:
If the domain directory for other managed servers resides on a shared directory, this step is not required. Instead, the new nodes mount the already existing domain directory and use it for the newly added managed server.
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=edgdomaintemplateScaleSOA.jar -template_name=edgdomain_templateScaleSOA
Run the following command on SOAHOST1 to copy the created template file to SOAHOSTn:
scp edgdomaintemplateScaleSOA.jar oracle@SOAHOSTn:/ORACLE_COMMON_HOME/common/bin
Run the unpack command on SOAHOSTn to unpack the template in the managed server domain directory:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template= edgdomaintemplateScaleSOA.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Create JMS servers for Oracle SOA Suite and UMS on the new managed server:
Use the 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 4.3, "Recommended Locations for the Different Directories":
ORACLE_BASE/admin/domain_name/cluster_name/jms
Note:
This directory must exist before the managed server is started or the start operation fails.
Create a new JMS server for Oracle SOA Suite (for example, SOAJMSServer_N). Use SOAJMSFileStore_N for this JMS server. Target the SOAJMSServer_N server to the recently created managed server (WLS_SOAn).
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 4.3, "Recommended Locations for the Different Directories":
ORACLE_BASE/admin/domain_name/cluster_name/jms
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.
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).
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 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. Open the SubDeployments tab. The subdeployment module for SOAJMS appears.
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).
Click the SOAJMSServerXXXXXX subdeployment. Add the new JMS server for Oracle SOA Suite called SOAJMSServer_N to this subdeployment. Click Save.
Update the subdeployment targets for the UMSJMSSystemResource to include the recently created UMS JMS server. To do this, expand the Services node in the 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. Open the SubDeployments tab. The subdeployment module for UMSJMS appears.
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).
Click the UMSJMSServerXXXXXX subdeployment. Add the new JMS server for UMS called UMSJMSServer_N to this subdeployment. Click Save.
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 4.3, "Recommended Locations for the Different Directories").
From the Administration Console, select the server name (WLS_SOAn) 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:
ORACLE_BASE/admin/domain_name/soa_cluster_name/tlogs
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 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 setting is propagated to the cloned server).
To disable host name verification:
In the Oracle Enterprise Manager console, select Oracle WebLogic Server Administration Console.
Expand the Environment node in the Domain Structure window.
Click Servers.
On the Summary of Servers page, select WLS_SOAn in the Names column of the table.
On the settings page for the server, open the SSL tab.
Expand the Advanced section of the page.
Click Lock & Edit.
Set host name verification to None.
Click Save.
Start Node Manager on the new node. To start Node Manager, use the installation in shared storage from the already existing nodes and then start Node Manager by passing the host name of the new node as a parameter as follows (on SOAHOSTn):
WL_HOME/server/bin/startNodeManager.sh New_Node_IP
Note:
If you used the paths shown in Chapter 6, "Installing Oracle WebLogic Server and Creating the Middleware Home," WL_HOME would be ORACLE_BASE/product/fmw/wlserver_10.3.
Start the new managed server, WLS_SOAn, from the WebLogic Server Administration Console and make sure it is running.
Test the WLS_SOAn managed server by accessing the application on the LBR (http://soainternal.mycompany.com/soa-infra). The application should be functional.
Note:
The HTTP Servers in the topology should round-robin requests to the new added server (a few requests, depending on the number of servers in the cluster, may be required to hit the new server). Its is not required to add all servers in a cluster to the WebLogicCluster directive in Oracle HTTP Server's mod_wl_ohs.conf file. However routing to new servers in the cluster will take place only if at least one of the servers listed in the WebLogicCluster directive is running.
Configure server migration for the newly added server.
Note:
Since this new node uses an existing shared storage installation, the node already is using a Node Manager and an environment configured for server migration that includes netmask, interface, wlsifconfig script superuser privileges, and so on. The floating IP for the new Oracle SOA Suite managed server is already present in the new node.
To configure server migration:
Log in to the WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node and then click Servers.
On the Summary of Servers page, click the name of the server (represented as a hyperlink) in Name column of the table for which you want to configure migration.
On the settings page for the selected server, open the Migration subtab.
In the Available field of the Migration Configuration section, select the machines to which to allow migration and click the right arrow.
Note:
Specify the least-loaded machine as the migration target for the new server. The required capacity planning must be completed so that this node has enough available resources to sustain an additional managed server.
Choose the Automatic Server Migration Enabled option. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Restart the Administration Server, managed servers, and Node Manager.
Test server migration for the new server. To test migration, perform the following steps from the node where you added the new server:
Abruptly stop the WLS_SOAn managed server. To do this, run kill -9 pid on the PID of the managed server. You can identify the PID of the node using the following command:
ps -ef | grep WLS_SOAn
Watch the Node Manager Console for a message indicating that WLS_SOAn's floating IP has been disabled.
Wait for Node Manager to attempt a second restart of WLS_SOAn. Node Manager waits for a fence period of 30 seconds before trying this restart.
Once Node Manager restarts the server, stop it again. Node Manager should log a message indicating that the server will not be restarted again locally.
Note:
After a server is migrated, to fail it back to its original node or machine, stop the managed server from the Oracle WebLogic Administration Console and then start it again. The appropriate Node Manager will start the managed server on the machine to which it was originally assigned.
Table 16-2 lists the static artifacts to back up in the Oracle WebCenter Content 11g enterprise deployment.
Table 16-2 Static Artifacts to Back Up in the Oracle WebCenter Content 11g Enterprise Deployment
| Type | Host | Location | Tier |
|---|---|---|---|
|
ORACLE HOME (DB) |
CUSTDBHOST1 and CUSTDBHOST2 |
The location is user defined. |
Data tier |
|
MW HOME (OHS) |
WEBHOST1 and WEBHOST2 |
ORACLE_BASE/product/fmw |
Web tier |
|
MW HOME (this includes the SOA Oracle home as well) |
SOAHOST1 and SOAHOST2* |
MW_HOME The SOA Oracle home is also under MW_HOME: ORACLE_HOME |
Application tier |
|
Installation-related files |
OraInventory, User_Home/bea/beahomelist, |
N/A |
* WCCHOST1 and WCCHOST2 use the binaries installed from SOAHOST1 and SOAHOST2. Backup is centralized in SOAHOST1 and SOAHOST2.
Table 16-3 lists the runtime artifacts to back up in the Oracle WebCenter Content 11g enterprise deployment.
Table 16-3 Runtime Artifacts to Back Up in the Oracle WebCenter Content 11g Enterprise Deployment
| Type | Host | Location | Tier |
|---|---|---|---|
|
Application artifacts (EAR and WAR files) |
SOAHOST1, SOAHOST2, WCCHOST1, and WCCHOST2 |
Find the application artifacts by viewing all of the deployments through the administration console. |
Application tier |
|
Oracle SOA Suite runtime artifacts |
SOAHOST1 or SOAHOST2 |
ORACLE_BASE/admin/domain_name/soa_cluster_name |
Application tier |
|
Oracle WebCenter Content runtime artifacts |
WCCHOST1 or WCCHOST2 |
ORACLE_BASE/admin/domain_name/wcc_cluster_name |
Application tier |
|
Oracle WebCenter Content: Imaging runtime artifacts |
WCCHOST1 or WCCHOST2 |
ORACLE_BASE/admin/domain_name/img_cluster_name |
Application tier |
|
Customized managed server configuration for Oracle WebCenter Content |
WCCHOST1 or WCCHOST2 |
ORACLE_BASE/admin/domain_name/mserver/domain_name/ucm/cs/bin/intradoc.cfg and ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh |
Application tier |
|
Customized managed server configuration for Oracle SOA Suite |
SOAHOST1 or SOAHOST2 |
If using UMS: DOMAIN_HOME/servers/server_name/tmp/_WL_user/ums_driver_name/*/configuration/driverconfig.xml (where and ORACLE_BASE/admin/domain_name/mserver/domain_name/bin/server_migration/wlsifconfig.sh |
Application tier |
|
Oracle HTTP Server instance home |
WEBHOST1 and WEBHOST2 |
ORACLE_BASE/admin/instance_name |
Web tier |
|
Oracle RAC databases |
CUSTDBHOST1 and CUSTDBHOST2 |
The location is user-defined. |
Data tier |
For more information on backup and recovery of Oracle Fusion Middleware components, see Oracle Fusion Middleware Administrator's Guide.
Much of the production enterprise deployment involves firewalls. Because database connections are made across firewalls, Oracle recommends that the firewall be configured so that the database connection is not timed out. For Oracle Real Application Clusters (RAC), the database connections are made on Oracle RAC VIPs and the database listener port. You must configure the firewall to not time out such connections. If such a configuration is not possible, set the*SQLNET.EXPIRE_TIME=n* parameter in the ORACLE_HOME/network/admin/sqlnet.ora file on the database server, where n is the time in minutes. Set this value to less than the known value of the timeout for the network device (that is, a firewall). For Oracle RAC, set this parameter in all of the Oracle home directories.
When first installed, the Oracle WebCenter Content and Imaging web services are configured with no Oracle Web Service Manager (OWSM) security policies applied. When no security policies are applied, the services leverage the basic HTTP authentication mechanism, where user credentials (user ID and password) are transmitted in the web service HTTP message header. Oracle recommends using the appropriate Oracle WSM policy enforcements instead of basic HTTP authentication. To configure Oracle WSM security policies for Oracle WebCenter Content and Imaging web services, follow the steps in the Oracle WebCenter Content Developer's Guide for Imaging and the Oracle WebCenter Content Installation Guide.
This section covers the following topics:
Section 16.11.1, "Page Not Found When Accessing soa-infra Application Through Load Balancer"
Section 16.11.3, "Incomplete Policy Migration After Failed Restart of SOA Server"
Section 16.11.5, "Administration Server Fails to Start After a Manual Failover"
Section 16.11.6, "Error While Activating Changes in Administration Console"
Section 16.11.7, "SOA or Imaging Server Not Failed Over After Server Migration"
Section 16.11.8, "SOA or Imaging Server Not Reachable From Browser After Server Migration"
Section 16.11.9, "OAM Configuration Tool Does Not Remove URLs"
Section 16.11.16, "Regenerating the Master Password for Oracle WebCenter Content Servers"
Problem: A 404 page not found message is displayed in the web browser when you try to access the soa-infra application using the load balancer address. The error is intermittent and Oracle SOA Suite servers appear as Running in the WebLogic Server Administration Console.
Solution: Even when the Oracle SOA Suite managed servers are up and running, some of the applications contained in them can be in Admin, Prepared or other states different from Active. The soa-infra application may be unavailable while the Oracle SOA Suite server is running. Check the Deployments page in the Administration Console to verify the status of the soa-infra application. It should be in the Active state. Check the Oracle SOA Suite server's output log for errors pertaining to the soa-infra application and try to start it from the Deployments page in the Administration Console.
Problem: The soa-infra application fails to start after changes to the Coherence configuration for deployment have been applied. The Oracle SOA Suite server output log reports the following:
Cluster communication initialization failed. If you are using multicast, Please make sure multicast is enabled on your network and that there is no interference on the address in use. Please see the documentation for more details.
Solutions:
When using multicast instead of unicast for cluster deployments of SOA composites, you may get a message similar to the preceding one if a multicast conflict arises when starting the soa-infra application (that is, starting the managed server on which Oracle SOA Suite runs). These messages, which occur when Oracle Coherence throws a run-time exception, also include the details of the exception itself. If such a message appears, check the multicast configuration in your network. Verify that you can ping multicast addresses. In addition, check for other clusters that may have the same multicast address but have a different cluster name in your network, as this may cause a conflict that prevents soa-infra from starting. If multicast is not enabled in your network, you can change the deployment framework to use unicast as described in Oracle Coherence Developer's Guide for Oracle Coherence.
When entering well-known address list for unicast (in server start parameters), make sure that the node's addresses entered for the localhost and clustered servers are correct. Error messages like the following are reported in the server's output log if any of the addresses is not resolved correctly:
oracle.integration.platform.blocks.deploy.CompositeDeploymentCoordinatorMessages errorUnableToStartCoherence
Problem: The Oracle SOA Suite server fails to start through the administration console before setting Node Manager property startScriptEnabled=true. The server does not come up after the property is set either. The Oracle SOA Suite server output log reports the following:
SEVERE: <.> Unable to Encrypt data Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. ORABPEL-35010 . Unable to Encrypt data. Unable to Encrypt data. Check installation/post-installation steps for errors. Check for errors during SOA server startup. . at oracle.bpel.services.common.util.EncryptionService.encrypt(EncryptionService.java:56) ...
Solution: Incomplete policy migration results from an unsuccessful start of the first Oracle SOA Suite server in a cluster. To enable full migration, edit the <jazn-policy> element the system-jazn-data.xml file to grant permission to bpm-services.jar:
<grant>
<grantee>
<codesource>
<url>file:${oracle.home}/soa/modules/oracle.soa.workflow_11.1.1/bpm-services.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>java.security.AllPermission</class>
</permission>
</permissions>
</grant>
Problem: An Oracle SOA Suite, Oracle WebCenter Content, or Imaging server fails to start. The domain has been extended for new types of managed server (for example, Oracle WebCenter Content extended for Imaging) or the system has been scaled up (added new servers of the same type). The Oracle SOA Suite, Oracle WebCenter Content, or Imaging server output log reports the following:
<Warning> <JDBC> <BEA-001129> <Received exception while creating connection for pool "SOADataSource-rac0": Listener refused the connection with the following error: ORA-12516, TNS:listener could not find available handler with matching protocol stack >
Solution: Verify the number of processes in the database and adjust accordingly. As the SYS user, issue the SHOW PARAMETER command:
SHOW PARAMETER processes
Set the initialization parameter using the following SQL command:
ALTER SYSTEM SET processes=300 SCOPE=SPFILE
Restart the database.
Note:
The method that you use to change a parameter's value depends on whether the parameter is static or dynamic, and on whether your database uses a parameter file or a server parameter file. See the Oracle Database Administrator's Guide for details on parameter files, server parameter files, and how to change parameter values.
Problem: Administration Server fails to start after the Administration Server node failed and manual failover to another nodes is performed. The Administration Server output log reports the following:
<Feb 19, 2009 3:43:05 AM PST> <Warning> <EmbeddedLDAP> <BEA-171520> <Could not obtain an exclusive lock for directory: ORACLE_BASE/admin/edg_domain/aserver/edg_domain/servers/AdminServer/data/ldap/ldapfiles.
Waiting for 10 seconds and then retrying in case existing WebLogic Server is still shutting down.>
Solution: When restoring a node after a node crash and using shared storage for the domain directory, you may see this error in the log for the Administration Server due to unsuccessful lock cleanup. To resolve this error, remove the file ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/data/ldap/ldapfiles/EmbeddedLDAP.lok.
Problem: Activation of changes in Administration Console fails after changes to a server's start configuration have been performed. The Administration Console reports the following when Activate Changes is clicked:
An error occurred during activation of changes, please see the log for details. [Management:141190]The commit phase of the configuration update failed with an exception: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean
Solution: This may happen when start parameters are changed for a server in the Administration Console. In this case, provide user name and password information in the server start configuration in the Administration Console for the specific server whose configuration was being changed.
Problem: After reaching the maximum restart attempts by local Node Manager, Node Manager in the failover node tries to restart it, but the server does not come up. The server seems to be failed over as reported by Node Manager's output information. The VIP used by the Oracle SOA Suite or Oracle WebCenter Content: Imaging server is not enabled in the failover node after Node Manager tries to migrate it (if config in the failover node does not report the VIP in any interface). Executing the command sudo ifconfig $INTERFACE $ADDRESS $NETMASK does not enable the IP in the failover node.
Solution: The rights and configuration for sudo execution should not prompt for a password. Verify the configuration of sudo with your system administrator so that sudo works without a password prompt.
Problem: Server migration is working (Oracle SOA Suite or Oracle WebCenter Content: Imaging server is restarted in the failed over node), but the Virtual_Hostname:8001/soa-infra URL cannot be accessed in the web browser. The server has been killed in its original host, and Node Manager in the failover node reports that the VIP has been migrated and the server started. The VIP used by the Oracle SOA Suite or Imaging server cannot be pinged from the client's node (that is, the node where the browser is being used).
Solution: The arping command executed by Node Mnager to update ARP caches did not broadcast the update properly. In this case, the node is not reachable to external nodes. Either update the nodemanager.properties file to include the MACBroadcast or execute a manual arping:
/sbin/arping -b -q -c 3 -A -I INTERFACE ADDRESS > $NullDevice 2>&1
Where INTERFACE is the network interface where the virtual IP is enabled and ADDRESS is the virtual IP address.
Problem: The OAM Configuration Tool has been used and a set of URLs was added to the policies in Oracle Access Manager. One of multiple URLs had a typo. Executing the OAM Configuration Tool again with the correct URLs completes successfully; however, when accessing Policy Manager, the incorrect URL is still there.
Solution: The OAM Configuration Tool only adds new URLs to existing policies when executed with the same app_domain name. To remove a URL, use the Policy Manager Console in OAM. Log in to the Access Administration site for OAM, click My Policy Domains, click the created policy domain (SOA_EDG), then click the Resources tab, and remove the incorrect URLs.
Problem: After configuring OHS and LBR to access the Oracle WebLogic Administration Console, some activation changes cause the redirection to the login screen for the Administration Console.
Solution: This is the result of the console attempting to follow changes to port, channel, and security settings as a user makes these changes. For certain changes, the console may redirect to the Administration Server's listen address. Activation is completed regardless of the redirection. It is not required to log in again; users can simply update the URL to wcc.mycompany.com/console/console.portal and directly access the home page for the Administration Console.
Note:
This problem will not occur if you have disabled tracking of the changes described in this section.
Problem: After configuring OAM, some activation changes cause the redirection to the Administration Console's home page (instead of the context menu where the activation was performed).
Solution: This is expected when OAM SSO is configured and the Administration Console is set to follow configuration changes (redirections are performed by the Administration Server when activating some changes). Activations should complete regardless of this redirection. For successive changes not to redirect, access the Administration Console, choose Preferences, then Shared Preferences, and unselect the Follow Configuration Changes checkbox.
Problem: Attempts to start a managed server that uses the Java Object Cache, such as OWSM managed servers, fail. The following errors appear in the logs:
J2EE JOC-058 distributed cache initialization failure J2EE JOC-043 base exception: J2EE JOC-803 unexpected EOF during read.
Solution: Another process is using the same port that JOC is attempting to obtain. Either stop that process, or reconfigure JOC for this cluster to use another port in the recommended port range.
Problem: Oracle WebCenter Content: Imaging creates the credential access permissions during startup and updates its local domain directory copy of the system-jazn-data.xml file. While testing the environment without an LDAP policy store being configured, the Administration Server may push manual updates to the system.jazn-data.xml file to the domain directories where the Oracle WebCenter Content: Imaging servers reside. This can cause the copy of the file to be overwritten, given rise to a variety of exceptions and errors in the restarts or access to the Oracle WebCenter Content: Imaging console.
Solution: To re-create the credential access permissions and update the Administration Server's domain directory copy of the system-jazn-data.xml file, use the grantIPMCredAccess command from the Oracle WebLogic Scripting Tool. To do this, start wlst.sh from the ORACLE_HOME associated with Oracle WebCenter Content, connect to the Administration Server, and execute the grantIPMCredAccess() command on WCCHOST1:
cd ORACLE_HOME/common/bin
./wlst.sh
wls:/offline> connect()
wls:/domain_name/serverConfig> grantIPMCredAccess()
Note:
When connecting, provide the credentials and address for the Administration Server.
Problem: If a host name-based security filter is used in Oracle WebCenter Content (config.cfg file), a high latency and performance impact may be observed in the system in the event of very intensive document uploads from Oracle WebCenter Content: Imaging to Oracle WebCenter Content. This is caused by the reverse DNS lookup which is required in Oracle WebCenter Content to allow the connections from the Imaging servers.
Solution: Using a host name-based security filter is recommended in preparation of configuring the system for disaster protection and to restore to a different host (since the configuration used is IP-agnostic when using a host name-based security filter). However, if the performance of the uploads needs to be improved, you can use an IP-based security filter instead of a host name-based filter.
To change the host name-based security filter in Oracle WebCenter Content to an IP-based filter:
Open the file ORACLE_BASE/admin/domain_name/wcc_cluster_name/cs/config/config.cfg in a text editor.
Remove or comment out the following two lines:
SocketHostNameSecurityFilter=localhost|localhost.mycompany.com|wcchost1vhn1|wcchost2vhn1 AlwaysReverseLookupForHost=Yes
Add the IP addresses (listen addresses) of the WLS_IMG1 and WLS_IMG2 managed servers (WCCHOST1VHN1 and WCCHOST2VHN1, respectively) to the SocketHostAddressSecurityFilter parameter list:
SocketHostAddressSecurityFilter=127.0.0.1|0:0:0:0:0:0:0:1|X.X.X.X|Y.Y.Y.Y
where X.X.X.X and Y.Y.Y.Y are the listen addresses of WLS_IMG1 and WLS_IMG2, respectively. (Please note that 127.0.0.1 must be included in the list as well.)
Save the modified config.cfg file and restart the Oracle WebCenter Content servers for the changes to take effect.
Problem: You are experiencing out-of-memory issues on managed servers.
Solution: Increase the size of the memory heap allocated for the Java VM to at least one gigabyte:
Log in to the Oracle WebLogic Administration Console.
Click Environment, then Servers.
Click a managed server name.
Open the Configuration tab.
Open the Server Start tab in the second row of tabs.
Include the memory parameters in the Arguments box, for example:
-Xms256m -Xmx1024m -XX:CompileThreshold=8000 -XX:PermSize=128m -XX:MaxPermSize=1024m
Note:
Please note that the memory parameter requirements may differ between various JVMs (Sun, JRockit, or others). See "Increasing the Java VM Heap Size for Managed Servers" in the Oracle WebCenter Content Installation Guide for further details.
Save the configuration changes.
Restart all running managed servers.
In case the cwallet.sso file of the Oracle WebCenter Content managed servers domain home becomes inconsistent across the cluster, is deleted, or is accidentally overwritten by an invalid copy in the ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig directory, you can perform these steps to regenerate the file:
Stop all Oracle WebCenter Content managed servers (WLS_WCCx).
Remove the cwallet.sso file from ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig.
Remove the password.hda file from ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/private.
Start the WLS_WCC1 server in WCCHOST1.
Verify the creation or update of the cwallet.sso file in ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig as well as the creation of the password.hda file in ORACLE_BASE/admin/domain_name/aserver/wcc_cluster_name/cs/config/private.
Use Oracle WebCenter Content's System Properties command-line tool to update the passwords for the database.
Verify that the standalone Oracle WebCenter Content applications (Batchloader, System Properties, and so on) are working correctly.
Copy the cwallet.sso file from ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig to the Administration Server's domain directory at ORACLE_BASE/admin/domain_name/aserver/domain_name/config/fmwconfig.
Start the second Oracle WebCenter Content server, and verify that the Administration Server pushes the updated cwallet.sso file to ORACLE_BASE/admin/domain_name/mserver/domain_name/config/fmwconfig in WCCHOST2 and that the file is the same as created or updated by the Oracle WebCenter Content server in WCCHOST1.
Verify that the standalone Oracle WebCenter Content applications (Batchloader, System Properties, and so on) are working correctly.
Verify that the standalone Oracle WebCenter Content applications work correctly on both nodes at the same time.
When you log in to the WebLogic Server administration console using Oracle Access Manager single sign-on (SSO), then clicking the logout button does not end the user session. You are not redirected to the OAM login page, which is in accordance with the SSO logout guidelines, but rather the home page is reloaded. To truly log out, you may need to manually clean up the cookies for your web browser.