| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) Part Number E12036-10 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1) Part Number E12036-10 |
|
|
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 SOA components and, optionally, Oracle Business Activity Monitoring.
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 ADMINVHN 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 SOA components, Oracle BAM, or Oracle BAM as 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 virtual IP (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 virtual IP (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 SOA 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.
Change directory to the location of the Configuration Wizard. This is within the SOA home directory. From SOAHOST1:
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]
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.
In the Specify Domain Name and Location screen, enter the domain name (soaedg_domain).
Make sure that the domain directory matches the directory and shared storage mount point recommended in Chapter 4, "About Recommended Locations for the Different Directories." Enter the following for the domain directory:
ORACLE_BASE/admin/domain_name/aserver/
And the following for the application directory. 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 Oracle RAC configuration for component schemas, select Convert to GridLink.
Click Next.
The Configure Gridlink RAC Component Schema screen appears (Figure 8-2).
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 database using lowercase characters. For example:
soaedg.mycompany.com.
Username: Enter the database schema owner name 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 SCAN address and port for the RAC database being used. You can identify this address by querying the appropriate 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 Oracle Database 11g Release 1 (11.1), use the virtual IP and port of each database's instance listener, for example:
custdbhost1-vip.mycompany.com (port 1521)
and
custdbhost2-vip.mycompany.com (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), use the hostname and port of each database's ONS service, for example
custdbhost1.mycompany.com (port 6200)
and
custdbhost2.mycompany.com (6200)
In the Test JDBC Data Sources screen, the connections are 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 the WSM-PM_Cluster as follows:
WLS_WSM
WLS_WSM2
Click Next.
In the Configure Machines screen, 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.
Note:
The machine name does not need to be a valid host name or listen address; it is just a unique identifier of a Node Manager location
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 and 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.
This 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.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=<adminuser> 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.
To start Node Manager on SOAHOST1, set the StartScriptEnabled property to 'true,' and then start Node Manager using startNodeManager.sh.
To start Node Manager on SOAHOST1:
Run the setNMProps.sh script located in the following directory:
ORACLE_COMMON_HOME/common/bin
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. For more information, see also Section 16.13.5, "Incomplete Policy Migration After Failed Restart of SOA Server."
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 that manages the AdminServer is started. If there is no AdminServer on this machine and this machine is not an AdminServer failover node, you can start the Node Manager using the following command from SOAHOAST1:
./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) tab, 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.
Click Save and Activate 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 OS.
Start WLST and connect to Node Manager with nmconnect and the credentials set in the previous steps and start the Administration Server using nmstart. Enter the Node Manager Username and password that you entered in step 2e.
cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
Once you are in the WLST shell:
wls:/offline>nmConnect('nodemanager_username','nodemanager_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 and that the ONS setup is correct. Perform this procedure for every GridLink data source created.
To validate the GridLink data sources 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 Monitoring tab and select one of the servers.
Click the Statistics tab and select 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 datasource.
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 the WSM-PM_Cluster cluster is listed.
Check that you can access Oracle Enterprise Manager at the following URL:
http://ADMINVHN:7001/em
Log in to EM 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 following directory exists as explained in Section 4.3, "About Recommended Locations for the Different Directories."
ORACLE_BASE/admin/domain_name/mserver
To create a separate domain directory:
Run the pack command on SOAHOST1 to create a template pack as follows:
cd ORACLE_COMMON_HOME/common/bin ./pack.sh -managed=true -domain=ORACLE_BASE/admin/domain_name/aserver/domain_name -template=soadomaintemplate.jar -template_name=soa_domain_template
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=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Note:
You must have write permissions on the following directory before running the unpack command:
/ORACLE_BASE/admin/domain_name
For example:
ORACLE_BASE/admin/soaedg_domain/
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
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.
Repeat the steps for the Administration Server.
Expand Farm_<domain_name>, WebLogic Domain, and then <domain_name>, and select Admin server.
This step is required because you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server (see Chapter 13, "Setting Up Node Manager for an Enterprise Deployment"). Because 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 13, "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.
To restart the Administration Server:
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.13, "Troubleshooting the Topology in an Enterprise Deployment" 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 soadomaintemplate.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=soadomaintemplate.jar -app_dir=ORACLE_BASE/admin/domain_name/mserver/applications
Note:
The configuration steps provided in this enterprise deployment topology are documented with the assumption that a local (per node) domain directory is used for each managed server.
This step is required if you have not set up the appropriate certificates to authenticate the different nodes with the Administration Server, as described in Chapter 13, "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 13, "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.
You must use the StartScriptEnabled property to avoid class loading failures and other problems. See also Section 16.13.5, "Incomplete Policy Migration After Failed Restart of SOA Server."
To start Node Manager on SOAHOST2:
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.13, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Access the following URL:
http://SOAHOST2:7010/wsm-pm
Click validate policy manager.
Configure the Java Object Cache (JOC) among all the servers running Oracle WSM. This procedure is optional, but increases the performance of Oracle WSM by keeping a local cache instead of having to search for a cache.
Use JOC for MDS updates in B2B if you are planning to change the delivery channels for B2B agreements frequently.
Configure the Java Object Cache using the configure-joc.py script in the following directory:
MW_HOME/oracle_common/bin/
This is a Python script that runs in WLST online mode and expects the Administration Server to be up and running.
Use ports in the 9988 to 9998 range when configuring JOC ports for Oracle products.
To configuring the Java Object Cache for Oracle WSM:
Connect to the Administration Server on SOAHOST1 using the command-line Oracle WebLogic Scripting Tool (WLST), for example:
MW_HOME/soa/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
After configuring the Java Object Cache using the wlst commands or configure-joc.py script, restart all affected managed servers for the configurations to take effect.
The script can also be used to perform the following optional 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, "Verifying Manual Failover of the Administration Server"
Section 8.6.6.2, "Validating Access to SOAHOST2 Through Oracle HTTP Server"
Section 8.6.6.3, "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.
To set the WebLogicCluster parameter:
On WEBHOST1 and WEBHOST2, add directives to the admin_vh.conf and soainternal_vh.conf files located in the following directory:
ORACLE_BASE/admin/instance_name/config/OHS/component_name/moduleconf
Note that this assumes you created the admin_vh.conf and soainternal_vh.conf files using the instructions in Section 7.6, "Defining Virtual Hosts."
Add the following directives to the admin_vh.conf file within the <VirtualHost> tags.
# 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>
The admin_vh.conf file will appear as it does in Example 8-1.
Add the following directives to the soainternal_vh.conf file within the <VirtualHost> tags:
# WSM-PM
<Location /wsm-pm>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1:7010,SOAHOST2:7010
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
The admin_vh.conf file will appear as it does in Example 8-2.
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
Example 8-1 admin_vh.conf file
# The admin URLs should only be accessible via the admin virtual host
<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>
Example 8-2 soainternal_vh.conf file
<VirtualHost *:7777>
ServerName soainternal.mycompany.com:80
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>
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.
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 the 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.13.14, "Redirecting of Users to Login Screen After Activating Changes in Administration Console."
To validate access through Oracle HTTP Server:
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.13, "Troubleshooting the Topology in an Enterprise Deployment" for possible causes.
Validate WSM-PM_Cluster through both Oracle HTTP Server 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://soa.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. The following sections provide the steps to verify the failover and failback of the Administration Server from SOAHOTS1 and 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 Virtual IP 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 Chapter 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)
This section contains the following topics:
Section 8.6.6.1, "Failing Over the Administration Server to a Different Node"
Section 8.6.6.2, "Validating Access to SOAHOST2 Through Oracle HTTP Server"
Section 8.6.6.3, "Failing the Administration Server Back to SOAHOST1"
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 a different node:
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:
/sbin/arping -q -U -c 3 -I eth0 10.0.0.1
Start the Administration Server on SOAHOST2 using the procedure in Section 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 -q -U -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
|
 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|