8 Creating a Domain for an Enterprise Deployment

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.1, "Overview of Creating a Domain"

• Section 8.2, "Enabling VIP1 in SOAHOST1"

• Section 8.3, "Running the Configuration Wizard on SOAHOST1 to Create a Domain"

• Section 8.4, "Post-Configuration and Verification Tasks"

• Section 8.5, "Propagating the Domain Configuration to SOAHOST2"

• Section 8.6, "Configuring Oracle HTTP Server for the WebLogic Domain"

• Section 8.7, "Backing Up the WebLogic Domain Configuration"

8.1 Overview of Creating a 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.	Section 8.2, "Enabling VIP1 in SOAHOST1"
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.	Section 8.4, "Post-Configuration and Verification 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.	Section 8.7, "Backing Up the WebLogic Domain Configuration"

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.

8.2 Enabling VIP1 in SOAHOST1

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:

1. 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
   

2. 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
   

3. 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,).

8.3 Running the Configuration Wizard on SOAHOST1 to Create a Domain

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:

1. 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.

2. On SOAHOST1, change directory to the location of the Configuration Wizard:

   cd ORACLE_COMMON_HOME/common/bin
   

3. Start the Oracle Fusion Middleware Configuration Wizard:

   ./config.sh
   

4. In the Welcome screen, select Create a New WebLogic Domain, and click Next.

5. The Select Domain Source screen appears (Figure 8-1).

   Figure 8-1 Select Domain Source Screen

   
   Description of "Figure 8-1 Select Domain Source Screen"
   
   

   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]."

6. 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
   

7. Click Next.

8. In the Configure Administrator Username and Password screen, enter the username and password to be used for the domain's administrator.

   Click Next.

9. 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.

10. In the Configure JDBC Components Schema screen, do the following:

    1. Select the OWSM MDS schema.

    2. 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.

    3. Click Next.

11. The Configure Gridlink RAC Component Schema screen displays (Figure 8-2).

    Figure 8-2 Configure GridLink RAC Component Schema

    
    Description of "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)

12. 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.

13. In the Select Advanced Configuration screen, select the following:

    • Administration Server

    • Managed Servers, Clusters and Machines

    • Deployment and Services

    Click Next.

14. 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.

15. 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.

16. 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.

17. In the Assign Servers to Clusters screen, assign servers to clusters as follows:

    • WSM-PM_Cluster:

      • WLS_WSM1

      • WLS_WSM2

    Click Next.

18. 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.

19. In the Assign Servers to Machines screen, assign servers to machines as follows:

    • SOAHOST1: WLS_WSM1

    • SOAHOST2: WLS_WSM2

    • ADMINHOST: AdminServer

    Click Next.

20. 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.

21. 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.

22. In the Configuration Summary screen, click Create.

23. In the Create Domain screen, click Done.

8.4 Post-Configuration and Verification Tasks

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.2, "Starting Node Manager 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.6, "Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server"

• Section 8.4.7, "Applying the Java Required Files (JRF) Template to the WSM-PM_Cluster"

• Section 8.4.8, "Disabling Host Name Verification for the Administration Server and the WLS_WSM1 Managed Server"

• Section 8.4.9, "Starting and Validating the WLS_WSM1 Managed Server"

8.4.1 Creating boot.properties for the Administration Server on SOAHOST1

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:

1. Create the following directory structure:

   mkdir -p ORACLE_BASE/admin/domain_name/aserver/domain_name/servers/AdminServer/security
   

2. 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.

3. Save the file and close the editor.

8.4.2 Starting Node Manager on SOAHOST1

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:

1. 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.

2. 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
   

8.4.3 Starting the Administration Server on SOAHOST1

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:

1. 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
   

2. Use the Administration Console to update the Node Manager credentials.

   1. In a browser, go to the following URL;

      http://ADMINVHN:7001/console

   2. Log in as the administrator.

   3. Click Lock & Edit.

   4. Click domain_name, Security, General, and then expand the Advanced options at the bottom.

   5. Enter a new username for Node Manager, or make a note of the existing one and update the Node Manager password.

   6. Save and activate the changes.

3. 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.

4. 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
   

8.4.4 Validating GridLink Data Source Configuration

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:

1. Log on to the Oracle WebLogic Administration Console.

2. In the Domain Structure tree, expand Services, and select Data Sources.

3. Click one of the new data sources.

4. Click the Testing tab, select one of the servers, and click Test Data Source.

5. Click the Monitoring tab and select on one of the servers.

6. Click the ONS tab, and then click the Testing tab.

7. 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.

8.4.5 Validating the Administration Server Configuration

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:

1. In a browser, go to the following URL:

   http://ADMINVHN:7001/console
   

2. Log in as the administrator.

3. Verify that the WLS_WSM1 and WLS_WSM2 managed servers are listed.

4. Verify that WSM-PM_Cluster is listed.

5. Check that you can access Oracle Enterprise Manager at the following URL:

   http://ADMINVHN:7001/em
   

6. 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."

8.4.6 Creating a Separate Domain Directory for Managed Servers in the Same Node as the Administration Server

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:

1. 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
   

2. 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/

8.4.7 Applying the Java Required Files (JRF) Template to the WSM-PM_Cluster

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:

1. 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."

2. On the navigation tree on the left, expand Farm_domain_name, WebLogic Domain, and then domain_name, and select WSM-PM_Cluster.

3. Click Apply JRF Template on the right.

4. 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.

8.4.8 Disabling Host Name Verification for the Administration Server and the WLS_WSM1 Managed Server

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:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page appears.

5. Select AdminServer(admin) in the Names column of the table. The Settings page for AdminServer(admin) appear.

6. Click the SSL tab.

7. Click Advanced.

8. Set Hostname Verification to None.

