Oracle® Fusion Applications Customer Relationship Management Enterprise Deployment Guide 11g Release 1 (11.1.3) Part Number E16684-09 |
|
|
PDF · Mobi · ePub |
This chapter describes the additional scaleout steps required for the soa_server1
and soa_server2
server on CRMHOST1
and CRMHOST2
.
Note:
The Oracle SOA Suite server uses the Java Message Service (JMS) server. JMS requires a shared file system for its file store and transactional log. Each Oracle SOA Suite Managed Server in a cluster uses a separate local file system on the shared disk. During a node failure, the Oracle SOA Suite server must be moved to a targeted node in order to run the same server using the exact JMS file store and transaction log. To enable this server migration, each Oracle SOA Suite server must be configured with its own virtual IP, which can be floated on any server where the Oracle SOA Suite server is migrated.
The procedures in this chapter use the Oracle SOA Suite server in the Oracle Fusion Customer Relationship Management domain as an example. You must perform the same procedures for the Oracle SOA Suite servers in all other domains.
Note:
For Oracle Fusion Customer Relationship Management, the Oracle SOA Suite virtual IPs for CRMHOST1
and CRMHOST2
are called CRMSOAVH1
and CRMSOAVH2
. For all other domains, replace the first three characters with domain-specific syntax. For HCMSOAVH1
, SCMSOAVH1
, ICSOAVH1,
and so on.
This chapter includes the following topics:
Section 15.1, "Enabling Virtual IPs on CRMHOST1 and CRMHOST2"
Section 15.4, "Updating the FusionVirtualHost_crm.conf Configuration File"
Section 15.5, "Configuring JMS for the Oracle SOA Suite Server"
Section 15.6, "Configuring Oracle Coherence for Deploying Composites"
Section 15.7, "Configuring a Default Persistence Store for Transaction Recovery"
Section 15.8, "Disabling Host Name Verification for the soa_servern Managed Servers"
Section 15.10, "Starting and Validating soa_server1 on CRMHOST1"
Section 15.12, "Starting and Validating soa_server2 on CRMHOST2"
Note:
Before performing any of the procedures in this chapter, ensure that soa_server1
is running on CRMHOST1
and soa_server2
is running on CRMHOST2
.
To enable the virtual IP on Linux:
Note:
In this example, ethX
is the ethernet interface (eth0
or eth1
) and Y
is the index (0, 1, 2, and so on). In addition, the CRMSOAVH1
and CRMSOAVH2
VIPs will be used.
On CRMHOST1
:
Run the ifconfig
command as root:
/sbin/ifconfig interface:index IPAddress netmask netmask
For example:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Enable your network to register the new location of the virtual IP:
/sbin/arping -q -U -c 3 -I interface IPAddress
For example:
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
Validate that the address is available by pinging it from another node.
For example:
/bin/ping 100.200.140.206
Ensure that you have performed the steps described in Section 15.1, and the scale-out steps described in Section 8.3, Section 8.4, and Section 8.5 before setting the soa_server1
listen address.
To set the listen address for the Managed Server:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select soa_server1 in the table. The Setting page for soa_server1
is displayed.
Set the Listen Address to CRMSOAVH1
.
Click Save.
Click Activate Changes.
The changes will not take effect until the soa_server1
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select soa_server1 in the table and then click Shutdown.
After the server has shut down, select soa_server1 in the table and then click Start.
Ensure that you have performed the steps described in Section 15.1 before setting the soa_server2
listen address.
Perform these steps to set the listen address for the Managed Server:
Log in to the Administration Console.
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select soa_server2 in the column of the table. The Settings page for soa_server2
is displayed.
Set the Listen Address to CRMSOAVH2
.
Click Save.
Click Activate Changes.
The changes will not take effect until the soa_server2
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select soa_server2 in the table and then click Shutdown.
After the server has shut down, select soa_server2 in the table and then click Start.
To enable Oracle HTTP Server to route to soa_cluster
, which contains the soa_server
n
Managed Servers, you must set the WebLogicCluster parameter to the list of nodes in the cluster.
To set the parameter:
On WEBHOST1
and WEBHOST2
, update the WebLogicCluster parameter in the ORACLE_BASE
/config/CommonDomain_webtier/config/OHS/ohs1/moduleconf/FusionVirtualHost_crm.conf
file to contain a cluster list of virtual host
:port
entries. For example:
<Location /soa-infra> SetHandler weblogic-handler WebLogicCluster CRMSOAVH1:9024,CRMSOAVH2:9024 </Location>
Restart Oracle HTTP Server on both WEBHOST1
and WEBHOST2
:
WEBHOST1> ORACLE_BASE/config/CommonDomain_webtier/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/config/CommonDomain_webtier/bin/opmnctl restartproc ias-component=ohs1
The servers specified in the WebLogicCluster parameters are only important at startup time for the plug-in. The list must provide at least one running cluster member for the plug-in to discover other members in the cluster. The listed cluster member must be running when Oracle HTTP Server is started. Oracle WebLogic Server and the plug-in work together to update the server list automatically with new, failed, and recovered cluster members.
Sample scenarios include the following:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered dynamically at runtime.
Example 2: You have a three-node cluster, but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all the members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started. For more information on configuring the Oracle WebLogic Server plug-in, see Oracle Fusion Middleware Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server.
After CRMHOST1
has been provisioned, the JMS server and file store are set up and configured for CRMHOST1
. You now must configure the file store for CRMHOST2
. Configure the location for all persistence stores to a directory visible from both nodes.
To configure the file store for CRMHOST2
:
Log in to the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Services node and then click the Persistence Stores node.
The Summary of Persistence Stores page appears.
Click Lock & Edit.
Click New, and then Create File Store.
In the Directory field, enter the following:
Name: for example, SOAJMSFileStore_auto_2
Target: soa_server2
Directory:
ORACLE_BASE/config/domains/CRMHOST1/CRMDomain
Click OK and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Servers node.
The Summary of JMS Servers page appears.
Click Lock & Edit.
Click New.
Enter a name (for example, SOAJMSServer_2
), then select SOAJMSFileStore_auto_2 in the Persistence Store dropdown list.
Click Next.
Select soa_server2 as the target.
Click Finish and Activate Changes.
In the Domain Structure window, expand the Services node and then click the Messaging > JMS Modules node.
The JMS Modules page appears.
In the Change Center, click Lock & Edit.
Click SOAJMSModule and then click the Subdeployments tab.
Click SOAJMSServerxxxxx under Subdeployments.
Add the new SOAJMSServer_2
as additional targets for the subdeployment.
Click Save and Activate Changes.
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in SOA enterprise deployments. Use unicast if you disable multicast communication for security reasons.
Note:
An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the SOA system from starting. The deployment framework must be properly customized for the network environment on which the SOA system runs. Oracle recommends the configuration described in this section.
Multicast communication enables Oracle Fusion Middleware SOA to discover all of the members of a cluster to which it deploys composites dynamically. However, unicast communication does not enable nodes to discover other cluster members in this way. Consequently, you must specify the nodes that belong to the cluster. You do not need to specify all of the nodes of a cluster, however. You need only specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. As a result, when a new node has joined the cluster, it is able to discover all of the other nodes in the cluster. Additionally, in configurations such as SOA enterprise deployments, where multiple IPs are available in the same box, you must configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Tip:
To guarantee high availability during deployments of SOA composites, specify enough nodes so that at least one of them is running at any given time.
Specify the nodes using the tangosol.coherence.wka
n
system property, where n
is the number for each Oracle HTTP Server. The numbering starts at 1. This numbering must be sequential and must not contain gaps. In addition, specify the host name used by Oracle Coherence to create a cluster through the tangosol.coherence.localhost
system property. This local host name should be the virtual host name used by the SOA server as the listener addresses (CRMSOAVH1
and CRMSOAVH2
). Set this property by adding the -Dtangosol.coherence.localhost
parameters to the Arguments field of the Oracle WebLogic Server Administration Console's Server Start tab.
Note:
CRMSOAVH1
is the virtual host name that maps to the virtual IP where soa_server1
is listening (in CRMHOST1
). CRMSOAVH2
is the virtual host name that maps to the virtual IP where soa_server2
is listening (in CRMHOST2
).
To add the host name used by Oracle Coherence:
Log in to the Oracle WebLogic Server Administration Console.
In the Domain Structure window, expand the Environment node.
Click Servers.
The Summary of Servers page appears.
Select soa_server1 (represented as a hyperlink) from the column of the table.
The Settings page appears.
Click Lock & Edit.
Click the Server Start tab.
Enter the following for soa_server1
and soa_server2
into the Arguments field.
For soa_server1
, enter the following:
-Dtangosol.coherence.wka1=CRMSOAVH1 -Dtangosol.coherence.wka2=CRMSOAVH2 -Dtangosol.coherence.localhost=CRMSOAVH1 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
For soa_server2
, enter the following:
-Dtangosol.coherence.wka1=CRMSOAVH2 -Dtangosol.coherence.wka2=CRMSOAVH1 -Dtangosol.coherence.localhost=CRMSOAVH2 -Dtangosol.coherence.localport=8089 -Dtangosol.coherence.wka1.port=8089 -Dtangosol.coherence.wka2.port=8089
Note:
There should be no breaks in lines between the different -D
parameters. Do not copy or paste the code from above to your Administration Console's Arguments text field. This may result in HTML tags being inserted in the Java arguments. The code should not contain other characters than those included in the example above.
Click Save and Activate Changes.
Note:
You must ensure that these variables are passed to the Managed Server correctly. (They should be reflected in the server's output log.) Failure of the Oracle Coherence framework can prevent the soa-infra application from starting.
Note:
The multicast and unicast addresses are different from the ones used by the Oracle WebLogic Server cluster for cluster communication. Oracle SOA Suite guarantees that composites are deployed to members of a single Oracle WebLogic Server cluster even though the communication protocol for the two entities (the Oracle WebLogic Server cluster and the groups to which composites are deployed) are different.
Note:
The Oracle Coherence cluster used for deployment uses port 8088 by default. This port can be changed by specifying the -Dtangosol.coherence.wkaX.port
startup parameter.
Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. The WebLogic Server uses this transaction log for recovery from system crashes or network failures. To leverage the migration capability of the Transaction Recovery Service for the servers within a cluster, store the transaction log in a location accessible to a server and its backup servers.
Note:
Preferably, this location should be a dual-ported SCSI disk or on a Storage Area Network (SAN).
To set the location for the default persistence store:
Log in to the Oracle WebLogic Server Administration Console (http://crminternal.mycompany.com:7777/console
).
In the Change Center, click Lock & Edit.
In the Domain Structure window, expand the Environment node and then click the Servers node. The Summary of Servers page is displayed.
Click the server name soa_server1 (represented as a hyperlink) in the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.
Click the Configuration tab and then the Services tab.
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 for CRMHOST1
is the following:
CRMHOST1> ORACLE_BASE/config/domains/CRMHOST1/CRMDomain/tlogs
Click Save and Activate Changes.
Restart the Managed Servers to activate the changes (ensure that Node Manager is up and running):
Log in to the Oracle WebLogic Server Administration Console (http://crminternal.mycompany.com:7777/console
).
In the Summary of Servers screen, select the Control tab.
Select soa_server1 and soa_server2 in the table and then click Shutdown.
Start the soa_server1
and soa_server2
servers.
Note:
To enable migration of the Transaction Recovery service, specify a location on a persistent storage solution that is available to other servers in the cluster. Both soa_server1
and soa_server2
must be able to access this directory.
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server. By default, Host Name Verification should be set to None. If it is not, follow the steps below.
If you have not configured the server certificates, you will receive errors when managing the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the enterprise deployment topology configuration is complete.
To disable Host Name Verification:
Log in to Oracle WebLogic Server Administration Console. For example, http://crminternal.mycompany.com:7777/console
.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page appears.
Select soa_server1 (represented as a hyperlink) in the table.
The Settings page appears.
Select the SSL tab.
Expand the Advanced section of the page.
Set Hostname Verification to None.
Click Save.
Repeat Steps 1 through 9 for the soa_server2
Managed Server.
Save and activate the changes.
To restart Node Manager on CRMHOST1
:
Stop Node Manager by stopping the process associated with it:
If it is running in the foreground in a shell, simply use CTRL+C.
If it is running in the background in the shell, find the associated process and use the kill
command to stop it. For example:
CRMHOST1> ps -ef | grep NodeManager
orcl 9139 9120 0 Mar03 pts/6 00:00:00/bin/sh ./startNodeManager.sh
Run the following command:
CRMHOST1>kill -9 9139
Start Node Manager:
CRMHOST1> ORACLE_BASE/products/fusionapps/wlserver_10.3/common/nodemanager/ CRMHOST1/startNodeManagerWrapper.sh
To start the soa_server1
Managed Server on CRMHOST1
:
Access the Administration Console. For example, http://crminternal.mycompany.com:7777/console
.
Click Servers.
Open the Control tab.
Select soa_server1.
Click Start.
To validate the soa_server1
Managed Server on CRMHOST1
:
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started." If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.
Access http://
CRMSOAVH1
:9024/soa-infra
and http://
crminternal
.mycompany.com:7777/soa-infra
to verify status of soa_server1
.
Note:
Although the soa_server1
server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the above URLs and watching for errors pertaining each individual application in the server's output file.
To restart Node Manager on CRMHOST2
, follow the steps in Section 15.9, "Restarting Node Manager on CRMHOST1."
To start the soa_server2
Managed Server on CRMHOST2
and ensure that it is configured correctly:
From the Administration Console, start the soa_server2
Managed Server.
Verify that the server status is reported as "Running" in the Administration Console. If the server is shown as "Starting" or "Resuming," wait for the server status to change to "Started." If another status is reported (such as "Admin" or "Failed"), check the server output log files for errors.
Access http://
CRMSOAVH2
:9024/soa-infra
and http://
crminternal
.mycompany.com:7777/soa-infra
.
Note:
Although soa_server2
server may be up, some applications may be in a failed state. Therefore, Oracle recommends verifying the above URLs and watching for errors pertaining each individual application in the server's output file.