At the recent tech briefing I attended, IBMer Steve Knudson had a great session called "NIM Master Tuning and NIM Master Group Migrations." (He also covers some of this material in this techdoc.) One thing Steve explained in the session was how to get better NIM server performance when you have several clients enabled for installation. I know I'll put this information to use when I'm building out new servers; I often end up deploying dozens of LPARs at once across multiple frames.
He pointed out that with all of this activity happening at the same time, you might experience slow processing when enabling the next NIM client install or resetting a NIM client due to the extensive rereading of /etc/exports. In addition, the NIM master will end up un-exporting and re-exporting NIM resources for different sets of NIM clients.
From the techdoc:
"Consider setting global_export=yes. If you perform frequent simultaneous installs, when one install completes, the default behavior of the master is to unexport NFS exports, remove the completed client from the export lists and re-export the filesystems. During this interval, other 'in-flight' client installs may see the message, 'NFS server not responding, still trying' on the client console."
As an alternative to the traditional way of exporting NIM resources to each client, you can export NIM resources as read-only for all enabled NIM clients. The NIM master will keep them set to read-only until the last client install completes. With no clients enabled, and no reservations held for any resource, you can run:
nim –o change –a global_export=yes master
If you run a showmount –e before and after making the change, you can see the difference. Before the change the resources were exported to particular clients, while after they're exported read-only for all users. This is from Steve's document:
export list for bmark29:
With global_export, exports are read-only for everyone:
Steve does note the potential security issue here, but unless you're worried about users getting access to data in your mksysb file or some such thing, I don't see it as a big deal if others view your AIX install content.
Steve also points out that you can change the max_nimesis_threads attribute from the default of 20 to support a high number of simultaneous installs (16 or more). For example:
nim –c change –a max_nimesis_threads=60 master
Finally, Steve says that while the networking defaults should be fine on a default AIX install, this can verified by running:
When doing so, look for tcp_sendspace, tcp_recvspace, and rfc1323.
Also check that use_isno is set with:
no –a | grep isno
use_isno = 1
As this is a restricted setting in AIX 6.1, the –F flag must be used:
no –F –a | grep use_isno
Steve is a go-to authority on NIM. People still rely upon his NIM basics and advanced slides (from presentations in 2007) to set up their master servers and get in-depth details. It was great listening to Steve's NIM expertise in person.