![]() ![]() ![]() ![]() ![]() ![]() |
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:
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.
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. |
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:
sipserver.xml
configuration file to duplicate your production container configuration.Each procedure is described in the sections that follow.
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.
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.
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:
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.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:
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.
<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>
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.
To upgrade individual engine tier servers, you gracefully shut each server down, change its cluster membership, and then restart it. Follow these steps:
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.
Note: | Perform this step only once, after adding the first engine tier server to the new cluster: |
startManagedWebLogic.cmd engine-server1 t3://adminhost:7001
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.
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. |
![]() ![]() ![]() |