| Oracle® Fusion Applications Enterprise Deployment Guide 11g Release 1 (11.1.2) Part Number E16684-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Enterprise Deployment Guide 11g Release 1 (11.1.2) Part Number E16684-04 |
|
|
PDF · Mobi · ePub |
This chapter describes the additional scaleout steps required for the soa_server2 server on 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 14.1, "Enabling Virtual IPs on CRMHOST1 and CRMHOST2"
Section 14.4, "Updating the FusionVirtualHost_crm.conf Configuration File"
Section 14.5, "Configuring JMS for the Oracle SOA Suite Server"
Section 14.6, "Configuring Oracle Coherence for Deploying Composites"
Section 14.7, "Configuring a Default Persistence Store for Transaction Recovery"
Section 14.8, "Disabling Host Name Verification for the soa_servern Managed Servers"
Section 14.10, "Starting and Validating soa_server1 on CRMHOST1"
Section 14.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 14.1, and the scale-out steps described in Section 7.3, Section 7.4, and Section 7.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 14.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_servern 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:
<LocationMatch /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.
Enter a name (for example, SOAJMSFileStore_auto_2), and a target, soa_server2:
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.
Select SOAJMSServer 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 name of the server (represented as a hyperlink) in the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.
Open 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.
Restart 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 14.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.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|