7 Performing OSM Post-Installation Tasks
This chapter describes Oracle Communications Order and Service Management (OSM) post-installation tasks.
OSM Client Configuration Post-Installation Tasks
Note:
If there is an upgrade to OSM 7.5.0.0.1, it is normal to see multiple entries for the cartridge management WS application in the WebLogic Admin console. However, only one of those should be active with all others showing status as retired. You can delete the retired application versions at your convenience.Enabling Graphical Display on UNIX or Linux Systems
To display graphical representations such as orchestration plans on UNIX or Linux systems, OSM requires an Xserver such as Xvfb (X virtual framebuffer), an X11 server that is available for most UNIX or Linux platforms.
The following steps apply to Oracle Solaris. For other operating systems, refer to the respective product documentation.
-
Obtain and install Xvfb for your operating system.
Refer to your OS product documentation for specifics on Xvfb. On Solaris, Xvfb is included in the SUNWxwsrv package.
-
Start the Xvfb X server.
When starting Xvfb, disable host-based access control restrictions by providing the -ac option on the command line. For example:
Xvfb :1 -ac
-
Set the value of the DISPLAY environment variable to the host where you want the display to show, and the display number. Export the DISPLAY variable. For example, in the sh shell, type:
export DISPLAY=localhost:1
Note:
This command assumes X server is running on display number 1 and on the same computer where WebLogic Server is running. If you have a different configuration, specify the IP address of the computer where the X server is running instead of localhost.
-
For convenience, you can place the Xvfb and DISPLAY setting commands in your user account configuration shell script or in the WebLogic Server startup script (startWebLogic.sh) so that they run when you start OSM.
-
If you are running on Solaris 5.10, add the following statement to the Java command line in the startWebLogic.sh file for your WebLogic server domain:
-Djava.awt.headless=true
If the above statement is missing from the Java command line, the following error may occur:
-X10: fatal IO error 22 (invalid argument) on X server "localhost:
In addition, performance and stability issues may occur when OSM accesses the server's display.
If you are running multiple instances of OSM on the same system, set up a dedicated Xvfb server for each instance.
To set up dedicated Xvfb servers for multiple instances of OSM:
-
Start one instance of the Xvfb server on display 1:
Xvfb :1
-
Set the value of the DISPLAY environment variable in the first WebLogic server domain instance to 1:
DISPLAY=localhost:1
-
Start the first WebLogic server domain instance.
-
Repeat steps 1 to 3 for each additional OSM instance running on the same system.
Note:
You must increment the Xvfb server display and the DISPLAY environment variable by one for each additional OSM instance. For example, the second instance would have a value of 2 for the Xvfb server display and the DISPLAY environment variable.
Connection, File Store, and Thread Configuration Post Installation Tasks
The following sections include post installation tasks for configuring connections, file stores, and threads.
Customizing OSM Run-Time Parameters
After installation, you may want to change OSM run-time parameters. For example, you can increase the number of rows in a worklist, or update the OSM administrator's e-mail address.
OSM run-time parameters are configured in the oms-config.xml file. You can access this file in the domain_home directory.
For details, see the chapter describing the oms-config.xml file in OSM System Administrator's Guide.
Preventing Connection Timeout Issues During Cartridge Deployment
When deploying large cartridges to an OSM system with many managed servers, you may receive cartridge deployment timeout errors. To resolve this error, increase the cartridge deployment timeout setting. The default cartridge deployment timeout setting is 600 seconds (10 minutes), but you can increase this value to a maximum of 3600 seconds (60 minutes).
To modify the default cartridge deployment timeout setting, change the value for the CartridgeDeploymentTransactionTimeout parameter in the domain_home/oms-config.xml file on each machine in the cluster. For example:
<oms-parameter> <oms-parameter-name>com.mslv.oms.cartridgemgmt.DeployCartridgeMDB.CartridgeDeploymentTransactionTimeout</oms-parameter-name> <oms-parameter-value>3600</oms-parameter-value> </oms-parameter>
For more information about changing this oms-config.xml parameter, see OSM System Administrator's Guide.
To override this default setting for a specific cartridge, you can specify this parameter as an OSM Cartridge Management Variables in Design Studio. You must use the full parameter name.
com.mslv.oms.cartridgemgmt.DeployCartridgeMDB.CartridgeDeploymentTransactionTimeout
For more information, see the Design Studio Help.
Note:
If an order has stopped processing due to a timeout, the order must be terminated. It will not resume processing even after the timeout value has been increased.
Configuring OSM JDBC Connections
The OSM installer creates JDBC connections that enable WebLogic communication to the Oracle RAC database instances.
The Statement Timeout value specifies the amount of times before the database terminates SQL statements that are taking too long to complete. This value is the WebLogic Server domain Java transaction API (JTA) timeout value plus 2 seconds giving the database enough time to react to a JTA timeout. The oracle.jdbc.ReadTimeout value stops the database from reading a socket after the Statement Timeout. These values should not be modified without making corresponding changes to each other. For more information about setting the JTA timeout value, see "Preventing Connection Timeout when Using a Remote Database."
The Statement Cache Size value determines the number of SQL statements that can remain in the statement cache. In a production environment, you can start this value at 30 and increasing the value only if you cannot improve parse ratios by tuning the cursors. For a development environment, the default setting of 10 is enough.
To configure the OSM JDBC Connections, do the following:
-
Log in to the WebLogic Server Administration Console.
The WebLogic Administration Console is displayed.
-
Click Lock & Edit.
-
In Domain Structure, select Services, then Data Sources.
The Summary of JDBC Data Sources screen is displayed.
-
Select an OSM JDBC data source. The OSM JDBC data source are as follows:
osm_pool_sid_group_y
where sid is the Oracle RAC database instance system identifier and y is the group letter.
The Configuration tab is displayed
-
Click the Connection Pools tab.
-
Click Advanced.
-
In the Properties field, add the following:
oracle.jdbc.ReadTimeout=value
where value is the Statement Timeout value converted to milliseconds plus 2000 milliseconds.
For example, if the Statement Timeout value is 602 seconds, then the oracle.jdbc.ReadTimeout should be 604000 milliseconds.
-
In the Statement Cache Size field, enter a value from 30 to 40 in a production environment.
-
Click Save.
-
Click Activate Changes.
Creating and Configuring Persistent File Stores
A persistent file store provides storage for WebLogic Server subsystems and services that require persistence. For example, a file store can store JMS messages. The OSM installer uses the default file store for each managed server and associated OSM JMS servers in the cluster.
Oracle recommends that you create a persistent file store for each managed server in the cluster and for the associated JMS server pairs of each managed server. If the managed servers are configured for whole server migration, ensure that the persistent stores are located in a shared directory.
To create and configure a persistent file store:
-
Create or ensure that a directory exists for the persistent file stores. The directory must exist on your system, so ensure that it is already created.
Note:
When a custom file store is targeted to a migratable target, the specified directory must be accessible from all candidate server members in the migratable target. For highest reliability, use a shared storage solution that is itself highly available, for example, a storage area network (SAN) or a dual-ported SCSI disk.
-
Log in to the WebLogic Server Administration Console.
The WebLogic Administration Console is displayed.
-
Click Lock & Edit.
-
In the Domain Structure tree, expand Services and select Persistent Stores.
The Summary of Persistent Stores page is displayed.
-
Click New and then click Create FileStore.
The Create a New File Store page is displayed.
Note:
After you create a file store you cannot rename it. You must delete it and create another one with a different name.
-
Enter the following:
-
Name: The name of the file store.
-
Target: The server instance or migratable target on which you want to deploy the file store.
Note:
In a clustered environment, it is recommended that you target a custom file store to the same migratable target as the migratable JMS server, so that a member server is not a single point of failure.
-
Directory: The path name to the directory on the file system where the file store is kept.
-
-
Click OK.
-
On the Summary of Persistent Stores page, select the file store that you just created.
-
Click the Configuration tab and update Advanced parameters, as required:
-
Logical Name: Optional name that can be used by subsystems that need a way to refer to different stores on different servers using the same name.
-
Synchronous Write Policy: Specifies how this file store writes data to disk.
-
-
Click Save.
-
In the left pane, expand Services and then Messaging, and then select JMS Servers.
The Summary of JMS Servers page is displayed.
-
In an OSM cluster, the OSM installer creates the following JMS servers in pairs:
oms_jms_server_managed_server osmJmsNonMigratableServer_managed_server
where managed_server is the managed server that the JMS server is associated with.
Note:
For a non-clustered managed server, the name of the JMS server is: oms_jms_server.
Select the one from the managed server pair that will use the custom file store.
-
On the settings page for the JMS server, click the Configuration tab, and then the General sub-tab.
-
In Persistent Store, select the custom file store that you want for the JMS server.
-
Click Save.
For more information about configuring general JMS server properties, see WebLogic Server Administration Console Help.
-
In the Change Center of the Administration Console, click Activate Changes.
Note:
Not all changes take effect immediately. For some changes you must restart WebLogic Server.
-
Repeat steps 11 to 16 for the other JMS server in the JMS server pair.
-
Repeat steps 3 to 16 for each managed server in the cluster.
Externalizing the Coherence Thread Configuration File
For better access and visibility to the osm-distributed and osm-invocation thread-count values, you can also put the osm-coherence-cache-config.xml in a location external to the oms.ear file where each WebLogic server can access it. In addition, doing this enables you to specify different osm-coherence-cache-config.xml files for each managed server with custom thread-count settings for each managed server if you require.
To externalize osm-coherence-cache-config.xml:
-
From the machine running the administration server, open a terminal.
-
Extract and modify the osm-coherence-cache-config.xml file from the oms.ear file as described in the previous procedure, but do not add the file back to security.gar.
-
Copy the file to domain_home/osm-coherence-cache-config.xml.
-
Extract the security.gar file from the oms.ear file using the following command.
jar xvf oms.ear security.gar
-
Extract the META-INF/coherence-application.xml directory and file using the following command.
jar xvf security.gar META-INF/coherence-application.xml
-
Open the coherence-application.xml file and replace the existing content with the following text:
<?xml version="1.0"?> <coherence-application xmlns="http://xmlns.oracle.com/coherence/coherence-application"> <cache-configuration-ref override-property="cache-config/OsmGar">META-INF/osm-coherence-cache-config.xml </cache-configuration-ref> </coherence-application>
-
Save coherence-application.xml and add it back to the security.gar file using the following command:
jar uvf security.gar META-INF/coherence-application.xml
- Update the oms.ear file with the updated security.gar file using the
following command:
jar uvf oms.ear security.gar
-
Log in to the WebLogic Server Administration Console.
-
In the Domain Structure tree, expand Environment, then click Servers.
The Summary of Servers screen is displayed.
-
Ensure that the managed servers in the OSM cluster are in the Running state.
-
In the Domain Structure tree click Deployments.
The Summary of Deployments screen is displayed.
-
Click Lock & Edit.
-
In the Name column, select the check box beside oms.
-
Click Update.
The Update Application Assistant screen appears.
-
In the Source path row, click Change Path.
-
In the Path field, enter the path to the modified oms.ear file.
-
From the Current Location area, select oms.ear.
-
Click Next.
-
Click Next.
-
Click Finish.
-
In the Domain Structure tree expand Environment, then click Coherence Clusters.
The Summary of Coherence Clusters screen is displayed.
-
From the Name column, select osmCoherenceClusternn (where n is a number that OSM installer generates when it creates the coherence cluster for OSM).
The Configuration tab is displayed.
-
Click the Cache Configurations sub tab.
-
Click New.
-
In the Name field, enter a name.
-
In the JNDI Name field, enter OsmGar.
-
In the Cache Configuration File field, enter domain_home/osm-coherence-cache-config.xml.
For example:
/u01/app/oracle/config/domains/wls1213_domain/osm-coherence-cache-config.xml
-
Click Next.
-
In the Clusters table, select Part of the cluster, and then select all the managed servers in the cluster.
-
Click Finish.
-
click Activate Changes.
-
In the Domain Structure tree, expand Environment, then click Servers.
The Summary of Servers screen is displayed.
-
Restart all managed servers in the cluster.
Copying Metric Rule Files
A set of XML files called ADML files contains the metric rules that allow the system to collect aggregated metric data about your system. OSM Order Metrics Manager allows the data that the system gathers to be displayed in any metric client. The OSM installation includes an interface called Oracle Dynamic Monitoring Service (DMS), which displays this metric data in a set of metrics tables.
In some configurations, the Middleware_home location for the administration server is separate from Middleware_home locations for OSM managed servers. In this case, you must remotely copy the domain-oracle_comms_osm-11.0.xml file from the ADML directory of an OSM managed server to the ADML directory of the administration server.
The metric rules files are automatically installed in the correct directory when you first start the OSM server. Metric rules files are installed in the ADML directory, as in the following example:
Middleware_home/oracle_common/modules/oracle.dms/adml
If this directory is not accessible to the OSM server, you must copy the files using the procedure in this section.
Note:
You might have to run the procedure in this section several times. If the administration server does not share the domain directory or the Middleware_home directory with a managed server, the system does not create the oms_dms directory and you must copy ADML files manually to the administration server's Middleware_home directory.
To copy metric rules files:
-
Start an OSM WebLogic managed server.
-
Go to the domain_home/osm_dms directory.
-
As a UNIX or Linux user with write permission to the ADML directory, run the following script:
copyAdmlFiles.sh
This script copies the ADML files domain-oracle_comms_osm-11.0.xml and server-oracle_comms_osm-11.0.xml to the Middleware_home/oracle_common/modules/oracle.dms/adml directory.
For a graphical representation of the metrics data, you can use the Oracle Communications Application Management Pack interface for Oracle Enterprise Manager Cloud Control 12c. For more information about installing and configuring Application Management Pack, see Oracle Application Management Pack for Oracle Communications System Administrator's Guide. For more information about Enterprise Manager, see Oracle Enterprise Manager Cloud Control Basic Installation Guide.
Note:
If you are using Internet Explorer 11 as the web browser to access Oracle Enterprise Manager Cloud Control 12.1.0.4, you must update Oracle Enterprise Manager Cloud Control 12.1.0.4 with the following patch:
Patch 20465665: MERGE REQUEST ON TOP OF 11.1.1.7.1 FOR BUGS 18680326 14739854 19933990
Download the patch from the Oracle support website at:
Instructions for applying the patch are provided in the patch Read me file.
For more information about accessing the DMS interface to view metrics tables, as well as using Application Management Pack to graphically view metrics data, see the topic about metrics data in OSM System Administrator's Guide.
Relocating ADML Files Without Restarting the Server
Whether the files are copied automatically by the OSM server or manually, DMS locates the new ADML files when you restart the WebLogic servers. You can also have DMS locate the ADML files immediately, without restarting the servers.
To have DMS locate new ADML files without restarting the servers:
-
If you are a UNIX or Linux user, run the following script:
Middleware_home/oracle_common/common/bin/wlst.sh
Note:
You cannot use the wlst.sh script in the WebLogic_home/common/bin directory because this script does not have the Oracle JRF extensions enabled.
-
At the command prompts, run the following command:
connect('user','password','t3://hostname:port')
where user is the user name of the WebLogic administrator, password is the password of the WebLogic administrator, hostname is the name of the administration server and port is the administration server port number. For more information about using WLST over a secure connection, see the security section of OSM System Administrator's Guide.
-
Load the metric rules files by running the following command:
reloadMetricRules()
The system loads the metric rules files in the ADML directory. This command shows the metric rules of all the managed servers and the administration server. If one of the OSM ADML files is missing from the reported files list for a server, ensure that the Middleware_home directory for that server has the ADML files correctly deployed.
-
Open the setDomainEnv.sh file from the domain_home/bin directory of the administration server.
-
Add the following string to the JAVA_OPTIONS property:
-Dweblogic.management.disableManagedServerNotifications=true
Registering Oracle HTTP Server Instance
To view metrics data using Application Management Pack, you must have Oracle HTTP Server configured and running in OSM. For more information, see Setting up an Oracle HTTP Server for OSM Cluster Load Balancing [Doc ID 1618630.1] knowledge article on the Oracle support website at:
You must also register the Oracle HTTP Server instance in OSM.
To register the Oracle HTTP Server instance:
-
Start an OSM WebLogic administration server.
-
Go to the bin directory of the Oracle HTTP Server instance, for example, OHS_Instance_HOME/bin.
-
Run the following command:
opmnctl registerinstance -adminHost hostname -adminPort port
where hostname is the name of the OSM WebLogic administration host machine and port is the port of the OSM WebLogic administration server.
The Oracle HTTP Server instance is registered in the OSM server.
Queue Configuration Post Installation Tasks
The following sections provide instructions for configuring OSM and solution queues after installing OSM.
Configuring Distributed Queues for an OSM Solution
In addition to the distributed queues that OSM creates during installation, you may need to create and configure your own custom distributed queues to support your particular OSM solution.
Use the following high-level steps to create and configure a distributed queue and its members:
-
Create the member queues, one per managed server pinned to each JMS server.
-
Create the distributed queue with equally-weighted member queues and target the distributed queue to the cluster.
-
Confirm that the distributed queue is accessible and visible to all managed servers in the cluster.
To create the member queues:
-
In the WebLogic Administration Console, expand Services, Messaging, and then select JMS Modules.
-
On the Summary of JMS Modules page, select oms_jms_module.
Note:
You must use the predefined JMS system module to allow the connection factory to deliver messages to the correct managed server. Do not create a new JMS system module.
-
On the Configuration page, above the Summary of Resources table, click New.
-
On the Create a New JMS System Module Resource page, select Queue and click Next.
-
On the JMS Destination Properties page, enter the name and JNDI name of the member queue, and then click Next.
-
Select the subdeployment you want to assign to the queue.
The number of subdeployments should equal the number of JMS servers, and hence managed servers configured in the cluster.
-
Upon selection of a subdeployment, the queue is automatically assigned to the correct JMS server.
-
Click Finish. The newly created member queue is displayed in the resources list.
-
Repeat steps 2-8 to create a queue for each managed server in the cluster.
For information about using JMS queues, see OSM System Administrator's Guide.
To create the distributed queue:
-
On the Configuration page, above the Summary of Resources table, click New.
-
On the Create a New JMS System Module Resource page, select Distributed Queue and click Next.
-
On the JMS Distributed Destination Properties page, do the following:
-
Enter the name and JNDI name of the distributed queue.
-
Ensure the Load Balancing Policy is set to Round-Robin.
-
Deselect Allocate Members Uniformly.
-
-
Click Next.
-
From the Members Available list, select the newly created queues and move them to the Chosen list.
-
Click Finish. The distributed queue is displayed in the resources list.
To confirm that the distributed queue is visible to each server in the cluster:
Configuring Separate Error Queues
Messages added to an error queue from an internal OSM queue are encoded, so you cannot determine which queue the error originated from. To assist in troubleshooting, you can create separate error queues with appropriate names for each of the internal OSM queues and target the OSM queues to these new error queues. For more information about creating queues, consult the Oracle WebLogic Server documentation.
OSM Integration with External Systems
The following sections describe OSM integration tasks between OSM, Oracle Communications ASAP, and Oracle Communications Unified Inventory Management (UIM). These integration tasks are also applicable for OSM integration with other remote applications.
Configuring Domain Trust
You should enable domain trust when SAF is configured, as it is needed for robust inter-domain communication using distributed destinations. Domain trust relies on the use of a shared password, which provides access to all domains that participate in the trust. Strict password management is critical.
If you use SAF without domain trust configured, you may experience unstable SAF behavior in your environment.
For details about enabling global trust, see "Enabling Global Trust" in Oracle Fusion Middleware Administering Security for Oracle WebLogic Server.
Integrating OSM and ASAP or IP Service Activator Using SAF Agent and JMS Bridging
To ensure reliable communication Oracle recommends that you create a Store-and-Forward (SAF) agent and JMS bridge between the Oracle Communications ASAP WebLogic server or Oracle Communications IP Service Activator WebLogic server and the OSM WebLogic server.
Figure 7-1 illustrates an example SAF and JMS bridge configuration between the web service interface on ASAP and a web service client on OSM. An example SAF and JMS bridge configuration between the web service interface on IP Service Activator and a web service client on OSM would appear the same.
Figure 7-1 SAF Agent and JMS Bridge Configuration Between OSM and ASAP
![Description of Figure 7-1 follows Description of Figure 7-1 follows](img/saf.gif)
Description of "Figure 7-1 SAF Agent and JMS Bridge Configuration Between OSM and ASAP"
In this example, an OSM SAF agent sends requests to the ASAP request queue, and ASAP returns responses through the ASAP SAF agent to the OSM reply-to queue. In addition, ASAP sends work order state changes from the JSRP XVTEventTopic through a JMS bridge with a SAF agent to the OSM event queue.
For detailed instructions for creating SAF and JMS bridges between ASAP and OSM, see Configuring WebLogic Resources for OSM Integration With ASAP And UIM On Different Domains (Doc ID 1431235.1) knowledge article on the Oracle support website at:
This article is also applicable to IP Service Activator or to any other remote application that uses a WebLogic JMS server to send and receive web service or JMS messages.
Note:
When using the above instructions with any remote application other than ASAP, remember to change any reference to ASAP to the remote application for which you are creating bridges. For example, change ASAP to IPSA.
Integrating OSM and UIM Using SAF Agent
Oracle recommends that you create a SAF agent between the UIM WebLogic server and the OSM WebLogic server. Oracle recommends this SAF agent for the web service interfaces to ensure reliable communication.
Figure 7-2 illustrates an example SAF configuration between the web service interface on UIM and a web service client on OSM.
Figure 7-2 SAF Agent Configuration Between OSM and UIM
![Description of Figure 7-2 follows Description of Figure 7-2 follows](img/saf_uim.gif)
Description of "Figure 7-2 SAF Agent Configuration Between OSM and UIM"
In this example, an OSM SAF agent sends requests to the UIM request queue, and UIM returns responses through the UIM SAF agent to the OSM reply-to queue.
For detailed instructions for creating SAF agents between UIM and OSM, see Configuring WebLogic Resources for OSM Integration With ASAP And UIM On Different Domains (Doc ID 1431235.1) knowledge article on the Oracle support website at:
This article is applicable to any remote application that uses a WebLogic JMS server to send and receive web service messages.
Deploying Custom Plug-Ins When Running on Managed Server
If OSM is running on a WebLogic managed server, the behaviorBuild.properties file must be configured to specify the URL of the administration server (for example, http://hostname:port).
From the system prompt, run the command ant deploy
.
In the WebLogic Administration Console, perform the following steps:
-
Undeploy the custom plug-in from the administration server.
-
Deploy the custom plug-in to the managed server.
-
Target the custom plug-in to the managed server.
Changing the WebLogic Server or Oracle RAC Database Size
The following sections describe how to change the number of managed servers in a cluster or the Oracle RAC database size.
Connecting Oracle RAC with JDBC Multi Data Source
During installation, the OSM installer prompts for the database parameters of the Oracle RAC instances and automatically creates the appropriate configuration in a JDBC multi data source. If you decide to manually configure your JDBC data source, you must understand the following discussion.
At the application layer, OSM maintains WebLogic Server order affinity. That is, all processing of an order is performed exclusively by one WebLogic Server instance, to minimize serialization. The OSM application cannot ensure all database operations for a particular order maintained by a WebLogic Server instance are directed to the same Oracle RAC instance. Thus, the approach to preserve Database Server order affinity is to have each WebLogic Server instance connect to only one Oracle RAC instance at any instant.
OSM uses a multi data source consisting of two data sources, each of which connects to an Oracle RAC database instance. Using the failover algorithm, the first data source is the primary data source and the other data source is the secondary data source. Under normal operation, only the primary data source is connected and used. When the primary data source fails, the multi data source chooses the next available data source as the primary data source.
The failover algorithm is used in both active-passive and active-active topologies. However, the configuration of the data source members within the multi data source is different:
-
In active-passive Oracle RAC, all instances in the WebLogic Server cluster are configured to the PREFERRED Oracle RAC database instance as the primary data source, and to the AVAILABLE Oracle RAC database instance as the secondary. Upon database failure, all WebLogic Server instances transition from the PREFERRED Oracle RAC database instance to the AVAILABLE Oracle RAC database instance.
Figure 7-3 illustrates this configuration.
Figure 7-3 Data Source Configuration for Oracle RAC Active-Passive
Description of "Figure 7-3 Data Source Configuration for Oracle RAC Active-Passive" -
In active-active Oracle RAC, WebLogic Server instances are partitioned. Half of the WebLogic Server instances are configured to one Oracle RAC database instance as the first data source and to the other Oracle RAC database instance as the second data source. The other half in the WebLogic Server cluster are configured with the sequence of the Oracle RAC database instances swapped. As a result, if one of the Oracle RAC database instances fails, half the WebLogic Server instances failover to the remaining Oracle RAC database instance, which is already handling the database operations of half of the WebLogic Server cluster.
Figure 7-4 illustrates this configuration.
Figure 7-4 Data Source Configuration for Oracle RAC Active-Active
Description of "Figure 7-4 Data Source Configuration for Oracle RAC Active-Active"In the active-active Oracle RAC configuration, the use of the failover algorithm (as opposed to a load-balancing algorithm) may appear counter-intuitive. However, keep in mind that load balancing in an active-active Oracle RAC configuration is not managed at the multi data source layer, but rather by partitioning the instances in the WebLogic Server cluster. There is no dynamic load balancing between WebLogic instances and database instances.
The relationship of a WebLogic instance and database instance in an active-active Oracle RAC configuration is many-to-one. That is, more than one WebLogic instance may choose the same database instance as its primary database instance, but a WebLogic instance cannot choose more than one database instance as its primary database instance. When you add a new database instance, you can either reassign an existing WebLogic instance to it, or create a new WebLogic instance.
WebLogic Server instances must be partitioned appropriately to load-balance with active-active Oracle RAC. The recommended approach is to have an even number of physical application servers with the same hardware dimensioning and weight. You should monitor the performance of your WebLogic and database instances to ensure they are not overloaded or under utilized. You can add more WebLogic instances to a database instance that is not fully utilized, or reassign a WebLogic instance to another database instance that is overloaded.
When a WebLogic Server cluster resizes, the ownership of an order is reassigned. The cache transfer of records from one database instance to another has a temporary impact on performance.
Adding Oracle RAC Instances
You can add a Oracle RAC instance to your environment in the following roles:
-
As an additional passive backup instance in an active-passive environment.
-
As a passive backup instance in an active-active environment. The new instance connects to the existing WebLogic partitions through new secondary data sources connected to the existing multi data sources.
Figure 7-5 shows an example of adding a third Oracle RAC instance as a backup in an active-active environment. The figure shows the new Oracle RAC instance and data sources in bold. Note that no WebLogic partition uses RAC3 as a primary instance.
Figure 7-5 Data Sources for a Third Backup Oracle RAC Instance in an Active-Active Environment
Description of "Figure 7-5 Data Sources for a Third Backup Oracle RAC Instance in an Active-Active Environment" -
As an active instance in an active-active environment. Choose this option for higher availability. The new instance connects to:
-
A new WebLogic group through a new primary data source configured in a new multi data source.
-
The existing WebLogic groups through new secondary data sources configured in existing multi data sources.
Figure 7-6 shows an example of adding a third Oracle RAC instance as an active member of an active-active environment. The figure shows the new elements in bold. Note that each Oracle RAC instance serves as a primary instance for a new WebLogic group.
Figure 7-6 Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment
Description of "Figure 7-6 Data Sources for a Third Active Oracle RAC Instance in an Active-Active Environment" -
See the following for more information:
-
For grouping and adding new managed servers, see the WebLogic Server documentation and "Adding a New Managed Server to a Clustered Environment."
-
For adding a new Oracle RAC instance and partitioning the OSM database schema, see the Oracle Database documentation and OSM System Administrator's Guide.
-
For adding new data sources and multi data sources, see "Manually Configuring Additional Data Sources for an Oracle RAC Instance."
Manually Configuring Additional Data Sources for an Oracle RAC Instance
OSM supports high availability in the database layer through configuration of Oracle Real Application Clusters (Oracle RAC) for either:
-
Failover, also known as warm standby or active-passive Oracle RAC.
-
Load balancing, or active-active Oracle RAC.
Each WebLogic Server instance in the OSM cluster interacts with Oracle RAC through a WebLogic multi data source configured for failover with multiple data sources, one for each Oracle RAC instance. This setup is used for both active-passive and active-active configurations. In an active-active configuration, load balancing is achieved by evenly distributing the clustered server nodes into groups in an alternating fashion.
During installation, the OSM installer automatically creates the appropriate data source configuration for the first Oracle RAC instance. You can let it automatically configure data sources for additional Oracle RAC instances, or you can choose to manually configure additional data sources after installation.
If you choose to manually configure additional data sources after installation, the Installer automatically creates the following:
-
Two data sources: osm_pool_rac1_group_a and osm_pool_rac1_group_b.
-
Two multi data sources: oms_pool_group_a and oms_pool_group_b
You must configure additional data sources as described in "Manually Creating and Configuring Data Sources." The number of additional data sources you configure depends on the number of Oracle RAC instances and your environment's configuration type.
For a second Oracle RAC instance:
-
In an active-passive configuration, create one new data source.
-
In an active-active configuration, create two new data sources.
For additional Oracle RAC instances beyond the second:
-
In an active-passive configuration, the new Oracle RAC instance is an additional backup instance. Create one new data source to connect the existing multi data sources to the new Oracle RAC instance.
-
In an active-active configuration, the new Oracle RAC instance can be one of the following:
-
A passive backup instance. Create new data sources connecting each existing multi data source to the new Oracle RAC instance. See Figure 7-6 for a detailed example.
-
An active instance. Create a new multi data source and 2n-1 new data sources, where n is the total number of Oracle RAC instances. Of the new data sources, n connect the new multi data source to the Oracle RAC instances, and n-1 connect the existing multi data sources to the new Oracle RAC instance.
For example, if you are adding a third Oracle RAC instance, you would create five new data sources: three to connect the new multi data source to each Oracle RAC instance, and two to connect the existing multi data sources to the new Oracle RAC instance.
See Figure 7-6 for a detailed example.
-
Manually Creating and Configuring Data Sources
To create and configure additional data sources for an Oracle RAC instance:
-
Log in to the WebLogic Administration Server Console.
-
In the Domain Structure tree, expand Services, JDBC, then select Data Sources.
-
On the Summary of JDBC Data Sources page, click New.
-
On the JDBC Data Sources Properties page, do the following:
-
Enter a name for the JDBC data source.
-
If you have an active-passive configuration, name the data source osm_pool_n where n is the number of the new Oracle RAC instance.
For example, if you are adding a third Oracle RAC instance, name the new data source osm_pool_3.
-
If you have an active-active configuration, name the data source osm_pool_racn_group_x, where n and x represent the Oracle RAC instance and WebLogic group that the data source connects.
For example, if you are adding a third Oracle RAC instance, one of the new data sources will be called osm_pool_rac3_group_c. It connects to the third Oracle RAC instance and the WebLogic group called group_c.
-
-
Enter a unique JNDI name for the data source in either configuration. For example, oracle/communications/osm/internal/jdbc/pool_3.
-
Select Oracle as the database type.
-
Click Next.
-
-
Select one of the following non-XA thin drivers and click Next:
-
If your Oracle RAC database is configured with a remote listener (the default), select *Oracle's Driver (Thin) for RAC Service-Instance connections; Versions: 10 and later.
-
If your Oracle RAC database is configured with local listeners, select *Oracle's Driver (Thin) for Instance connections; Versions: 9.0.1 and later.
-
-
On the Transaction Options page, do the following:
-
Ensure the default option Supports Global Transactions is selected.
-
Select the Logging Last Resource option.
-
Click Next.
-
-
On the Connection Properties page, specify the service name, database name, host, and port of the additional Oracle RAC instance based on one of the following scenarios:
-
If your Oracle RAC database is configured with a remote listener and server-side load balancing (the default):
-
Specify the same the host, port, and service name as those specified for the existing data sources.
-
Specify the unique instance name of the new Oracle RAC instance. The instance name is required in order to override server-side load balancing. See "Listener Considerations for Oracle RAC" for a full discussion of listener functionality.
For example, if an existing data source URL is:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl)(INSTANCE_NAME=orcl1)))
The new data source URL will specify the same host, port, and service name, and a unique instance name, as follows:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=orcl)(INSTANCE_NAME=orcl2)))
-
-
If your Oracle RAC database is configured with local listeners only:
-
Specify either a different host or port than the host or the port of the existing data sources.
-
Specify either the same service name or a unique instance name, depending on which the existing data sources specify. If the existing data sources specify both, the new data source must as well.
For example, if the existing data source URL is:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host1.oracle.com)(PORT=1521)))(CONNECT_DATA=(INSTANCE_NAME=orcl1)))
The new data source URL will specify a different host, and only specify the instance name, as follows:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=host2.oracle.com)(PORT=1521)))(CONNECT_DATA=(INSTANCE_NAME=orcl2)))
-
-
Enter the OSM database schema user name and password, and then confirm the password.
-
Click Next.
-
-
On the Test Database Connection page, do one of the following:
-
Review the connection parameters and click Test Configuration.
WebLogic attempts to create a connection from the administration server to the database. Results are displayed at the top of the page. If the test is unsuccessful, you should correct any configuration errors and retry the test.
Click Next.
-
If the JDBC driver you selected is not installed on the administration server, click Next to skip this step.
-
-
On the Select Targets page, do one of the following:
-
If you have an active-passive configuration, target the new data source to the entire cluster.
-
If you have an active-active configuration, target the data source to one group in the cluster.
For example, in Figure 7-6, the new data sources ending in group_a are targeted to the group_a servers, the new data sources ending in group_b are targeted to the group_b servers, and the new data sources ending in group_c are targeted to the group_c servers.
-
-
Click Finish.
Your configuration is saved and the data source is deployed to the cluster.
-
Configure the connection properties for the new data source. See "Configuring Connection Pool Properties."
-
Repeat the previous steps for each required new data source.
-
Add the new data sources to multi data sources. See "Adding Data Sources to Multi Data Sources."
Configuring Connection Pool Properties
In addition to the properties you defined in the previous section, you must configure the data source's connection pool properties.
To configure the connection pool properties, do the following:
-
Select the data source and navigate to the Connection Pool tab.
-
In the Properties list, enter oracle.net.CONNECT_TIMEOUT=10000.
-
In the Initial Capacity field, enter 0.
-
Click Advanced options.
-
Select the Test Connections on Reserve check box.
-
In the Test Frequency field, enter 300.
-
In the Test Table Name field, enter SQL SELECT 1 FROM DUAL.
-
In the Seconds to Trust an Idle Pool Connection, enter 10.
-
In the Shrink Frequency field, enter 900.
-
Save your changes.
Adding Data Sources to Multi Data Sources
You can make all data source and multi data source changes in a single edit session. You do not have to activate your changes between steps.
For any number of new Oracle RAC instances, add the new data sources to the existing multi data sources as described in "Adding Data Sources to an Existing Multi Data Source." For Oracle RAC instances beyond the second instance, you must also create a new multi data source, and add some of the new data sources to it, as described in "Creating a New Multi Data Source."
Note:
Oracle recommends that you shut down all managed servers before changing the order of the data sources as described in the procedure below because the order affects the name of the Oracle Coherence cluster when OSM starts.
Adding Data Sources to an Existing Multi Data Source
To add new data sources to an existing multi data source:
-
In the Domain Structure tree, expand Services, then select Data Sources.
-
On the Summary of Data Sources page, click a multi data source name.
-
Click the Configuration Data Sources tab, and do one of the following:
-
For an active-passive configuration, move the data source that you want to include in the multi data source to the Chosen list.
-
For an active-active configuration, add the data sources to the multi data sources in an rotating order so that no data source appears in the same rank twice.
For example, if you have three multi data sources, the data sources must appear in the order shown in Table 7-1.
Table 7-1 Example Data Source Order
Multi Data Source Data Source List oms_pool_group_a
-
osm_pool_rac1_group_a
-
osm_pool_rac3_group_a
-
osm_pool_rac2_group_a
oms_pool_group_b
-
osm_pool_rac2_group_b
-
osm_pool_rac1_group_b
-
osm_pool_rac3_group_b
oms_pool_group_c
-
osm_pool_rac3_group_c
-
osm_pool_rac2_group_c
-
osm_pool_rac1_group_c
See "Adding Oracle RAC Instances" for an illustration of how these data sources and multi data sources connect to Oracle RAC instances and WebLogic partitions.
-
-
-
Save your changes.
-
Repeat the previous steps for each multi data source.
Creating a New Multi Data Source
To create a new multi data source and add the new data sources to it:
-
In the Domain Structure tree, expand Services, then select Data Sources.
-
On the Summary of Data Sources page, click New and select Multi Data Source.
-
On the Configure the Multi Data Source page, enter the following information:
-
Name: Enter oms_pool_group_x where x is the next letter in a sequence.
For example, if your existing multi data sources are oms_pool_group_a and oms_pool_group_b, name the new multi data source oms_pool_group_c.
-
JNDI Name: Enter the JNDI path to where this JDBC data source will be bound.
-
Algorithm Type: Select Failover.
-
-
On the Select Targets page, do one of the following:
-
If you have an active-passive configuration, target the new multi data source to the entire WebLogic cluster.
-
If you have an active-active configuration, target the multi data source to the same group in the WebLogic cluster that you targeted most of your new data sources to (typically a newly-added WebLogic server group).
For example, in Figure 7-6, the new multi data source oms_pool_group_c is targeted to the same WebLogic server group as the new data sources rac3_group_c, rac1_group_c, and rac2_group_c.
-
-
On the Select Data Source Type page, select the Non-XA Driver option.
-
On the Add Data Sources page, add the data sources in an order that alternates with that of the existing multi data sources. See Table 7-1 for an example with three multi data sources.
-
Click Finish.
Adding a New Managed Server to a Clustered Environment
To add a new managed server to a clustered environment:
-
Ensure that the managed servers and the cluster are created. For information on how to add managed servers, see Oracle Fusion Middleware documentation.
-
Ensure that the managed servers have been assigned to the cluster, and that OSM is installed on the cluster.
-
Create a new managed server and do the following:
-
If a proxy is used in the cluster configuration, add the new managed server's IP address and port number to the proxy server's configuration. For example, if you use a WebLogic HTTP proxy, update the WebLogicCluster parameter in the domain_home/apps/OracleProxy4_proxyserver_proxy/WEB-INF/web.xml file (where proxyserver is the proxy server name) and redeploy the proxy for the change to take effect.
-
If the cluster address of the cluster is set, update it with the new managed server's IP address and port number.
-
- If any cartridge queues are present, create them manually using steps provided in the Queue Configuration Post Installation Tasks section for the to-be added managed server.
- If an Order-to-Activate cartridge is already deployed, run
ant task config_All
. - Run the installer scripts to update the environment with all the resources for the
to-be added managed server and deploy the OSM apps. All the OSM default resources
like JMS server, queues, persistent store and so on, will be created by the
installer for the new managed server.
Run discovery.sh to capture the updated properties related to Oracle Real Application Cluster (Oracle RAC), JMS store and so on. For more information about the properties, refer to Specifying Configuration Properties in the Configuration Phase.
$ export PASSPHRASE=passphrase $ export OSM_INSTALLER_HOME=</path/to/installerHome> $ $OSM_INSTALLER_HOME/scripts/discover.sh -n osm_env_name -c $OSM_CFG_HOME
Run configDB.sh, if there is a change in the Oracle RAC configuration.$ export PASSPHRASE=passphrase #It should be same as used in discover.sh $ export OSM_INSTALLER_HOME=</path/to/installerHome> $ $OSM_INSTALLER_HOME/scripts/configDB.sh -n osm_env_name -c $OSM_CFG_HOME
Run configDomain.sh, to update the domain with all the resources for the to-be added managed server and deploy the OSM apps.$ export PASSPHRASE=passphrase #It should be same as used in discover.sh $ export OSM_INSTALLER_HOME=</path/to/installerHome> $ export FMW_HOME=</path/to/fmw_home> $ $OSM_INSTALLER_HOME/scripts/configDomain.sh -n osm_env_name -c $OSM_CFG_HOME
- Start the proxy and all managed servers.
Removing a Managed Server from a Clustered Environment
When you remove a managed server from a clustered environment, you must first delete the related queues, then remove the managed server using the WebLogic Administration Console. See "Preparing to Remove a Managed Server from a Clustered Environment" and "Removing a Managed Server from a WebLogic Cluster" for more information.
Preparing to Remove a Managed Server from a Clustered Environment
For each queue created for the cartridges on OSM, remove its destination on the to-be-deleted managed server and then delete the queues.
Removing a Managed Server from a WebLogic Cluster
To remove an OSM managed server from a WebLogic cluster:
-
Shut down the Oracle database server or servers used by your OSM instance.
-
Log in to the WebLogic Administration Console.
The WebLogic Administration Console is displayed.
-
Click Environment.
-
Click Servers.
The Summary of Servers screen is displayed.
-
Click Control.
-
Select all managed servers. Do not select the administration server (followed by "(admin)" in the list).
Note:
Note which OSM managed server you want to remove.
-
Click Shutdown.
-
Select Force Shutdown Now.
The State changes from RUNNING to SHUTDOWN.
-
Click Services.
-
Click JMS Modules.
The JMS Modules screen is displayed.
-
Click oms_jms_module.
The Settings for oms_jms_module screen is displayed.
-
For every OSM or Order-to-Activate distributed queue, do the following:
-
Click the distributed_queue, where distributed_queue is the name of the OSM distributed queue.
The Settings for distributed_queue screen is displayed.
-
Click Members.
The Distributed Queue Members screen is displayed.
-
Select the queue_managed_server, where queue is the OSM or Order-to-Activate queue and managed_server is the managed server you want to remove.
-
Click Delete.
-
-
Delete every queue_managed_server or topic_managed_server, where queue and topic are the names of the OSM queues and topics and managed_server is the managed server you want to remove.
-
If the managed server you are removing is configured with JMS service migration, remove the osmJmsNonMigratableTemplate_managed_server template associated to the managed server you want to delete.
-
Click Subdeployments.
The Subdeployments screen is displayed.
-
Select the oms_jms_server_ManagedServer you want to delete.
If the managed server you are removing is configured with JMS service migration, also select the osmJmsNonMigratableServer_managed_server subdeployment associated to the managed server you want to delete.
Note:
You cannot delete a managed server subdeployment until there are no resources associated with it. If any resources still appear, either delete the resource if it is a queue, or remove the managed server from the member list if it is a distributed queue.
-
Click Delete.
-
Click Services.
-
Click JMS Servers.
The Summary of JMS Servers screen is displayed.
-
Select the oms_jms_server_ManagedServer you want to delete.
If the managed server you are removing is configured with JMS service migration, also select the osmJmsNonMigratableServer_managed_server JMS server associated to the managed server you want to delete.
-
Click Delete.
-
Click Environment.
-
Click Servers.
The Summary of Servers screen is displayed.
-
Select the managed server you want to delete.
-
Click Delete.
-
Click Environment.
-
Click Clusters.
The Summary of Clusters screen is displayed.
-
Click the name of the cluster that the managed server you deleted was associated with.
-
In the Clusters Address field, remove the IP address and port number for the managed server you deleted.
-
In the Number of Servers In Cluster Address field, reduce the number by one.
-
Click Save.
-
If a proxy is used in the cluster configuration, delete the managed server's IP address and port number from the proxy server's configuration. For example, if you use a WebLogic HTTP proxy, update the WebLogicCluster parameter in the domain_home/apps/OracleProxy4_proxyserver_proxy/WEB-INF/web.xml file (where proxyserver is the proxy server name) and redeploy the proxy.
-
Save and close the file.