Wednesday, February 06, 2008

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.

Labels: , ,