A Standard Operating Environment LPAR
It is so easy to build an AIX LPAR these days, that we can end up with lots of them very quickly. When this happens, or even before it does, it may be worth building one more : a S
nvironment or SOE. This can provide consistency in your organisation's configuration and make it even faster to build new LPARs without starting from scratch.What is an SOE for AIX?
The NIM from A to Z in AIX 5L Redbook
has a valuable section on building an SOE. Although it's
for NIM on AIX 5, it raises some important issues. The Best Practices section explains that an SOE for AIX systems is "a set of
best practices, procedures, documents, standards, conventions, tools,
and utilities with which you install and administer an AIX server." The server doesn't need to be physical - an LPAR is also a server. It's a logical server, so it doesn't need to have its own dedicated hardware.Virtually ready for an SOE
A virtualised environment makes it easy to build new LPARs very quickly. You no longer need dedicated hardware: disk, network, CPU, memory can all be allocated without hardware investments or even stepping into a data centre. As we've seen before on AIX Down Under
, it's easy to load ISO images via the VIO server
. That makes it straightforward to build a new SOE and then to clone it to create other LPARs. If you prefer to use NIM, you can refer to the Redbook mentioned above as well as online documentation for NIM.Detonate, don't renovate
Plenty of green field AIX sites start out with a single
LPAR which is meant to serve as the "golden image" from which all new
LPARs will be built. If it's the first LPAR then it ends up having all sorts of software installed for testing.
Standards are broken quicker than they are created and what was the
golden image soon looks a little more like it's made of lead. It's probably time to start again.Carrying the
sins of the past
In other situations, a previous "legacy"
version of AIX is in place. It has many mysterious hacks, features,
links, installations and settings which no one really understands and
everyone is afraid to touch. Although you could clone this system, with
its workarounds (that word should always send a shiver up your spine), you will probably find that it's worth making a
completely fresh start with a New
and Complete Overwrite of AIX
. You can always review the old
system's configuration, but at least the changes you make to the new
image will be understood and documented, rather than remaining in the secret realm of IT whizzes from generations before us.Laying the foundations
So how do you build a Standard Operating
Environment (SOE) LPAR from scratch? First, as we saw in an earlier
post, you can install a base AIX using
the VIO server virtual media library
. Every organisation is
different and it's impossible to outline a standard which will fit
everyone, but here are some ideas which will help:
as you go. It's important that if someone else has to build the SOE
again, it will be easy to do. When the SOE changes, the SOE document
should also. And it also needs to be easy to find, so that others can rely on your past efforts without interrupting your holidays ... or your retirement.
the latest AIX. Get the latest fix packs from IBM Fix Central and
use the trusty VIO VM Library to patch it up. Check your prerequisites
are in place (HMC, firmware etc.). AIX 6.1 has been around since
November 2007 and it's got lots of features which make it worthwhile and
necessary to move on from earlier versions. A good starting point is
6.1 Installation and Migration page.
- Use the technology. Take advantage of virtualisation, redundancy, eliminating single points of failure and removing unnecessary dependencies. While we're on the subject, use the standard tools. Too many systems are on old operating system versions because of a single unsupported, unlicensed, unrelocatable* piece of software which can easily be replaced by something that comes with a supported version of AIX.
- Tighten security up front. Use
to turn on security. It's far easier to loosen security settings than
tighten them once you're in production.
- Keep version control. Within the SOE LPAR
you can include a file with a version number. That should get copied when the SOE gets cloned. If a new package gets rolled out to all
LPARs, or a config change needs to be made, you can have a ready history on each cloned LPAR of what SOE
version it was built from.
- Keep a backup of
major SOE releases. The mkdvd command allows you to keep the mksysb
backup of the OS in ISO format. A backup allows a quick load of the ISO image if you need to check
anything from an earlier version or even rebuild your SOE.
Global or local?
Some configurations are likely to be universal across all AIX LPARs. The software and configuration settings which ought to apply to every LPAR, ought to be in the SOE. Other changes will only apply to certain LPARs. Is every LPAR going to be a TSM client, or a DB2 or Oracle client? Does Apache get installed? What about monitoring agents, standard scripts, tuning parameters? Every change from a vanilla install is going to be either global (on the SOE) or local - restricted to a limited number of LPARs. Once you understand which changes belong to which category, you're a long way towards building your SOE LPAR. The more localised software might be sitting in a common file system, perhaps on a NIM server or in a management LPAR.Learning to SOE
There are many more factors in building a SOE LPAR - it's impossible to cover them all here. But if you have a good grasp of the steps involved, you could have a new SOE LPAR built by this afternoon (except that I'm writing this late at night, Sydney time, but you get the point).* I'm not sure if "unrelocatable" is a real word, but my surname is English, so I reserve the right to invent my own dictionary.