 |
» |
|
|
|
|  | |
It can take something like a full shift to upgrade a single,
moderately complex system. (Detailed time estimates are in Chapter 3 “Planning a System Upgrade ”.) This does not mean
you can only upgrade one machine a day; much of the downtime is
taken up by the software loading files and converting the filesystem
layout and configuration files. But it does mean you should not
plan to upgrade an entire site in a day — a small workgroup
of fewer than ten similarly configured machines is probably the
most you should plan to get done without help. If you manage more machines than that, you will need a strategy
for staggering the upgrades over a period of time, possibly an extended
period of time if you need to order new hardware for some machines,
or if some systems run third-party applications that have not yet
been certified on 10.x. Factors To Take into
Account | |
Your strategy will probably need to take account of the following: Need: which systems need 10.01 or 10.10 soonest. Ease: which systems require the least work to upgrade. Affinity: which systems are similar. Interoperability: which machines depend on which
others.
You and your users must determine which systems need HP-UX
10.01 or 10.10 the soonest. The Release Notes for HP-UX
10.10, and the Release Notes
for individual HP products, provide summaries of the new features. The snoop
tool, provided with the 9.x-to-10.01 upgrade software, will help
you identify what, if anything, must be done before a given system
can be upgraded (see Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”
for details). In general, defer upgrading systems that will require the
most work, allowing time to order disks, memory or software, and
to do additional administration such as removing unneeded filesets. Plan to upgrade similar systems at the same time. Once you
have successfully upgraded the first system, you should be able
to take shortcuts with the remaining systems. See “Strategy for Similarly
Configured Systems ” later
in this chapter. By interoperability we mean the ability
to share resources such as NFS-mounted file systems and network
printers. Systems that provide applications or services to a common
pool of users should also be considered under this heading. Plan to upgrade systems that require interoperability at the
same time, as far as possible. If it is not possible, you will need
to plan for systems still running 9.x to continue to operate with
systems running 10.x. HP has provided tools to facilitate this;
see “Operating 9.x and 10.x Systems
Together ” later in
this chapter. Shared HP-UX "System"
Directories It is possible for 9.x systems to share HP-UX "system" directories
by means of NFS mounts; for example, one workstation might mount
/usr/local from
another workstation that has more disk space. It is not possible to share such directories
between 9.x and 10.x systems. For example, If you try to upgrade
a 9.x system that has /usr/local
NFS mounted from another 9.x system, the result will be: /usr/local
on the remote system will not be touched. The 10.01 files that should go into /usr/local
will not be loaded.
In this case, you should do the following: Arrange to upgrade all systems sharing any 9.x "system" directory
(such as directories under /usr)
on the same day or during the same shift. Shut down all of these systems at the same time. Upgrade the NFS server system. Users of this system can now log back in. Upgrade the NFS client system(s). This will unmount all the NFS-mounted directories, leaving
empty directories in their place. These directories will still be
empty at the end of the upgrade. Remount the NFS-mounted directories on the client
system(s). Users can now log back in.
A Sample Strategy | |
Your site upgrade strategy might look something like this: Sketch out the order in which you would ideally like to upgrade
your systems, given your users' needs for 10.x features, 10.x-compatibility
of critical applications, and so on. Understand the 9.x-to-10.x interoperability issues,
and familiarize yourself with the tools and procedures HP has supplied
to help solve them (see “Operating 9.x and 10.x Systems
Together ”, later in this chapter). Choose "typical" systems and analyze them using
the tools supplied by HP (see Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”). By "typical", we mean a system that is similar to a number
of other systems in hardware type (Series 700 or 800), disk space,
and peripheral and networking configuration. (If you have a number
of systems that are very similar, you may be
able to use the procedure suggested under “Strategy for Similarly
Configured Systems ” later in this chapter.) Use this analysis to pre-qualify the remaining systems
on your list. You should be able to divide the list roughly into three categories: Systems that can be upgraded with minimal
preparation and post-upgrade effort. These would be systems on which all of the following are true: Critical third-party binary applications are certified
for 10.x. Most 9.x applications should run without problems on 10.x,
because of transition links that link 9.x
HP-UX pathnames to their 10.x equivalents (see Chapter 5 “Converting Code and Scripts ” for more information.) But, to be certain,
you should contact application suppliers, and you may also want
to pre-qualify critical applications on a 10.x test system. The prepare
tool reports few compatibility problems in source code and scripts,
other than HP-UX pathname differences (which transition
links handle). See Chapter 5 “Converting Code and Scripts ”.
Cases that will take more time. These would include systems that need more disk space, or
need hardware upgrades, or form part of an HP-UX cluster (see “Converting HP-UX ("DUX") Clusters”, later in this chapter);
or that run critical code or scripts that require modification for
10.x (see Chapter 5 “Converting Code and Scripts ” and Chapter 8 “Compatibility between 9.x Releases
and 10.01 ”). Systems that can't be upgraded, for example Series
300 systems (see Chapter 3 “Planning a System Upgrade ”).
Rework your list so that systems near the top have
the following characteristics: Need to run 10.x as soon as possible. Present few or no problems for upgrade. Run code and scripts that require little conversion
effort. Are typical of a number of other systems.
We'll refer to these as "good candidates" from now on. Resolve any configuration problems the tools report
on the "good candidate" systems (see Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”). Decide on your strategy for converting source code
and scripts on the "good candidates" (see Chapter 3 “Planning a System Upgrade ”). Convert source code and scripts on the "good candidates"
if you so decide (see Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”
and Chapter 5 “Converting Code and Scripts ”). Pay particular attention to code or scripts that are re-used
on several systems; it may be a good investment of time to convert
these now. Users' .login
and .profile
scripts may also need individual attention if they are heavily customized. Upgrade the "good candidate" systems to 10.01 (see
Chapter 6 “Upgrading Your System from 9.x to
10.01 ”). Convert startup and shutdown scripts, and do other
post-upgrade tasks, on the "good candidates" (see Chapter 7 “After the Upgrade ”). Upgrade applications on the "good candidates", and
update them to 10.10 if you so decide. | | | |  | NOTE: You must upgrade systems running
9.07 to 10.10. You will initially upgrade these systems to an intermediate
version of 10.01, but that version is supported only
for the purposes of upgrading it immediately to 10.10. | | | | |
Implement 9x-to-10.x interoperability strategies
on systems that cannot be, or will not be, upgraded soon (see “Operating 9.x and 10.x Systems
Together ”, later in this
chapter). Analyze the remaining systems (see Chapter 4 “Pre-Upgrade Tasks for All 9.x Systems”. Upgrade the remaining systems (see Chapter 6 “Upgrading Your System from 9.x to
10.01 ”). Convert startup and shutdown scripts on the remaining
systems (see Chapter 7 “After the Upgrade ”), or copy
these scripts from a similar system that has already been upgraded. Upgrade applications on these systems, and upgrade
them to 10.10 if you so decide (see Chapter 7 “After the Upgrade ”).
Strategy for Similarly
Configured Systems | |
If you have several systems that are much alike in their configuration
and are all used for the same or similar purposes, you may be able
to simplify the procedure outlined above. For example, you might have a workgroup of Series 750s, all
running HP-UX 9.05 and the same version of the most commonly used
or mission-critical applications from a single root disk and single
LAN card, with similar networking and I/O configuration. For such a group of similar systems, you can do the following: Run snoop
to analyze one system (see “Running snoop ”). Fix any problems snoop
reports (see “Modifying Your System ”). Analyze source code, .login
and .profile
files and other user scripts, and convert them if necessary (see
Chapter 3 “Planning a System Upgrade ” and Chapter 5 “Converting Code and Scripts ”). Upgrade this system to 10.01 (see Chapter 6 “Upgrading Your System from 9.x to
10.01 ”). Modify system startup and shutdown scripts and do
any other post-upgrade tasks that may be necessary (see Chapter 7 “After the Upgrade ”). Install and test converted 9.x code and scripts
if necessary. Qualify 9.x application binaries using your normal
regression-testing procedures. Upgrade HP applications (and third-party applications
for which a 10.x upgrade is available), and updatee this system
to 10.10 if you so decide. Fix any problems on the remaining systems that snoop
warned you about when you ran it on the first system. Run snoop
in unattended mode on each of the remaining systems (see “Modifying Your System ” for an example). Check the snoop.log
file on each system to make sure there are no PROBLEMS,
and no CAUTIONS
you do not already know about from the first system. Run upgrade
in unattended mode on each of the remaining systems. Make sure you check the logfiles before allowing users back
on (see “Examining the Upgrade Log Files”). Copy over code and scripts from the first system
to each of the remaining systems, adapting them to the individual
systems and re-testing them as needed. Copy over application binaries certified on the
first system. Upgrade HP applications (and third-party applications
for which a 10.x upgrade is available), and update the remaining
systems to 10.10 if you so decide.
Sharing Disk Space | |
If you have one large Series 700 or 800 system (with plenty
of spare disk space and memory), and one or more low-end Series
700 systems, you may want to consider implementing NFS
Diskless. You can save disk space by upgrading the large system to 10.01,
configuring it as an NFS Diskless server, then booting the remaining
systems as NFS Diskless clients, freeing up space on the clients'
local disks (you can now remove the HP-UX 9.x files from these disks). See the 10.01 version of the HP-UX System Administration
Tasks manual for information on configuring and managing
NFS Diskless; for a high-level overview, see the Release
Notes for HP-UX 10.10. (Instructions for getting the
Release Notes for HP-UX 10.10 from the 10.01
upgrade tape or CDROM are under “Locating and Loading Tools and Documentation”.) |
Printable version
