Sunday 17 March 2013

AIX Updates: Committed Admins Need not Apply

The traditional approach to installing AIX fixes was toapplythem rather than commit them. What's the difference? When you install updates using SMITTY or the installp command's apply flag (installp -a), the previous version is first saved to a directory. You can then test the newly installed updates. If for some reason you face a problem with them, you can reject them (installp -r) and revert to the earlier version. If you're happy with the new version of filesets (as is usually the case), you can commit them (installp -c). This cleans out the older version and saves you some disk space. 

First, it's important to note this is all about installing AIX updates -- in other words, installing fixes to the existing major release of AIX. So if you're moving from AIX 6.1 to a more recent Technology Level (TL) or Service Pack (SP) of AIX 6.1, you have the option to apply or commit your updates. If you're migrating to a new release (for example, from AIX 6.1 to AIX 7.1), then you're upgrading the Base Operating System (BOS). This necessarily means you will be committing the filesets that get installed, as you can't reject them without reverting to a full OS backup of some kind. 

Back to the AIX fix updates. “Apply first, test, and then commit (or reject).” That's the way we've been working since the day dot. The advantage was a quick rollback by rejecting the new filesets. The cost was a little extra space in the / and /usr file systems for saving older filesets. After a few days of running your system without a hitch, you could commit the filesets which were in the apply state, and reclaim that file system space. 

Does the old “apply” strategy still apply?
Now, when you upgrade to a new TL, you're installing an “all-or-nothing package.” For TL updates, the reject process does not work well and is not supported, according to an IBM Technote (see the Resources section below). So the apply option for TLs seems to have no advantages. 

What about Service Packs?
Service Packs are smaller than Technology Levels, but Service Packs that are installed as a whole (the preferred method) require a reboot. If you were to apply the SP's updates, reboot, and test them, and then decide to reject them, that also would require a reboot. Either way, a rollback plan from a full Service Pack involves a reboot. So if you're going to have to reboot anyway, the back-out plan would be best to include a bootable pre-update version of the OS. It takes little preparation time, and shouldn't involve any downtime prior to the installation of AIX updates. 

You can create the pre-update image by building a clone of rootvg via the alt_disk_copy command. This requires an additional disk to copy the existing rootvg. Another approach is to use multibos, which allows you to install a standby instance of the OS on the same disk as your existing rootvg. You can see details of these methods in the links in the Resources section. 

Quick Escape Plan
There may be a case for applying updates, rather than committing them up front, but it's still best to have a bootable back-out method, both for TLs and for Service Pack updates. 

AIX provides a few methods for rolling back after installing updates, if you need to do so. You can still install updates by applying them first and committing later, but this doesn't seem to have the importance or relevance it used to have. Even if you do keep the old approach, it's hard to beat having an pre-update image ready that you can return to with a simple reboot. 

Resources 

IBM AIX OS Release and Service Delivery Strategy 
http://www-03.ibm.com/systems/power/software/aix/support/release_strategy.html  

Recommended process for Updating to a new Technology Level or Service Pack (IBM Technote) 
http://www-01.ibm.com/support/docview.wss?uid=isg3T1010755  

Different Supported ways of updating to a new Technology Level 
http://www.ibm.com/developerworks/aix/library/au-aixtlupdate/index.html  

Installing Technology Levels and Service Packs for AIX 
http://www.ibm.com/developerworks/aix/library/au-aixservicepacks/ 

No comments:

Post a Comment