Zero Downtime In Middleware Infrastructure

WebLogic cluster is a basic building block to achieve high availability during normal operations as well as during planned maintenance activities.

In a typical BEA WebLogic cluster configuration, an application becomes unavailable during the redeployment process and users cannot access the site.

For enterprise environments where it is not possible to schedule downtime to update applications and other components, a multi-cluster configuration leaves web applications up and running during redeployment.

Figure 1. Zero Downtime – Multi Cluster Configuration

Zero Downtime Operation

Steps of the zero downtime operation are as follows:

1. Normal operations traffic is routed through primary cluster.

2. Before maintenance, route traffic through secondary cluster.

3. Update/upgrade primary cluster.

4. Route traffic back through primary cluster.

5. Update/upgrade secondary cluster.

This configuration allows zero downtime with session loss during instantaneous cluster switch.

Database Considerations

The zero downtime configuration supports update only in the middleware tier. In a scenario where both clusters point to a single instance of the database, database updates during application migration can become an issue.

Application-Specific Considerations

If an application uses JMS resources, additional steps may require migration of JMS resources and messages. A WebLogic portal and integration service pack upgrade often needs a database update to handle framework metadata.

The zero downtime cluster configuration is expensive because it needs to run two clusters in parallel for each WebLogic domain.

An alternative, orchestrated upgrade procedure with single running WebLogic clusters, shown in Figure 2, can minimize downtime significantly.

Figure 2. Low Downtime Cluster Configuration

An orchestrated migration procedure is recommended for major application releases and WebLogic version upgrades. The steps are as follows:

1. Prepare future cluster configuration with required upgrade components.

2. Route normal operations traffic routed through current cluster.

3. Bring down the current cluster.

4. Perform database updates (if required).

5. Start the future cluster configuration.

It is suggested that detailed migration procedures and test procedures be developed and documented during pre-production migrations.

Factors in considering zero-downtime versus low-downtime are found in Table 1.

Type of Upgrade	Low Downtime Configuration Expected Downtime	Zero Downtime Configuration Expected Downtime
JVM Upgrade	Zero	Zero
WebLogic Patch Upgrade	Zero	Zero
WebLogic Service Pack Upgrade No database update Compatible database updates	WebLogic cluster admin and managed nodes restart time - ~30 minutes *	~ 30 minutes*
WebLogic Service Pack Upgrade With Database update	WebLogic cluster admin and managed nodes restart time + database updates – ~1 Hour *	Database updates with application restart – ~1 Hour * Database update with no application restart – ~ 30 minutes *
Application Minor release – Application Code Redeployment	Application redeployment time ~2 – 15 minutes*	Zero
Application major release Code redeployment Database updates WebLogic service pack update WebLogic major version upgrade	Depending on upgrade components. 1-6 hours *	Major release with database updates – ~ 1 Hour * Major release with no update or compatible updates – Zero
Physical or Virtual server maintenance	Zero	Zero

Table 1. Cluster Configuration Comparisons

* Expected downtime is a just estimate for common application and system architecture. Actual downtime will be specific to individual application and system architecture.

What about WebLogic 9.2 “side-by-side” deployment?

With WebLogic 9.2 self contained applications with following characteristics can be redeployed using “side-by-side” or “production redeployments” deployments while meeting zero down time requirements.

Self Contained Applications

- Stand-alone Web Application (WAR) modules and Enterprise Applications (EARs) whose clients access the application via a Web application (HTTP).

- Enterprise Applications that are accessed by inbound JMS messages from a global JMS destination, or from inbound JCA requests.

- All types of Web Services, including conversational and reliable Web Services.

- Application packaged with version identified in MANIFEST.MF file.

Applications with following characteristics do not qualify for Zero Down Time upgrade.

- Stand-alone EJB or RAR modules.

- Transaction applications using JTS drivers

- Applications not using WebLogic datasource for database access

- EJB 1.1 CMP applications

- Changes in application deployment targets, security model and web application’s persistent store settings.

In highly available and controlled environments “side-by-side” deployment is not a widely used option specifically in following scenarios.

- Release changes in EAR bundle are transparent to infrastructure teams.

- Standardized deployment processes are used for enterprise wide deployments.