AIX - NIM - Ressources

Client (nim client) :
Any standalone machine or lpar in a NIM environment other than the NIM master. Clients use resources that reside on the NIM master to perform various software maintenance, backup, or other utility functions.
*Note that NIM resources do not always have to reside on the NIM master, but for our purposes they all will.

Groups (machine groups) :
In the spirit of convenience you can create a machine group which consists of a number of NIM clients. All NIM operations initiated from the master to that machine group subsequently are performed to all machines that are part of that group. For example, you can define a machine group and call it “Group1”. Group1 has ClientA, ClientB, ClientC, and ClientD in it. You can initiate a bos_inst operation to each individual client, or if all clients are being installed with the same image, you can initiate the bosinst operation to Group1. All client systems will be installed at the same time. The downside to this however, is that you sacrifice performance for convenience. It is best if you decide to use machine groups to test out what sort of load your network and NIM master can hold before seeing diminishing returns.

Master (nim master) :
The one and only one machine in a NIM environment that has permission to run commands remotely on NIM clients. A client can only have one master, and a master can not be a client of any other master. The NIM master must also be at an equal or higher OS/TL/SP level than any client in the NIM environment. The NIM master also can not create SPOT resources at a higher level than it is currently installed at. Finally, the NIM master can not install any clients with an OS/TL/SP higher than his own. Long story short, for all intents and purposes, for any NIM operation, make sure you master is at an equal or higher level.
The NIM master also will hold all of our NIM resources. Due to this we’ll want to make sure the NIM master has plenty of space available to it. Ideally, having a separate volume group (nimvg) is beneficial, so the rootvg does not get out of control in size.

Resource (nim resources) :
This can be a single file or up to a whole filesystem that is used to provide some sort of information to, or perform an operation on a NIM client. Resources are allocated to NIM clients using NFS and can be allocated to multiple clients at the same time. Various resource types will be explained below. I’ve decided to order them in a logical order of description rather than alphabetical order. It should make more sense to read through them in this manner.

lpp_source
When running an installation of a system outside of NIM, you use an installation CD. NIM uses resources. Two of the most important resources are made using the installation CD. First of all let’s understand what exactly is on an installation CD that allows us to install a system. There are 4 parts :
- The filesets that get installed.
- The .toc file so the system knows what filesets are on the media.
- The boot images so the CD can boot the system initially
- A /usr filesystem to run the commands needed to install the system.


The lpp_source is created from an AIX installation CD and is responsible for holding :
- The filesets that get installed.
- The .toc file so NIM knows what is available in the lpp_source to be installed to the client.

In short, the lpp_source is simply a depot. It’s just a directory that holds all of the filesets and the .toc file.

SPOT
The SPOT resource (stands for Shared Product Object Tree in case you were wondering) is responsible for the following :
- Creating a boot image to send to the client machine over the network.
- Running the commands needed to install the NIM client.

Essentially the SPOT is a /usr filesystem just like the one on your NIM master. You can think of it as having multiple “mini-systems” on your NIM master, because each SPOT is its own /usr filesystem. You can upgrade it, add fixes to it, use it to boot a client system....etc. Just like your NIM master’s /usr filesystem, going in there manually and messing around with files can easily corrupt it. The good thing about a SPOT however, is that it is easily rebuilt.
You can also create a SPOT from a NIM mksysb resource. This SPOT however is not as versatile as one created from an lpp_source and can not be upgraded with any fixes and can only be used with the mksysb resource it was created from.

mksysb
This is simply a mksysb image of a machine. The mksysb image can be of the NIM master, a NIM client, or a machine outside of the NIM environment. This resource can be defined in one of two ways.
- From an existing mksysb taken to file that resides on the NIM master.
- Creating a new mksysb image of a currently existing NIM client.
At this time there is no supported way to use a mksysb tape or mksysb on CD/DVD, as an input device to define a mksysb resource in NIM.

bosinst_data
When booting from installation media to install or upgrade a system you boot to what are known as the “BOS Menus” or Base Operating System Installation Menus. Here you select your console, what language to use, what disks to install to.....and many other options. In NIM we can create a “bosinst_data” resource that will answer these questions for us. By doing this we can perform a “non-prompted” installation. So if you have a NIM client in another building, down the road, or half way across the country, you can create this type of NIM resource which will provide the answers to those questions, so once you kick off the install from the NIM master no further interaction is required. The system should (ideally) install and reboot itself afterward.

A mksysb (as discussed above) has a “built in” bosinst.data file. If the option in that file
(PROMPT =) is set to yes, this file really does nothing as the choices you make in the BOS menus will override the options in the file. However, if the mksysb was created to have that option set to no, then we can create a new bosinst_data resource which will trump the one that is part of the mksysb.

image_data
Outside of NIM this file is responsible for knowing how your rootvg is built. It contains information like the partition size of rootvg, the disks belonging to rootvg, all of the filesystems (and their sizes) that belong to rootvg, whether the rootvg is mirrored, and other information. As with the bosinst_data file, a mksysb also has one of these “built in”. If this built in file needs to be altered in any way, we can accomplish this by creating and allocating an image_data resource.