Upgrading a Clustered Environment

Upgrading a Clustered Topology

Table 5-1 lists the steps required to upgrade the example clustered, multi-host Oracle SOA Suite topology illustrated in Figure 5-1.

Table 5-1 Oracle SOA Suite and BPM Cluster Upgrade Roadmap

Task	For More Information
Review the upgrade topology, and identify `SOAHOST1` and `SOAHOST2` on your setup.	See Understanding the SOA Cluster Upgrade Topology
Shut down the Administration Server, all the Managed Servers, and the Node Managers running on `SOAHOST1` or `SOAHOST2`.	See Stopping Servers and Processes
Perform a complete upgrade of your existing deployment on `SOAHOST1`. Perform the post-upgrade configurations that apply to your environment.	See Upgrading SOA Suite and Business Process Management
After a successful upgrade, propagate the domain configuration of `SOAHOST1` on `SOAHOST2`. To do this, you must pack the domain on `SOAHOST1`, and unpack it on `SOAHOST2` in a NEW 14c (14.1.2.0.0) domain.	See Propagating Domain Configuration to Another Host
Restart the Administration Server and the Managed Servers on `SOAHOST1` and `SOAHOST2`.	Starting the Admin Server and SOA Managed Servers
Perform any additional post-upgrade configuration tasks for your environment.	See Performing Post Upgrade Tasks

Understanding the SOA Cluster Upgrade Topology

Figure 5-1 shows a sample topology of a clustered Oracle SOA Suite deployment with SOA, Oracle Web Services Manager (OWSM), Oracle Service Bus (OSB) and Oracle Business Activity Monitoring (Oracle BAM) in separate clusters across two application hosts, SOAHOST1 and SOAHOST2. The Oracle HTTP Server, Administration Server, Oracle Enterprise Manager Fusion Middleware Control and database are shared with both hosts.

Specifically, this chapter describes the steps required to upgrade a WebLogic domain that contains multiple WebLogic Server clusters that are scaled out to multiple host computers. You can apply the concepts and procedures in this chapter to your own specific Oracle SOA Suite environment.

The steps required to upgrade this sample topology are described in the next section in Table 5-1.

Figure 5-1 Clustered SOA Topology

Description of "Figure 5-1 Clustered SOA Topology "

Using Secured Task Forms in a Clustered Topology

The task form is a Java Server Page XML (.jspx) file that you create in the Oracle JDeveloper designer where you created the SOA composite containing the human task.

If your SOA composite includes a human task form, or if task forms are deployed on non-SOA servers, then you must secure the task form after the upgrade.

Propagating Domain Configuration to Another Host

After verifying that the upgrade was successful, use these steps to propagate the newly upgraded files to another host.

After you have completed your single node upgrade on HOST1, use these steps to propagate the newly upgraded files to another node (in this example the secondary host is called HOST2).

Executing the pack command on the server where the Admin Server and one of the Managed Servers is installed.

In our sample topology, you would execute the following on HOST1:

cd /14c_ORACLE_HOME/oracle_common/common/bin

./pack.sh -domain=/12c_DOMAIN_HOME -template=domainupgradetemplate.jar -template_name=domainupgradetemplate -managed=true

In this example:

14c_ORACLE_HOME refers the actual path to the 14c Oracle home directory (the installation directory for the 14c (14.1.2.0.0)bits).
Replace 12c_DOMAIN_HOME with the actual path to the upgraded domain directory.
domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.
domainupgradetemplate is the name assigned to the domain template file.
By default, the domainupgradetemplate is created in the current directory where you ran the pack command. In this example, it would be created in the following directory, but you can specify a full path for the template jar file as part of the -template argument to the pack command:
```
ORACLE_COMMON_HOME/common/bin/
```

The pack command creates a template archive (.jar) file that contains a snapshot of either an entire domain or a subset of a domain. You can use a template that contains a subset of a domain to create a Managed Server domain directory hierarchy on a remote machine.

Executing the unpack Command from the 12c Oracle Home on HOST2.

Make sure that the Administration and Managed Servers are still stopped and then execute the unpack command to create a full domain (or a subset of a domain) used for a Managed Server domain directory on the remote machine. You may use unpack only with a template compatible with your current installation.

