| |
|
| Sun Java Enterprise System Upgrade Guide for HP-UX | |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade of Sun Java™ Enterprise System (Java ES) 2005Q1 (Release 3) 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-0061). 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. 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. On HP-UX similar technologies are employed for managing installed software packages and tracking changes through a package registry.
The Java ES packages can be installed and removed through the HP-UX swinstall and swremove 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 swinstall and swremove commands.
Patches to HP-UX packages are distributed through the SunSolve website at: http://sunsolve.sun.com.
HP-UX patches can patch one or more packages. The swinstall command saves a backup of the package being patched to facilitate the removal of the patch using the swremove 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.
Operating System Issues
The operating system issues impacting the upgrading of Java ES software are 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.
HP-UX platform update releases are available at:
Select “Jun’04(11.11 Support Plus)”
Upgrade PlanningThe approach you take for upgrading a deployed Java ES Release 3 software system to Java ES Release 4 can depend on many factors:
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 possible to achieve that end with minimal downtime.
These two examples represent upgrade scenarios of very different complexities, requiring substantially different upgrade plans.
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.
Upgrade Paths
Because of the different characteristics of the Release 3 to Release 4 on HP-UX, upgrade paths involves upgrade from JES3 to JES4, 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 is captured.
The upgrade path to Java ES Release 4 are described in the following table:
Table 1-4 Upgrade Paths to Java ES 2005Q4 (Release 4)
Product Number
JavaES
ReleaseUpgrade 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/app/docs/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.
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 where an upgraded version of a component requires an upgraded version of some component upon which it has a dependency. You cannot successfully upgrade the component without first upgrading the component upon which it depends. In other words, the Release 4 version of the component is not compatible with the Release 3 version of the component upon which it has a dependency.
- Soft upgrade dependency. A soft upgrade dependency is where 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 the component without upgrading the component upon which it depends. In other words, the Release 4 version of the component is compatible with the Release 3 version of the component upon which it has a dependency.
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 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.
Upgrade All
Java ES Component Dependencies
As 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.
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.
Directory Preparation Tool (DPT) is not included in Table 1-6 because it has no dependencies on shared components. Service Registry (SR) and Web Proxy Server are omitted because they are new product components for which to upgrade previous version from which to upgrade.
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.”
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 Components 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 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.
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, refer 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.
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 (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.
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.
- Directory Server and Administration Server (See Chapter 3, "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.
- Directory Proxy Server (See Chapter 4, "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 5, "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, but if your architecture contains both, upgrade Web Server first.
- Message Queue (See Chapter 6, "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 7, "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 8, "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.
- Access Manager (See Chapter 9, "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 10, "Directory Preparation Tool".)
Directory Preparation Tool depends on the Directory Server schema and should therefore be run against Directory Server. 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 and Calendar Server.
- Messaging Server (See Chapter 11, "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 12, "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 13, "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 14, "Instant Messaging".)
Instant Messaging, if upgraded, can be upgraded at almost any point after Access Manager has been upgraded.
- Portal Server (See Chapter 15, "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 Remote Access (See Chapter 15, "Portal Server".)
Portal Server Secure Remote Access, if upgraded, can be upgraded anytime after Portal Server has been upgraded.
- Delegated Administrator (See Chapter 16, "Portal Server Remote Access".)
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.
