Operations Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Upgrading Oracle Communications Converged Application Server Software

Notes: The sections that follow provide only general instructions for upgrading Oracle Communications Converged Application Server software to a new Service Pack release. Your service pack or new software may contain additional instructions and tools to help you upgrade the software. Defer to those instructions if they are available.
Note: If you are upgrading from one major software release to another (such as upgrading from WebLogic SIP Server 3.x to Oracle Communications Converged Application Server), refer to Upgrading WebLogic SIP Server 3.x Oracle Communications Converged Application Server in the Configuration Guide instead of these instructions.
Note: If you want to upgrade a SIP protocol application or converged HTTP/SIP protocol application, these instructions are not required. See Upgrading Deployed SIP Applications instead.

The following sections describe how to upgrade production Oracle Communications Converged Application Server installations to a new Service Pack release of the software:

 

Overview of System Upgrades

Because a typical production Oracle Communications Converged Application Server installation uses multiple server instances in both the engine and SIP data tiers, upgrading the Oracle Communications Converged Application Server software requires that you follow very specific practices. These practices ensure that:

The sections that follow describe how to use a configured load balancer to perform a “live” upgrade of the Oracle Communications Converged Application Server software on a production installation.

When upgrading the Oracle Communications Converged Application Server software (for example, in response to a Service Pack), a new engine tier cluster is created to host newly-upgraded engine tier instances. One-by-one, servers in the engine tier are shut-down, upgraded, and then restarted in the new target cluster. While servers are being upgraded, Oracle Communications Converged Application Server automatically forwards requests from one engine tier cluster to the other as necessary to ensure that SIP data tier requests are always initiated by a compatible engine tier server. After all servers have been upgraded, the older cluster is removed and no longer used. After upgrading the engine tier cluster, servers in the SIP data tier may also be upgraded, one-by-one.

 

Requirements for Upgrading a Production System

To upgrade a production Oracle Communications Converged Application Server installation you require:

WARNING: Before modifying any production installation, thoroughly test your proposed changes in a controlled, “stage” environment to ensure software compatibility and verify expected behavior.

 

Upgrading to a New Version of Oracle Communications Converged Application Server

Follow these steps to upgrade a production installation of Oracle Communications Converged Application Server to a newer Service Pack version of the Oracle Communications Converged Application Server software. These instructions upgrade both the SIP Servlet container implementation and the SIP data tier replication and failover implementation.

The steps for performing a software upgrade are divided into several high-level procedures:

  1. Configure the Load Balancer—Define a new, internal Virtual IP address for the new engine tier cluster you will configure.
  2. Configure the New Engine Tier Cluster—Create and configure a new, empty engine tier cluster that will host upgraded engine tier servers and your converged applications.
  3. Define the Cluster-to-Load Balancer Mapping—Modify the SIP Servlet container configuration to indicate the virtual IP address of each engine tier cluster.
  4. Duplicate the SIP Servlet Configuration—Copy the active sipserver.xml configuration file to duplicate your production container configuration.
  5. Upgrade Engine Tier Servers and Target Applications to the New Cluster—Shut down individual engine tier server instances, restarting them in the new engine tier cluster.
  6. Upgrade SIP Data Tier Servers—Shut down individual SIP data tier servers, restarting them with the new SIP data tier software implementation.

Each procedure is described in the sections that follow.

Configure the Load Balancer

Begin the software upgrade procedure by defining a new internal virtual IP address for the new engine tier cluster you will create in Configure the New Engine Tier Cluster. The individual server IP addresses (the pool definition) for the new virtual IP address should be identical to the pool definition of your currently-active engine tier cluster. Figure 7-1 shows a sample configuration for a cluster having three engine tier server instances; both virtual IP addresses define the same servers.

Figure 7-1 Virtual IP Address Configuration for Parallel Clusters

Virtual IP Address Configuration for Parallel Clusters

See your load balancer documentation for more information about defining virtual IP addresses.

In the next section, you will configure the Oracle Communications Converged Application Server domain to identify the virtual IP addresses that map to each engine tier cluster. Oracle Communications Converged Application Server uses this mapping during the upgrade procedure to automatically forward requests to the appropriate “version” of the cluster. This ensures that SIP data tier requests always originate from a compatible version of the Oracle Communications Converged Application Server engine tier.

Configure the New Engine Tier Cluster

Follow these steps to create a new Engine Tier cluster to host upgraded containers, and to configure both clusters in preparation for a software upgrade:

  1. On the Administration Server machine, install the new Oracle Communications Converged Application Server software into a new BEA home directory. The steps that follow refer to c:\beanew as the BEA home directory in which the new software was installed. c:\bea refers to the software implementation that is being upgraded.
  2. Log in to the Administration Console for the active Oracle Communications Converged Application Server domain.
  3. In the Administration Console, create a new, empty engine tier cluster for hosting the upgraded engine tier servers:
    1. In the left pane, select the Environment->Clusters node.
    2. Click New to configure a new cluster.
    3. Enter a name for the new cluster. For example, “NewEngineCluster.”
    4. Enter a unicast channel or multicast address and port number for the cluster.
    5. Click OK to create the cluster.
  4. Proceed to Define the Cluster-to-Load Balancer Mapping.

Define the Cluster-to-Load Balancer Mapping

In this procedure, you configure the cluster-to-load balancer mapping to define the internal, virtual IP address that is assigned to the older and newer engine tier clusters.

