> Operations Guide > Upgrading WebLogic SIP Server Software

Operations Guide

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

Upgrading WebLogic SIP Server Software

Notes: The sections that follow provide only general instructions for upgrading WebLogic SIP 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 2.2 to WebLogic SIP Server 3.0), refer to Upgrading a WebLogic SIP Server 2.2 Configuration to Version 3.0 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 WebLogic SIP Server installations to a new Service Pack release of the software:

 

Overview of System Upgrades

Because a typical production WebLogic SIP Server installation uses multiple server instances in both the engine and data tiers, upgrading the WebLogic SIP 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 WebLogic SIP Server software on a production installation.

When upgrading the WebLogic SIP 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, WebLogic SIP Server automatically forwards requests from one engine tier cluster to the other as necessary to ensure that 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 data tier may also be upgraded, one-by-one.

 

Requirements for Upgrading a Production System

To upgrade a production WebLogic SIP 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 WebLogic SIP Server

Follow these steps to upgrade a production installation of WebLogic SIP Server to a newer Service Pack version of the WebLogic SIP Server software. These instructions upgrade both the SIP Servlet container implementation and the data tier replication and failover implementation included in the sipserver Enterprise Application (EAR).

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 Data Tier Servers—Shut down individual data tier servers, restarting them with the new 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 6-1 shows a sample configuration for a cluster having three engine tier server instances; both virtual IP addresses define the same servers.

Figure 6-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 WebLogic SIP Server domain to identify the virtual IP addresses that map to each engine tier cluster. WebLogic SIP Server uses this mapping during the upgrade procedure to automatically forward requests to the appropriate "version" of the cluster. This ensures that data tier requests always originate from a compatible version of the WebLogic SIP 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 WebLogic SIP 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 WebLogic SIP 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 Clusters node.
    2. Click New to configure a new cluster.
    3. Enter a name for the new cluster. For example, "NewEngineCluster."
    4. Enter the multicast address and port number of 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 WebLogic SIP Server domain.
  2. Click the Lock & Edit button.
  3. 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.
  4. 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".
  5. Click Activate Changes to apply the new configuration.

    6. 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 WebLogic SIP 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 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. Click Lock & Edit.
  3. 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 name of the server you want to upgrade.
  4. Select the Control->Start/Stop tab in the right pane.
  5. Select Shutdown->When work completes from the table.
  6. Select Yes to perform the shutdown.

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

  7. Select the Environment->Servers tab in the left pane and verify that the Managed Server has shut down.
  8. 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. Click Apply.
    7. Next, expand the Environment->Clusters tab and select the newly-created engine tier cluster ("NewEngineCluster").
    8. Select the Configuration->Servers tab in the right pane.
    9. Click Add to add a new server.
    10. Select the name of the stopped server from the drop-down list, and click Finish.
  9. After adding the first engine tier server to the new cluster, you can now target your own applications to the new cluster.
    10. 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 applciation, 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.
  10. 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
  11. In the Administration Console, select the Servers node and verify that the Managed Server has started.
  12. 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. Data tier servers can now be upgraded using the instructions in Upgrade Data Tier Servers.

Upgrade Data Tier Servers

WARNING: Your 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 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 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 Data Tier Servers in the Configuration Guide for information about determining the state of data tier servers.

  Back to Top       Previous  Next