In 2006, all the rules changed with respect to operating system upgrades in AIX. Even the
nomenclature has changed from maintenance level (ML) to technology level (TL). Is this
just a rebranding or are there substantive changes here? What about best practices? When
should you deploy technology- (maintenance) level upgrades? Furthermore, what is the best
way of retrieving upgrades, service packs, and fixes? Finally, how do you actually
perform a TL upgrade?
This article explains all of these concepts and discusses recent changes to the upgrade
methodology. In doing so, you'll review important new concepts such as the Concluding
Service Pack (CSP), which is the final service pack of a TL. You'll even walk through an
actual upgrade of a system where you'll be working with systems such as the IBM®
Service Update Management Assistant (SUMA) and Fix Central. SUMA helps the systems
administrator automate the retrieval of AIX updates. Fix Central is the Web-based central
repository for all TLs, services packs, and fixes, including hardware firmware. Finally,
you'll learn the rationale in determining when you should deploy a TL upgrade.
Technology level overview
Although some systems administrators still use the term "maintenance level" when
discussing their AIX version, the term is now reserved for legacy AIX systems. The new
IBM methodology dictates two TL releases per year. The first TL includes hardware
features, enablement, and software services. The second includes software features in the
release, which means the second release is larger and more comprehensive. Finally, there
is also now support for new hardware on older TLs.
Historically, new hardware was only supported in new technology releases, which obviously
required an upgrade to the new level. The way AIX now supports new hardware is broken
down into two categories. The first category is support. First, AIX has actually
undergone changes allowing it to recognize new hardware at boot time. Changes to support
the new hardware include, at a minimum, updates of tables that are referenced at boot.
These determine the processor type and how to create new boot media. The second category
is referred to as exploitation, which requires AIX to undergo more pervasive changes to
the operating system, such as changes to the Virtual Memory Manager (VMM) to exploit new
pages sizes. This new release strategy was first implemented in 2007, starting with AIX
V5.3 TL6, which was the first level to have two-year support.
Service pack overview
What about service packs? A service pack (SP) contains groups of Program Temporary Fixes
(PTF)s for highly pervasive issues. Service packs are cumulative and are generally
released every four to six weeks after the release of a new TL. Service packs can include
any of the following:
- Customer-reported problems that can't wait until the next TL.
- Critical problems reported by development teams.
- Limited changes to support new hardware, such as device drivers' kernels changes to
reflect a new processor. These are changes that do not add new functionality. New
functionality will only be added for TLs or new releases. SP release schedules are
approximately every four to six weeks.
So, what happens between service packs? Interim fixes, sometimes referred to as fix packs
or temporary fixes, or stand-alone PTFs, are made available for relief until the time
that the fix becomes available in a service pack. It's what IBM calls "temporary relief."
They are tracked on the system with either the
lslpp -L command or
emgr -l command.
Security updates, published through advisories, are made available by IBM through
subscription services.
Concluding service packs
Another important concept to understand is the Concluding Service Pack (CSP). The CSP is
the final service pack for a TL. It usually contains fixes for critical problems or
security issues. The new strategy also includes a longer period of support for each OS
TL. Each TL will now be supported for up to a two-year period. This means that you can
continue to call IBM support for up to a two-year period (from the introduction to the
update) without having to move up to the latest TL. The new server update strategy also
promises improved serviceability throughout the life of TL. This is done by allowing you
to maintain your operating system by installing service packs and PTFs throughout the
entire lifecycle of the TL.
Automating TLs and service pack deployments with
SUMA
The IBM Service Update Management Assistance (SUMA) is an extremely important system
because it allows you to automate the retrieval of TL and service pack deployments. In
this section, you're going to use SUMA to retrieve TLs. SUMA was first released with AIX
V5.3. More than anything, SUMA helps the system administrator automate the retrieval of
AIX updates, allowing the administrator to get away from the mundane tasks of manually
retrieving updates from the Web. Furthermore, it allows you to configure policies to
automatically download either entire TL upgrades, service packs, or even interim fixes.
The primary objective of the utility is to allow systems administrators to spend more
time on proactive systems administration and less time on redundant or tedious work such
as downloading updates.
So, how do SUMAs work? Essentially, they use a scheduling module that allows policies to
be run at predefined intervals, which conform to your maintenance window. The policies
can be configured easily without any extensive configuration. You even have the option to
manually run SUMA (either from smit or the command line) to bring in whatever updates you
require. To configure SUMA, you need to know the fix type. There are eight different
kinds of fix types. They include APAR, PTF, Critical, Security, I/O Server, Latest (all
fixes), Filesets (specific types), and Maintenance Levels. In addition, there are three
types of actions you can perform on a policy. These include preview, download, and
download and clean. Preview mode does not really do anything; it just generates a preview
of what would be downloaded. The "download only" action downloads the actual data, while
the "download and clean" action removes filesets no longer necessary after a new fix
level has been brought down. This limits the size of the data that you'll need to
keep.
You can run the suma command from either smit or the command line. In the first example,
use smit to download an entire TL:
# smit suma.
When the smit screen comes up, choose
Download Updates Now (easy) and
click
Enter.
Figure 1. Downloading updates from the smit screen
From this screen, scroll down to
Download Maintenance Level or Technology
Level and click
Enter (see Figure 2).
Figure 2. Selecting Download Maintenance Level or Technology
Level
At the window in Figure 3, click
F4 and choose the appropriate TL
level.
Figure 3. Choosing the appropriate TL level
In this case, it is 6100-01, as shown in Figure 4.
Figure 4. TL level of 6100-01
Click
Enter and let it run. When it completes, you'll see a summary, as
shown in Figure 5.
Figure 5. Summary page
This provides you with the following summary:
- 59 downloaded
- 0 failed
- 36 skipped
Now try it from the command line. In this case, you're going to download TL Two for AIX
V6.1. Do this by running the
suma -x command (see Figure 6).
Figure 6. Running the suma -x command
After about 30 minutes, it completes successfully (see Figure 7).
Figure 7. Command completed
The files get installed in /usr/sys/inst.images, which is where you would also manually
put them if you were to retrieve them using different processes.
Why is SUMA important? Perhaps most importantly, it helps to ensure that your systems have
the latest patches that it needs. Current fixes are important. Secondly, it downloads the
patches without intervention, which allows the systems administrator to focus on more
important tasks.
Fix Central
This section reviews Fix Central and discusses how to use it to download TL and service
pack deployments. Fix Central is the central repository for all TLs and service packs for
AIX. Among other things, you'll see how to log into Fix Central and retrieve service
packs. Completely revamped in October of 2007, it provides fixes and updates for all your
software, hardware, and operating systems. This includes the Hardware Management Console
(HMC). Using Fix Central, you can download using the following options: by APAR, Fix ID,
or Test. In addition, there are three download options, IBM Download Director, HTTP, and
FTP.
Download a service pack from the exact TL that you downloaded previously during the work
with suma from the command line -- 6100-02. First go to Fix Central for System p®,
as shown in Figure 8 (see
Related topics for a link to Fix
Central).
Figure 8. Fix Central for System P
From here, in the drop-down menu, choose your version. Another drop-down menu pops up,
which is where you can select from one of the following: fix packs, fix recommendations,
fix search, managing updates, and security advisories. Choose
fix pack.
Click
Continue (see Figure 9).
Figure 9. Choosing Fix packs type
From here, select the TL: 6100-02. At this time, you can either download the latest
service pack or the entire TL. Choose the entire TL (see Figure 10).
Figure 10. Choosing the entire TL
The options for download include Download Director, bulk FTP, or CD. In this case, use
Download Director. I recommend this method because it has a friendly interface and there
is also flexibility to pause downloads.
Figure 11. Download Director
The length of time is dependent on your Internet connection. For me, on broadband, this
took roughly an hour.
As a systems administrator, the Fix Central URL should definitely be one of your browser
favorites. Fix Central helps you keep your systems up to date and is the best method of
manually retrieving data for your upgrades. You really can't be an effective AIX systems
administrator without knowing how to use this tool.
Upgrading a TL
Now review the procedures to upgrade your system to the next TL.
First log in as root:
# su - root. Make sure you back up your system. If you
prefer, you can also use alt_disk_install or multibios; the bottom line is that you need
to have a plan B if you must go back to your prior level. You should also commit them,
because they can't be rejected and they also make it easier to track and reject PTFs.
Do a backup using the following command:
# mksysb. When the backup is
completed, you're set!
Installation
Create a .toc file. This is done by running the inutoc command (see Figure 12). You run
this in the directory where your filesets reside. If you don't have the .toc file, your
update will not work.
Figure 12. Running the inutoc command
When this is completed, you are ready to start the upgrade. Move to the directory where
your .toc file resides. If you do this, you will not have to specify a path name during
your upgrade:
# smit update_all.
On the screen in Figure 13, you will be making several changes.
Figure 13. Update software screen
For Input device/directory for software, put in the dot (.). If you remembered to cd to
the directory that has the .toc file, you don't need to specify the full path name. In
this case, you did not commit the software, though as a practical matter because you
can't back out of a TL upgrade, you really should say yes to limit the amount of filesets
stored on your system -- a real disk hog. In this case, you first previewed the data to
ensure that there would not be any problems. This is the third option on this smit menu
(shown in Figure 13). The preview option does nothing except validate whether something
might be missing as a prerequisite of the upgrade. This is good to do to avoid surprises.
You don't want to find out something is missing during your two-hour maintenance window
of the month. You can run a preview at any time without any impact to the system.
In our case, as you can see in Figure 14, the preview is successful and there are no
failures. So you are ready to move on.
Figure 14. Output of the preview
When you are ready to run the upgrade, change the preview to
no. You will
also have to change the default field that relates to << Accept new license
agreement >>. For some reason, AIX defaults to no. Change it to
yes.
After you click
Enter, it will prompt you to make sure you want to do
this. Click
Enter to continue to start the process (see Figure 15).
Figure 15. Start the upgrade process
This can run for up to an hour, depending on the speed of your system and the type of
upgrade you are performing. When the process is complete, you can scroll down to the
summary section to see if you've been successful, which in this case is yes. (see Figure
16).
Figure 16. Success
Your final step is to reboot the box. Make sure you perform this step before bringing your
applications back and going live. After I rebooted the box, I ran the oslevel command to
confirm the new system level (see Listing 1).
Listing 1. Confirming the new system
level
1
2
|
lpar46ml16fd_pub > # oslevel -s
6100-02-01-0847
|
What does this information signify? It tells that you are running AIX V6 TL2, service pack
1, released in 2008 in the 47th week. The forth field, 0847, indicates the year and week.
Finally, it is highly recommended that you apply the latest service pack when moving to
the new TL. In our case we did not have to, because the latest pack was already a part of
the TL upgrade.
TL upgrade deployment schedule
When should you actually perform a TL upgrade? There are generally three scenarios where
you will make this choice:
- When your TL is going out of the available support period.
- You want to test a new distribution level that will be going into production and need
to get the longest period of fix support.
- You want to use the new features and functionality of the TL.
The short answer is that there really is no right or wrong time to perform an upgrade.
Some clients need an environment that requires maximum uptime and stability. These
clients typically wait until new TLs are out for at least six months to a year before
applying them. Other folks will wait for several TL's to be put into place prior to
upgrading to ensure maximum reliability. For clients that like to take advantage of new
features and ensure that they have the latest security patches, they typically install
new service packs shortly after they come out. From a vendor-support perspective, IBM
would prefer if you upgraded your TLs (and service packs, for that matter) as soon as
they come out. The reason is that it's just easier to support systems that are always at
current levels. I like to upgrade at least once a year to a new TL. In doing so, I will
also usually wait until at least service pack number two has been released. If you really
want to err on the side of caution, wait until service pack number three. That way, you
will know that your release is really rock solid.
Summary
This article,discussed how to work with technology upgrades and service packs on AIX. It
reviewed recent enhancements and changes in both nomenclature and substance. At the same
time, it discussed best practices on how and when to upgrade environments. It looked at
various methods at bringing the data to our systems: automatically using SUMA and
manually with the IBM Fix Central. The article also performed an actually upgrade (with
smit) using a download performed using SUMA.
A stretched cluster configuration can also be used with PowerHA 7.1.2 Standard
Edition with the use of LVM cross-site Mirroring. The stretched cluster is capable
of using all three levels of cluster communication (TCP/IP, SAN heartbeat and
repository disk). The distance can be up to 15 km, with direct SAN links and up to
120 km with dense wavelength division multiplexing (DWDM) or coarse wavelength
division multiplexing (CWDM) or other SAN extenders. This provides for synchronous
replication or mirroring.
All the interfaces are defined in this type of configuration as CAA gateway
addresses. CAA maintains the repository information automatically across
sites through unicast address communication.