Note:

Do not attempt to unpack the domain on top of an existing domain. Oracle recommends that you unpack the contents of the domain upgrade template jar file into a new domain location.

It is important to note that even if you use the -overwrite_domain=true argument when unpacking the domain, the contents of the existing domain will remain in place and will cause issues with when starting the servers. For this reason, Oracle recommends that you unpack the domain template jar file into a new location, or, manually delete the contents of the existing location before you unpack.

A sample unpack command code snippet is shown below.

cd /12c_ORACLE_HOME/oracle_common/common/bin

./unpack.sh -template=domainupgradetemplate.jar - domain=NEW_DOMAIN_LOCATION

In this example:

12c_ORACLE_HOME refers the actual path to the 12c Oracle home directory, the installation directory for the 14c (14.1.2.0.0).
Replace NEW_DOMAIN_LOCATION with the actual path to the upgraded domain directory.
domainupgradetemplate.jar is a sample name for the jar file you are creating, which will contain the domain configuration files.
domainupgradetemplate is the name assigned to the domain template file.

Copying the template file created on HOST 1 to HOST2.

After you perform a complete upgrade of your deployment on HOST1, and you have completed any post-upgrade configurations that apply to your new environment, you must copy the domain template to HOST2.

Use the following command to copy from HOST1 the domain upgrade template JAR file created during the upgrade.

scp domaintemplate.jar company@HOST2:14c_ORACLE_HOME/oracle_common/common/bin

Completing the following verification steps after the unpack.

Verify that settings for WLS_HOME and ORACLE_HOME located in the setDomainEnv.sh script from the 12c domain are pointing to 14c (14.1.2.0.0).
Start the Node Manager, WebLogic Administration Server, and the Managed Servers on HOST1 and HOST2 in the following order:
1. On HOST1 and HOST2, start the Node Manager.
2. On HOST1, start the WebLogic Administration Server.
3. On HOST1 and HOST2, start the Managed Servers.

For more information, see Starting Servers and Processes. Carefully review the order in which Managed Servers should be started.

Post-Upgrade Tasks for Cluster Upgrades

After a successful cluster upgrade, you may need to perform additional post-upgrade configurations tasks. Perform only those tasks that pertain to your clustered environment.

Changing Domain Mode Post Upgrade

After the upgrade, your domain retains its original pre-upgrade domain security mode settings. If you want to change the domain mode, to enable enhanced security, for example, you must explicitly change the settings using the WebLogic Remote Console or by modifying the DomainMBean.

If your domain is currently set to Production Mode, and you want to enable added security, then after the upgrade use the WebLogic Remote Console to change the domain mode and enable the Secured Production Mode. Change the Domain Mode in Oracle WebLogic Remote Console Online Help.

Caution:

Changes to the domain mode require a full domain restart - a rolling restart is not sufficient. You must stop all managed servers before you attempt to change the domain mode.

When upgrading a domain to 14c (14.1.2.0.0), if there is no explicit secure mode setting, then the Reconfiguration Wizard will explicitly set secure mode to disabled in the upgraded domain. This is to preserve the behavior that was present in the original domain. If there is an explicit secure mode setting, it will be preserved in the upgraded domain. For more information, see Understand How Domain Mode Affects the Default Security Configuration in Securing a Production Environment for Oracle WebLogic Server.

Note:

Secured Production Mode enforces more restrictive and stringent security settings to ensure less vulnerability to threats. To make sure that your domain is secure, after enabling Secured Production Mode, you will have to choose the security configuration options that are appropriate for the environment in which the domain runs, such as obtaining and storing certificates, protecting user accounts, and securing the network on which the domain runs. If these options are not properly configured, you will be blocked from using WebLogic Server.

After you have created your WebLogic domain, several key steps remain to ensure its integrity such as selecting appropriate security configurations. For more information, see Securing the Domain After You Have Created It in Administering Security for Oracle WebLogic Server.

Starting the Admin Server and SOA Managed Servers

Restart the Oracle WebLogic Administration server and any other SOA Managed servers.

Start the Administration Server

Note:

The procedures in this section describe how to start servers and processes using the WLST command-line utility or a script. You can also use the Oracle Fusion Middleware Control and the Oracle WebLogic Server Remote Console. See Starting and Stopping Administration and Managed Servers and Node Manager.