9. Click Save.

10. Repeat steps 4 to 8 for the WLS_WSM1 server.

11. Save and activate the changes.

12. Restart the Administration Server for the changes to take effect:

    1. In the Summary of Servers screen, select the Control tab.

    2. Select AdminServer(admin) in the table and then click Shutdown.

    3. Start the Administration Server again using the procedure in Section 8.4.3, "Starting the Administration Server on SOAHOST1."

8.4.9 Starting and Validating the WLS_WSM1 Managed Server

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:

1. Start the WLS_WSM1 managed server using the Oracle WebLogic Server Administration Console as follows:

   1. Expand the Environment node in the Domain Structure window.

   2. Choose Servers. The Summary of Servers page appears.

   3. Click the Control tab.

   4. Select WLS_WSM1 and then click Start.

2. 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.

3. Access the following URL:

   http://SOAHOST1:7010/wsm-pm
   

4. 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.

8.5 Propagating the Domain Configuration to SOAHOST2

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.3, "Starting Node Manager on SOAHOST2"

• Section 8.5.4, "Starting and Validating the WLS_WSM2 Managed Server"

• Section 8.5.5, "Configuring the Java Object Cache for Oracle WSM"

8.5.1 Propagating the Domain Configuration to SOAHOST2 Using the unpack Utility

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:

1. 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
   

2. 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
   

8.5.2 Disabling Host Name Verification for the WLS_WSM2 Managed Server

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:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers. The Summary of Servers page appears.

5. Select WLS_WSM2 in the Names column of the table. The Settings page for AdminServer(admin) appear.

6. Click the SSL tab.

7. Click Advanced.

8. Set Hostname Verification to None.

9. Save and activate the changes.

8.5.3 Starting Node Manager on SOAHOST2

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:

1. 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.

2. Start Node Manager:

   cd WL_HOME/server/bin
   ./startNodeManager.sh
   

8.5.4 Starting and Validating the WLS_WSM2 Managed Server

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:

1. Start the WLS_WSM2 managed server using the Administration Console.

2. 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.

3. Access the following URL:

   http://SOAHOST2:7010/wsm-pm
   

4. Click validate policy manager.

8.5.5 Configuring the Java Object Cache for Oracle WSM

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:

1. 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.

2. 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")
   

3. 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.

8.6 Configuring Oracle HTTP Server for the WebLogic Domain

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.1, "Configuring Oracle HTTP Server for the Administration Server and the WLS_WSMn Managed Servers"

• 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.4, "Setting the Frontend URL for the Administration Console and Setting Redirection Preferences"

• 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"

8.6.1 Configuring Oracle HTTP Server for the Administration Server and the WLS_WSMn Managed Servers

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:

1. 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 [e-mail]
       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 [e-mail]
       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 [e-mail]
       RewriteEngine On
       RewriteOptions inherit
   
   </VirtualHost>
   

   Note:

   Values such as 7777, admin.mycompany.com:80, and [e-mail] that are noted in this document serve as examples only. Enter values based on the actual environment.

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
   

8.6.2 Turning on the WebLogic Plug-In Enabled Flag

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:

1. Log on to the Administration Console.

2. Click on the domain name in the navigation tree on the left.

3. Click on the Web Applications tab.

4. Click Lock & Edit.

5. Select the WebLogic Plugin Enabled check box.

6. Save and activate the changes.

8.6.3 Registering Oracle HTTP Server With WebLogic Server

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.

8.6.4 Setting the Frontend URL for the Administration Console and Setting Redirection Preferences

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:

1. Log in to Oracle WebLogic Server Administration Console.

2. Click Lock & Edit.

3. Expand the Environment node in the Domain Structure window.

4. Click Servers to open the Summary of Servers page.

5. Select Admin Server in the Names column of the table. The Settings page for AdminServer(admin) appears.

6. Click the Protocols tab.

7. Click the HTTP tab.

8. 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).

9. Save and activate the changes.

10. 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.

    1. Log in to the Oracle WebLogic Server Administration Console.

    2. Click the preferences link in the banner.

    3. Click the shared preferences tab.

    4. 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."

8.6.5 Validating 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.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.

8.6.6 Manually Failing Over the Administration Server to SOAHOST2

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:

1. Stop the Administration Server.

2. Migrate IP to the second node.

   1. Run the following command as root on SOAHOST1 (where X:Y is the current interface used by ADMINVHN):

      /sbin/ifconfig ethX:Y down
      

   2. 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.

3. Update routing tables through arping, for example:

   SOAHOST2> /sbin/arping -b -A -c 3 -I eth0 10.0.0.1
   

4. Start the Administration Server on SOAHOST2 using the procedure inSection 8.4.3, "Starting the Administration Server on SOAHOST1.".

5. Test that you can access the Administration Server on SOAHOST2 as follows:

   1. Ensure that you can access the Oracle WebLogic Server Administration Console using the following URL:

      http://ADMINVHN:7001/console
      

   2. 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.

8.6.7 Validating Access to SOAHOST2 Through Oracle HTTP Server

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.

8.6.8 Failing the Administration Server Back to SOAHOST1

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:

1. Make sure the Administration Server is not running.

2. Run the following command on SOAHOST2.

   /sbin/ifconfig ethZ:N down
   

3. 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

4. Update routing tables through arping. Run the following command from SOAHOST1.

   /sbin/arping -b -A -c 3 -I ethZ 100.200.140.206
   

5. 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
    
   

6. Test that you can access the Oracle WebLogic Server Administration Console using the following URL:

   http://ADMINVHN:7001/console
   

7. Check that you can access and verify the status of components in the Oracle Enterprise Manager using the following URL:

   http://ADMINVHN:7001/em
   

8.7 Backing Up the WebLogic Domain Configuration

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