|
| |
| Sun Java Enterprise System 2005Q4 Upgrade Guide | |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade of Sun Java™ Enterprise System (Java ES) software to Java ES 2005Q4 (Release 4). It contains the following sections:
Java ES 2005Q4 (Release 4) ComponentsAs an introduction to planning the upgrade of Java ES software, this section reviews the components included in Java ES Release 4. Depending on your upgrade scenario, you might need to upgrade one or more of these components to their Release 4 version.
Java ES components are grouped into different types, as described in the Java Enterprise System Technical Overview (http://docs.sun.com/doc/819-2330). Accordingly, system service components provide the main Java ES infrastructure services, while service quality components enhance those system services. These two types of Java ES components are together referred to here as product components, components that are selectable within the Java ES installer.
Each product component depends on one or more locally shared libraries known as Java ES shared components. Shared components are installed automatically by the Java ES installer during product component installation, depending on the product components that are being installed.
Release 4 Product Components
The Java ES Release 4 product components are shown in the following table, listed alphabetically. For the service quality components among them, the table includes the type of service enhancement they provide.
Release 4 Shared Components
Java ES shared components, upon which the product components installed on a single computer depend, cannot be selected or deselected within the Java ES installer. When installing Java ES product components, the Java ES installer automatically installs the shared components needed by the installed product components.
The Java ES Release 4 shared components are listed in the following table.
About Java ES UpgradesThe upgrade of Java ES software to Release 4 is not generally performed using the Java ES installer or any other system utility. It is performed component-by-component, computer-by-computer, using component-specific upgrade procedures.
The upgrade of a component can range from a major upgrade, which might not be compatible with the previous version of the component, to a fully-compatible upgrade that simply provides bug fixes. Because of dependencies between Java ES components, the nature of the upgrade can impact whether other components need to be upgraded as well.
Product Component Upgrades
Java ES product component upgrades involve two basic operations that mirror the initial installation and configuration of Java ES product components:
- Installing upgraded software. The new software can enhance or fix existing software, or replace existing software. In general, the new software is achieved through the application of patches to existing software packages, the replacement of existing packages, the installation of new packages, or a full re-installation of a component using the Java ES installer.
- Re-configuration. Re-configuration encompasses any change in configuration data, user data, or dynamic application data needed to support the upgraded software. A change in data can mean additional data, a change in data format (whether in property files or database schema), or a change in data location. Sometimes re-configuration requires that you perform an explicit procedure and sometimes it takes place automatically without your involvement.
These two aspects of component upgrades are described in this Upgrade Guide for each of the Java ES product components.
The Upgrade Guide also covers other important aspects of product component upgrades, including:
Shared Component Upgrades
Java ES shared component upgrades are often a necessary part of upgrading the product components that depend on them.
The upgrading of shared components is typically more straightforward than the upgrading of product components. In general, the upgrade is achieved through the application of patches to existing packages or the replacement of existing packages. As compared to upgrading product components, there is normally no re-configuration required, nor pre or post upgrade procedures to be performed.
While shared components can be upgraded one by one, Java ES Release 4 allows you to collectively upgrade a number of shared components in one operation. For more information, see Chapter 2, "Upgrading Java ES Shared Components."
Upgrade Technologies
The upgrade of both product components and shared components, as described in this Upgrade Guide, involves the modification or replacement of currently installed software packages and, in some cases, the installation of new packages. Solaris and Linux platforms employ similar technologies for managing installed software packages and tracking changes through a package registry.
- Solaris platform. Java ES packages can be installed and removed through the Solaris pkgadd and pkgrm commands, using packages found on the Java ES software distribution. Package contents, once installed, can be modified using patches that are applied or removed through the patchadd and patchrm commands. Patches to Solaris packages are distributed through the SunSolve website at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
Solaris patches can patch one or more packages. The patchadd command saves a backup of the package being patched to facilitate the removal of the patch using the patchrm command. Patches are identified by a patch ID, which consists of a patch number followed by a revision number that is incremented as the patch is modified over time.
Solaris patches can also be collected into a patch cluster. The patch cluster lets you collectively download and apply all the patches in the cluster. Patch clusters are provided for upgrading Java ES shared components (see Chapter 2, "Upgrading Java ES Shared Components").
- Linux platform. Java ES RPM (Red Hat Package Manager) packages can be installed or updated through the rpm command, using packages found on the Java ES software distribution. Package contents, once installed, however, cannot be modified using patches. Rather, RPM packages are updated using the rpm -U command option, which replaces the current package with a newer package.
As a convenience, many RPM package upgrades are distributed not only on the Java ES software distribution, but also through the SunSolve website at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
For distribution through SunSolve, RPM packages can be wrappered as patches and assigned a patch ID and revision number similar to Solaris patches. These Linux patches can include one or more RPM packages, each identified by a unique RPM name, RPM number, and a revision number that is incremented as the RPM package is modified over time.
Operating System Issues
A number of operating system issues impact the upgrading of Java ES software, as described below.
Required Operating System Patches
In some situations, the successful upgrade of a Java ES product component can require you to first patch the operating system or apply specific fixes. Rather than applying the specific operating system patch required in each case, it is generally preferable to simply bring the operating system up to date before performing Java ES upgrades.
- Solaris platform patches are available through the SunSolve website as a patch cluster, a collection of operating system patches that can be collectively applied. The operating system patch clusters for Solaris 8, 9, and 10 are available at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Linux platform update releases are available at: https://www.redhat.com/apps/download/
Minor Release Upgrades
A significant number of Java ES shared components have Solaris release-specific packages. The release-specific packages might not function correctly on other Solaris platforms. For example, packages that are released for the Solaris 8 operating system cannot be expected to work for Solaris 9 or Solaris 10 operating systems.
When upgrading the operating system from one minor release to another, the various installed Java ES shared components will be affected. When shared components have release-specific packages, these packages will also need to be upgraded after the operating system is upgraded, to match the newly upgraded operating system.
Upgrades to Non-Supported Platforms
Java ES 2004Q2 (Release 2) is supported on Solaris 8 and 9 operating systems and on Red Hat Enterprise Linux (RHEL) 2.1. If you wish to upgrade your operating system platform to Solaris 10 or RHEL 3.0, which are not supported by Java ES Release 2, you will also need to upgrade your Java ES Release 2 to a Java ES Release that supports the upgraded platform, preferably to Java ES Release 4.
Because upgrade of some Java ES components requires that other Java ES components be running, you cannot, as a general rule, upgrade your operating system platform to Solaris 10 or RHEL 3.0 before upgrading Java ES from Release 2 (Java ES Release 2 does not support these platforms).
Instead, the approach you need to take depends on platform:
- Linux platform. You should upgrade Java ES Release 2 to Release 4 first and then perform the upgrade to RHEL 3.0.
- Solaris platform. You should uninstall Java ES Release 2, upgrade your operating system to Solaris 10, and then perform a fresh install of Java ES Release 4. Such an operation means that all Java ES components must be freshly configured. In this situation it would be prudent to back up all Java ES Release 2 configuration files and customizations for use in configuring Java ES Release 4 components.
Upgrade PlanningThe approach you take to upgrading a deployed Java ES software system to Java ES Release 4 can depend on your upgrade objectives and priorities, as well as the scope and complexity of your deployment architecture.
For example, your Java ES deployment architecture might consist of a single Java ES component 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 interdependent Java ES components deployed across a number of different computers, and your upgrade objective is to achieve some new functionality by upgrading the minimum number of components required to achieve that end with minimal downtime.
These two examples represent upgrade scenarios of very different complexities, requiring substantially different upgrade plans. No one plan works for all deployed Java ES software systems.
In general, the greater the number of Java ES components and the greater the number of computers in your deployment architecture, the more complex will be your upgrade plan.
What is an Upgrade Plan?
An upgrade plan specifies how to approach each stage of the upgrade process. This process involves, at a minimum, the phases shown in the following table.
The following sections provide information that can help in formulating an upgrade plan.
Upgrade Plan Considerations
Your upgrade plan will depend on a number of factors beyond the scope and complexity of your deployment architecture. These factors include the following considerations:
These factors are discussed in the following sections.
Upgrade Paths
While it is possible to upgrade all previous releases of Java ES software to Java ES 2005Q4 (Release 4), the only certified upgrades are from Java ES 2005Q1 (Release 3) and Java ES 2004Q2 (Release 2). Upgrades from earlier releases are not documented in this Upgrade Guide.
The various upgrade paths involve different upgrade strategies, as described in Table 1-4.
Because of the different characteristics of the Release 3 to Release 4 and the Release 2 to Release 4 upgrade paths, and because the upgrade procedures for product components often depend on the upgrade path, the separate chapters in this Upgrade Guide describing the upgrade of each product component are divided into two sections: one on upgrading from Release 3 to Release 4 and one on upgrading from Release 2 to Release 4.
Table 1-4 Upgrade Paths to Java ES 2005Q4 (Release 4)
Product Number
Java ES Release
System Characteristics
Upgrade Strategies
2005Q1
Release 3
Java ES Release 4 supports a mixture of Release 3 and Release 4 components on a single computer. This includes both product components and shared components. Compatibilities between Release 3 and Release 4 components have been tested, and any known incompatibilities are noted in the Java Enterprise System Release Notes (http://docs.sun.com/doc/819-2329).
The coexistence of Release 3 and Release 4 components provides for the possibility of selectively upgrading Release 3 components to Release 4 on a given computer, or within a deployment architecture consisting of multiple computers.
2004Q2
Release 2
Java ES Release 4 does not support a mixture of Release 2 and Release 4 components on a single computer. This includes both product components and shared components. There are known incompatibilities between the release versions, and interoperability between Release 2 and Release 4 components is not certified.
When upgrading components from Release 2 to Release 4 on a given computer, all Release 2 components should be upgraded to Release 4. However, assuming compatibility of components, it is possible to mix Release 2 and Release 4 components residing on different computers within a deployment architecture consisting of multiple computers.
2003Q4
and priorRelease 1
and priorJava ES Release 4 does not support a mixture of Release 1 or prior releases and Release 4 components on a single computer. This includes both product components and shared components. There are known incompatibilities between the release versions, and interoperability between Release 1 or prior components and Release 4 components is not certified.
Java ES Release 4 does not certify the direct upgrade of Release 1 or prior releases to Release 4.
In some cases, however, It is possible to perform an upgrade from Release 1 by upgrading first to Java ES Release 3, as documented in the Release 3 Java Enterprise System Upgrade and Migration Guide (http://docs.sun.com/doc/819-0062).
In other cases the upgrade from Release 1 to Release 4 can be performed in the same way as the upgrade from Release 2 or Release 3 to Release 4, and in those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
Upgrade Dependencies
One of the main issues in planning the upgrade of any given Java ES component is to understand that component’s dependencies on other Java ES components, and whether such other components also need to be upgraded to support the upgrade of the dependent component.
In this respect, there are two types of upgrade dependencies:
- Hard upgrade dependency. A hard upgrade dependency is when an upgraded version of a component requires an upgraded version of some component upon which it has a dependency. This requirement can be due to new functionality, new interfaces, or bug fixes needed by the dependent component. You cannot successfully upgrade and use the component without first upgrading the component upon which it depends.
- Soft upgrade dependency. A soft upgrade dependency is when an upgraded version of a component does not require an upgraded version of some component upon which it has a dependency. You can successfully upgrade and use the component without upgrading the component upon which it depends.
Upgrading a Java ES component requires you to upgrade all the components upon which it has hard upgrade dependencies, but allows you to not upgrade components upon which it has soft upgrade dependencies. (This general rule does not apply to upgrades from Release 2 to Release 4 on a single computer.)
This general rule does not necessarily apply, however, when multiple interdependent components are involved in an upgrade. In such cases, you have to upgrade a component if only one of several other Java ES components has a hard upgrade dependency on that particular component.
Selective Upgrade or Upgrade All
The difference between hard and soft upgrade dependencies allows for the possibility of selectively upgrading Java ES components within a deployed system. This possibility only applies to upgrading from Release 3 to Release 4 on a single computer (see upgrade path characteristics in Upgrade Paths). Selective upgrade from Release 2 to Release 4 on a single computer is not supported.
- Selective Upgrade. The selective upgrade approach starts with the Java ES component you wish to upgrade to Release 4. Determine the hard upgrade dependencies for that component, which includes dependencies on both product components and shared components. Those components also need to be upgraded. You repeat this process for each successive hard upgrade dependency until no further components need to be upgraded. This exercise specifies all Java ES components that need to be upgraded.
The two approaches to performing upgrades are compared in the following table.
The choice between selective upgrade and upgrade all is not rigid. For example, you might choose to selectively upgrade the product components on a particular computer, but wish to upgrade all shared components needed to support the selected product components. In fact, for upgrades from Release 3 to Release 4, selectively upgrading product components, while upgrading all of the corresponding shared components, is often the preferred approach.
Multi-instance Upgrades
The sequence of upgrade procedures can depend on whether and how redundancy is being used in a deployment architecture. Multiple instances of a Java ES component can be used to achieve high availability, scalability, serviceability, or some combination of these service qualities. There are three technologies that make use of redundant components in Java ES deployment architectures: load balancing, high availability techniques (Sun Cluster and High Availability Session Store), and multimaster replication (Directory Server).
In most cases where redundancy is involved, it is desirable to perform upgrades without incurring downtime. These rolling upgrades attempt to successively upgrade redundant instances of a component without compromising the service that they provide.
In most cases the redundant instances are deployed across multiple computers. From an upgrade planning perspective, this might imply isolating the upgrade of such replicated components from other component upgrades in order to achieve minimal downtime. In other words, you might perform all the pre-upgrade tasks for the component on each computer before performing a rolling upgrade of the replicated component.
Each replication technology has configuration or re-configuration procedures that might affect the overall sequence of Java ES component upgrades. For example, components that run in a Sun Cluster environment can require upgrading Sun Cluster before upgrading the components that are running in the Sun Cluster environment.
Java ES Component DependenciesAs mentioned in the previous section, an upgrade plan specifies the Java ES components you need to upgrade and the sequence by which you need to upgrade those components. One of the important considerations in an upgrade plan is the dependencies between the various Java ES components in your deployed system.
Whether you take a selective upgrade approach or you upgrade all components, the sequence by which you perform the component upgrades is affected by the nature of the dependencies between them.
This section provides information about Java ES component dependencies. The following dependency factors impact your upgrade plan.
Each of these factors is discussed briefly in the following sections.
Dependencies On Shared Components
When upgrading Java ES product components, you have to take into account dependencies these Java ES components have on Java ES shared components. When a product component has a hard upgrade dependency on a shared component, the shared component also must be upgraded.
Shared Component Dependency Matrix
Table 1-6 shows the dependencies of Java ES 2005Q4 (Release 4) product components on Java ES shared components. The abbreviations for product components that head the columns of Table 1-6 are taken from Table 1-1. The abbreviations for shared components are spelled out in Table 1-2.
Four product components are not included in Table 1-6: Directory Proxy Server (DPS), High Availability Session Store (HADB), and Directory Preparation Tool (DPT) have been omitted because they have no dependencies on shared components. Service Registry (SR) is omitted because it is a new product component for which there is no previous version from which to upgrade. Web Proxy Server (WPS), another new Release 4 product component, however, is included in Table 1-6 because it can be upgraded to Release 4 from its previous release, which was not included in Java ES.
Within the matrix of Table 1-6 hard upgrade dependencies for Release 3 to Release 4 upgrades are marked “H,” while soft upgrade dependencies are marked “S.” For Release 2 to Release 4 upgrades, all shared component dependencies are, by definition, hard upgrade dependencies; all shared components must be upgraded from Release 2 to Release 4.
The dependencies shown in Table 1-6 for any product component represent both direct and indirect shared component dependencies. In other words, a product component might depend on a specific shared component that, in turn, depends on one or more other shared components. The shared component dependencies shown in Table 1-6 include all such indirect dependencies. The following figure illustrates inter-dependencies among shared components.
Figure 1-1 Shared Component Inter-dependencies
Shared Component Upgrade Guidelines
Table 1-6 lets you determine the shared components to upgrade when upgrading one or more product components on a given computer:
- Release 2 to Release 4 Upgrades. If you are performing an upgrade from Release 2 to Release 4, all the shared components marked as “S” or “H” in Table 1-6 for the respective product components must be upgraded.
- Release 3 to Release 4 Upgrades. If you are upgrading all product components from Release 3 to Release 4, all the shared components indicated in Table 1-6 for the respective product components should be upgraded.
Even if you are selectively upgrading product components, however, it is the recommended practice to upgrade the shared components needed by all product components on the computer; Release 4 shared components are certified to support Release 3 product components.
While selectively upgrading shared components might work in most cases (that is, upgrading only those shared components that support selectively upgraded product components, or upgrading only hard upgrade dependencies compared to soft upgrade dependencies), significantly more risk is involved in adopting this approach.
If no hard upgrade dependencies are involved, you might not upgrade shared components at all. However, as a general rule, it is a good practice to upgrade your underlying Java ES shared component base to the most current versions.
Note
The sequence of upgrading shared components can depend upon the shared component inter-dependencies shown in Figure 1-1.
Also, if you plan to upgrade J2SE to J2SE 5.0, you should upgrade this shared component first. J2SE is the base component for many Java ES components.
For information on how to upgrade shared components, consult Chapter 2, "Upgrading Java ES Shared Components."
Dependencies On Product Components
Dependencies of one product component on another are an important determinant of the Java ES components you need to upgrade and the sequence by which you need to upgrade them. Dependencies on product components fall into two general categories: runtime dependencies and configuration dependencies.
- Runtime Dependencies. The functioning of a software system is based on the interactions between its deployed components. The infrastructure dependencies between Java ES components are discussed in the Java Enterprise System Technical Overview. In upgrading any Java ES product component, you must take into account such dependencies. If an upgraded version of one component has a hard upgrade dependency on another component, that dependency implies that the dependent component should only be upgraded after the component upon which it depends is upgraded.
- Configuration Dependencies. In many cases a Java ES component must be installed, configured, and running for another component to be configured. For example, a Directory Server configuration directory must be running for you to configure Messaging Server components, or a Directory Server user/group directory must be running for an Access Manager service to be registered. Component upgrade procedures often involve re-configuration of upgraded components or migration of configuration data. In fact, some product components’ main function is to provide configuration or administrative support to other components. As a result, configuration dependencies can have a strong impact on the sequence of upgrade procedures.
Table 1-7 shows the dependencies between the Java ES product components listed in Table 1-1. Using Table 1-7, you can diagram the chain of dependencies in your upgrade set. The left column lists each product component, the middle column shows its dependencies on other product components, the third characterizes each dependency, and the last column indicates whether or not the respective components must be local.
General Sequencing GuidelinesThe factors discussed in the previous sections can all impact which Java ES components you plan to upgrade as well as the order in which you upgrade them. These factors also influence your approach to upgrading Java ES components that are deployed across multiple computers. The specific impact of all these factors depends on your deployment architecture.
Nevertheless a few general sequencing guidelines apply, though not in every case. The following list provides the order in which Java ES components can be successfully upgraded on a single computer or in a deployed system. When performing an upgrade, simply omit those components that are not part of your deployment architecture, or, if you are performing a selective upgrade, omit those components which are not part of your upgrade plan.
Note
The chapters in this Upgrade Guide are arranged according to the order you would normally upgrade Java ES components, as indicated by these sequencing guidelines.
- Shared Components (See Chapter 2, "Upgrading Java ES Shared Components")
Shared components should generally be upgraded before the components which depend on them.
- Sun Cluster software (See Chapter 3, "Sun Cluster Software")
If any components run in a Sun Cluster environment, and the Sun Cluster software needs to be upgraded, it should be upgraded before the components that use Sun Cluster services. Sun Cluster agents, if upgraded, should be upgraded as part of the Sun Cluster upgrade.
- Directory Server and Administration Server (See Chapter 4, "Directory Server and Administration Server")
Many components store user data or configuration data in Directory Server, so upgrades to Directory Server should generally be performed before upgrading the components that have runtime or configuration dependencies on Directory Server. Administration Server must be upgraded with Directory Server.
- Directory Proxy Server (See Chapter 5, "Directory Proxy Server")
Directory Proxy Server has a hard upgrade dependency on Directory Server and Administration Server and is therefore upgraded after Directory Server and Administration Server. Other components might access Directory Server through Directory Proxy Server.
- Web Server (See Chapter 6, "Web Server")
A number of Java ES components require the support of a web container, which, if upgraded, should be upgraded before the components requiring web container services. Normally web container services are provided by Web Server or Application Server, but if your architecture contains both, upgrade Web Server first.
- Message Queue (See Chapter 7, "Message Queue")
Message Queue, if upgraded, is best upgraded before Application Server, which requires Message Queue to be Java 2 Enterprise Edition (J2EE) compliant.
- High Availability Session Store (See Chapter 8, "High Availability Session Store")
High Availability Session Store, if upgraded, is best upgraded before Application Server, which requires High Availability Session Store for high availability.
- Application Server (See Chapter 9, "Application Server")
Application Server depends on Web Server for its load balancing plug in, so if you are using that capability, Application Server should be upgraded after Web Server.
- Web Proxy Server (See Chapter 10, "Web Proxy Server")
Web Proxy Server can be upgraded anytime, though generally it would be upgraded after the Web Server or Application Server component for which it provides a proxy service. Web Proxy Server is a new Java ES Release 4 component that can be upgraded from its previous non-Java ES release.
- Access Manager (See Chapter 11, "Access Manager"
Access Manager plays a central role in authentication and authorization, including single sign-on, and, if upgraded, should be upgraded before the components that depend on it for those services. In addition, Access Manager requires specific Directory Server schema (Schema 2), which affects how other components use Directory Server.
- Directory Preparation Tool (See Chapter 12, "Directory Preparation Tool")
Directory Preparation Tool depends on the Directory Server schema and should therefore be run against Directory Server after Access Manager is upgraded. (For an exception to this guideline, see Upgrading Access Manager from Java ES Release 2.) If upgrading Directory Preparation Tool, it should be upgraded before you upgrade the communications components that depend on Directory Preparation Tool to make changes in the directory: Messaging Server, Calendar Server, Communications Express, and Delegated Administrator.
- Messaging Server (See Chapter 13, "Messaging Server")
Messaging Server, if upgraded, should be upgraded only after the preceding upgrades and should be upgraded before Communications Express, which has a dependency on Messaging Server components.
- Calendar Server (See Chapter 14, "Calendar Server")
Calendar Server, if upgraded, should be upgraded after Messaging Server since some of its functions require Messaging Server support. Calendar Server should be upgraded before Communications Express, which has a dependency on Calendar Server.
- Communications Express (See Chapter 15, "Communications Express")
Communications Express, if upgraded, depends on many of the preceding components (Calendar Server, Messaging Server, Directory Preparation Tool, Access Manager, Web Server, and Directory Server) and, if upgraded, should be upgraded after them.
- Instant Messaging (See Chapter 15, "Communications Express")
Instant Messaging, if upgraded, can be upgraded at almost any point after Access Manager has been upgraded.
- Portal Server (See Chapter 17, "Portal Server")
Portal Server, like Communications Express, depends on many of the preceding components, but in particular, it depends on Communications Express to provide messaging and calendar channels, and, if upgraded, should therefore be upgraded after Communications Express
- Portal Server Secure Remote Access (See Chapter 18, "Portal Server Secure Remote Access")
Portal Server Secure Remote Access, if upgraded, can be upgraded anytime after Portal Server has been upgraded.
- Delegated Administrator (See Chapter 19, "Delegated Administrator")
Delegated Administrator, if upgraded, can be upgraded and used to provision users any time after Directory Preparation Tool has been upgraded and run against Directory Server. By convention, users are provisioned after other services have been upgraded and started, however, Delegated Administrator can be upgraded before upgrading the communications components that depend on Delegated Administrator for provisioning users.
