Sun Java Enterprise System 7 Installation and Upgrade Guide

Planning for Upgrades

An upgrade plan is the essential starting point for performing an upgrade to Java ES 7. In an upgrade plan you specify the Java ES products you will upgrade and the sequence by which you will upgrade those products on the different computers or operating system instances in your Java ES deployment.

Your upgrade plan depends on a number of factors, each of which should be given careful consideration in preparing for upgrade to Java ES 7:

Upgrade Objectives and Priorities

An upgrade plan reflects your upgrade objectives and priorities, which often depend on the scope and complexity of your existing deployment architecture.

For example, your Java ES deployment architecture might consist of a single Java ES product running on a single computer, and your upgrade objective is to fix some bug in the previous software release. On the other hand, your Java ES deployment architecture might consist of a number of interoperating Java ES products deployed across a number of different computers, and your upgrade objective is to achieve some new functionality by upgrading the minimum number of products required to achieve that end with minimal downtime.

In general, the greater the number of Java ES products and computers in your deployment architecture, and the more ambitious your upgrade objectives, the more complex will be your upgrade plan.

Upgrade Dependencies

One of the main issues in planning the upgrade of a Java ES product is to understand that product's dependencies on other Java ES products, and whether other products need to be upgraded to support the upgrade of the intended product. Researching and working through this issue can affect your upgrade plan in two distinct ways:

The Interoperability Matrix in Sun Java Enterprise System 7 Release Notes provides dependency information about each product in Java ES 7 Base, including supported product versions for each dependency. Use this information, coupled with knowledge of the product versions in your existing Java ES deployment, to determine whether you need to upgrade some additional products in order to support your intended upgrades.

Multi-Instance Upgrades

The sequence of upgrade procedures in an upgrade plan depends on how redundancy is being used in a deployment architecture. Multiple instances of a Java ES product can be used to achieve high availability, scalability, serviceability, or some combination of these service qualities. Three technologies make use of redundant products in Java ES deployment architectures: load balancing (Directory Proxy Server, Web Server, Web Proxy Server, Application Server, Access Manager, and Portal Server), high availability techniques (Sun Cluster and High Availability Session Store, and others), and Directory Server replication.

In most cases where redundancy is involved, upgrades must be performed without incurring significant downtime. These rolling upgrades attempt to successively upgrade redundant instances of a product without compromising the service that they provide.

Redundant instances are usually deployed across multiple computers. For upgrade planning, you might need to isolate the upgrade of replicated products from other product upgrades in order to achieve minimal downtime. In such cases, you often perform all the pre-upgrade tasks for the replicated products on each computer before performing the rolling upgrade.

Each replication technology has configuration or reconfiguration procedures that might affect the overall sequence of Java ES product upgrades. For example, products that run in a Sun Cluster environment can require upgrading Sun Cluster before upgrading the products that are running in the Sun Cluster environment.

The Java ES Upgrade Process

The process of upgrading a Java ES deployment can involve a number of individual product upgrades performed in a particular order to ensure a smooth transition to a updated software system. Upgrades of large or complex Java ES deployments are normally carried out first in a staging environment, before being executed in a production environment. The use of a staging environment allows you to test after each product upgrade as well as to write scripts to simplify or accelerate the upgrade in a production environment.

When you have tested the upgrade process in a staging environment, and have confidence that the upgrade is working properly, you can reproduce the process in your production environment.