This section contains the following topics:
After successfully completing the conditional common post-installation tasks review and perform the following conditional common high availability tasks.
Some components in the Oracle Fusion Applications environment are dependent on one another. Therefore, it is important to start and stop components in the proper order. In the course of normal IT operations, common operations include shutting down computers and starting them back up. Therefore, it is crucial to start and stop Oracle Fusion Applications in a sequential manner. See Start and Stop an Oracle Fusion Applications Environment in the Oracle Fusion Applications Administrator's Guide.
The Oracle Fusion Applications topology is highly scalable, and can be scaled up or out. When scaling up the topology, add a new Managed Server to provisioning hosts that are already running one or more Managed Servers. When scaling out the topology, add one or more instances of Managed Servers to new hosts.
The first Oracle HTTP Server (WEBHOST1
) was configured during the provisioning process. This section describes how to scale out Oracle HTTP Server to additional hosts.
Before scaling out Oracle HTTP Server to additional hosts, ensure the following is done:
If any directory under REPOSITORY_LOCATION
/installers/webtier/prepatch
and/or REPOSITORY_LOCATION
/installers/webtier/patch
exists, perform the steps in this section. If no directory exists, perform only Steps 1 and 3 on both WEBHOST1
and WEBHOST2
(skip Step 2).
To install Web Tier patches, do the following:
Set or change the environment variable $
ORACLE_HOME
to APPLICATIONS_BASE
/webtier_mwhome/webtier/
, as shown in the following examples:
UNIX:
export ORACLE_HOME=APPLICATIONS_BASE/webtier_mwhome/webtier
To install the patches:
If a subfolder exists in the prepatch
folder of the Web Tier installer, change directory to the prepatch
folder and run the following command:
ORACLE_HOME/OPatch/opatch napply
Change directory to the patch
folder and run the command again.
Make sure the same patches are installed on both WEBHOST1
and WEBHOST2
by running the following command on both WEBHOST1
and WEBHOST2
, comparing the output to ensure the patches are the same:
APPLICATIONS_BASE/webtier_mwhome/webtier/OPatch/opatch lsinventory
If any directory under REPOSITORY_LOCATION
/installers/webgate/prepatch
and/or REPOSITORY_LOCATION
/installers/webgate/patch
exists, perform the steps in this section. If no directory exists, perform only Steps 1 and 3 on both WEBHOST1
and WEBHOST2
(skip Step 2).
To install WebGate patches, do the following:
Set or change the environment variable $
ORACLE_HOME
to APPLICATIONS_BASE
/webtier_mwhome/webgate/
, as shown in the following examples:
UNIX:
export ORACLE_HOME=APPLICATIONS_BASE/webtier_mwhome/webgate
To install the patches:
If a subfolder exists in the prepatch
folder of the WebGate installer, change directory to the prepatch
folder and run the following command:
ORACLE_HOME/OPatch/opatch napply
Change directory to the patch
folder and run the command again.
Make sure the same patches are installed on both WEBHOST1
and WEBHOST2
by running the following command on both hosts:
APPLICATIONS_BASE/webtier_mwhome/webgate/OPatch/opatch lsinventory
After installing WebGate, do the following:
(UNIX) Append environment variable LD_LIBRARY_PATH
with the Web Tier library path APPLICATIONS_BASE
/webtier_mwhome/webtier/lib
.
UNIX:
WEBHOST2> export LD_LIBRARY_PATH=APPLICATIONS_BASE/webtier_mwhome/ webtier/lib:$LD_LIBRARY_PATH
Run the commands that follow.
UNIX:
# Usage: deployWebGateInstance.sh -w <WebGate_instancedir> -oh WebGate_Oracle_Home $ cd APPLICATIONS_BASE/webtier_mwhome/webgate/webgate/ohs/tools/ deployWebGate $ ./deployWebGateInstance.sh -w APPLICATIONS_CONFIG/CommonDomain_webtier1/ config/OHS/ohs2 -oh APPLICATIONS_BASE/webtier_mwhome/webgate $ cd APPLICATIONS_BASE/webtier_mwhome/webgate/webgate/ohs/tools/setup/ InstallTools $ ./EditHttpConf -w APPLICATIONS_CONFIG/CommonDomain_webtier1/config/OHS/ ohs2 -oh APPLICATIONS_BASE/webtier_mwhome/webgate -o webgate.conf
Do the following on WEBHOST1
:
From APPLICATIONS_CONFIG
/CommonDomain_webtier/config/OHS/ohs1/webgate/config
, copy the following to APPLICATIONS_CONFIG
/CommonDomain_webtier1/config/OHS/ohs2/webgate/config
on WEBHOST2
:
"ObAccessClient.xml","cwallet.sso","password.xml"
From APPLICATIONS_CONFIG
/CommonDomain_webtier/config/OHS/ohs1/webgate/config/simple
, copy the following to APPLICATIONS_CONFIG
/CommonDomain_webtier1/config/OHS/ohs2/webgate/config/simple
on WEBHOST2
:
"aaa_key.pem","aaa_cert.pem"
Restart Oracle HTTP Server:
UNIX:
WEBHOST2> cd APPLICATIONS_CONFIG/CommonDomain_webtier1/bin WEBHOST2> ./opmnctl stopall WEBHOST2> ./opmnctl startall
Oracle HTTP Server scaleout is now complete, and WEBHOST1
and WEBHOST2
should behave identically.
This section describes how to setup and configure Node Manager to a new host to be used as a scaled-out host.
Before setting up Node Manager, ensure the following:
Start with a clean machine (denoted as SCALED_OUT_HOST), if it is the first time it is being set up.
The UNIX/etc/hosts
file has proper entries. To verify this from the clean machine, ping the hosts listed in /etc/hosts
files with the fully qualified name of the hosts.
The user created on SCALED_OUT_HOST
to perform the scale out should be the same as the user on PROVISIONED_HOST
.
The directory structure APPLICATIONS_BASE
is mounted on SCALED_OUT_HOST
and it is the same shared file system as used by PROVISIONED_HOST
.
The Local domains directory on the PROVISIONED_HOST
should not be mounted on SCALED_OUT_HOST
.
The directory structure APPLICATIONS_CONFIG
/nodemanager
on SCALED_OUT_HOST
has been created.
Provisioning the initial Oracle Fusion Applications environment on PROVISIONED_HOST
has already completed and verified.
Provisioning has created the identity keystore PROVISIONED_HOST
_fusion_identity.jks
for PROVISIONED_HOST
. Subsequently, the identity keystore SCALED_OUT_HOST
_fusion_identity.jks
must be created for SCALED_OUT_HOST
.
Do the following to create the keystore:
There are the scale-out tasks that are common to all Oracle Fusion Applications Managed Servers in all domains (Common, Oracle Fusion CRM, Oracle Fusion Financials, Oracle Fusion Human Capital Management, Oracle Fusion Incentive Compensation, Oracle Fusion Project Portfolio Management, Oracle Fusion Procurement, and Oracle Fusion Supply Chain Management) except Oracle Business Intelligence. These tasks are the following:
Starting SCALED_OUT_HOST
Node Manager in SSL mode
Adding a new machine in the Oracle WebLogic Server console
Packing and unpacking the Managed Server domain home
Cloning Managed Servers and assigning them to SCALED_OUT_HOST
Configuring Oracle HTTP Server
Configuring server migration for the Managed Servers
Validating the system
For specific information about scaling the Oracle Business Intelligence domain, see Scale Out the Oracle Business Intelligence Domain.
To start Node Manager in the Secure Sockets Layer (SSL) mode, follow the instructions in Scale Out Node Manager.
Since the PROVISIONED_HOST
domain directory file system is also available from SCALED_OUT_HOST
, both the pack
and unpack
commands can be executed from SCALED_OUT_HOST
.
To pack and unpack the Managed Server domain home:
The following naming conventions are used in the procedure that follows:
ManagedServerName_1 is the name of the Managed Server to be cloned.
ClonedManagedServer is the name given to the Managed Server that is being cloned. For consistency, its name should follow the same naming convention as ManagedServerName, in this format: ClonedManagedServer_n, where n is a number starting with 2, and is incremented when multiple instances are cloned. For example, ClonedManagedServer_3, ClonedManagedServer_4, and so on.
To add a Managed Server and assign it to SCALED_OUT_HOST
:
Log in to the Administration Server: http://
domain_name
internal.mycompany.com/console
.
(domain_name
is the domain containing the Managed Server that is being cloned).
Navigate to Domain_Name, Environment, Servers.
Switch to Lock & Edit mode.
Select the ManagedServerName_1 check box and then click Clone.
Specify the following Server Identity attributes:
Server Name - ClonedServerName
_2
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "_2".
Server Listen Address - <SCALED_OUT_HOST
>
Server Listen Port - leave "as is"
Click OK.
The newly cloned server should now be seen, ClonedServerName
_2
.
Click ClonedServerName_2 and change the following attributes:
Machine - <SCALED_OUT_HOST
>
Cluster Name - accept the default, ClonedServerNameCluster
Ensure that this cluster name is the same as the cluster name of the original Managed Server.
Click Save and then Activate Changes.
Navigate to Domain_Name, Environment, Servers.
From the Name column, click the ClonedServerName_2 scaled-out server link.
Click Lock & Edit, and then select the Configuration tab.
Select the Keystores tab, and ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the APPLICATIONS_CONFIG
/keystores/
SCALED_OUT_HOST
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
Change the Custom Identity Keystore Passphrase entry. This should be the same as the keystorepassword, which is the password given in the APPLICATIONS_BASE/provisioning/plan/provisioning.plan
file.
Re-enter the Confirm Custom Identity Keystore Passphrase.
Ensure that the Confirm Custom Trust Keystore path is pointing to the APPLICATIONS_CONFIG
/keystores/fusion_trust.jks
file.
Leave the Custom Trust Keystore type blank.
Change the Custom Trust Keystore Passphrase entry. This should be the same as the keystorepassword, which is the password given in the APPLICATIONS_BASE/provisioning/plan/provisioning.plan
file.
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to SCALED_OUT_HOST
_fusion
.
Change the Private Key Passphrase to the keypassword, which is the password given in the APPLICATIONS_BASE/provisioning/plan/provisioning.plan
file.
Re-enter the keypassword from Step 13.c for the Confirm Private Key Passphrase.
Click Save.
Select the Server Start tab.
Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:
-DJDBCProgramName=DS/domain_name/ClonedServerName_2 -Dserver.group=ClonedServerNameCluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
Change the extended logging format fields to the following:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save.
Click Activate Changes.
Repeat Steps 2 to 18 for all the Managed Servers on this domain.
Run the newly created Managed Servers:
Log in to the Administration Server: http://
domain_name
internal.mycompany.com/console
.
Navigate to Domain_Name,Environment, Servers, Control.
Select the newly created Managed Servers and click Start.
Navigate to Domain_Name, Environment, Servers and check the State to verify that the newly created Managed Servers are running.
To configure Oracle HTTP Server:
Example 18-1 Sample "ManagedServer" Code
<Location /managedServer> SetHandler weblogic-handler WebLogicCluster <PROVISIONED_HOST:port>,<SCALED_OUT_HOST:port> </Location>
Server migration is required for proper failover of Oracle Fusion Applications components in the event of failure in any of the PROVISIONED_HOST
and SCALED_OUT_HOST
nodes. See Set Up Server Migration for Oracle Fusion Applications.
Verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the domain's Oracle WebLogic Server Administration Console and stop all the Managed Servers on PROVISIONED_HOST
while the Managed Servers on SCALED_OUT_HOST
are running.
Before cloning a Managed Server, do the following:
Log in to Oracle Fusion Applications with the correct user ID.
Select the appropriate menu to access the application provisioned to that managed server.
Copy the URL by keeping the portion/segment of https://
host
[:
port
]/
ApplicationName
/faces/
NameOfWebPage
.
The following URLs are examples of Managed Servers in various domains:
https://crmexternal.mycompany.com/contractManagement/faces/ContractsDashboard
https://finexternal.mycompany.com/ledger/faces/JournalEntryPage
https://finexternal.mycompany.com/payables/faces/InvoiceWorkbench
https://finexternal.mycompany.com/receivables/faces/ReceiptsWorkArea
https://finexternal.mycompany.com/receivables/faces/TransactionsWorkArea
https://commonexternal.mycompany.com/helpPortal/faces/AtkHelpPortalMain
https://commonexternal.mycompany.com/homePage/faces/AtkHomePageWelcome
https://hcmexternal.mycompany.com/hcmCore/faces/AddPersonUiShellMainPage
https://hcmexternal.mycompany.com/hcmCore/faces/PersonSearch
https://scmexternal.mycompany.com/productManagement/faces/ItemDashboard
https://scmexternal.mycompany.com/costManagement/faces/ItemCostProfileWorkarea
https://icexternal.mycompany.com/incentiveCompensation/faces/IcCnCompPlanWorkarea
https://prjexternal.mycompany.com/projectsFinancials/faces/PRJProjectWorkarea
https://prjexternal.mycompany.com/projectsFinancials/faces/PrjCostWorkArea
Verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
Log in to the domain's Oracle WebLogic Server Administration Console and stop all the Managed Servers on SCALED_OUT_HOST
.
Start the Managed Servers on PROVISIONED_HOST
.
Repeat Step 2. (Ensure the log in prompt is visible.)
Start all the Managed Servers on SCALED_OUT_HOST
and verify that they are running on PROVISIONED_HOST
and SCALED_OUT_HOST
.
In addition to the scale-out tasks found in Perform Scale-Out Tasks Common to All Domains, perform the following task to scale out the Oracle Fusion CRM Data Quality feature.
Data Quality is an Informatica tool that provides the following:
A matching function, which allows to search, match, and identify duplicate customer records based on key customer attributes such as name, address, date of birth, Social Security Number, or tax ID number. It also includes data quality connector, a generalized interface that can make real-time and batch requests to an external data-cleansing engine.
An address-cleansing feature, which corrects and validates address data based on postal requirements.
Implementing Data Quality requires four steps:
Obtaining postal reference data and license keys.
Setting up the Data Quality Engine, also known as Informatica Identity Resolution (IIR).
Configuring Data Quality Connector and IIR in Oracle Fusion Functional Setup Manager.
Creating a second Data Quality server on CRMHOST2
.
Before configuring data quality for scale out, obtain postal reference data and license key files from AddressDoctor. For information about how to obtain these, see the licensing documentation.
To set up the data quality engine:
On CRMHOST1
, change directory to APPLICATIONS_BASE
/InformaticaIR/bin
.
Run the following commands:
CRMHOST1> source setfusionEnv.sh CRMHOST1> ./liup CRMHOST1> ./idsup
Start the following:
./idsconc -a
On the launched console, select Rulebase Type=SSA and Alias=rtunitrb and click OK. Then click Yes to create a new rulebase.
In the IIR console, navigate to System , New, Create a system from SDF.
Enter the following system information:
System Name - FusionDQRealtime
System Definition File - APPLICATIONS_BASE
/InformaticaIR/ids/FusionDQRealtime.sdf
DB Type - SSA
Alias - fusion_s01
Click OK, and then click Close to dismiss the Create/System window.
Navigate to System menu, Select, System Name: FusionDQRealtime and click OK.
Navigate to System menu, Load IDT to start loading the individual IDT tables, one by one, until the following IDTs are completed:
load_location load_organization load_org_address load_person load_per_address load_per_phone
Close the IIR Console started in Step 2 and run the following commands to stop the IIR server:
CRMHOST1> APPLICATIONS_BASE/InformaticaIR/bin/idsdown CRMHOST1> APPLICATIONS_BASE/InformaticaIR/bin/lidown
Assuming the postal reference data and license key files have been received from AddressDoctor (requested in Obtaining Postal Reference Data and License Keys ), run the following commands:
CRMHOST1> cd APPLICATIONS_BASE/InformaticaIR/ssaas/ad5/ad/db CRMHOST1> cp mylocation/key . CRMHOST1> cp mylocation/*.MD .
mylocation
is the directory where the license key and the postal reference data were copied.
*.MD
is the postal data reference file. key
is a text file that contains the AddressDoctor license.
AddressDoctor supports 248 countries. Each *.MD
file is per country or a group of countries. Each of these files should be copied to the *.MD
directory.
Run the following commands to start the IIR server:
CRMHOST1> APPLICATIONS_BASE/InformaticaIR/bin/liup CRMHOST1> APPLICATIONS_BASE/InformaticaIR/bin/idsup
From the IIR Console, do the following to start the UPD Synchronizer:
Run the following command:
CRMHOST1> APPLICATIONS_BASE/InformaticaIR/bin/idsconc -a
On the launched console, select Rulebase Type=SSA and Alias=rtunitrb, and click OK to go the RuleBase.
In the IIR console, go to System, Select and select FusionDQRealtime.
Go to Tools, Synchronizer, Run Synchronizer and click OK to accept all the defaults shown in the Update Synchronizer popup window.
Ensure that the IDT Name=(all) option is selected.
To configure the data quality connector and IIR:
Log in to Oracle Fusion Functional Setup Manager as an administrator. For example, http://
commoninternal
.mycompany.com/homePage/faces/AtkHomePageWelcome
.
Click Navigator, then Setup and Maintenance.
Select the All tasks tab.
Select Input Name= manage server and then click Search.
The Manage Server Configurations task displays.
Click Go to Task to open the Manage Data Quality Server Configurations page, and then click Search to find all existing configurations.
Select Realtime and Batch Basic Server and do the following:
Click Edit.
Enter the server IP address and port of the IIR search server set up as the IIR matching server.
For the server IP address, enter the CRMHOST1
IP address. Enter the default port number, 1666
. Since the port number can be different than the default port number, run the following command to confirm that the correct one is used:
grep SSA_SEPORT= APPLICATIONS_BASE/InformaticaIR/env/isss
Select Enable Matching.
Click Save and Close.
From the Manage Data Quality Server Configurations page, select Realtime Cleanse Server and do the following:
Click Edit.
Enter the server IP address and port of the IIR search server set up as the IIR matching server.
For the server IP address, enter the CRMHOST1
IP address. Enter the default port number, 1666
. Since the port number can be different than the default port number, run the following command to confirm that the correct one is used:
grep SSA_SEPORT= APPLICATIONS_BASE/InformaticaIR/env/isss
Select Enable Cleansing.
Click Save and Close.
From the Manage Data Quality Server Configurations page, select Batch Cleanse Server and repeat Steps 7.a through 7.d from Step 7.
Search for the task Manage Data Synchronization and click Go to Task.
From Actions dropdown list, select Refresh Identity Table Information to refresh the IDT repository information.
Select Enable for Sync for each IDT and click Save.
Click Schedule Synchronization Process and then Advanced.
Select Using a schedule.
Select Hourly/Minute from the Frequency dropdown list. (This frequency should be determined by the business requirement.)
Enter every 5 minutes for this example. (This every 5 minutes sample should be determined by the business requirement.)
Select a "next few days" end date from the calender. (This few days sample should be determined by the business requirement.)
Click Submit to schedule the Sync ESS job.
Do the following to validate that Data Quality is up and running:
Ensure that the Customer Center application is running.
In Customer Center, create a unique organization and then try to create that same organization again.
If Data Quality is working correctly, a popup window will display telling that this organization cannot be created because it already exists.
To create a second data quality server:
Run the following command:
CRMHOST2> cd REPOSITORY_LOCATION/installers/iir/fusion_iir
Edit the install.props
file to include the following values:
############################################## # USE ABSOLUTE PATHS FOR ALL ############################################## # These environment variables are required to be set for # IIR to be able to use the ORACLE DB CLIENT ############################################## ORACLE_HOME=APPLICATIONS_BASE/dbclient TNS_ADMIN=APPLICATIONS_CONFIG/ess/tnsadmin LD_LIBRARY_PATH=APPLICATIONS_BASE/dbclient/lib ############################################## # These properties are required to be set for # IIR to be installed in the right directory ############################################## FUSION_STAGE_DIR=REPOSITORY_LOCATION/installers/iir IIR_STAGE_DIR=REPOSITORY_LOCATION/installers/iir IIR_VERSION=IIR_901sp1_linux_amd64 IIR_TOP=APPLICATIONS_BASE/IIR2 ############################################## # These properties are required to be set for IIR to be # able to connect to the Oracle DB to install Schema Objects ############################################## IIR_DB_HOSTNAME=FUSIONDBHOST1-VIP IIR_DB_PORT=1521 IIR_DB_SID=FADB1 IIR_DB_USER=fusion_dq IIR_DB_PASSWD=PASSWORD ################################################# # ALL THESE PROPERTIES ARE NEEDED BY THE INSTALLER # DO NOT MODIFY THESE UNLESS NECESSARY ################################################# IIR_INSTALL_LOG_LOC=REPOSITORY_LOCATION/installers/iir/fusion_iir IIR_INSTALL_TYPE=all IIR_INCLUDE_DOC=yes ############################################## # Default is one Server Instance ############################################## IIR_INSTANCE_1_PORT=1601 ############################################## # Not Implemented yet ############################################## IIR_INSTANCE_2_PORT= ############################################## # This option is needed for Search to be accessible through a Browser ############################################## IIR_HTTP=Y ############################################## # This is for Installing the IIR Control and Sync Objects ( needed only for the #first time) ############################################## INSTALL_IIR_OBJECTS=N ############################################## # This is needed for OEM Key ############################################## SSALI_MZXPQRS=STANISLAUS
Run the following command:
./runInstaller.sh install.props > test_console
The installation is now complete.
Configure the data quality connector and IIR:
Log in to Oracle Fusion Functional Setup Manager as an administrator. For example, http://
commoninternal
.mycompany.com/homePage/faces/AtkHomePageWelcome
.
Click Navigator, then Setup and Maintenance.
Select the All tasks tab.
Select Input Name= manage server and then click Search.
The Manage Server Configurations task displays.
Click Go to Task to open the Manage Data Quality Server Configurations page, and then click Search to find all existing configurations.
Select Realtime and Batch Basic Server and do the following:
Click Edit.
Enter the server IP address and port of the IIR search server set up as the IIR matching server.
For the server IP address, enter the CRMHOST1
IP address. Enter the default port number, 1666
. Since the port number can be different than the default port number, run the following command to confirm that the correct one is used:
grep SSA_SEPORT= APPLICATIONS_BASE/InformaticaIR/env/isss
Select Enable Matching.
Click Save and Close.
Update the SecondaryServer1Address and SecondaryServer1Port values respectively for the host name and port of the Secondary Server CRMHOST2
. These parameters can be found in the Server Parameter Values section.
Select Enable High Availability for each server configuration.
Click Save and Close.
Restart IIR on CRMHOST1
and CRMHOST2
.
On CRMHOST1
:
CRMHOST1> cd APPLICATIONS_BASE/InformaticaIR/bin CRMHOST1> source setfusionEnv.sh CRMHOST1> . ../env/isss CRMHOST1> ./idsdown CRMHOST1> ./idsup
On CRMHOST2
:
CRMHOST2> cd APPLICATIONS_BASE/IIR2/InformaticaIR/bin CRMHOST2> source setfusionEnv.sh CRMHOST2> . ../env/isss CRMHOST2> ./idsdown CRMHOST2> ./idsup
The following is sample output of the idsdown
command:
bash-3.2$ ./idsdown Mon Jun 24 11:48:48 2013 idsdown: shutting down idscssv on localhost:1669 Mon Jun 24 11:48:48 2013 idsdown: shutting down idscosv on localhost:1667 Mon Jun 24 11:48:48 2013 idsdown: shutting down idssesv on localhost:1666 Mon Jun 24 11:48:48 2013 idsdown: shutting down idsxmsv on localhost:1670 Mon Jun 24 11:48:48 2013 idsdown: shutting down idshtsv on localhost:1671 Mon Jun 24 11:48:48 2013 idsdown: shutting down idsrbsv on localhost:1668
Restart the Oracle Fusion Applications instances (which require DQ) so that the DQ Connector can do load balancing and failover.
In addition to the scale-out tasks found in Perform Scale-Out Tasks Common to All Domains, do also the following for the Oracle Fusion Common domain:
Perform one additional step when cloning Managed Servers
Remove Oracle Coherence start-up properties from the wlcs_server1
server
Configure shared content folders for the UCM_server1
server
Add a sip
data-tier channel to the wlcs_sipstate2
server
Unpack the UCM_server2
server
Configure the Oracle WebCenter product suite
Scale out Oracle WebCenter Content inbound refinery server
Add the UCM_server1
and UCM_server2
servers to the connection pool
To add a Managed Server to the Common domain, do the following:
Remove Oracle Coherence startup properties from the wlcs_server1
Managed Server's Startup tab before scaling out the wlcs_server2
Manager Server.
Although the provisioning process adds Oracle Coherence startup properties to the wlcs_server1
Managed Server, Oracle Coherence is not configured and is not currently used in Oracle Fusion Applications on-premise deployments.
To remove the startup properties:
To configure shared content folders for the UCM_server1
server, do the following:
Create a COMMONUCMLBRVH
Transmission Control Protocol (TCP) VIP with port 6300 on the load-balancing router (LBR) with PROVISIONED_HOST
:7034
and SCALED_OUT_HOST
:7034
as its members.
Because Oracle WebCenter Content failover works only with TCP connections, ensure to use TCP, and not Hypertext Transfer Protocol (HTTP), in the LBR setup.
Shut down the UCM_server1
Managed Server:
Log in to the Oracle WebLogic Server Administration Console (http://commoninternal.mycompany.com/console
).
In the Domain Structure window, first navigate to Environment, then Servers, and then click Control.
Select UCM_server1.
Click Shutdown and then Force Shutdown Now.
In the /u02/local/oracle/config/domains/
PROVISIONED_HOST
/CommonDomain/ucm/cs/bin/intradoc.cfg
file on PROVISIONED_HOST
, create the variables IntradocDir
, vaultDir
, and weblayoutDir
if they do not already exist, and point them to the shared location: ORACLE_BASE
/config/domains/
PROVISIONED_HOST
/CommonDomain/ucm/cs
.
Copy the PROVISIONED_HOST
/u02/local/oracle/config/domains/
PROVISIONED_HOST
/CommonDomain/ucm/cs
directory from the local to the shared location, ORACLE_BASE
/config/domains/
PROVISIONED_HOST
/CommonDomain/ucm/cs
.
In the config
file on PROVISIONED_HOST
(ORACLE_BASE
/config/domains/
PROVISIONED_HOST
/CommonDomain/ucm/cs/config/config.cfg
), edit two existing properties with the following:
SocketHostNameSecurityFilter=localhost|localhost.localdomain| localhost6|localhost6.localdomain6|WEBHOST1|PROVISIONED_HOST|WEBHOST2| SCALED_OUT_HOST|COMMONUCMLBRVH
and
IdcCommandServerHost=127.0.0.1
Start the UCM_server1
Managed Server.
Ensure that the UCM_server1
Managed Server is functioning properly. It should be possible to access and log in to the following:
http://
PROVISIONED_HOST
:7012/cs
http://
PROVISIONED_HOST
:7012/ibr
Unless a sip
data-tier channel is added, the wlcs_sipstate2
server start-up fails with the following error:
There are no sip nor diameter channels targeted to server "wlcs_sipstate2"
Therefore, do the following for the wlcs_sipstate2
scaled-out server only:
To provision the UCM_server2
server cluster with a shared configuration, copy the APPLICATIONS_CONFIG
/domains/
PROVISIONED_HOST
/CommonDomain/ucm
folder structure, including files, to /u02/local/oracle/config/domains/
SCALED_OUT_HOST
/CommonDomain
for the UCM_Server2
local configuration.
This section describes the additional steps to complete the Oracle WebCenter product suite scale out.
This section tells how to do the following:
Configure the Oracle WebCenter Portal wc_spaces
and wc_spaces
2 servers
Configure persistence stores for JMS servers
Configure a default persistence store for transaction recovery
Set the listen address for the IPM_server1
and IPM_server2
servers
Add IPM_server1
and IPM_server2
VIP addresses to the list of allowed hosts
Add the UCM_server1
and UCM_server2
servers to the connection pool
After scaling out the Oracle WebCenter Portal Managed Server, do the following:
When configuring Oracle WebCenter Content Server, the FusionAppsContentRepository
content repository should move from the file system to the Fusion database. To verify the move of the repository to the database, upload the /etc/hosts
file on PROVISIONED_HOST
to WebCenter Content Server by running the following commands, in order:
UNIX:
export RIDC_JAR=<APPLICATIONS_BASE>/fusionapps/ecm/ucm/Distribution/FAProv/ oracle.ucm.fa_client_11.1.1.jar export UCMSCRIPT_JAR=/u01/oracle/products/fusionapps/ecm/ucm/Distribution/ FAProv/ucmscript.jar $ java -cp $UCMSCRIPT_JAR:$RIDC_JAR oracle.ucm.client.UploadTool --url=idc://PROVISIONED_HOST:7034 --username=admin_username --uploadFile=/etc/hosts --dSecurityGroup=public --dDocTitle=hosts --Tool.AccountRequired=false --quiet
In the java -cp
command, the Intradoc protocol is being used in the URL option --url=idc://
, and not http
.
Get the IntradocServerPort number 7034
used in the URL above from the config
file:
UNIX:
/u02/local/oracle/config/domains/PROVISIONED_HOST/CommonDomain/ucm/cs/config/config.cfg
After the UNIX /etc/hosts
file successfully uploads to the Fusion database, something similar to the following displays:
Upload successful. [dID=1 | dDocName=UCMFA000001]
Use the dID
number in the next SQL command.
UNIX:
$ sqlplus FUSION_OCSERVER11G/fusionDB_password
SQL> select dID, dRenditionID, dFileSize, DLastModified
from FileStorage where dID=1;
SQL>
The following is sample output from the SQL command:
DID DRENDITIONID DFILESIZE DLASTMODIFIED 1 primaryFile 702 21-MAY-13 12.16.03.524000 PM 1 webViewableFile 702 21-MAY-13 12.16.03.687000 PM
Set the location for all persistence stores targeted to the IPM_server1
and IPM_server2
Managed Servers to a directory that is visible from both PROVISIONED_HOST
and SCALED_OUT_HOST
.
To configure the persistence stores:
Each server has a transaction log which stores information about committed transactions that are coordinated by the server that may not have been completed. Oracle 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.
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://commoninternal.mycompany.com/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 displays.
Click the name of the server (represented as a hyperlink) in the IPM_server1 table. The settings page for the selected server opens with the Configuration tab active.
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. For example, create a directory
PROVISIONED_HOST> APPLICATIONS_CONFIG/domains/PROVISIONED_HOST /CommonDomain/tlogs
Click Save.
Repeat Steps 1 through 7 for the IPM_server2
Managed Server.
Click 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://commoninternal.mycompany.com/console
).
In the Summary of Servers screen, select the Control tab.
Select IPM_server1 and IPM_server2 in the table and then click Shutdown.
After the servers have shut down, select IPM_server1 and IPM_server2 in the table and click Start.
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 IPM_server1
and IPM_server2
must be able to access this directory.
Ensure the following the path exists on the machine:
(Linux) /usr/share/X11/fonts/TTF
(Solaris) /usr/X11/lib/X11/fonts/TrueType
Ensure that virtual IPs have been enabled on PROVISIONED_HOST
and SCALED_OUT_HOST
before setting the IPM_server1
and IPM_server2
listen addresses.
To set the listen address for the Managed Servers:
Log in to the Administration Console (http://commoninternal.mycompany.com/console
).
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select IPM_server1 in the table.
The Settings page for IPM_server1
Managed Server displays.
Set the listen address to COMMONIPMVH1 and click Save.
Navigate to the Summary of Servers page and select IPM_server2 in the table.
The Settings page for the IPM_server2
Managed Server displays.
Set the listen address to COMMONIPMVH2 and click Save.
Both COMMONIPMVH1
and COMMONIPMVH2
are pingable.
Click Activate Changes.
The changes will not take effect until the IPM_server1
and IPM_server2
Managed Servers are restarted. To restart the Managed Servers, do the following:
Ensure that Node Manager is up and running.
On the Summary of Servers page, select the Control tab.
Navigate to the Summary of Servers page, select IPM_server1 andIPM_server2 in the table, and then click Shutdown.
After the servers have shut down, select IPM_server1 and IPM_server2 in the table and click Start.
Follow the steps below to scale out the Oracle WebCenter Content Inbound Refinery (IBR) server. Note that IBR is provisioned only if the provisioning offering(s) selected needs it. Subsequently, the environment may not need IBR.
If APPLICATIONS_LOCAL_CONFIG
/domains/
PROVISIONED_HOST
/CommonDomain/ucm/ibr
is present on PROVISIONED_HOST
, then IBR is provisioned in the environment.
Edit the APPLICAITONS_LOCAL_CONFIG
/domains/
PROVISIONED_HOST
/CommonDomain/ucm/ibr/config/config.cfg
file on PROVISIONED_HOST
with the following:
IDC_Name=
PROVISIONED_HOST
7012
InstanceMenuLabel=
PROVISIONED_HOST
7012
SocketHostNameSecurityFilter=localhost|localhost.localdomain|localhost6|localhost6.localdomain6|
PROVISIONED_HOST
|
SCALED_OUT_HOST
HttpServerAddress=
PROVISIONED_HOST
:7012
(PROVISIONED_HOST
's server address instead of load balancer, as it is a singleton node.)
Add the following to the config.cfg
file on both PROVISIONED_HOST
and SCALED_OUT_HOST
:
EnableReserveDirectoryCheck=false
Restart the ucm_server1
server.
Navigate to http://
SCALED_OUT_HOST
:7012/ibr
(SCALED_OUT_HOST
's ibr
) and log in when prompted.
The post-installation configuration page displays, as it is not a clustered node.
On the post-installation configuration page:
Set the server socket port to 7035.
Ensure the port has a unique server instance name and unique local paths on SCALED_OUT_HOST
.
Set the Incoming Socket Connection Address Security Filter:
SocketHostNameSecurityFilter=localhost|localhost.localdomain|localhost6|localhost6.localdomain6|
PROVISIONED_HOST
|
SCALED_OUT_HOST
Click Submit.
Restart the ucm_server2
server.
Navigate to http://
PROVISIONED_HOST
:7012/cs
and select Administration > providers.
ibrprovider is already defined in this list.
Add a new outgoing provider:
Click Add.
Set the values to match the values of ibrprovider.
MANDATORY: The value for the new outgoing ibrprovider must differ from the value of the default ibrprovider.
Assign the following unique values: to Provider Name, Provider Description, Server Host Name, Server Port, Instance Name, and Relative Web Root.
– Provider Name: ibr_provider2
– Provider Description: ibrprovider for second server
– Server Host Name: SCALED_OUT_HOST
– Server Port: 7035
– Instance Name: SCALED_OUT_HOST_HOST
7012
– Relative Web Root: /cs
Navigate to Inbound Refinery on the second node: http://
SCALED_OUT_HOST
:7012/ibr.
(UNIX only) Select Conversion Settings and update the primary web rendition.
Navigate to Third-Party Applications Settings, General OutsideIn Filter Options, Options and set the following path to the fonts: /usr/share/X11/fonts/TTF
.
Solaris:
Navigate to Third-Party Applications Settings, General OutsideIn Filter Options, Options and set the following path to the fonts: /usr/X11/lib/X11/fonts/TrueType
.
The font location can be specific to the operating system.
Restart the UCM_server1
and UCM_server2
Managed Servers.
Oracle Data Integrator Managed Servers are present in four domains:
Oracle Fusion CRM
Oracle Fusion HCM
Oracle Fusion Human Capital Management
Oracle Fusion Incentive Compensation
Oracle recommends using unicast communication in odi_server
enterprise deployments, unless use of multicast is a must. Consider using multicast communication for large Oracle Data Integrator clusters with approximately 20 or more Oracle Data Integrator Managed Servers
WARNINIG: An incorrect configuration of the Oracle Coherence framework that is used for deployment may prevent the odi_server
Managed Server from starting. Oracle recommends the configuration described in this section.
Unicast communication does not enable nodes to discover other cluster members automatically when a new Oracle Data Integrator server is added to a cluster. Consequently, specify the nodes that belong to the cluster. It is not necessary to specify all of the nodes of a cluster, however. Specify only enough nodes so that a new node added to the cluster can discover one of the existing nodes. Consequently, 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 Oracle Data Integrator enterprise deployments, where multiple IPs are available in the same box, configure Oracle Coherence to use a specific host name to create the Oracle Coherence cluster.
Tip:
To guarantee high availability during deployments of odi_server
Managed Servers, specify enough nodes so that at least one of them is running at any given time.
Specify the nodes using the -Doracle.odi.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. 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.
To add the virtual-host names to Oracle Coherence:
This section describes how to scale the Oracle Business Intelligence domain.
Oracle Fusion Applications offerings use following Oracle Business Intelligence components from the Oracle Business Intelligence domain:
Oracle Business Intelligence Analytics
Essbase
Oracle Real-Time Decisions
Oracle Business Intelligence Publisher
Oracle Business Intelligence Publisher (Oracle BI Publisher)
Oracle Transaction Business Intelligence
Oracle Essbase
Oracle Fusion General Ledger combines the traditional general ledger functionality with Oracle Essbase functionality, which is embedded seamlessly within Oracle Fusion General Ledger. At the time users create their chart of accounts, the balances cube is created automatically. Later, in case of a change such as a cost center is added or a date effective hierarchy is modified, the General Ledger automatically creates or modifies the corresponding balances cube hierarchy. As transactions or journals are posted, the General Ledger automatically updates the multidimensional cube. Unlike a data warehouse, no batch programs need to be run to populate the balances cube; it is all happening in real time when a journal is posted.
Oracle Business Intelligence Publisher
Oracle BI Publisher provides the ability to create and format high quality reports across Oracle Fusion Financials applications. It applies templates, which users design in familiar desktop tools, to standard extracts and reports. For example, it is used widely used in Oracle Fusion Payments for formatting of the check payments and electronic payment files.
Oracle Transaction Business Intelligence
Oracle Transaction Business Intelligence is widely used in Oracle Fusion Financials as a reporting tool. Using Oracle Transaction Business Intelligence, users can perform adhoc queries directly from transaction tables using drag-and-drop functionality to build custom reports in real time from the various Oracle Fusion Financials applications. It helps immensely in reducing the need to build and maintain customized reports.
Oracle Business Intelligence Analytics
Oracle Business Intelligence Analytics provides day-to -day key performance indicators (KPIs) of any item in Oracle Fusion Financials. Intelligence and analytics are embedded within the context of business transactions to help users complete the transitions. For example, before users post a journal, the system tells them the impact the journal has on the account balances. This eliminates the need to navigate to a separate page to run a query or run a report. End users are not distracted from the task at hand, reporting and process demand is reduced, and smarter decisions are made in the context of the transaction.
Before beginning, ensure the following:
Node Manager has been started in the Secure Sockets Layer (SSL) mode by following the instructions in Scaling Out Node Manager.
The Administration Console's Follow Configuration Changes feature has been disabled (to eliminate redirections):
Log into the Administration Console (http://biinternal.mycompany.com/console
) and go to Preferences, Shared Preferences.
Deselect Follow Configuration Changes and click Save.
Prerequisites include the following:
Configuring a JMS file persistence store on BIHOST1
Setting the listen address for the bi_server1
server
Updating the FusionVirtualHost_bi.conf
configuration file
Configure the location for the Java Message Service (JMS) file persistence store to a directory visible from both nodes. Change the persistent store to use this shared base directory.
Log in to the Administration Console (http://biinternal.mycompany.com/console
).
In the Domain Structure window, expand the Services node.
In the Change Center, click Lock & Edit.
Click the Persistent Stores node.
The Summary of Persistent Stores page displays.
Click JRFWSAsyncFileStore and enter a directory that is located in the shared storage. This shared storage is accessible from both BIHOST1
and BIHOST2
:
APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain/JRFWSAsyncFileStore
Click Save.
Click Activate Changes.
The changes will not take effect until the Managed Server is restarted.
Do the following:
Ensure that Node Manager is up and running.
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
After the server has shut down, select bi_server1 in the table and then click Start.
Run the following commands on BIHOST1
to restart the Oracle Business Intelligence system components:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance/bin
$ ./opmnctl stopall
$ ./opmnctl startall
Make sure that the steps described in Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST have been performed before setting the bi_server1
listen address.
To set the listen address for the Managed Server:
Log in to the Administration Console (http://biinternal.mycompany.com/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 bi_server1 in the table. The Settings page for bi_server1
is displayed.
Set the Listen Address to BIVH1
.
Both BIVH1
and BIVH2
are pingable.
Click Save.
Click Activate Changes.
The changes do not take effect until the bi_server1
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select bi_server1 in the table and then click Shutdown.
After the server has shut down, select bi_server1 in the table and then click Start.
Restart the Oracle Business Intelligence system components on BIHOST1
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance/bin
$ ./opmnctl stopall
$ ./opmnctl startall
This section describes how to scale out the Oracle Business Intelligence system using the Configuration Assistant. It is assumed that an Oracle Business Intelligence ORACLE_BASE (binaries) has already been installed and is available from BIHOST1
and BIHOST2
, and that a domain with an Administration Server has been created. This is the domain that will be extended in this section to support Oracle Business Intelligence components.
OPTIONAL: Oracle strongly recommends to read the Oracle Fusion Middleware release notes for any additional installation and deployment considerations before starting the setup process.
This section tells how to do the following:
Scale out Oracle Business Intelligence on BIHOST2
Start Node Manager in SSL mode
Scale out the system components
Configure secondary instances of singleton system components
Configure the bi_server2
Managed Server
Perform additional configuration for Oracle Business Intelligence high availability
Configure a default persistence store for transaction recovery
Start and validate Oracle Business Intelligence on BIHOST2
Validate access through Oracle HTTP Server
Configure Node Manager for the Managed Servers
Configure server migration for the Managed Servers
To scale out the Oracle Business Intelligence system:
To start Node Manager in SSL mode:
Stop the default Node Manager running on BIHOST2
using one of the following methods:
Use CTRL+C in the shell where it was started
Use the standard process-identification and kill commands in the operating system appropriate to the product and the Oracle Fusion Applications enterprise deployment.
Start Node Manager in SSL mode on BIHOST2
:
UNIX:
BIHOST2> cd APPLICATIONS_CONFIG/nodemanager/BIHOST2 BIHOST2> ./startNodeManagerWrapper.sh &
Update the Node Manager for the BIHOST2
machine using the Oracle WebLogic Server Console by doing the following:
Log in to the Administration Server: http://biinternal.mycompany.com/console
.
Navigate to BIDomain, Environment, Machines.
In the left-hand pane, click Lock & Edit.
In the right-hand pane, click BIHOST2
.
In the window that opens, click the Node Manager tab and set the following attributes:
– Type - SSL
– Listen Address - <BIHOST2
>
– Listen Port - 5556
Click Save and then Activate Changes.
The changes will not take effect until the bi_server2
Managed Server is restarted.
Do the following:
Stop the Administration Server:
UNIX:
BIHOST1> APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain/bin/stopWebLogic.sh
Connect to the Administration Server through nmConnect
and start the Administration Server using nmstart
.
– Set the following environment variable:
UNIX:
export WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=
APPLICATIONS_CONFIG/keystores/fusion_trust.jks"
– Start the Administration Server:
UNIX:
BIHOST1> cd APPLICATIONS_BASE/fusionapps/ wlserver_10.3/common/bin BIHOST1> ./wlst.sh
– In the WLST shell, execute the following command:
wls:/offline> nmConnect (username='Admin_User',password='Admin_ Password',host='BIHOST1',port='5556', nmType='ssl', domainDir= 'APPLICATIONS_CONFIG/domains/BIHOST1/BIDomain') wls:/nm/domain_name> nmStart ('AdminServer') wls:/nm/domain_name> exit ()
The username and password used in nmConnect
are the Node Manager credentials (user name and password) specified when creating the provisioning response file.
Restart the bi_server2
Managed Server:
– On the Summary of Servers page, select the Control tab.
– Select bi_server2 in the table and then click Shutdown.
– After the server has shut down, select bi_server2 in the table and then click Start.
To scale out the system components, do the following in Oracle Enterprise Manager Fusion Middleware Control:
Restart is not needed at this point, because a restart is performed after completing the steps in Configure Secondary Instances of Singleton Components.
Oracle Business Intelligence Scheduler and Oracle Business Intelligence Cluster Controller are singleton components that operate in active/passive mode. Configure a secondary instance of these components so that they are distributed for high availability.
To configure secondary instances, do the following in Fusion Middleware Control:
This section explains what to do to configure the bi_server2
Managed Server.
Setting the Listen Address for the bi_server2 Managed Server
Make sure that the steps described in Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST have been performed before setting the bi_server2
listen address.
To set the listen address for the Managed Server:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/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 bi_server2 in the table. The settings page for bi_server2
is displayed.
Set the Listen Address to BIVH2
.
Click Save.
Click Activate Changes.
The changes will not take effect until the Managed Server is restarted.
Do the following:
Ensure that Node Manager is up and running.
On the Summary of Servers page, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
After the server has shut down, select bi_server2 in the table and then click Start.
Configuring Custom Identity and Custom Trust for the bi_server2 Managed Server
To configure custom identity and custom trust:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
In the Change Center, click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server2 in the table. The Settings page for bi_server2
displays.
Click Keystores, and then do the following:
Click Change next to Demo Identity and Demo Trust.
Select Custom Identity and Custom Trust from the Keystores dropdown list and click Save.
Under Identity, do the following:
– Change the Custom Identity Keystore entry to point to the APPLICATIONS_CONFIG
/keystores/
BIHOST2
_fusion_identity.jks
file.
– Enter and confirm the Custom Identity Keystore Passphrase.
Under Trust, do the following:
– Change the Custom Identity Keystore entry to point to the APPLICATIONS_CONFIG
/keystores/fusion_trust.jks
file.
– Enter and confirm the Custom Trust Keystore Passphrase.
– Click Save.
Click SSL, and then do the following:
Ensure that Identity and Trust Locations is set to Keystores.
Under Identity, do the following:
– Change the Private Key Alias to BIHOST2
_fusion
.
– Enter and confirm the Private Key Passphrase to the keypassword.
– Click Save.
Click Activate Changes.
(UNIX) Set the following property in APPLICATIONS_BASE
/fusionapps/wlserver_10.3/common/bin/wlst.sh
:
WLST_PROPERTIES=" -Dweblogic.wlstHome='${WLST_HOME}'
-Dweblogic.security.SSL.trustedCAKeyStore=APPLICATIONS_CONFIG/keystores/
fusion_trust.jks ${WLST_PROPERTIES}"
Disabling Host Name Verification for the bi_server2 Managed Server
This step is required if the appropriate certificates have not been set up to authenticate the different nodes with the Administration Server. If the server certificates have not been configured, errors are displayed during the management of the different WebLogic servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again after the topology configuration is complete.
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page is displayed.
Select bi_server2 in the table. The settings page for the server is displayed.
Click the SSL tab.
Expand the Advanced section of the page.
Set Host Name Verification to None.
Click Save.
Click Activate Changes.
The change will not take effect until the bi_server2
Managed Server is restarted (make sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
Select bi_server2 in the table and then click Start.
Restart the Oracle Business Intelligence system components on BIHOST2
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance1/bin
$ ./opmnctl stopall
$ ./opmnctl startall
Adding bi_server2 System Properties to the Server Start Tab
After scaling out the bi_server2
Managed Server, add a new system property to the Server Start tab of this Managed Server.
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server2 in the table.
The settings page for the server displays.
Click Server Start.
Add the following property to the arguments:
-DJDBCProgramName=DS/BIDomain/bi_server2
Click Save and then Activate Changes.
Restart the bi_server2
Managed Server (ensure sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
Select bi_server2 in the table and then click Start.
Restart the BI System Components on BIHOST2
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance1/bin
$ ./opmnctl stopall
$ ./opmnctl startall
This section describes additional high availability configuration tasks for Oracle BI Enterprise Edition, Oracle Real-Time Decisions, Oracle BI Publisher, and Oracle Financial Reports.
Additional Configuration Tasks for Oracle BI Scheduler
If server-side scripts are used with Oracle BI Scheduler, it is recommended to configure a shared directory for the scripts so that they can be shared by all Oracle BI Scheduler components in a cluster.
Perform these steps only if server-side scripts are used.
To share Oracle BI Scheduler scripts:
Create an APPLICATIONS_CONFIG
/BIShared/OracleBISchedulerComponent/coreapplication_obisch1
directory.
From BIHOST1
, copy the default Oracle BI Scheduler scripts (for example, APPLICATIONS_CONFIG
/BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/common
) and custom Oracle BI Scheduler scripts (for example, APPLICATIONS_CONFIG
/BIInstance/bifoundation/OracleBISchedulerComponent/coreapplication_obisch1/scripts/scheduler
) to the following location:
APPLICATIONS_CONFIG
/BIShared/OracleBISchedulerComponent/coreapplication_obisch1
Update the SchedulerScriptPath and DefaultScriptPath elements of the Oracle BI Scheduler instanceconfig.xml
file, as follows:
SchedulerScriptPath: Refers to the path where Oracle BI Scheduler-created job scripts are stored. Change this to the path of the shared BI Scheduler scripts location.
DefaultScriptPath: Specifies the path where user-created job scripts (not agents) are stored. Change this to the path of the shared BI Scheduler scripts location.
The instanceconfig.xml
files for Oracle BI Scheduler are in the following locations:
On BIHOST1:: APPLICATIONS_CONFIG
/BIInstance/config/OracleBISchedulerComponent/coreapplication_obisch1
On BIHOST2: APPLICATIONS_CONFIG
/BIInstance1/config/OracleBISchedulerComponent/coreapplication_obisch1
Update these files for each Oracle BI Scheduler component in the deployment.
Restart the Oracle BI Scheduler component.
On BIHOST1:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance/bin
$ ./opmnctl stopproc
ias-component=coreapplication_obisch1
$ ./opmnctl startproc
ias-component=coreapplication_obisch1
On BIHOST2:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance1/bin
$ ./opmnctl stopproc
ias-component=coreapplication_obisch1
$ ./opmnctl startproc
ias-component=coreapplication_obisch1
Additional Configuration Tasks for Oracle Real-Time Decisions
This sections contains information about the following:
Configuring Oracle Real-Time Decisions clustering
Adding Oracle RTD system properties to the server start tab
Configuring Oracle Real-Time Decisions Clustering Properties
Perform these steps in Fusion Middleware Control to set up cluster-specific configuration properties for Oracle Real-Time Decisions (Oracle RTD). It is only necessary to perform the steps on one of the nodes in the deployment. It is not necessary to set cluster-specific configuration properties for Oracle RTD for subsequent nodes.
Log in to Fusion Middleware Control (http://biinternal.mycompany.com/em
).
Expand the Application Deployments node in the Farm_BIDomain window.
Expand Oracle RTD(11.1.1)(bi_cluster).
Click any node under it. For example, Oracle RTD(11.1.1)(bi_server1).
In the right pane, click Application Deployment, and then select System MBean Browser.
In the System MBean Browser pane, expand Application Defined MBeans.
For any one of the servers under Oracle RTD, navigate to the MBean and set the attribute, as shown in the following table. Other servers automatically get updated with the value that is set.
Table 18-2 Oracle RTD MBean Attributes and Values for Clustering
MBean | Attribute | Value |
---|---|---|
SDClusterPropertyManager -> Misc |
DecisionServiceAddress |
|
Click Apply.
Adding Oracle RTD System Properties to the Server Start Tab
After scaling out Oracle RTD, use the Administration Console to add three system properties to the Server Start tab of each Managed Server.
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers.
The Summary of Servers page displays.
Select bi_server<1,2> in the table.
The settings page for the server displays.
Click Server Start.
Add the following property to the arguments:
-Drtd.clusterRegistryJobIntervalMs=12000 -Drtd.clusterDepartureThresholdMs=50000 -Drtd.clusterDepartureThreshold2Ms=50000
Click Save and then Activate Changes.
Restart the bi_server<1,2>
Managed Server (ensure sure that Node Manager is up and running):
In the Summary of Servers screen, select the Control tab.
Select bi_server<1,2> in the table and then click Shutdown.
Select bi_server<1,2> in the table and then click Start.
Restart the BI System Components on BIHOST1
and BIHOST2
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstancen/bin $ ./opmnctl stopall $ ./opmnctl startall
Performing this task enables an instance of Oracle RTD to be migrated successfully from one host to another in the event of a failure of a Managed Server.
Even after these changes, if the server migration finishes in less than 50 seconds, the Oracle RTD batch framework is in an inconsistent state.
If the enterprise has deployed any RTD Inline Services that host Batch Job implementations, and if after a server migration the batch console command, "batch-names", or its brief name, "bn", shows no registered batch jobs, then the Oracle RTD Batch Manager service must be stopped and restarted. To do this, perform these steps:
In Fusion Middleware Control, expand the WebLogic Domain node in the left pane. Then, right-click BIDomain and select System MBean Browser.
Locate SDPropertyManager, Misc MBean under Application Defined MBeans, OracleRTD, Server:bi_server n.
Be sure to select the Misc MBean that corresponds to the local node where the change is being made. For example, in case of connecting to APPHOST1
, then make sure to update the attribute associated with bi_server1
.
Set the BatchManagerEnabled attribute to false and click Apply.
Set the BatchManagerEnabled attribute back to true and click Apply. Performing this task causes the Batch Manager to stop and be restarted.
When it restarts, it runs on either the same server as before, or on a different server.
After restarting Batch Manager, note that the corresponding MBean does not always immediately get refreshed on the server where Batch Manager comes back up, so this is not a concern. Instead, verify that Batch Manager is now operational by using the Batch Console tool:
Locate the zip file for the Oracle RTD client tools in the following location:
APPLICATIONS_BASE/fusionapps/bi/clients/rtd/rtd_client_11.1.1.zip
Because most Oracle RTD client tools do not run on UNIX, unzip this file in a location on a Windows machine (referred to here as RTD_HOME). Then, locate the batch console jar file in:
RTD_HOME/client/Batch/batch-console.jar
Change to this directory and execute the jar, passing to it the URL and port of either the Managed Server, or of the cluster proxy:
java -jar batch-console.jar -url http://SERVER:PORT
When prompted, enter the user name and password of a user who is a member of the Administrator role, BI_Adminstrator role, or some other role authorized to administer Oracle RTD batch jobs.
When prompted for a command, enter bn
:
Checking server connection... command: bn CrossSellSelectOffers command:quit
If Batch Manager has successfully restarted, then the bn
command lists the names of all batch implementations hosted by all deployed RTD Inline Services.
The commonly deployed example, CrossSell, hosts a batch implementation named CrossSellSelectOffers, shown in the preceding example.
Additional Configuration Tasks for Oracle BI Publisher
Perform the steps in this section on each machine where Oracle BI Publisher is configured.
Configuring Integration with Oracle BI Presentation Services
To configure Oracle BI Publisher integration with Oracle BI Presentation Services:
Log in to Oracle BI Publisher (http://biinternal.mycompany.com/xmlpserver
) with Administrator credentials and select the Administration tab.
Under Integration, select Oracle BI Presentation Services.
Verify and update the following:
Server Protocol: http
Server: biinternal.mycompany.com
Port: 80
URL Suffix: analytics-ws/saw.dll
Click Apply.
Under System Maintenance, select Server Configuration.
In the Catalog section, change the BI Publisher Repository value to the shared location for the Configuration Folder. For example:
APPLICATIONS_CONFIG/BIShared/BIPublisher/repository
Click Apply.
Restart the Oracle BI Publisher application:
Log in to the Administration Console (http://biinternal.mycompany.com/console
).
Click Deployments in the Domain Structure window.
Select bipublisher(11.1.1).
Click Stop, and then select When Work Completes or Force Stop Now.
After the application has stopped, click Start and then Start Servicing All requests.
Setting the Oracle BI Enterprise Edition Data Source
The Oracle BI EE Data Source must point to the clustered Oracle BI Servers through the Cluster Controllers. Perform this task in Oracle BI Publisher.
To set the Oracle BI EE data source in Oracle BI Publisher:
Log in to Oracle BI Publisher (http://biinternal.mycompany.com/xmlpserver
) with Administrator credentials and select the Administration tab.
Under Data Sources, select JDBC Connection.
Update the Oracle BI EE data source setting by changing the Connection String parameter to the following:
jdbc:oraclebi://primary_cluster_controller_host:primary_cluster_controller_ port/PrimaryCCS=primary_cluster_controller_host;PrimaryCCSPort=primary_cluster_ controller_port;SecondaryCCS=secondary_cluster_controller_host; SecondaryCCSPort=secondary_cluster_controller_port;
For example:
jdbc:oraclebi://BIHOST1:10212/PrimaryCCS=BIHOST1;PrimaryCCSPort=10212; SecondaryCCS=BIHOST2;SecondaryCCSPort=10212;
Since the Cluster Controller Port may be different between BIHOST1
and BIHOST2
, use the following procedure to check the port being used:
Log in to the Oracle Enterprise Manager Console: http://biinternal.mycompany.com/em
.
Expand Farm_Domain, Business Intelligence, coreapplication.
Navigate to Availability.
Check the port number used by the Cluster Controller on BIHOST1
and BIHOST2
.
Do one of the following:
Select Use System User.
Deselect Use System User and specify BIImpersonateUser credentials.
See Credentials for Connecting to the Oracle BI Presentation Catalog in Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition.
Click Test Connection. A "Connection established successfully" message should be received.
Click Apply.
Configuring Java Message Service for Oracle BI Publisher
Configure the location for the persistence store to the Oracle Fusion Applications database.
On BIHOST2:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
In the Domain Structure window, expand the Services node and then click the Persistence Stores node. The Summary of Persistence Stores page is displayed.
Click Lock & Edit.
Click New, and then Create JDBCStore.
Enter a name (for example, BipJDBCStore-bi_server2
) and target (for example, bi_server2
). Select bip_datasource as the data source, and enter Bip_bi_server2_
as the prefix name.
Click OK and then 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 is displayed.
Click Lock & Edit.
Click New.
Enter a name (for example, BipJmsServer-bi_server2
) and in the Persistence Store drop-down list, select BipJDBCStore-bi_server2 and click Next.
Select bi_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 is displayed.
In the Change Center, click Lock & Edit.
Click BipJmsResource and then click the Subdeployments tab.
Select BipJmsSubDeployment under Subdeployments.
Add the new Oracle BI Publisher JMS Server (BipJmsServer-bi_server2) as an additional target for the subdeployment.
Click Save and then Activate Changes.
To validate, do the following:
Log in to each Oracle BI Publisher URL.
Navigate to Administration, System Maintenance, Scheduler Diagnostics.
All statuses should be in a Passed state and both instances should be visible.
Additional Configuration Tasks for Oracle Business Intelligence for Microsoft Office
The information in this section tells how to do the following:
Configure Oracle Business Intelligence for Microsoft Office properties
Validate Oracle Business Intelligence for Microsoft Office
Configuring Oracle Business Intelligence for Microsoft Office Properties
To perform additional configuration tasks for Oracle Business Intelligence for Microsoft Office:
Validate the Oracle BI Enterprise Edition Office Server setup by accessing http://biinternal.mycompany.com/bioffice/about.jsp
.
The About Oracle BI EE Office Server page displays.
Go to the Oracle BI Enterprise Edition Office Server directory. For example:
APPLICATIONS_CONFIG
/domains/
BIHOST1
/BIDomain/servers/bi_server1/tmp/_WL_user/bioffice_11.1.1/cvsibb/war/WEB-INF
To locate the Oracle BI Enterprise Edition Office Server directory, check the LogDir parameter on the About Oracle BI EE Office Server page. The Oracle BI Enterprise Edition Office Server directory is the parent directory of the log directory.
Determine the exact location for BIHOSTn by using the following URL: http://BIVH
n
:10217/bioffice/about.jsp
.
On bothBIHOST1
and BIHOST2
, open bioffice.xml for editing and modify the BI Office properties shown in the following table.
Table 18-3 BI Office Properties in bioffice.xml
Property Name | Valid Value | Description |
---|---|---|
SawBaseURL |
http://biinternal.mycompany.com/analytics/saw.dll or http://biinternal.mycompany.com/analytics-ws/saw.dll |
Load Balancer Virtual Server Name URL for Oracle BI Presentation Services. Important: If SSO is enabled, then enter the URL for the protected analytics servlet deployed when configuring BI Office to integrate with the SSO-enabled Oracle BI Server. The URL that is specified for this property is used for Web services requests between the BI Office Server and Presentation Services. |
SawUseSSO |
0 = No (Default) 1 = Yes |
Set this property to |
SawWebURLforSSO |
http://biinternal.mycompany.com/analytics/saw.dll |
When SSO is enabled, use this property to enter the public URL that allows external users to access Oracle Business Intelligence using SSO from the Oracle BI Add-in for Microsoft Office. |
Restart the BI Office application:
Log in to the Administration Console (http://biinternal.mycompany.com/console
).
Click Deployments in the Domain Structure window.
Select bioffice(11.1.1).
Click Stop.
After the application has stopped, click Start.
Validate that the SawBaseURL parameter has been updated on the About Oracle BI EE Office Server page.
Validating Oracle Business Intelligence for Microsoft Office
To validate configuration for Oracle Business Intelligence for Microsoft Office:
Log in to Oracle BI Presentation Services at:
http://biinternal.mycompany.com/analytics
In the lower left pane, under the Get Started heading, select Download BI Desktop Tools and then select Oracle BI for MS Office.
Install Oracle BI for Microsoft by running the Oracle BI Office InstallShield Wizard.
Open Microsoft Excel or Microsoft PowerPoint.
From the Oracle BI menu, select Preferences.
In the Connections tab, select New.
Enter values for the following fields:
Server Name: Provide a name for the connection.
BI Office Server: Provide the URL for the Oracle BI Office Server.
Application Name: Enter the Application Name defined for the Oracle BI Office Server when the Oracle BI Office Server application was deployed to Oracle WebLogic Server. The default name is bioffice.
Port: Enter the Oracle BI Office Server port number.
The following figure shows the New Connection dialog.
Figure 18-1 New Connection Dialog for Oracle BI Office
Click Test Connection to test the connection between the add-in and the Oracle BI Office Server.
Successful connections receive a "Test connection successful" message, as shown in the following figure.
Figure 18-2 Test Connection Successful Message
Log in as an Administrator (for example, weblogic
) and validate that it is possible to access the Oracle BI Task Pane, as shown in the following figure.
Figure 18-3 Oracle BI Task Pane in Microsoft Excel
Additional Configuration Tasks for Oracle Financial Reporting
There are additional configuration tasks to perform for Oracle Financial Reporting. Do the following on BIHOST1
and BIHOST2
:
Update the VARIABLE_VALUE_LIMIT
from 4096 to 3072000 in the NQSConfig.INI
file. For example,
VARIABLE_VALUE_LIMIT = 3072000;
On BIHOST1
, this file is located in APPLICATIONS_CONFIG
/BIInstance/config/OracleBIServerComponent/coreapplication_obis1
.
On BIHOST2
, this file is located in APPLICATIONS_CONFIG
/BIInstance1/config/OracleBIServerComponent/coreapplication_obis1
.
Run the following commands to restart the Oracle Business Intelligence system components on BIHOST1
and BIHOST2
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstancen/bin $ ./opmnctl stopall $ ./opmnctl startall
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 Oracle 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 logs in the Oracle Fusion Applications database.
To set the location for the default persistence store:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/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 bi_server2 in the table. The Settings page for the selected server is displayed, and defaults to the Configuration tab.
Navigate to Configuration > Services.
In the Transaction Log Store section of the page, do the following:
For the type, select JDBC from the dropdown list. list.
For the data store, select bip_datasource from dropdown list.
For the prefix name, enter TLOG_bi_server2_
.
Click Save.
Click Activate Changes.
Restart bi_server2
to activate the changes:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
In the Summary of Servers screen, select the Control tab.
Select bi_server2 in the table and then click Shutdown.
Start the bi_server2
server.
Restart the Oracle Business Intelligence system components on BIHOST2
:
UNIX:
$ cd APPLICATIONS_CONFIG/BIInstance1/bin
$ ./opmnctl stopall
$ ./opmnctl startall
This information in this section tells how to do the following:
Start the bi_server2
Managed Server
Start the Oracle Business Intelligence system components
Validate Oracle Business Intelligence URLs
Starting the bi_server2 Managed Server
To start the bi_server2
Managed Server:
Start the bi_server2
Managed Server using the Oracle WebLogic Server Administration Console, as follows:
Log in to the Oracle WebLogic Server Administration Console (http://biinternal.mycompany.com/console
).
Expand the Environment node in the Domain Structure window.
Select Servers. The Summary of Servers page is displayed.
Click the Control tab.
Select bi_server2 and then click Start.
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.
Starting the Oracle Business Intelligence System Components
Control Oracle Business Intelligence system components using opmnctl
commands.
To start the Oracle Business Intelligence system components using the opmnctl
command-line tool:
Go to the directory that contains the Oracle Process Manager and Notification Server command-line tool, located in APPLICATIONS_CONFIG
/BIInstance1/bin
.
Run the opmnctl
command to start the Oracle Business Intelligence system components
(UNIX)./opmnctl startall
: Starts Oracle Process Manager and Notification Server and all Oracle Business Intelligence system components
(UNIX)./opmnctl start
: Starts Oracle Process Manager and Notification Server only
(UNIX)./opmnctl startproc ias-component=
component_name
: Starts a particular system component. For example, where coreapplication_obips1
is the Presentation Services component:
UNIX:
./opmnctl startproc ias-component=coreapplication_obips1
Check the status of the Oracle Business Intelligence system components:
UNIX:
./opmnctl status
UNIX:
opmnctl status
Validating Oracle Business Intelligence URLs
Access the following URLs:
Access http://BIVH2:10217/analytics
to verify the status of bi_server2
.
Access http://BIVH2:10217/wsm-pm
to verify the status of Web Services Manager. Click Validate Policy Manager. A list of policies and assertion templates available in the data is displayed.
WARNING: The configuration is incorrect if no policies or assertion templates appear.
Access http://BIVH2:10217/xmlpserver
to verify the status of the Oracle BI Publisher application.
Access http://BIVH2:10217/ui
to verify the status of the Oracle Real-Time Decisions application.
Access http://BIVH2:10217/mapviewer
to verify the status of the map view functionality in Oracle BI EE.
Access http://BIVH2:10217/hr
to verify Financial Reporting.
Access http://BIVH2:10217/calcmgr/index.htm
to verify Calculation Manager.
Access http://BIVH2:10217/aps/Test
to verify APS.
Access http://BIVH2:10217/workspace
to verify workspace.
Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to bi_cluster. Perform these steps to verify the URLs:
Oracle recommends using host name verification for the communication between Node Manager and the servers in the domain. This requires the use of certificates for the different addresses communicating with the Administration Server and other servers. See Scale Out Node Manager. for further details. The procedures in that section must be performed twice using the information provided in the following table.
Table 18-4 Details for Host Name Verification for Node Manager and Servers
Run | Host Name (Host) | Server Name (WLS_SERVER) |
---|---|---|
Run1: |
|
|
Run2: |
|
|
If Node Manager is configured for the Managed Servers earlier, it is not necessary to configure it again.
Server migration is required for proper failover of the Oracle BI Publisher components in the event of failure in any of the BIHOST1
and BIHOST2
nodes. See Set Up Server Migration for Oracle Fusion Applications.
This section describes how to configure and validate secondary instances of Oracle Essbase Agent so that they are distributed for high availability.
Using Essbase in a Multi-Node Real Application Cluster (RAC) Oracle Fusion Applications Database Environment:
Currently in an Oracle Fusion Applications environment provisioned with multi-node RAC database instances, Essbase is configured to connect only to the primary Oracle Real Application Clusters (RAC) node through Open Database Connectivity (ODBC). The connection does not fail over to other RAC nodes when the primary node is down. This means that the primary RAC node must be running when Oracle Fusion Applications uses Essbase to provide online analytical processing capabilities.
When Oracle Fusion Applications functionality fails due to Essbase, check if the primary RAC node is up and running. If the primary RAC node is down, restarting it resolves the failure. There is currently no workaround to make the connection failover to other RAC nodes.
Perform the following steps in Fusion Middleware Control to scale out the secondary Oracle Essbase Agent:
Log in to Fusion Middleware Control (http://biinternal.mycompany.com/em
).
Expand the Business Intelligence node in the Farm_BIDomain window.
Click coreapplication.
Click Availability, then click Failover.
Click Lock and Edit Configuration to activate the Primary/Secondary Configuration section of the Availability tab.
Specify the Secondary Host/Instance for Essbase Agent.
Ensure the Shared Folder Path is set to APPLICATIONS_CONFIG
/BIShared/Essbase/essbaseserver1
and click Apply.
Click Activate Changes.
Under Manage System, click Restart.
Click Yes in the confirmation dialog.
Under Potential Single Points of Failure, no problems should be reported for Essbase Agent.
Do the following to validate Essbase clustering:
Scale out and or scale up an Oracle Fusion Applications environment. When scaling out, add a new instance of a Managed Server to a new host (called SCALED_OUT_HOST
in previous sections) that does not already have the Managed Server running in it. When scaling up, add a new instance of a Managed Server in an existing host (either a PROVISIONED_HOST
or SCALED_OUT_HOST
) that already has one or more instances of the Managed Server running in it.
This section describes how to scale up an environment by adding a new instance of a Managed Server to an existing host, called SCALED_UP_HOST
. Note that a SCALED_UP_HOST
is one of the PROVISIONED_HOST
or SCALED_UP_HOST
that are already part of the Oracle Fusion Applications environment. For clarity in this section, we use SCALED_UP_MGD_SERVER
to denote the Managed Server to be scaled up.
This section explains how to do the following:
Scale up the topology (add Managed Servers to an existing node) for Oracle ADF server
Scale out the topology (add Managed Servers to a new node) for Oracle SOA Suite server
Scale up the topology (add Managed Servers to an existing node) for Oracle SOA Suite server
Scale up the topology (add Managed Servers to an existing node) for Oracle Business Intelligence
Before performing the tasks in this section, ensure that the Managed Server (SCALED_UP_MGD_SERVER
) to be scaled up and its domain (referred to as domain
) is running.
To add a Managed Server (SCALED_UP_MGD_SERVER
) and assign it to SCALED_UP_HOST
:
Log in to the Administration Server: http://
domain_name
internal.mycompany.com/console
.
Navigate to Domain_Name ,Environment, Servers.
Switch to Lock & Edit mode.
Select the SCALED_UP_MGD_SERVER checkbox and then click Clone.
Specify the following Server Identity attributes:
Server Name - SCALED_UP_MGD_SERVER_n
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Increase the number of instances of SCALED_UP_MGD_SERVER
by one and use that number to replace "n
" at the end of the server name. Oracle recommends following the managed server naming convention NamedManagedServer_n
.
Server Listen Address - <SCALED_UP_HOST
> (This is the existing host where the new instance of SCALED_UP_MGD_SERVER
is added.)
Server Listen Port - Give an unused port on the machine SCALED_UP_HOST
Click OK.
Navigate back to Domain_Name, Environment, Servers. See the newly cloned server, SCALED_UP_MGD_SERVER_n
.
From SCALED_UP_MGD_SERVER_n
, click Advanced and then select the WebLogic Plug-In Enabled checkbox.
Click Save and then click Activate Changes.
Run the newly created Managed Server:
Navigate to Domain_Name, Environment.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to Domain_Name, Environment, Servers, Control.
Check the newly created Managed Server and click Start.
Navigate to Domain_Name, Environment, Servers and check the State to verify that the newly created Managed Server is running.
Log in to the Administration Server once again (http://
domain_name
internal.mycompany.com/console
) and verify that all the Managed Servers, including the new instance of the scaled-up Managed Server, are running.
Do the following:
Switch to Lock & Edit mode.
Select the SCALED_UP_MGD_SERVER checkbox.
Select the Server Start tab.
Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:
-DJDBCProgramName\=DS/domain_name/SCALED_UP_MGD_SERVER_n -Dserver.group\=SCALED_UP_MGD_SERVERCluster
The naming convention of a SCALED_UP_MGT_SERVER_CLUSTER
is the name of the managed server appended with "Cluster" after dropping "Server_n". For example, if SCALED_UP_MGD_SERVER_n
is HomePageServer_4, its cluster (that is, server group) is HomePageCluster.
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
Change the extended logging format fields to the following:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save.
Click Activate Changes.
Restart the SCALED_UP_MGD_SERVER_n
for the changes to take affect.
Verify URLs to ensure that the appropriate routing and failover are working.
To verify the URLs:
Log in to the domain's Oracle WebLogic Server Administration Console and stop all the instances of SCALED_UP_MGD_SERVER
currently running in SCALED_UP_HOST
, PROVISIONED_HOST
, and SCALED_OUT_HOST
, where applicable. (Also stop SCALED_UP_MGD_SERVER_n
that are just added.)
Do the following:
Edit the FusionVirtualHost_
domain
.conf
file where domain
takes the value of fs
(Common domain), crm
, fin
, hcm
, ic
, scm
, and so on, depending on the domain used.
If the SCALED_UP_HOST
's host and port do not already exist in the SCALED_UP_MGT_SERVER
entry, complete Steps b and c. Otherwise, skip to Step 3.
Locate the name (in lower case) of the scaled-up Managed Server in the file. Add the value SCALED_UP_HOST
:port
to the WebLogicCluster property. Note that there are two parts, internal and external, in the FusionVirtualHost_
domain
.conf
file on WEBHOST
. The SCALED_UP_HOST
:port
must be added to both the internal and external parts. If scaling out web tier to WEBHOST2
and others, do the same on these hosts as well.
The following is an example of scaling up the HomePage
Managed Server, and what the SCALED_UP_HOST
:port
looks like in the <Location> xml
element in the FusionVirtualHost_fs.conf
file
<Location /homepage> SetHandler weblogic-handler WebLogicCluster <PROVISIONED_HOST:port>,<SCALED_UP_HOST:port>, <SCALED_OUT_HOST:port> WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine On RewriteOptions inherit </Location>
Restart Oracle HTTP Server on both WEBHOST1
and all other web-tier hosts, where applicable.
Log in to the domain's Oracle WebLogic Server Administration Console and start the SCALED_UP_MGD_SERVER_n
Managed Server. Begin with n
=1.
Access the URL of the application deployed to the SCALED_UP_MGD_SERVER
from a different machine to verify that routing and failover are functioning properly.
Close all browser windows then open a new one to ensure that the Oracle Fusion Applications login window displays correctly. The URL for the HomePage
Managed Server for example, is:
https://
domain
external.mycompany.com/homePage/faces/AtkHomePageWelcome
Log in to the domain's Oracle WebLogic Server Administration Console and stop the SCALED_UP_MGD_SERVER_n
Managed Server started in Step 3.
Repeat Steps 3 through 5 for the other instances of the SCALED_UP_MGD_SERVER
.
After completing validation, start all instances of SCALED_UP_MGD_SERVER
.
Before performing the procedures in this section, ensure that CommonDomain and its Managed Servers are running.
To add a Managed Server and assign it to SCALED_UP_HOST
:
Log in to the Administration Server: http://
domain_name
internal
.mycompany.com/console
.
Navigate to Domain_Name, Environment, Servers.
Switch to Lock & Edit mode.
Select the Managed_Servers checkbox (for example, soa_server1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - soa_server
n
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Increase the total number of instances of soa_server
in this domain by one and use that number to replace n
at the end of the server name. Oracle recommends following the Oracle SOA Suite server naming convention soa_server
n
.
Server Listen Address - <SCALED_UP_HOST
>
Server Listen Port - Give an unused port on the machine SCALED_UP_HOST
Click OK.
Navigate back to Domain_Name. See the newly cloned SOA server, soa_server
n
.
Do the following:
Click soa_servern.
From the General tab, select Advanced and then select the WebLogic Plug-In Enabled checkbox.
Click Save and then Activate Changes.
Run the newly created Managed Servers:
Navigate to Domain_Name.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to Domain_Name.
Check the newly created Managed Servers and click Start.
Navigate to Domain_Name and check the State to verify that the newly created Managed Servers are running.
Log in to the Administration Server once again (http://
domain_name
internal
.mycompany.com/console
) and verify that all the Managed Servers, including scaled-up servers, are running.
Do the following:
Switch to Lock & Edit mode.
Select the Managed_Server checkbox (for example, soa_servern).
Select the Server Start tab.
Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:
-DJDBCProgramName\=DS/CommonDomain/soa_servern
-Dserver.group\=SOACluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
Change the extended logging format fields to the following:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save.
Click Activate Changes.
Restart the Managed Server for the changes to take affect.
Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the domain's SOACluster.
To verify the URLs:
Log in to the domain's Oracle WebLogic Server Administration Console and stop all the instances of soa_server
currently running in SCALED_UP_HOST
, PROVISIONED_HOST
, and SCALED_OUT_HOST
, where applicable. (Also stop soa_server
n
that are just added.)
Do the following:
Edit the FusionVirtualHost_
domain
.conf
file where domain
takes the value of fs
(Common domain), crm
, fin
, hcm
, ic
, scm
, and so on, depending on the domain used.
If the SCALED_UP_HOST
's host and port do not already exist in the/soa/composer
entry, complete Steps b and c. Otherwise, skip to Step 3.
Locate/soa/composer
in the file. Add the value SCALED_UP_HOST
:port
to the WebLogicCluster property. Note that there are two parts, internal and external, in the FusionVirtualHost_
domain
.conf
file on WEBHOST
. The SCALED_UP_HOST
:port
must be added to both the internal and external parts. If scaling out web tier to WEBHOST2
and others, do the same on these hosts as well.
The following is an example of scaling up the HomePage
Managed Server, and what the SCALED_UP_HOST
:port
looks like in the <Location> xml
element in the FusionVirtualHost_fs.conf
file
<Location /homepage> SetHandler weblogic-handler WebLogicCluster <DOMAINHOSTSOAVH1:port>, <DOMAINHOSTSOAVH2:port> WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine On RewriteOptions inherit </Location>
Restart Oracle HTTP Server on both WEBHOST1
and all other web-tier hosts, where applicable.
Log in to the domain's Oracle WebLogic Server Administration Console and start the soa_server
n
Managed Server. Begin with n
=1.
Access the URL http://
domain_name
internal.mycompany.com/soa-infra
to verify that routing and failover are functioning properly.
Close all browser windows then open a new one to ensure that the Oracle Fusion Applications login window displays correctly.
Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_server
n
Managed Server started in Step 3.
Repeat Steps 3 through 5 for the other instances of the soa_server
n
.
After completing validation, start all instances of soa_server
n
.
The procedure in this section allows to increase the number of instances of system components, such as Oracle Business Intelligence server, Oracle Business Intelligence Presentation Services server, and Oracle Business Intelligence Java host, on SCALED_UP_HOST
. (Note that it is not necessary to run multiple Oracle Business Intelligence servers on SCALED_UP_HOST
.)
Before performing the procedure, ensure that BIDomain and its Managed Server and system components are running in an existing host (referred to as SCALED_UP_HOST
), where it is either a PROVISIONED_HOST
or SCALED_OUT_HOST
.
This section describes the additional scale-out steps required for the soa_server1
and soa_server2
servers on PROVISIONED_HOST
and SCALED_OUT_HOST
.
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 file on the shared folder. During a node failure, the Oracle SOA Suite server must be moved to a targeted node 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.
For Java Database Connectivity (JDBC), each Oracle SOA Suite Managed Server in a cluster uses a dedicated table per server on a database using the shared data source connection. During a node failure, the Oracle SOA Suite server must be moved to a targeted node to run the same server using the exact JDBC store and transaction log.
Perform the procedures in this section for the Oracle SOA Suite servers in all domains except the BIDomain, which has no Oracle SOA Suite servers.
For Oracle Fusion Applications, the Oracle SOA Suite virtual IPs PROVISIONED_HOST
and SCALED_OUT_HOST
are called DOMAINHOSTSOAVH1
and DOMAINHOSTSOAVH2
.
where
DOMAIN
is replaced with the domain-specific syntax. For example, CRMSOAVH1
, CRMSOAVH2
, FINSOAVH1
, HCMSOAVH1
, ICSOAVH1
, PROJSOAVH1
, and so on.
When scaling out the Oracle SOA Suite server, add new Managed Servers configured to new nodes.
Before beginning, ensure the following:
SCALED_OUT_HOST
Node Manager has been started in the Secure Sockets Layer (SSL) mode
Start with a clean machine if it is the first time it is being used for a scale out
The UNIX /etc/hosts
file has proper entries. To verify this from the clean machine, ping the hosts listed in /etc/hosts
files with the fully qualified name of the hosts.
The user created on SCALED_OUT_HOST
should the same as the user on PROVISIONED_HOST
The directory structure APPLICATIONS_BASE
is mounted on SCALED_OUT_HOST
, and is the same shared file system as used by PROVISIONED_HOST
The directory structure APPLICATIONS_CONFIG
on SCALED_OUT_HOST
has been created
The initial deployment on PROVISIONED_HOST
has already been done and verified by provisioning
Since the PROVISIONED_HOST
domain directory file system is also available from SCALED_OUT_HOST
, both the pack
and unpack
commands can be executed from the SCALED_OUT_HOST
.
To pack and unpack the Managed Server domain home:
To add a Managed Server and assign it to SCALED_OUT_HOST
:
Log in to the Administration Server: http://
domain_name
internal
.mycompany.com/console
.
Navigate to Domain_Name, Environment, Servers.
Switch to Lock & Edit mode.
Select the Managed_Server checkbox (for example, soa_server1) and then click Clone.
Specify the following Server Identity attributes:
Server Name - soa_server3
To ensure consistency in naming, copy the name of the server shown in Server Identity and paste it into the Server Name field. Then change the number to "3".
Server Listen Address - <SCALED_OUT_HOST
>
Server Listen Port - leave "as is"
Click OK.
Navigate back to Domain_Name, Environment, Servers. See the newly cloned server, soa_server3
.
Click soa_server3 and change the following attributes:
Machine - <SCALED_OUT_HOST
>
Cluster Name - accept the default, SOACluster
Ensure that this cluster name is the same as the cluster name of the original Managed Server.
From soa_server3, click Advanced and then select the WebLogic Plug-In Enabled checkbox.
Click Save.
Select the Keystores tab, and then ensure that the keystores value is Custom Identity and Custom Trust.
Do the following:
Change the Custom Identity Keystore path to point to the APPLICATIONS_BASE
/fusionapps/wlserver_10.3/server/lib/
SCALED_OUT_HOST
_fusion_identity.jks
file.
Leave the Custom Identity Keystore type blank.
Change the Custom Identity Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Create the Identity Keystore on SCALED_OUT_HOST.
Re-enter the Confirm Custom Identity Keystore Passphrase.
Ensure that the Confirm Custom Trust Keystore path is pointing to the APPLICATIONS_BASE
/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks
file.
Leave the Custom Trust Keystore type blank.
Change the Custom Trust Keystore Passphrase entry. This should be the same as the keystorepassword field described in the first bullet in Step 4 in Creating the Identity Keystore on SCALED_OUT_HOST.
Re-enter the Custom Trust Keystore Passphrase.
Click Save.
Select the SSL tab.
Make sure that Identity and Trust Locations is set to Keystores.
Change the Private Key Alias to SCALED_OUT_HOST_fusion
.
Change the Private Key Passphrase to the keypassword, as described in the second bullet in Step 4 in Creating the Identity Keystore on SCALED_OUT_HOST.
Re-enter the keypassword from Step c for the Confirm Private Key Passphrase.
Click Save.
Select the Server Start tab.
Change the Arguments to reflect the name of the cloned Managed Server and make sure the server group is the correct cluster name. For example, the following should be seen:
-DJDBCProgramName\=DS/domain_nameDomain/soa_server3
-Dserver.group\=SOACluster
Click Save.
Select the Logging tab, and then select the HTTP tab.
Do the following:
Change the Log file name to logs/access.log.%yyyyMMdd%
.
Change the rotation type to By Time.
Leave the Limit number of retained files option unchecked.
Leave the Rotate log file on startup option unchecked.
Click Save.
Expand Advanced.
Change the format to Extended.
Change the extended logging format fields to the following:
date time time-taken cs-method cs-uri sc-status sc(X-ORACLE-DMS-ECID) cs(ECID-Context) cs(Proxy-Remote-User) cs(Proxy-Client-IP)
Click Save.
Click Activate Changes.
Run the newly created Managed Server:
Navigate to Domain_Name, Environment.
From the Navigation pane on the Oracle WebLogic Server console, select Activate Changes.
Navigate to Domain_Name, Environment, Servers, Control.
Check the newly created Managed Server and click Start.
Navigate to Domain_Name, Environment, Servers, and check the State to verify that the newly created Managed Servers are running.
Verify URLs to ensure that the appropriate routing and failover is working from Oracle HTTP Server to the domain's SOACluster.
To verify the URLs:
Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_server1
Managed Server on PROVISIONED_HOST
while the Managed Servers on SCALED_OUT_HOST
are running.
Do the following:
Edit the FusionVirtualHost
file, adding the scaled-out soa_server3
Managed Server's host and port.
Add the code shown in the following example to both the Internal and External part of the FusionVirtualHost
file on WEBHOST1
and WEBHOST2
.
<Location /soa/composer> SetHandler weblogic-handler WebLogicCluster <DOMAINHOSTSOAVH1:port>,<DOMAINHOSTSOAVH2:port>, WLProxySSL ON WLProxySSLPassThrough ON RewriteEngine On RewriteOptions inherit </Location>
Restart Oracle HTTP Server on both WEBHOST1
and WEBHOST2
.
Access http://
domain_name
internal.mycompany.com/soa-infra
to verify that routing and failover are functioning properly. (Ensure the log in prompt is visible.)
Log in to the domain's Oracle WebLogic Server Administration Console and stop the soa_server3
Managed Server on SCALED_OUT_HOST
.
Start the soa_server1
Managed Server on PROVISIONED_HOST
.
Repeat Step 3. (Ensure the log in prompt is visible.)
Start the soa_server3
Managed Server on SCALED_OUT_HOST
and verify that soa_server1
and soa_server3
are running.
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 DOMAINHOSTSOAVH1
and DOMAINHOSTSOAVH2
VIPs are used.
To enable the virtual IP on Linux:
On PROVISIONED_HOST
:
(UNIX) 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
(UNIX only) Enable the 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:
UNIX:
/bin/ping 100.200.140.206
Ensure to have performed the steps described in Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST, and the scale-out steps described in Add a New Machine In the Oracle WebLogic Server Console, Pack and Unpack the Managed Server Domain Home to SCALED_OUT_HOST, and Clone Managed Servers and Assign Them to SCALED_OUT_HOST before setting the soa_server
n
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_servern in the table. The Setting page for soa_server
n
is displayed.
Set the Listen Address to DOMAINHOSTSOAVH1
.
Click Save.
Click Activate Changes.
The changes do not take effect until the soa_server
n
Managed Server is restarted (ensure that Node Manager is up and running):
On the Summary of Servers page, select the Control tab.
Select soa_servern in the table and then click Shutdown.
After the server has shut down, select soa_servern 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, set the WebLogicCluster parameter to the list of nodes in the cluster.
The FusionVirtualHost
configuration file uses specific file-naming conventions. For information about these conventions, see Table 18-1 in Configure Oracle HTTP Server.
To set the parameter:
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 there is a two-node cluster and add a third member is added, it is not necessary to update the configuration to add the third member. The third member will be discovered dynamically at runtime.
Example 2: There is a three-node cluster, but only two nodes are listed in the configuration. However, if both listed nodes are down when Oracle HTTP Server is started, then the plug-in would fail to route to the cluster. Ensure that at least one of the listed nodes is running when Oracle HTTP Server is started.
If all the members of the cluster are listed, then guarantee it is possible to 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 Overview of Oracle WebLogic Server Proxy Plug-In in the Oracle Fusion Middleware Using Oracle WebLogic Server Proxy Plug-Ins 12.2.1.2 guide.
After PROVISIONED_HOST
has been provisioned, Oracle User Messaging Service is fully configured with UMSAQJMSForeignServer
in the UMSAQJMSSystemResource
JMS Module, and the Oracle Advanced Queuing (AQ-JMS) Foreign Server is deployed over the Oracle SOA Suite Cluster.
No additional JMS configuration is required for the scaled-out server host.
Although UMSJMSServer_auto_1
is configured with the UMSJMSFileStore_auto_1
file persistence deployed over the soa_server1
Managed Server, they are not being used by Oracle Fusion Applications.
After PROVISIONED_HOST
has been provisioned, the Java Message Service (JMS) servers are set up and configured and Java Database Connectivity (JDBC) stores are created and fully configured for PROVISIONED_HOST
. Create and configure now the JMS servers and JDBC stores for SCALED_OUT_HOST_HOST
.
Do the following to create and configure the JMS servers and JDBC stores for SCALED_OUT_HOST
:
Although deploying composites uses multicast communication by default, Oracle recommends using unicast communication instead in SOA enterprise deployments. Use unicast to disable multicast communication for security reasons.
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, specify the nodes that belong to the cluster. It is not necessary to specify all of the nodes of a cluster, however. It is only necessary to specify enough nodes so that a new node added to the cluster can discover one of the existing nodes. Consequently, 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, 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 (DOMAINHOSTSOAVH1
and DOMAINHOSTSOAVH2
). 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.
DOMAINHOSTSOAVH1
is the virtual host name that maps to the virtual IP where soa_server1
is listening (in PROVISIONED_HOST
). DOMAINHOSTSOAVH2
is the virtual host name that maps to the virtual IP where soa_server2
is listening (in SCALED_OUT_HOST
).
To add the host name used by Oracle Coherence:
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.
By default, the Oracle Coherence cluster uses port 8088 for deployment. This port can be changed by specifying the -Dtangosol.coherence.wkaX.port
startup parameter. To avoid a port number conflict when configuring coherence parameters in different domains, ensure that port 8089 increments by 1, or choose the next free port in this sequence.
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.
Each server has a transaction log that stores information about committed transactions that are coordinated by the server that may not have been completed. Oracle 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.
To set the location for the transaction log store:
Log in to the Oracle WebLogic Server Administration Console (http://
domain_name
internal.mycompany.com/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 appears.
Click the server name soa_server2 (represented as a hyperlink) in the table. The Settings page for the selected server appears, and defaults to the Configuration tab.
In the Configuration tab, click the Services tab.
In the Transaction Log Store section of the page, do the following:
For the type, change the dropdown list selection from Default Store to JDBC.
For the data store, select SOALocalTxDataSource from dropdown list.
For prefix name, enter DOMAIN
_FUSION_SOAINFRA.TLOG_soa_server2_
. (Do not forget to include the ending "_".)
The prefix name is specific for each domain.
Oracle Fusion Customer Relationship Management domain: CRM_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Financials domain: FIN_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Common domain: SETUP_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Incentive Compensation domain: OIC_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Human Capital Management domain: HCM_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Supply Chain Management domain: SCM_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Project Portfolio Management domain: PRJ_FUSION_SOAINFRA.TLOG_soa_server2_
Oracle Fusion Procurement domain: PRC_FUSION_SOAINFRA.TLOG_soa_server2_
When the JDBC transaction log store configuration is complete, and after bouncing the soa_server2
server, do the following:
Append the table name in the prefix name with WLStore
. For example, TLOG_soa_server2_WLStore
.
Verify that the new table, TLOG_soa_server2_WLStore
, has been created in DOMAIN
_FUSION_SOAINFRA
.
Click Save and then click Activate Changes.
Restart the Managed Server to activate the changes (ensure that Node Manager is up and running):
Log in to the Oracle WebLogic Server Administration Console (http://
domain_name
internal.mycompany.com/console
).
In the Summary of Servers screen, select the Control tab.
Select soa_server2 in the table and then click Shutdown.
Start the soa_server2
server.
This step is required if the appropriate certificates are not set up 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 the server certificates have not been configured, errors are displayed during the management of the different Oracle WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again after the enterprise deployment topology configuration is complete.
To disable Host Name Verification:
To restart Node Manager on PROVISIONED_HOST
:
(UNIX only) 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:
PROVISIONED_HOST> ps -ef | grep NodeManager
orcl 9139 9120 0 Mar03 pts/6 00:00:00/bin/sh ./startNodeManager.sh
Run the following command:
PROVISIONED_HOST> kill -9 9139
Start Node Manager.
UNIX:
PROVISIONED_HOST> APPLICATIONS_CONFIG/nodemanager/PROVISIONED_HOST/startNodeManagerWrapper.sh
To start the soa_server1
Managed Server on PROVISIONED_HOST
:
Access the Administration Console. For example, http://
domain_name
internal.mycompany.com/console
.
Click Servers.
Open the Control tab.
Select soa_server1.
Click Start.
To validate the soa_server1
Managed Server on PROVISIONED_HOST
:
To restart Node Manager on SCALED_OUT_HOST
, follow the steps in Restart Node Manager on PROVISIONED_HOST.
This section describes how to configure and validate the Oracle WebLogic Server Administration Server for high availability.
The Administration Server is a singleton application, so it cannot be deployed in an active-active configuration. By default, the Administration Server is only available on the first installed node. If this node becomes unavailable, then the Administration Console and Fusion Middleware Control also become unavailable. To avoid this scenario, the Administration Server and the applications deployed to it must be enabled for failover. The enterprise deployment architecture in this guide calls for the deploying the Administration Server on a disk shared between the primary node and the secondary node.
The following domains are deployed as part of the Oracle Fusion Applications enterprise deployment implementation:
The list of domains may differ depending on the product offerings that are provisioned in the environment.
Oracle Fusion Customer Relationship Management Domain
Oracle Fusion Common Domain
Oracle Fusion Financials Domain
Oracle Fusion Human Capital Management Domain
Oracle Fusion Supply Chain Management Domain
Oracle Fusion Incentive Compensation Domain
Oracle Fusion Project Portfolio Management Domain
Oracle Fusion Procurement Domain
Oracle Business Intelligence Domain
The process described in this section initially deploys each domain-specific Administration Server in shared storage (APPLICATIONS_BASE
) mounted on PROVISIONED_HOST
, and Managed Servers in the local disk (APPLICATIONS_CONFIG
).
This section tells how to do the following:
Enable an administrative virtual host on PROVISIONED_HOST
Add a new machine in the Oracle WebLogic Server Console
Enable the Administration Server to listen on the virtual IP address
DOMAINADMINVH
is used as a generic name in this section.
where
DOMAIN
is replaced with the domain-specific syntax. For example, CRMADMINVH
, FINADMINVH
, HCMADMINCH
, and so on.
The Administration Server must be configured to listen on a virtual IP Address to enable it to seamlessly failover from one host to another. In a failure, the Administration Server, along with the virtual IP Address, can be migrated from one host to another.
However, before the Administration Server can be configured to listen on a virtual IP Address, one of the network interface cards on the host running the Administration Server must be configured to listen on this virtual IP Address. The steps to enable a virtual IP Address are completely dependent on the operating system.
To enable a virtual IP Address on PROVISIONED_HOST
:
In a UNIX environment, the command must be run as the root user.
Create a new machine and assign the Administration Server to the new machine using the Administration Console:
Ensure to have performed the steps described in Enable an Administrative Virtual Host on PROVISIONED_HOST before setting the Administration Server listen address.
To set the Administration Server listen address:
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 AdminServer(admin) in the table. The Settings page for AdminServer(admin) is displayed.
Set the listen address to DOMAINADMINVH
(domain-specific administrative virtual host).
Click Save.
Click Activate Changes.
The changes will not take effect until the Administration Server is restarted. Follow these steps to restart the Administration Server:
In the Summary of Servers page, select the Control tab.
Select AdminServer(admin) in the table and then click Shutdown.
Set the following environment variable.
UNIX:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=
APPLICATIONS_CONFIG/keystores/fusion_trust.jks"
Start the Administration Server again from the command line using the nmconnect
user name and password.
UNIX:
PROVISIONED_HOST> APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/bin/wlst.sh PROVISIONED_HOST> nmConnect(username='username', password='password', domainName='domain_name', host='DOMAINADMINVH',port='5556', nmType='ssl', domainDir='APPLICATIONS_CONFIG/domains/PROVISIONED_HOST/domain_name') PROVISIONED_HOST> nmStart('AdminServer') PROVISIONED_HOST> exit ()
To configure Oracle HTTP Server:
On WEBHOST1
:
(UNIX) Change directory to APPLICATIONS_CONFIG
/CommonDomain_webtier/config/OHS/ohs1/moduleconf
.
Edit the domain-specific virtual host config
file. For example:
UNIX:
cp FusionVirtualHost_domain.conf FusionVirtualHost_domain.conf.org
The FusionVirtualHost
configuration file uses specific file-naming conventions. For information about these conventions, see Table 18-1 in Configuring Oracle HTTP Server.
Edit the FusionVirtualHost
configuration file, adding the Administrative virtual host and port. Example 18-2 shows sample code.
Replace DOMAINADMINVH
and port with domain-specific Administrative virtual host and port number.
Restart Oracle HTTP Server:
UNIX:
Change directory to APPLICATIONS_CONFIG
/CommonDomain_webtier/bin
and enter the following:
WEBHOST1> ./opmnctl stopall WEBHOST1> ./opmnctl startall
Example 18-2 Add AdministrativeVirtual Host and Port
## Context roots for application em <Location /em> SetHandler weblogic-handler WebLogicCluster DOMAINADMINVH:port </Location> ## Context roots for application console <Location /console > SetHandler weblogic-handler WebLogicCluster DOMAINADMINVH:port </Location>
Perform these steps to ensure that the Administration Server and Oracle Enterprise Manager Fusion Middleware Control are properly configured:
Ensure to have access the domain-specific Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control. For example:
http://
domain_name
internal.mycompany.com/console
http://
domain_name
internal.mycompany.com/em
After completing the steps in Configuring Administration Server High Availability for other domains, repeat Step 1 for other domains by replacing the domain-specific URL.
Do the following:
Log into Oracle Fusion Functional Setup Manager as a super user. The user should have the Oracle WebLogic Server Administrator role, for example, "FAadmin". Functional Setup Manager is located here:
https://commonexternal.mycompany.com/setup/faces/TaskListManagerTop
Select Register Domains in the left-hand task pane.
On the Register Domains page, select the domain to be updated and click Edit.
Do the following:
– Replace ADMIN_HOST
(the default value) with DOMAINADMINVH
wherever it appears.
– Update the value of Node Manager Protocol to ssl
.
– Ensure the value of Node Manager Port is 5556
.
Click Save and Close.
Repeat Step 3.a through Step 3.e for all domains except IDMDomain.
Replace the value of TAXONOMY_URL
in the fusion_env.properties
, fusion_prov.properties
, and atgpf_env.properties
files located in APPLICATIONS_CONFIG
/fapatch
with DOMAINADMINVH
if the Administration Server's listen address is updated with the virtual IP (VIP) for CommonDomain.
The changes do not take effect until the Administration Server is restarted. Follow these steps to restart the Administration Server:
In the Summary of Servers page, select the Control tab.
Select AdminServer(admin) in the table and then click Shutdown.
Set the following environment variable:
UNIX:
WLST_PROPERTIES="-Dweblogic.security.SSL.trustedCAKeyStore=
APPLICATIONS_CONFIG/keystores/fusion_trust.jks"
Start the Administration Server again from the command line using the nmconnect
user name and password.
UNIX:
PROVISIONED_HOST> APPLICATIONS_BASE/fusionapps/wlserver_10.3/common/bin/wlst.sh PROVISIONED_HOST> nmConnect(username='username', password='password', domainName='domain_name', host='DOMAINADMINVH',port='5556', nmType='ssl', domainDir='APPLICATIONS_CONFIG/domains/PROVISIONED_HOST/domain_name') PROVISIONED_HOST> nmStart('AdminServer') PROVISIONED_HOST> exit ()
Restart the Managed Servers:
Log in to the Oracle WebLogic Server Administration Console (http://
domain_name
internal.mycompany.com/console
).
Navigate to Domain_Name > Environment > Servers > Control.
Select all the Managed Servers and click Stop.
After all the servers have shut down, select all the servers in the table and then click Start.
In case a node fails, fail over the Administration Server to another node. This section describes how to fail over the Administration Server from PROVISIONED_HOST
to SCALED_OUT_HOST
.
Ensure the following:
The Administration Server is configured to listen on a domain-specific administrative virtual host, and not on any address
When failover happens, the Administration Server is failed over from PROVISIONED_HOST
to SCALED_OUT_HOST
and the two nodes have the following IPs:
PROVISIONED_HOST
: 100.200.140.165
SCALED_OUT_HOST
: 100.200.140.205
DOMAINADMINVH
: 100.200.140.206. This is the VIP where the domain-specific Administration Server is running, assigned to ethX:Y
, available in PROVISIONED_HOST
and SCALED_OUT_HOST
.
The domain directory where the Administration Server is running on PROVISIONED_HOST
is on shared storage and is mounted from SCALED_OUT_HOST
The following procedure explains how to fail over the Administration Server to a different node (SCALED_OUT_HOST
) with the Administration Server still using the same Oracle WebLogic Server machine. (This machine is a logical machine, not a physical one.)
To fail over the Administration Server:
Stop the Administration Server.
Migrate the IP to the second node:
Run the following command as root on PROVISIONED_HOST
to (where X:Y
is the current interface used by DOMAINADMINVH
):
PROVISIONED_HOST> /sbin/ifconfig ethX:Y down
Run the following command as root on SCALED_OUT_HOST
:
SCALED_OUT_HOST> /sbin/ifconfig interface:index IP_Address netmask netmask
For example:
/sbin/ifconfig eth0:1 100.200.140.206 netmask 255.255.255.0
Ensure that the netmask and interface to be used to match the available network configuration in SCALED_OUT_HOST
.
Update the routing tables with arping. For example, run the following command as root:
SCALED_OUT_HOST> /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
Validate that the address is available by pinging it from another node. For example:
/bin/ping 100.200.140.206
Start the Administration Server on SCALED_OUT_HOST
using the procedure in Enable an Administration Server to Listen on the Virtual IP Address.
Test access to the Administration Server on SCALED_OUT_HOST
:
Ensure that it is possible to access the domain-specific Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control. For example, for the Oracle Fusion Customer Relationship Management domain, use these URLs:
http://crminternal.mycompany.com/console
http://crminternal.mycompany.com/em
Repeat Step 6.a for other domain by replacing the domain-specific URL.
The Administration Server does not use Node Manager for failing over. After a manual failover, the machine name that appears in the Current Machine field in the Administration Console for the server is PROVISIONED_HOST
, and not the failover machine, SCALED_OUT_HOST
. Since Node Manager does not monitor the Administration Server, the machine name that appears in the Current Machine field, is not relevant and can be ignored.
Ensure that the Oracle WebLogic Server Administration Server can be failed back, that is, stop it on SCALED_OUT_HOST
and run it on PROVISIONED_HOST
. To do this, migrate DOMAINADMINVH
back to PROVISIONED_HOST
node.
To migrate DOMAINADMINVH
:
Stop the Administration Server on SCALED_OUT_HOST
.
Run the following command as root from SCALED_OUT_HOST
to shut down the network stack virtual interface:
SCALED_OUT_HOST> /sbin/ifconfig ethX:Y down
Run the following command as root from PROVISIONED_HOST
to restart the virtual interface:
PROVISIONED_HOST> /sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Ensure that the netmask and interface to be used match the available network configuration in PROVISIONED_HOST
.
Run the following command from PROVISIONED_HOST
to update the routing tables through arping:
PROVISIONED_HOST> /sbin/arping -q -U -c 3 -I eth0 100.200.140.206
Validate that the address is available by pinging it from another node. For example:
/bin/ping 100.200.140.206
Start the Administration Server again on PROVISIONED_HOST
using the procedure in Enable an Administration Server to Listen on the Virtual IP Address.
Test access to the Administration Server on PROVISIONED_HOST
:
Ensure that it is possible to access the domain-specific Oracle WebLogic Server Administration Console and Oracle Enterprise Manager Fusion Middleware Control. For example, for the Oracle Fusion Customer Relationship Management domain, use these URLs:
http://crminternal.mycompany.com/console
http://crminternal.mycompany.com/em
Repeat Step 7.a for other domain by replacing the domain-specific URL.
This section describes how to configure server migration according to Oracle Fusion Applications recommendations.
Before migrating Oracle Fusion Applications domains, ensure to have done the following for all Managed Servers needing to be migrated:
Enabled the Virtual IPs on PROVISIONED_HOST
and SCALED_OUT_HOST
. (See Enable Virtual IPs on PROVISIONED_HOST and SCALED_OUT_HOST.)
Set the listen address for the soa_server
n
Managed Servers. (See Set the Listen Address for soa_servern.)
The procedures in this section apply to these domains and applications:
Oracle SOA Suite in the Oracle Fusion Customer Relationship Management domain
Oracle SOA Suite in the Oracle Fusion Financials domain
Oracle SOA Suite and Oracle WebCenter Content: Imaging in the Oracle Fusion Common domain
Oracle Fusion Common domain
Oracle SOA Suite in the Oracle Business Intelligence domain
Oracle SOA Suite in the Oracle Fusion Human Capital Management domain
Oracle SOA Suite in the Oracle Fusion Supply Chain Management domain
Oracle SOA Suite in the Oracle Fusion Project Portfolio Management domain
Oracle SOA Suite in the Oracle Fusion Procurement domain
Oracle SOA Suite in the Oracle Incentive Compensation domain
The list of domains may differ depending on the product offerings that are provisioned in the environment.
The procedures described in this section must be performed for various components of the topology (for example, web tier, application tier, database tier). Variables are used in this section to distinguish between component-specific items:
WLS_SERVER1 and WLS_SERVER2 refer to the managed Oracle WebLogic Servers for the enterprise deployment component
PROVISIONED_HOST and SCALED_OUT_HOST refer to the host machines for the enterprise deployment component
CLUSTER refers to the cluster associated with the enterprise deployment component
The values to be used to these variables are provided in the component-specific sections in this guide.
In this enterprise topology, configure server migration for the WLS_SERVER1
and WLS_SERVER2
Managed Servers. The WLS_SERVER1
Managed Server is configured to restart on SCALED_OUT_HOST
should a failure occur. The WLS_SERVER2
Managed Server is configured to restart on PROVISIONED_HOST
should a failure occur. For this configuration, the WLS_SERVER1
and WLS_SERVER2
servers listen on specific floating IP addresses that are failed over by Oracle WebLogic Server migration. Configuring server migration for the Oracle WebLogic Servers consists of the following steps:
Step 1: Set up a user and tablespace for the server migration leasing table
Step 2: Create a multi-data source using the Oracle WebLogic Server Administration Console
Step 3: Edit Node Manager's properties file
Step 4: Set environment and superuser privileges for the wlsifconfig
script
Step 5: Configure server migration targets
Step 6: Test the server migration
The first step is to set up a user and tablespace for the server migration leasing table.
If other servers in the same domain have already been configured with server migration, the same tablespace and data sources can be used. In that case, the data sources and multi-data source for database leasing do not need to be re-created, but they have to be retargeted to the cluster being configured with server migration.
To set up a user and tablespace:
Create a tablespace called 'leasing'. For example, log on to SQL*Plus as the sysdba user and run the following command:
SQL> create tablespace leasing logging datafile
'DB_HOME/oradata/orcl/leasing.dbf'
size 32m autoextend on next 32m maxsize 2048m extent management local;
Create a user named leasing
and assign to it the leasing tablespace:
SQL> create user leasing identified by password;
SQL> grant create table to leasing;
SQL> grant create session to leasing;
SQL> alter user leasing default tablespace leasing;
SQL> alter user leasing quota unlimited on LEASING;
Create the leasing table using the leasing.ddl
script:
Copy the leasing.ddl
file located in either the APPLICATIONS_BASE
/fusionapps/wlserver_10.3/server/db/oracle/817
or the APPLICATIONS_BASE
/fusionapps/wlserver_10.3/server/db/oracle/920
directory to the database node.
Connect to the database as the leasing user.
Run the leasing.ddl
script in SQL*Plus:
SQL> @Copy_Location/leasing.ddl;
The second step is to create a multi-data source for the leasing table from the Oracle WebLogic Server Administration Console. Create a data source to each of the Oracle RAC database instances during the process of setting up the multi-data source, both for these data sources and the global leasing multi-data source.
Please note the following considerations when creating a data source:
Make sure that this is a non-XA data source
The names of the multi-data sources are in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on
Use Oracle's Driver (Thin) Version 9.0.1, 9.2.0, 10, 11
Use Supports Global Transactions, One-Phase Commit, and specify a service name for the database
Target these data sources to the cluster assigned to the enterprise deployment component
Creating a Multi-Data Source
To create a multi-data source:
In the Domain Structure window in the Oracle WebLogic Server Administration Console, click the Data Sources link.
Click Lock & Edit.
Select Multi Data Source from the New dropdown list.
The Create a New JDBC Multi Data Source page is displayed.
Enter leasing
as the name.
Enter jdbc/leasing
as the JNDI name.
Select Failover as algorithm (default).
Click Next.
Select the cluster that must be migrated. In this case, SOA cluster.
Click Next.
Select non-XA driver (the default).
Click Next.
Click Create a New Data Source.
Enter leasing-rac0
as the name. Enter jdbc/leasing-rac0
as the JNDI name. Enter oracle
as the database type. For the driver type, select Oracle Driver (Thin) for Oracle RAC Service-Instance connections, Versions 10 and later.
When creating the multi-data sources for the leasing table, enter names in the format of <MultiDS>-rac0, <MultiDS>-rac1, and so on.
Click Next.
Deselect Supports Global Transactions.
Click Next.
Enter the following for the leasing schema:
Service Name: The service name of the database.
Database Name: The Instance Name for the first instance of the Oracle RAC database.
Host Name: The name of the node that is running the database. For the Oracle RAC database, specify the first instance's VIP name or the node name as the host name.
Port: The port number for the database (1521).
Database User Name: Enter leasing
.
Password: The leasing password.
Click Next.
Click Test Configuration and verify that the connection works.
Click Next.
Target the data source to the cluster assigned to the enterprise deployment component (CLUSTER).
Click Finish.
Click Create a New Data Source for the second instance of the Oracle RAC database, target it to the cluster assigned to the enterprise deployment component (CLUSTER), repeating the steps for the second instance of the Oracle RAC database.
Add leasing-rac0
and leasing-rac1
to the multi-data source.
Make sure the initial connection pool capacity of the data sources is set to 0 (zero). In the Datasources screen do the following:
Select Services, then select Datasources.
Click Datasource Name, then click the Connection Pool tab.
Enter 0
(zero) in the Initial Capacity field.
Click Save, then click Activate Changes.
The third step is to edit Node Manager's properties file, which is located at:
APPLICATIONS_CONFIG/nodemanager/PROVISIONED_HOST APPLICATIONS_CONFIG/nodemanager/SCALED_OUT_HOST
This must be done for the node managers in both nodes where server migration is being configured. For example:
Interface=eth0 NetMask=255.255.255.0 UseMACBroadcast=true
Interface: This property specifies the interface name for the floating IP (for example, eth0
).
Do not specify the sub-interface, such as eth0:1
or eth0:2
. This interface is to be used without:0
or:1
. Node Manager's scripts traverse the different :X-enabled IPs to determine which to add or remove. For example, the valid values in Linux environments are eth0
, eth1
, eth2
, eth3
, eth
n
, depending on the number of interfaces configured.
NetMask: This property specifies the net mask for the interface for the floating IP. The net mask should the same as the net mask on the interface; 255.255.255.0 is used as an example in this document.
UseMACBroadcast: This property specifies whether to use a node's MAC address when sending ARP packets, that is, whether to use the -b
flag in the arping
command.
Verify in Node Manager's output (shell where Node Manager is started) that these properties are being used, or problems may arise during migration. Something like this should be seen in Node Manager's output:
... StateCheckInterval=500 Interface=eth0 NetMask=255.255.255.0 ...
The steps below are not required if the server properties (start properties) have been properly set and Node Manager can start the servers remotely.
Set the following property in the nodemanager.properties
file:
StartScriptEnabled: Set this property to 'true'. This is required for Node Manager to start the Managed Servers using start scripts.
(UNIX only) On PROVISIONED_HOST
and SCALED_OUT_HOST
, restart Node Manager:
Run the startNodeManagerWrapper.sh
script, which is located in the APPLICATIONS_CONFIG
/nodemanager/
PROVISIONED_HOST
and APPLICATIONS_CONFIG
/nodemanager/
SCALED_OUT_HOST_HOST
directories.
The fourth step, for UNIX only, is to set environment and superuser privileges for the wlsifconfig.sh
script.
Ensure that the PATH is set with the environment variables in the terminal from where Node Manager is started, and that it includes these files:
Table 18-5 Files Required for the PATH Environment Variable
File | Located in these directories |
---|---|
wlsifconfig.sh |
|
wlscontrol.sh |
|
nodemanager.domains |
|
Grant sudo
configuration for the wlsifconfig.sh
script.
Configure sudo
to work without a password prompt.
For security reasons, sudo
should be restricted to the subset of commands required to run the wlsifconfig.sh
script. For example, perform these steps to set the environment and superuser privileges for the wlsifconfig.sh
script:
Grant sudo
privilege to the Oracle WebLogic Server user (oracle
) with no password restriction, and grant execute privilege on the /sbin/ifconfig
and /sbin/arping
binaries.
Make sure the script is executable by the Oracle WebLogic Server user (oracle
). The following is an example of an entry inside /etc/sudoers
granting sudo execution privilege for oracle
and also over ifconfig
and arping
:
oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping
Ask the system administrator for the sudo
and system rights as appropriate to this step.
The fifth step is to configure server migration targets. Assign first all the available nodes for the cluster's members and then specify candidate machines (in order of preference) for each server that is configured with server migration.
Enterprise deployment recommends using cluster-based migration. Perform the following steps, including a step to enable automatic server migration (Step 10), to configure cluster-based migration for all Managed Servers in a cluster:
Log in to the Oracle WebLogic Server Administration Console. For example, http://
domain_name
internal.mycompany.com
.
In the Domain Structure window, expand Environment and select Clusters. The Summary of Clusters page is displayed.
Click the cluster used to configure migration (CLUSTER) in the Name column of the table.
Click the Migration tab.
Click Lock & Edit.
In the Available field, select the machine to which to allow migration and click the right arrow. In this case, select PROVISIONED_HOST
and SCALED_OUT_HOST
.
When there are three (3) hosts, select all three.
Select the data source to be used for automatic migration. In this case, select the leasing data source.
Click Save.
Click Activate Changes.
Enable automatic server migration for all Managed Servers in the cluster (Perform this task for all of the Managed Servers).
Although cluster-based migration is used for the Managed Servers, perform this step (from the Migration tab) to enable automatic server migration for all the Managed Servers in the selected cluster.
In the Domain Structure window of the Oracle WebLogic Server Administration Console, expand Environment and select Servers.
Tip:
Click Customize this table in the Summary of Servers page and move Current Machine from the Available window to the Chosen window to view the machine on which the server is running. This is different from the configuration if the server gets migrated automatically.
Select the server used to configure cluster-based migration.
Click the Migration tab, and then click Lock & Edit.
Select Automatic Server Migration Enabled. This enables Node Manager to start a failed server on the target node automatically.
Click Save.
Click Activate Changes.
Restart the administration server, node managers, and the servers for which server migration has been configured.
The sixth and final step is to test the server migration. Perform these steps to verify that server migration is working properly:
From PROVISIONED_HOST:
Stop the WLS_SERVER1
Managed Server.
UNIX:
PROVISIONED_HOST> kill -9 pid
In the command, process_id
specifies the process ID of the Managed Server. To identify the pid
in the node:
UNIX:
PROVISIONED_HOST> ps -ef | grep WLS_SERVER1 | grep domain_name_SOACluster
Watch the Node Manager console. A message indicating that WLS_SERVER1
's floating IP has been disabled should be displayed.
Wait for Node Manager to try a second restart of WLS_SERVER1
. It waits for a fence period of 10 seconds before trying this restart.
After Node Manager restarts the server, stop it few times. Node Manager should now log a message indicating that the server will not be restarted again locally.
From SCALED_OUT_HOST:
Watch the local Node Manager console. Ten (10) seconds after the last try to restart WLS_SERVER1
on PROVISIONED_HOST
, Node Manager on SCALED_OUT_HOST
should prompt that the floating IP for WLS_SERVER1
is being brought up and that the server is being restarted in this node.
As an example, for Oracle SOA Suite Managed Servers, access the soa-infra console in the same IP.
Verification from the Administration Console
Migration can also be verified in the Administration Console:
To complete server migration in a cluster, perform the same steps on the second, third, and so on, managed servers.
If the Oracle Fusion Customer Relationship Management product offering has been installed, continue to Complete Oracle Fusion Customer Relationship Management Post-Installation Tasks . Otherwise, go to the section that corresponds to the product offering that is installed.