To define the cluster-to-load balancer mapping:

  1. Log in to the Administration Console for the active Oracle Communications Converged Application Server domain.
  2. In the Administration Console, create a new load balancer map entry for the new cluster you created:
    1. In the left pane, select the SipServer node.
    2. Select the Configuration->Loadbalancer Map tab.
    3. Click New to create a new mapping.
    4. Enter the Cluster Name and SIP URI of the new cluster you created in Configure the New Engine Tier Cluster. For example, enter “NewEngineCluster” and “sip:172.17.0.2:5060”.
    5. Click Finish to create the new mapping.
  3. Repeat Step 2 to enter a mapping for the older cluster. For example, create an entry for “EngineCluster” and “sip:172.17.0.1:5060”.

    4. Note that you must include a mapping for both the older and the newer engine tier cluster. A mapping consists of the internal virtual IP address of the cluster configured on the load balancer, as well as the cluster name defined in the Oracle Communications Converged Application Server domain. Listing 0-3 shows an entry in the sipserver.xml file for the sample clusters described earlier.

    Listing 0-3 Sample cluster-loadbalancer-map Definition 
       <cluster-loadbalancer-map>
          <cluster-name>EngineCluster</cluster-name>
          <sip-uri>sip:172.17.0.1:5060</sip-uri>
       </cluster-loadbalancer-map>
       <cluster-loadbalancer-map>
          <cluster-name>NewEngineCluster</cluster-name>
          <sip-uri>sip:172.17.0.2:5060</sip-uri>
       </cluster-loadbalancer-map>
    </sip-server>

Duplicate the SIP Servlet Configuration

Before upgrading individual engine tier servers, you must ensure that the SIP Servlet container configuration and SIP data tier configuration in the new engine tier cluster matches your current production configuration. To duplicate the container configuration, copy your production sipserver.xml and datatier.xml configuration files to the new installation. For example: 

cp c:\bea\user_projects\domains\mydomain\config\custom\*.xml c:\beanew\user_projects\domains\mydomain\config\custom

As engine tier servers are restarted in the new engine tier cluster in the next procedure, they will have the same SIP container configuration but will use the new container implementation.

Upgrade Engine Tier Servers and Target Applications to the New Cluster

To upgrade individual engine tier servers, you gracefully shut each server down, change its cluster membership, and then restart it. Follow these steps:

  1. Access the Administration Console for your production domain.
  2. Select the first running engine tier server that you want to upgrade:
    1. Select the Environment->Servers tab in the left pane.
    2. Select the Control tab in the right pane.
    3. Select the name of the server you want to upgrade.
  3. Select Shutdown->When work completes from the table.

    4. The server remains active while clients are still accessing the server, but no new connection requests are accepted. After all existing client connections have ended or timed out, the server shuts down. Other server instances in the engine tier process client requests during the shutdown procedure.

  4. Select the Environment->Servers tab in the left pane and verify that the Managed Server has shut down.
  5. Change the stopped server’s cluster membership so that it is a member of the new engine tier cluster:
    1. Expand the Environment->Clusters tab in the left pane.
    2. Select the name of the active engine tier cluster.
    3. Select the Configuration->Servers tab in the right pane.
    4. Select the checkbox next to the name of the stopped server, and click Remove.
    5. Click Yes to remove the server from the cluster.
    6. Next, expand the Environment->Clusters tab and select the newly-created engine tier cluster (“NewEngineCluster”).
    7. Select the Configuration->Servers tab in the right pane.
    8. Click Add to add a new server.
    9. Select the name of the stopped server from the drop-down list.
    10. Click Finish.
  6. After adding the first engine tier server to the new cluster, you can now target your own applications to the new cluster.
    7. Note: Perform this step only once, after adding the first engine tier server to the new cluster:
    1. In the left pane, select the Deployments node.
    2. Click Install.
    3. Use the links to select an application to deploy, and click Next.
    4. Select Install this deployment as an application, and click Next.
    5. Select the name of the new engine tier cluster (“NewEngineCluster”). Also ensure that All servers in the cluster is selected.
    6. Click Finish.
    7. Select the checkbox next to the name of the application in the Deployments table.
    8. Click Start->Servicing all requests.
    9. Repeat this step to deploy all of your applications to the new cluster. Both the new and old engine tier clusters should be configured similarly.
  7. Restart the stopped managed server to bring it up in the new engine tier cluster:
    1. Access the machine on which the stopped engine tier server runs (for example, use a remote desktop on Windows, or secure shell (SSH) on Linux).
    2. Use the available Managed Server start script (startManagedWebLogic.cmd or startManagedWebLogic.sh) to boot the Managed Server. For example:
      3. startManagedWebLogic.cmd engine-server1 t3://adminhost:7001
  8. In the Administration Console, select the Environment->Servers node and verify that the Managed Server has started.
  9. Repeat these steps to upgrade the remaining engine tier servers.

At this point, all running Managed Servers are using the new SIP Container implementation and are hosting your production SIP Servlets with the same SIP Servlet container settings as your old configuration. SIP data tier servers can now be upgraded using the instructions in Upgrade SIP Data Tier Servers.

Upgrade SIP Data Tier Servers

WARNING: Your SIP data tier must have three active replicas (three server instances) in each partition in order to upgrade the servers in a production environment. With only two replicas in each partition, a failure of the active replica during the upgrade process will result in the irrecoverable loss of call state data. With only one replica in each partition, the upgrade cannot be initiated without losing call state data.

The procedure for upgrading server instances in the SIP data tier simply involves restarting each server, one at a time, to utilize the updated software. Always ensure that the previous server has fully restarted (is in ONLINE state) before restarting the next server.

WARNING: Do not shut down or restart a SIP data tier server instance in a partition unless two additional servers in the same partition are available, and both are in the ONLINE state. See Monitoring and Troubleshooting SIP Data Tier Servers in the Configuration Guide for information about determining the state of SIP data tier servers.

  Back to Top       Previous  Next