System Administrator’s Guide

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

Hitless Upgrade Using Production Redeployment

Network Gatekeeper supports seamless upgrades of communication services without service interruption. The upgrades are performed without disruptions in the traffic flow, without any need to restart servers, which means that the full processing capacity of the Network Gatekeeper cluster is preserved during the hitless upgrade.

Hitless upgrades are performed using the Production Redeployment strategy, also referred to in Weblogic Server as side-by-side redeployment. See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/deployment/redeploy.html

Upgrades of container services provided by Network Gatekeeper do not support production redeployment. Rolling upgrades should be used instead.See http://download.oracle.com/docs/cd/E13179_01/common/docs100/upgrade/rolling_upgrade.html.

 


Production Redeployment Overview

Production redeployment involves deploying a new version of an application alongside an older version of the same application. Weblogic Server automatically manages client connections so that only new client requests are directed to the new version. Clients already connected to the application during the redeployment continue to use the older version of the application until it has processed any pending request, at which point WebLogic Server automatically retires the older application. In this context, applications are network protocol plug-ins.

To support the production redeployment strategy, a plug-in must graceful shutdown. This means that it tracks any in-flight requests, and makes sure that it does not get undeployed while having any pending unprocessed requests. The WebLogic Server container takes care of parts of this, but all plug-ins need to perform protocol specific clean-up of any connections used for network traffic, and assert that all traffic is diverted to a new version of the module.

Production redeployments are performed on EAR file level, which means that all network protocol plug-ins that are tied to an application-facing interface are updated.

 


Production Redeployment Sequence

Below is a description of the Production Redeployment sequence:

  1. The redeployment operation is triggered. It is performed on the administration server and targeted to all servers in the cluster.
  2. The old version of the plug-in stops accepting new requests at the same time as the new version of the plug-in starts accepting them. At this point, both plug-ins are operational, the old version does not accept new requests. It only processes pending requests.
  3. When the old version has no pending requests, it is undeployed automatically.

While both the new and the old version of version of the plug-in are active, both plug-ins are registered in the plug-in manager, with the version of the plug-in indicated. See Managing and Configuring the Plug-in Manager.

 


Requirements for Production Redeployment

For production redeployment to work:

WARNING: If this is not done properly, the old version could be undeployed prematurely.

 


Typical Scenarios for Production Redeployment

The EAR names for each communication service and the JAR names for the specific network protocol plug-in(s) contained within it can be found under the heading “Properties for <Communication service>” in the section of Network Gatekeeper Administration Guide (this guide). See Deployment Model for Communication Services and Container Services for a description of how individual communication services are packaged.

 


Performing a Hitless Upgrade

Network Gatekeeper uses the WebLogic Server mechanism for production redeployment. See http://download.oracle.com/docs/cd/E13222_01/wls/docs100/deployment/redeploy.html for more information.

Below is the syntax for using weblogic.Deployer to do the upgrade:

java weblogic.Deployer -adminurl <adminhost>:<adminport> -user <admin user> -password <password> -graceful -rmiGracePeriod <grace period> -redeploy -name <name> -source <EAR file> -targets <Cluster name>

In addition to the -graceful and -rmiGracePeriod flags, the -retiretimeout <time period> flag can be used to force stop the application after the given time period.

In the code snippet below the Network Tier part of the Parlay X 2.1 Multimedia Messaging communication service on a cluster named WLNG_NT_Cluster is redeployed:

java weblogic.Deployer -adminurl <adminhost>:7001 -user weblogic -password weblogic -redeploy -rmiGracePeriod 30 -name wlng_nt_multimedia_messaging_px21 -source ./wlng_nt_multimedia_messaging_px21.ear -targets WLNG_NT_Cluster

The EARs are version-controlled, so the meta-inf\MANIFEST.MF file in the EAR must be updated with which version the EAR has:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: R27.5.0-101-94136-1.5.0_14-20080116-2103-windows-ia32 (BEA
  Systems, Inc.)
Bundle-Name: wlng_at_multimedia_messaging_px21
Bundle-Version: $<version>
Bundle-Vendor: BEA Systems, Inc
Weblogic-Application-Version: $<version>

  Back to Top       Previous  Next