As of release 14c (14.1.2.0.0), the WebLogic Server Administration Console has been removed. For comparable functionality, you should use the WebLogic Remote Console. For more information, see Oracle WebLogic Remote Console.

Note:

Depending on your existing security settings, you may need to perform additional configuration before you can start or manage a domain with secured production mode enabled. For more information, see Using Secured Production Mode.

When you start the Administration Server, you also start the processes running in the Administration Server, including the WebLogic Remote Console and Fusion Middleware Control.

To start an Administration Server, use the following script:

(UNIX) DOMAIN_HOME/bin/startWebLogic.sh

(Windows)DOMAIN_HOME\bin\startWebLogic.cmd

Note:

When using secured production mode, you must provide additional parameters to start the Administration Server. See Connecting to the Administration Server using WLST in Administering Security for Oracle WebLogic Server.

When prompted, enter your username, password and the URL of the administration server.

Start the Managed Servers

Start the WebLogic Server Managed Servers with the following script:

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd managed_server_name admin_url

Note:

When using secured production mode, you must provide additional parameters to start the Managed Servers. See Starting Managed Servers using a Start Script in Administering Security for Oracle WebLogic Server.

When prompted, enter your username and password.

Start SOA servers and processes in this order:

Oracle Web Services Manager (OWSM) Managed Server
Service-Oriented Architecture (SOA) Managed Server and Managed File Transfer (MFT)
Oracle Service Bus (OSB) Managed Server
Business Activity Monitoring (BAM) Managed Server

Note:

The startup of a Managed Server will typically start the applications which are deployed to it. Therefore, it should not be necessary to manually start applications after the Managed Server startup.

Removing OWSM Targets from SOA and OSB Clusters

If your 12c domain includes an Oracle Web Services Manager (OWSM) in its own cluster and you have extended that domain with a SOA cluster and an OSB cluster, then post upgrade you must manually untarget the wsm-pm from the SOA and OSB clusters.

To remove the owsm-pm target from the SOA and OSB clusters:

Log in to the WebLogic Server Administration Console 12c.

Enter the following URL in a browser:
```
http://host name:port_number/console
```
The port number is the port number of the Administration Server. By default, the port number is 7001.

The login page is displayed.
Select Deployments from Domain Structure.
Select wsm-pm under Deployments.
In the settings for wsm-pm, select Targets.
Select wsm-pm component of type Enterprise Application and select Change Targets.
Uncheck SOA cluster and OSB cluster.
When prompted, click Yes to apply the changes.
REQUIRED: Once the wsm-pm is targeted only to the OWSM cluster, you must rewire the components as described in Updating OWSM Cross-Component Wiring.

Updating OWSM Cross-Component Wiring

After you have removed OWSM targets from SOA and OSB clusters as described in Removing OWSM Targets from SOA and OSB Clusters, you must rewire the OWSM Policy Manager components as described below:

Start the Administration (admin) server and one OWSM server.
Log in to the Oracle Enterprise Manager Fusion Middleware Control 12c console and navigate to the Cross Components Wiring > Components option.

Description of the illustration cross_menu.png
Select OWSM Policy Manager from the list of available components:

Description of the illustration owsm_comp.png
From the Service End Points table, select the OWSM Policy Manager t3 connection entry and click Publish. The status will change from Out of Sync to Published.

Description of the illustration owsm_publish.png
Select OWSM Agent from the Component Type list. Select the t3 connection entry and click Bind.

Description of the illustration bind.png
Verify that the Service Type for the service end point is OWSM Policy Manager.

Description of the illustration bind_config.png
Repeat steps 5 and 6 to Bind the remaining component types. In this example, you will select com.oracle.ess and Fusion Middleware Control.

Reapplying an EDNTopic to SOA JMS Module After Cluster Upgrade

After upgrading a SOA Cluster domain to 14c (14.1.2.0.0), the upgraded SOA JMS module may be missing the EDNTopic. If the JMS module is missing the EDNTopic, you must manually add the topic or UDD for this topic using the Administration Console or WLST.

See the Remote Console online help for more information on reapplying the EDNTopic.