Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Portal 11g Release 1 (11.1.1.6.0) Part Number E12037-07 |
|
|
PDF · Mobi · ePub |
This chapter describes how to create a domain using the Configuration Wizard, Oracle WebLogic Server Administration Console, Oracle Enterprise Manager, and Oracle WSM Policy Manager. You can extend the domain to add WebCenter Portal components.
Note:
Before starting the setup process, read the Oracle Fusion Middleware Release Notes for additional installation and deployment information.
This chapter contains the following sections:
Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain"
Section 8.5, "Propagating the Domain Configuration to SOAHOST2"
Section 8.6, "Configuring Oracle HTTP Server for the WebLogic Domain"
Table 8-1 lists the steps for creating a WebLogic domain, including post-configuration tasks.
Table 8-1 Steps for Creating a WebLogic Domain
Step | Description | More Information |
---|---|---|
Enabling VIP1 in SOAHOST1 |
Enable a VIP1 for the SOAHOST1 hostname. |
|
Create a WebLogic Domain |
Run the Configuration Wizard to create WebLogic domain. |
Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain" |
Post-Configuration and Verification Tasks |
Follow the instructions for post-configuration and validation tasks. |
|
Propagate the Domain Configuration to SOAHOST2 |
Propagate the start scripts and classpath configuration from the Administration Server's domain directory to the managed server domain directory. |
Section 8.5, "Propagating the Domain Configuration to SOAHOST2" |
Configure the Oracle HTTP Server with the WebLogic domain |
Configure the Oracle HTTP Server with the WebLogic domain and validate the configuration. |
Section 8.6, "Configuring Oracle HTTP Server for the WebLogic Domain" |
Back Up the Domain |
Back up the newly configured WebLogic domain. |
Once this domain is created and configured you can extend the domain to include Oracle WebCenter Portal components, Oracle SOA Suite, Oracle WebCenter Content, and so on, described in the next chapters.
Please note that this step is required for failover of the Administration Server, regardless of whether or not SOA is installed.
You are associating the Administration Server with a virtual hostname (ADMINVHN). This Virtual Host Name must be mapped to the appropriate VIP (VIP1) either by a DNS Server or by a custom /etc/hosts
entry. Check that ADMINVHN is available according to your name resolution system, (DNS server, /etc/hosts), in the required nodes in your SOA topology. The VIP (VIP1) that is associated to this Virtual Host Name (ADMINVHN) must be enabled in SOAHOST1.
To enable the virtual IP on Linux:
Run the ifconfig
command as root:
/sbin/ifconfig interface:index IPAddress netmask netmask /sbin/arping -q -U -c 3 -I interface IPAddress
For example:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Enable your network to register the new location of the virtual IP, for example:
/sbin/arping -q -U -c 3 -I ethX 100.200.140.206
Validate that the address is available by pinging it from another node, for example:
/bin/ping 100.200.140.206
In this example 'ethX' is the ethernet interface (eth0 or eth1) and Y is the index (0, 1, 2,).
Run the Configuration Wizard from the ORACLE_COMMON_HOME directory to create a domain containing the Administration Server and Oracle Web Services Manager. Later, you will extend the domain to contain WebCenter Portal, SOA, and WebCenter Content components.
To create a domain:
Ensure that the database where you installed the repository is running. For Oracle RAC databases, all instances should be running, so that the validation check later in the procedure is more reliable.
On SOAHOST1, change directory to the location of the Configuration Wizard:
cd ORACLE_COMMON_HOME/common/bin
Start the Oracle Fusion Middleware Configuration Wizard:
./config.sh
In the Welcome screen, select Create a New WebLogic Domain, and click Next.
The Select Domain Source screen appears (Figure 8-1).
In the Select Domain Source screen, do the following:
Select Generate a domain configured automatically to support the following products.
Select the following products:
Basic WebLogic Server Domain - 10.3.6.0 [wlserver_10.3] (this should be selected automatically)
Oracle Enterprise Manager - 11.1.1.0 [oracle_common]
Oracle WSM Policy Manager 11.1.1.0 [oracle_common]
Oracle JRF - 11.1.1.0 [oracle_common] (this should be selected automatically)
If you accidentally deselect some of the targets, make sure that the following selections are made in this screen:
Oracle Enterprise Manager
Oracle WSM Policy Manager
Oracle JRF
Click Next.
Note:
If multiple Oracle Homes are installed (for example a WebCenter Portal Home and a SOA Home), available products will show up for both homes. In this step, select only products from the WebCenter Portal home (wc). This is indicated by brackets at the end of the product name; for example, "Oracle JRF - 11.1.1.0 [wc]."
In the Specify Domain Name and Location screen, enter the domain name (wcpedg_domain).
Make sure that the domain directory matches the directory and shared storage mount point recommended in Chapter 3, "Preparing the Network for an Enterprise Deployment".
For the domain directory, enter:
ORACLE_BASE/admin/domain_name/aserver
For the application directory, enter (this directory should be in shared storage):
ORACLE_BASE/admin/domain_name/aserver/applications
Click Next.
In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator.
Click Next.
In the Configure Server Start Mode and JDK screen, do the following:
For WebLogic Domain Startup Mode, select Production Mode.
For JDK Selection, select JROCKIT SDK1.6.0_<version>.
Click Next.
In the Configure JDBC Components Schema screen, do the following:
Select the OWSM MDS schema.
For the RAC configuration, you can select Convert to GridLink or Convert to RAC multi data source (described in Appendix A, "Using Multi Data Sources with Oracle RAC").
For the instructions given here, select Convert to GridLink.
Click Next.
The Configure Gridlink RAC Component Schema screen displays (Figure 8-2).
Figure 8-2 Configure GridLink RAC Component Schema
In this screen enter values for the following fields, specifying the connect information for the Oracle RAC database that was seeded with RCU:
Driver: Select Oracle's driver (Thin) for GridLinkConnections,Versions:10 and later.
Service Name: Enter the service name of the Oracle RAC database in lowercase letters, followed by the domain name. For example, wcpedg.mycompany.com
.
Username: Enter the complete user name (including the prefix) for the database schema owner of the corresponding component.
Password: Enter the password for the database schema owner.
Select Enable FAN.
Make sure Enable SSL is unchecked (alternatively if SSL is selected for ONS notifications to be encrypted, provide the appropriate wallet and wallet password).
Service listener: Enter the Oracle Single Client Access Name (SCAN) address and port for the Oracle RAC database being used. The protocol should be TCP
.
Oracle recommends that you use SCAN addresses to specify the Service Listener (and OSN Host) so you do not need to update a GridLink data source containing SCAN addresses if you add or remove Oracle RAC nodes. To determine the SCAN address, query the remote_listener
parameter in the database using the TCP protocol:
SQL>show parameter remote_listener; NAME TYPE VALUE ----- ------ ------- remote_listener string db-scan.mycompany.com:1521
Note:
For database versions that do not support SCAN:
For Oracle Database 11g Release 1 (11.1), enter the Virtual IP and port of each database's instance listener, for example:
custdbhost1-vip.mycompany.com (Port 1521)
and
custdbhost2-vip.mycompany.com (Port 1521)
For Oracle Database 10g, use multi data sources to connect to an Oracle RAC database. For information about configuring multi data sources see Appendix A, "Using Multi Data Sources with Oracle RAC".
ONS Host: Enter the SCAN address for the Oracle RAC database and the ONS remote port, as reported by the database:
[orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016
Note:
For Oracle Database 11g Release 1 (11.1), enter the host name and port for the database's ONS service. For example:
custdbhost1.mycompany.com (Port 6200)
and
custdbhost2.mycompany.com (Port 6200)
In the Test JDBC Data Sources screen, the connections should be tested automatically. The Status column displays the results. Ensure that all connections were successful. If not, click Previous to return to the previous screen and correct your entries.
Click Next when all the connections are successful.
In the Select Advanced Configuration screen, select the following:
Administration Server
Managed Servers, Clusters and Machines
Deployment and Services
Click Next.
In the Configure the Administration Server screen, enter the following values:
Name: AdminServer
Listen Address: enter ADMINVHN.
Listen Port: 7001
SSL listen port: N/A
SSL enabled: unchecked
Click Next.
In the Configure Managed Servers screen, click Add to add the following managed servers:
Table 8-2 Managed Servers
Name | Listen Address | Listen Port | SSL Listen Port | SSL Enabled |
---|---|---|---|---|
WLS_WSM1 |
SOAHOST1 |
7010 |
n/a |
No |
WLS_WSM2 |
SOAHOST2 |
7010 |
n/a |
No |
Click Next.
In the Configure Clusters screen, Click Add to add the following clusters:
Table 8-3 Clusters
Name | Cluster Messaging Mode | Multicast Address | Multicast Port | Cluster Address |
---|---|---|---|---|
WSM-PM_Cluster |
unicast |
n/a |
n/a |
Leave it empty. |
Click Next.
In the Assign Servers to Clusters screen, assign servers to clusters as follows:
WSM-PM_Cluster:
WLS_WSM1
WLS_WSM2
Click Next.
In the Configure Machines screen, do the following:
Click the Unix Machine tab and then click Add to add the following machines:
Note:
"Name" can be any unique string. "Node Manager Listen Address" must be a resolvable host name.
Table 8-4 Machines
Name | Node Manager Listen Address |
---|---|
SOAHOST1 |
SOAHOST1 |
SOAHOST2 |
SOAHOST2 |
ADMINHOST |
localhost |
Leave all other fields to their default values.
Click Next.
In the Assign Servers to Machines screen, assign servers to machines as follows:
SOAHOST1: WLS_WSM1
SOAHOST2: WLS_WSM2
ADMINHOST: AdminServer
Click Next.
In the Target Deployments to Clusters or Servers screen, make sure that the wsm-pm application is targeted to the WSM-PM_Cluster only. Make sure that all other deployments are targeted to the AdminServer. Click Next.
In the Target Services to Clusters or Servers screen, select the following:
On the left, select WSM-PM_Cluster. On the right, select JDBC System Resource (this automatically selects all the wsm datasources (mds-owsm)).
On the left, select Admin Server. On the right, select JDBC System Resource (this automatically selects all the wsm datasources (mds-owsm)).
All JDBC system resources should be targeted to both the Admin Server and WSM-PM_Cluster.
Make sure that all the remaining services are targeted to the Admin Server.
Click Next.
In the Configuration Summary screen, click Create.
In the Create Domain screen, click Done.
After configuring the domain with the Configuration Wizard, follow these instructions for post-configuration and verification.
The section includes the following topics:
Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1"
Section 8.4.3, "Starting the Administration Server on SOAHOST1"
Section 8.4.4, "Validating GridLink Data Source Configuration"
Section 8.4.5, "Validating the Administration Server Configuration"
Section 8.4.7, "Applying the Java Required Files (JRF) Template to the WSM-PM_Cluster"
Section 8.4.9, "Starting and Validating the WLS_WSM1 Managed Server"
Create a boot.properties
file for the Administration Server on SOAHOST1. This is a required step that enables you to start the Administration Server using Node Manager.
To create a boot.properties
file for the Administration Server:
Create the following directory structure:
mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
In a text editor, create a file called boot.properties
in the last directory created in the previous step, and enter the following lines in the file:
username=Admin_Username password=Password
Note:
When you start the Administration Server, the username and password entries in the file get encrypted. You start the Administration Server in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
For security reasons, you want to minimize the time the entries in the file are left unencrypted: after you edit the file, you should start the server as soon as possible so that the entries get encrypted.
Save the file and close the editor.
If you are starting Node Manager for the first time, set the StartScriptEnabled
property to 'true', and then start Node Manager using startNodeManager.sh
.
To start Node Manager on SOAHOST1:
Before starting Node Manager for the first time, run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled
property to 'true':
cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh
Note:
You must set the StartScriptEnabled
property to avoid class loading failures and other problems; you only need to do this once.
Start Node Manager:
cd WL_HOME/server/bin
export JAVA_OPTIONS="-DDomainRegistrationEnabled=true"
./startNodeManager.sh
Note:
It is important that you set -DDomainRegistrationEnabled=true
whenever a Node Manager is started that must manage the AdminServer. This is due to the fact that the AdminServer domain home does not exist in the Node Manager Domains file and you must use dynamic registration of the domain. Oracle does not recommend using this parameter except in the case specified here.
If there is no AdminServer on this machine and this machine is not an AdminServer failover node, you should start the Node Manager as:
./startNodeManager.sh
The Administration Server is started and stopped using Node Manager. However, the first start of the Administration Server with Node Manager, requires changing the defaulted username and password that are set for Node Manager by the Configuration Wizard. Therefore, use the start script for the Administration Server for the first start.
Steps 1-4 are required for the first start operation, subsequent starts require only step 4.
To start the Administration Server using Node Manager:
Start the Administration Server using the start script in the domain directory on SOAHOST1:
cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin ./startWebLogic.sh
Use the Administration Console to update the Node Manager credentials.
In a browser, go to the following URL;
http://ADMINVHN:7001/console
Log in as the administrator.
Click Lock & Edit.
Click domain_name, Security, General, and then expand the Advanced options at the bottom.
Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.
Save and activate the changes.
Stop the Administration Server process by using CTRL-C in the shell where it was started, or by process identification and kill in the operating system.
Start WLST and connect to Node Manager with nmconnect and the credentials set in the previous steps and start the Administration Server using nmstart.
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
Once you are in the WLST shell:
wls:/offline>nmConnect("Admin_User","Admin_Password", "SOAHOST1","5556","domain_name","/ORACLE_BASE/admin/domain_name/aserver/domain_name") wls:/nm/domain_name nmStart("AdminServer")
Note:
This username and password are used only to authenticate connections between Node Manager and clients. They are independent of the server admin ID and password and are stored in the nm_password.properties
file located in the following directory:
ORACLE_BASE/admin/domain_name/aserver/domain_name/config/nodemanager
When the servers are started, verify that the GridLink data sources are correctly configured for the MDS schema and that the ONS setup is correct. Perform this procedure for every GridLink data source created.
To validate the GridLink data source configuration:
Log on to the Oracle WebLogic Administration Console.
In the Domain Structure tree, expand Services, and select Data Sources.
Click one of the new data sources.
Click the Testing tab, select one of the servers, and click Test Data Source.
Click the Monitoring tab and select on one of the servers.
Click the ONS tab, and then click the Testing tab.
Select the server and click Test ONS.
If both tests are successful, the configuration is correct. If the ONS test fails, verify that the ONS service is running in the RAC database nodes:
orcl@db-scan1 ~]$ srvctl status scan_listener SCAN Listener LISTENER_SCAN1 is enabled SCAN listener LISTENER_SCAN1 is running on node db-scan1 SCAN Listener LISTENER_SCAN2 is enabled SCAN listener LISTENER_SCAN2 is running on node db-scan2 SCAN Listener LISTENER_SCAN3 is enabled SCAN listener LISTENER_SCAN3 is running on node db-scan2 [orcl@db-scan1 ~]$ srvctl config nodeapps -s ONS exists: Local port 6100, remote port 6200, EM port 2016 [orcl@db-scan1 ~]$ srvctl status nodeapps | grep ONS ONS is enabled ONS daemon is running on node: db-scan1 ONS daemon is running on node: db-scan2
Run the ONS test from every WebLogic server that uses the data source.
To ensure that the Administration Server for the domain you have created is properly configured, validate the configuration by logging into the Oracle WebLogic Server Administration Console and verifying the managed servers and the cluster are listed, and log into Oracle Enterprise Manager.
To verify that the Administration Server is properly configured:
In a browser, go to the following URL:
http://ADMINVHN:7001/console
Log in as the administrator.
Verify that the WLS_WSM1 and WLS_WSM2 managed servers are listed.
Verify that WSM-PM_Cluster is listed.
Check that you can access Oracle Enterprise Manager at the following URL:
http://ADMINVHN:7001/em
Log in to Enterprise Manager Console with the username and password you specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."
Use the pack
and unpack
commands to separate the domain directory used by the Administration Server from the domain directory used by the managed server in SOAHOST1 as recommended in Chapter 4, "Preparing the File System for an Enterprise Deployment."
Before running the unpack script, be sure the ORACLE_BASE
/admin/
domain_name
/mserver
directory exists as explained in Chapter 4, "About Recommended Locations for the Different Directories."
To create a separate domain directory:
Run the pack command on SOAHOST1 to create a template pack as follows:
SOAHOST1> cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=wcdomaintemplate.jar -template_name=wcdomaintemplate
Run the unpack command on SOAHOST1 to unpack the template in the managed server domain directory as follows:
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Note:
You must have write permissions on the /ORACLE_BASE/admin/domain_name directory before running the unpack command. For example, the directory:
/ORACLE_BASE/admin/wcpedg_domain/
After the domain is created with the Configuration Wizard, you must target a number of resources not included in the WebLogic server installation to the WSM-PM_Cluster.
To target these resources:
Log in to Oracle Enterprise Manager Fusion Middleware Control with the username and password you specified in Section 8.4.1, "Creating boot.properties for the Administration Server on SOAHOST1."
On the navigation tree on the left, expand Farm_domain_name, WebLogic Domain, and then domain_name, and select WSM-PM_Cluster.
Click Apply JRF Template on the right.
Wait for the confirmation message to appear on the screen.
This message should confirm that the JRF Template has been successfully applied to the WSM-PM_Cluster cluster.
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 11, "Setting Up Node Manager for an Enterprise Deployment"). If you have not configured the server certificates, you receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the Enterprise Deployment topology configuration is complete as described in Chapter 11, "Setting Up Node Manager for an Enterprise Deployment."
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select AdminServer(admin) in the Names column of the table. The Settings page for AdminServer(admin) appear.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Click Save.
Repeat steps 4 to 8 for the WLS_WSM1 server.
Save and activate the changes.
Restart the Administration Server for the changes to take effect:
In the Summary of Servers screen, select the Control tab.
Select AdminServer(admin) in the table and then click Shutdown.
Start the Administration Server again using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
After configuring the managed server, start it and check to confirm that it is running properly. You can start the managed server and check its status by using the Oracle WebLogic Server Administration Console.
To start the WLS_WSM1 managed server and check that it is configured correctly:
Start the WLS_WSM1 managed server using the Oracle WebLogic Server Administration Console as follows:
Expand the Environment node in the Domain Structure window.
Choose Servers. The Summary of Servers page appears.
Click the Control tab.
Select WLS_WSM1 and then click Start.
Verify that the server status is reported as Running in the Admin 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. See Section 16.8, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.
Access the following URL:
http://SOAHOST1:7010/wsm-pm
Click Validate Policy Manager.
If the configuration is correct, a list of policies and assertion templates available in the data store appear. If the configuration is not correct, no policies or assertion templates appear.
After completing the configuration of SOAHOST1, propagate the configuration to SOAHOST2 using the unpack utility, and then validate the propagated configuration.
This section includes the following topics:
Section 8.5.1, "Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility"
Section 8.5.2, "Disabling Host Name Verification for the WLS_WSM2 Managed Server"
Section 8.5.4, "Starting and Validating the WLS_WSM2 Managed Server"
Section 8.5.5, "Configuring the Java Object Cache for Oracle WSM"
Propagate the domain configuration using the unpack utility. Before running the unpack script, be sure the following directory exists as explained in Section 4.3, "About Recommended Locations for the Different Directories".
ORACLE_BASE/admin/domain_name/mserver
To propagate the domain configuration:
Run the following command on SOAHOST1 to copy the template file created previously.
cd ORACLE_COMMON_HOME/common/bin
scp wcdomaintemplate.jar oracle@SOAHOST2:/ORACLE_COMMON_HOME/common/bin
Run the unpack
command from the ORACLE_COMMON_HOME/common/bin
directory, not from the WL_HOME/common/bin
directory on SOAHOST2 to unpack the propagated template.
cd ORACLE_COMMON_HOME/common/bin ./unpack.sh -domain=ORACLE_BASE/admin/domain_name/mserver/domain_name -template=wcdomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 11, "Setting Up Node Manager for an Enterprise Deployment"). If you have not configured the server certificates, you will receive errors when managing the different WebLogic Servers. To avoid these errors, disable host name verification while setting up and validating the topology, and enable it again once the Enterprise Deployment topology configuration is complete as described in Chapter 11, "Setting Up Node Manager for an Enterprise Deployment."
To disable host name verification:
Log in to Oracle WebLogic Server Administration Console.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers. The Summary of Servers page appears.
Select WLS_WSM2 in the Names column of the table. The Settings page for AdminServer(admin) appear.
Click the SSL tab.
Click Advanced.
Set Hostname Verification to None.
Save and activate the changes.
Once you have propagated the domain configuration and disabled host name verification, start Node Manager using the StartNodeManager.sh
script.
To start Node Manager on SOAHOST2:
Run the setNMProps.sh script, which is located in the ORACLE_COMMON_HOME/common/bin directory, to set the StartScriptEnabled
property to 'true' before starting Node Manager:
cd ORACLE_COMMON_HOME/common/bin ./setNMProps.sh
Note:
You must use the StartScriptEnabled
property to avoid class loading failures and other problems.
Start Node Manager:
cd WL_HOME/server/bin ./startNodeManager.sh
Use the Administration Console to start and validate the WLS_WSM2 managed server.
To start the WLS_WSM2 managed server and check that it is configured correctly:
Start the WLS_WSM2 managed server using the Administration Console.
Verify that the server status is reported as Running in the Admin 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. See Section 16.8, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.
Access the following URL:
http://SOAHOST2:7010/wsm-pm
Click validate policy manager.
The Java Object Cache (JOC) should be configured among all the servers running Oracle WSM. This local cache is provided to increase the performance of Oracle WSM.
The Java Object Cache can be configured using the configure-joc.py script in the following directory:
MW_HOME/oracle_common/bin/
This is a Python script which can be used to configure JOC in the managed servers. The script runs in WLST online mode and expects the Administration Server to be running.
When configuring JOC ports for Oracle products, Oracle recommends using ports in the 9988 to 9998 range.
Note:
After configuring the Java Object Cache using the wlst commands or configure-joc.py script, all affected managed servers should be restarted for the configurations to take effect.
To configure the Java Object Cache for Oracle WSM:
Connect to the Administration Server using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
MW_HOME/wc/common/bin/wlst.sh
$ connect()
Enter the Oracle WebLogic Administration user name and password when prompted.
After connecting to the Administration Server using wlst
, start the script using the execfile
command, for example:
wls:/mydomain/serverConfig>execfile("MW_HOME/oracle_common/bin/configure-joc.py")
Configure JOC for all the managed servers for a given cluster.
Enter 'y' when the script prompts whether you want to specify a cluster name, and also specify the cluster name and discover port, when prompted. This discovers all the managed servers for the given cluster and configure the JOC. The discover port is common for the entire JOC configuration across the cluster. For example:
Do you want to specify a cluster name (y/n) <y> Enter Cluster Name : WSM-PM_Cluster Enter Discover Port : 9991
Here is a walkthrough for using configure-joc.py
for HA environments:
execfile("MW_HOME/oracle_common/bin/configure-joc.py") . Enter Hostnames (eg host1,host2) : SOAHOST1,SOAHOST2 . Do you want to specify a cluster name (y/n) <y>y . Enter Cluster Name : WSM-PM_Cluster . Enter Discover Port : 9991 . Enter Distribute Mode (true|false) <true> : true . Do you want to exclude any server(s) from JOC configuration (y/n) <n> n
The script can also be used to perform the following JOC configurations:
Configure JOC for all specified managed servers.
Enter 'n' when the script prompts whether you want to specify a cluster name, and also specify the managed server and discover port, when prompted. For example:
Do you want to specify a cluster name (y/n) <y>n Enter Managed Server and Discover Port (eg WLS_WSM1:9998, WLS_WSM1:9998) : WLS_WSM1:9991,WLS_WSM2:9991
Exclude JOC configuration for some managed servers.
The script allows you to specify the list of managed servers for which the JOC configuration "DistributeMode" will be set to 'false'. Enter 'y' when the script prompts whether you want to exclude any servers from JOC configuration, and enter the managed server names to be excluded, when prompted. For example:
Do you want to exclude any server(s) from JOC configuration (y/n) <n>y Exclude Managed Server List (eg Server1,Server2) : WLS_WSM1,WLS_WSM3
Disable the distribution mode for all managed servers.
The script allows you to disable the distribution to all the managed servers for a specified cluster. Specify 'false' when the script prompts for the distribution mode. By default, the distribution mode is set to 'true'.
Verify JOC configuration using the CacheWatcher utility. See Oracle Fusion Middleware High Availability Guide.
You can configure the Java Object Cache (JOC) using the HA Power Tools tab in the Oracle WebLogic Administration Console as described in the Oracle Fusion Middleware High Availability Guide.
This section describes tasks for configuring Oracle HTTP Server for the WebLogic Domain, and for verifying the configuration.
This section includes the following topics:
Section 8.6.2, "Turning on the WebLogic Plug-In Enabled Flag"
Section 8.6.3, "Registering Oracle HTTP Server With WebLogic Server"
Section 8.6.5, "Validating Access Through Oracle HTTP Server"
Section 8.6.6, "Manually Failing Over the Administration Server to SOAHOST2"
Section 8.6.7, "Validating Access to SOAHOST2 Through Oracle HTTP Server"
Section 8.6.8, "Failing the Administration Server Back to SOAHOST1"
To enable Oracle HTTP Server to route to the Administration Server and the WSM-PM_Cluster, which contain the WLS_WSMn managed servers, you must set the WebLogicCluster
parameter to the list of nodes in the cluster.
The servers specified in the WebLogicCluster
parameter are only important at startup time for the plug-in. The list needs to provide at least one running cluster member for the plug-in to discover other members of the cluster. Note that 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.
Some example scenarios:
Example 1: If you have a two-node cluster and then add a third member, you do not need to update the configuration to add the third member. The third member will be discovered on the fly at runtime.
Example 2: You have a three-node cluster but only two nodes are listed in the configuration. However, if both listed nodes are down when you start Oracle HTTP Server, then the plug-in would fail to route to the cluster. You must ensure that at least one of the listed nodes is running when you start Oracle HTTP Server.
If you list all members of the cluster, then you guarantee you can route to the cluster, assuming at least one member is running when Oracle HTTP Server is started.
For more information on configuring the WebLogic Server plug-in, see the Oracle Fusion Middleware Using Web Server Plug-Ins with Oracle WebLogic Server guide.
To set the WebLogicCluster parameter:
On WEBHOST1 and WEBHOST2, add lines to the mod_wl_ohs.conf
file located in the following directory:
ORACLE_BASE/admin/instance_name/config/OHS/component_name/
Add the following lines:
# The admin URLs should only be accessible via the admin virtual host NameVirtualHost *:7777 <VirtualHost *:7777> ServerName admin.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # Admin Server and EM <Location /console> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 </Location> <Location /consolehelp> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 </Location> <Location /em> SetHandler weblogic-handler WebLogicHost ADMINVHN WeblogicPort 7001 </Location> </VirtualHost> # Virtual host entry for external https URL configured at the Load Balancer <VirtualHost *:7777> ServerName https://wcp.mycompany.com:443 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit # WSM-PM <Location /wsm-pm> SetHandler weblogic-handler WebLogicCluster SOAHOST1:7010,SOAHOST2:7010 WLProxySSL ON WLProxySSLPassThrough ON </Location> </VirtualHost> # Virtual host entry for internal http URL <VirtualHost *:7777 <VirtualHost *:7777> ServerName wcpinternal.mycompany.com:80 ServerAdmin you@your.address RewriteEngine On RewriteOptions inherit </VirtualHost>
Note:
Values such as 7777
, admin.mycompany.com:80
, and you@your.address
that are noted in this document serve as examples only. Enter values based on the actual environment.
Restart Oracle HTTP Server on both WEBHOST1 and WEBHOST2.
WEBHOST1> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs1 WEBHOST2> ORACLE_BASE/admin/instance_name/bin/opmnctl restartproc ias-component=ohs2
For security purposes, and since the load balancer terminates SSL request (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), once you configure SSL for the load balancer, turn on the WebLogic plug-in enabled flag for the domain.
To turn on the WebLogic plug-in enabled flag:
Log on to the Administration Console.
Click on the domain name in the navigation tree on the left.
Click on the Web Applications tab.
Click Lock & Edit.
Select the WebLogic Plugin Enabled check box.
Save and activate the changes.
Once an Oracle WebLogic domain is created, the Oracle web tier can be linked to the domain. The advantage of doing this is that the Oracle web tier can be managed and monitored using Oracle Enterprise Manager Fusion Middleware Control.
To associate the Oracle web tier with the WebLogic domain use the following commands:
WEBHOST1> cd ORACLE_BASE/admin/instance_name/bin
WEBHOST1> ./opmnctl registerinstance -adminHost ADMINVHN -adminPort 7001 -adminUsername weblogic
You must also run this command from WEBHOST2 for OHS2.
After registering Oracle HTTP Server, it should appear as a manageable target in the Oracle Enterprise Manager Console. To verify this, log in to the Enterprise Manager Console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.
When you access the Oracle WebLogic Server Administration Console using a load balancer, changing the Administration Server's frontend URL is required so that the user's browser is redirected to the appropriate load balancer address.
The Oracle WebLogic Server Administration Console application tracks changes made to ports, channels and security using the console. When changes made through the console are activated, the console validates its current listen address, port and protocol. If the listen address, port and protocol are still valid, the console redirects the HTTP request replacing the host and port information with the Administration Server's listen address and port.
To change the Administration Server's frontend URL:
Log in to Oracle WebLogic Server Administration Console.
Click Lock & Edit.
Expand the Environment node in the Domain Structure window.
Click Servers to open the Summary of Servers page.
Select Admin Server in the Names column of the table. The Settings page for AdminServer(admin) appears.
Click the Protocols tab.
Click the HTTP tab.
Set the Frontend Host to admin.mycompany.com
and the Frontend HTTP Port to 80 (modify accordingly if HTTPS is used for the admin URL).
Save and activate the changes.
Disable tracking on configuration changes in the Oracle WebLogic Server Administration Console so that the console does not trigger the reload of configuration pages when activation of changes occurs.
Log in to the Oracle WebLogic Server Administration Console.
Click the preferences link in the banner.
Click the shared preferences tab.
Deselect the follow configuration changes check box.
Note:
If you have any issues activating any configuration changes after modifying the Frontend Host and Port settings, then refer to Section 16.8.2, "Redirecting of Users to Login Screen After Activating Changes in Administration Console."
Verify that the server status is reported as Running in the Admin 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. See Section 16.8, "Troubleshooting Oracle WebCenter Portal Enterprise Deployments" for possible causes.
Validate WSM-PM_Cluster through both Oracle HTTP Servers using the following URLs:
http://WEBHOST1:7777/wsm-pm
http://WEBHOST2:7777/wsm-pm
http://WEBHOST1:7777/console
http://WEBHOST2:7777/console
http://WEBHOST1:7777/em
http://WEBHOST2:7777/em
https://wcp.mycompany.com/wsm-pm
http://admin.mycompany.com/console
http://admin.mycompany.com/em
After setting the frontend URL to the load balancer address, access to the console through the WEBHOSTn addresses will be redirected by the console to the frontend URL, thus validating the correct configuration of both Oracle HTTP Server and the load balancer.
For information on configuring system access through the load balancer, see Section 3.3, "Configuring the Load Balancer."
After the registering Oracle HTTP Server as described in Section 8.6.3, "Registering Oracle HTTP Server With WebLogic Server," the Oracle HTTP Server should appear as a manageable target in the Oracle Enterprise Manager Console. To verify this, log into the Enterprise Manager Console. The WebTier item in the navigation tree should show that Oracle HTTP Server has been registered.
In case a node fails, you can fail over the Administration Server to another node. This section describes how to fail over the Administration Server from SOAHOST1 to SOAHOST2.
Assumptions:
The Administration Server is configured to listen on ADMINVHN, and not on ANY address. See step 14 in Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain".
These procedures assume that the two nodes use two individual domain directories, and that the directories reside in local storage or in shared storage in different volumes.
The Administration Server is failed over from SOAHOST1 to SOAHOST2, and the two nodes have these IPs:
SOAHOST1: 100.200.140.165
SOAHOST2: 100.200.140.205
ADMINVHN: 100.200.140.206. This is the VIP where the Administration Server is running, assigned to ethX:Y, available in SOAHOST1 and SOAHOST2.
The domain directory where the Administration Server is running in SOAHOST1 is on a shared storage and is mounted also from SOAHOST2.
Oracle WebLogic Server and Oracle Fusion Middleware components have been installed in SOAHOST2 as described in Section 6, "Installing the Software for an Enterprise Deployment" (that is, the same paths for ORACLE_HOME and MW_HOME that exist on SOAHOST1 are also available on SOAHOST2).
The following procedure shows how to fail over the Administration Server to a different node (SOAHOST2), but the Administration Server will still use the same WebLogic Server machine (which is a logical machine, not a physical machine).
To fail over the Administration Server to SOAHOST2:
Stop the Administration Server.
Migrate IP to the second node.
Run the following command as root on SOAHOST1 (where X:Y is the current interface used by ADMINVHN):
/sbin/ifconfig ethX:Y down
Run the following command on SOAHOST2:
/sbin/ifconfig interface:index IP_Address netmask netmask
For example:
/sbin/ifconfig eth0:1 10.0.0.1 netmask 255.255.255.0
Note:
Ensure that the netmask and interface to be used to match the available network configuration in SOAHOST2.
Update routing tables through arping
, for example:
SOAHOST2> /sbin/arping -b -A -c 3 -I eth0 10.0.0.1
Start the Administration Server on SOAHOST2 using the procedure inSection 8.4.3, "Starting the Administration Server on SOAHOST1.".
Test that you can access the Administration Server on SOAHOST2 as follows:
Ensure that you can access the Oracle WebLogic Server Administration Console using the following URL:
http://ADMINVHN:7001/console
Check that you can access and verify the status of components in the Oracle Enterprise Manager using the following URL:
http://ADMINVHN:7001/em
Note:
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 SOAHOST1, and not the failover machine, SOAHOST2. Since Node Manager does not monitor the Administration Server, the machine name that appears in the Current Machine field, is not relevant and you can ignored it.
Perform the same steps as in Section 8.6.5, "Validating Access Through Oracle HTTP Server". This is to check that you can access the Administration Server when it is running on SOAHOST2.
This step checks that you can fail back the Administration Server, that is, stop it on SOAHOST2 and run it on SOAHOST1 by migrating ADMINVHN back to SOAHOST1 node.
To migrate ADMINVHN back to SOAHOST1:
Make sure the Administration Server is not running.
Run the following command on SOAHOST2.
/sbin/ifconfig ethZ:N down
Run the following command on SOAHOST1:
/sbin/ifconfig ethX:Y 100.200.140.206 netmask 255.255.255.0
Note:
Ensure that the netmask and interface to be used match the available network configuration in SOAHOST1
Update routing tables through arping. Run the following command from SOAHOST1.
/sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
Start the Administration Server again on SOAHOST1 using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."
cd ORACLE_BASE/admin/domain_name/aserver/domain_name/bin ./startWebLogic.sh
Test that you can access the Oracle WebLogic Server Administration Console using the following URL:
http://ADMINVHN:7001/console
Check that you can access and verify the status of components in the Oracle Enterprise Manager using the following URL:
http://ADMINVHN:7001/em
Perform a backup to save your domain configuration. Make sure you stop the server first. The configuration files are located in the following directory:
ORACLE_BASE/admin/domain_name
To back up the domain configuration, run the following command on SOAHOST1:
tar -cvpf edgdomainback.tar ORACLE_BASE/admin/domain_name
Back up the Instance Home on the web tier using the following command:
tar -cvpf BACKUP_LOCATION/web_instance_name.tar ORACLE_INSTANCE