[Nemeth10] 13.6. Management of the AIX kernel

来源:百度文库 编辑:神马文学网 时间:2024/04/30 15:14:58

13.6. Management of the AIX kernel

The AIX kernel never requiresa rebuild. New devices are configured dynamically through IBM’smysterious black box known as the Object Data Manager (ODM).

It’s an enigmaticsetup. Many parameters that are commonly tunable on other kernels, suchas shared memory settings, cannot be tuned at all on AIX. Instead, theyare managed independently by the kernel. Other configurable options aremanaged through a series of six tuning commands.

The Object Data Manager

Rather than keepingdevice configuration information in text files or scripts, AIXsquirrels it away in the Object Data Manager (ODM) attribute/valuedatabase. Another layer of glue associates these property lists withspecific devices (driver instances, really) and binds the drivers tothe configuration information.

AIX’s intent is to supportpersistence for device configuration. Rather than having one way toconfigure devices on the fly (e.g., ifconfig or ndd)and a parallel system of configuration files and scripts that doconfiguration at boot time, AIX’s scheme attempts to unify thesefunctions so that most device changes are automatically sticky acrossreboots.

However, if you take the redpill and look at what’s actually going on within the system, theunderlying complexity can be daunting. The system has more entry pointsthan traditional UNIX, and the interactions among the components aren’talways obvious. Here’s an outline of the various layers:

  • The Object Data Manager is a configuration repository that’s analogous to the registry in Microsoft Windows. It’s actually a bit more sophisticated than the Windows registry in that it has the concept of object schemas and instances rather than just arbitrary property lists.

  • Programs access ODM through library routines, but you can also work with the ODM database through the odmadd, odmcreate, odmdrop, odmshow, odmget, odmchange, and odmdelete commands.[2]

    [2] Dan Foster, one of our technical reviewers, commented, “Direct manipulation of the ODM with the odm* tools is not recommended if you don’t know exactly what you’re doing. These commands do no error checking on the data you modify, whereas the normal ch*/mk*/rm* tools validate data prior to making changes. The odm* tools are like a loaded AK-47 with no safety mechanism: one quick touch, and you’ve discharged several rounds into an eviscerated target.”

  • The command family chdev, lsdev, lsattr, mkdev, rmdev, lsconn, and lsparent maps ODM configuration information to specific devices. AIX’s chdev is actually quite similar to the Solaris and HP-UX ndd command (see page 498), but by default chdev writes your changes both to the active driver and to the ODM configuration database. Even common parameters such as the system hostname and the details of static routes are stored as device attributes (the device in this case being an instance of the “inet” driver).

  • Several administration utilities provide front ends to the chdev family. For example, mktcpip is sort of like a persistent ifconfig that converts its arguments into a series of chdev calls on network interfaces, affecting both the active and saved configurations. (Would you guess that its syntax mirrors that of ifconfig? You guessed wrong.)

  • ODM is a user-level facility, so drivers don’t access it directly. Just as with traditional text-file configuration, some software must read the ODM configurations at boot time and poke the appropriate values into the running drivers.

Fortunately, most administrators need not touch the complexities of ODM thanks to SMIT and to higher-level tools such as mktcpip.

One indispensable utility for managing AIX devices is the cfgmgrcommand. Run it as root with no arguments after adding new hardware tothe system; the new hardware will miraculously be recognized and becomeavailable for use. Well, usually. If the device drivers haven’t alreadybeen loaded into the ODM database, cfgmgr will helpfully suggest a package for you to install from the AIX installation media. See the cfgmgr man page for further details.

Kernel tuning

AIXhas six categories of tunable values and supplies six correspondingcommands for tweaking them. Most of the values relate to performanceoptimization. Table 13.6captures each command and its purpose. Breaking from standard AIXconvention, the commands share a common syntax. The parameters can alsobe managed through the SMIT interface with the incantation smit tuning. See the man page for each command for detailed information.

Table 13.6. Commands for setting tunable kernel parameters in AIX
Command Domain Examples of things you can configure vmo Virtual memory Minimum number of free pages ioo Input/Output Asynchronous I/O behavior JFS2 configuration schedo Process scheduling Process time slices and priorities Virtual process management no Network IP forwarding

TCP and UDP socket buffer sizes

Packet time-to-live values nfso NFS UTF-8 support

Delegation support

Maximum number of NFS connections raso Reliability Only a few tunables, none of which are particularly valuable to administrators

The commands are simple to use. To enable IP forwarding, for example, run

aix$ sudo no -o ipforwarding=1

To list all available tunables for the I/O subsystem, type

aix$ sudo ioo -a

You can add the -r flag to any of the commands to ensure that your changes persist after a reboot.